Hacker News new | past | comments | ask | show | jobs | submit login
Shadow DOM (acko.net)
276 points by madisonmay on Apr 10, 2014 | hide | past | web | favorite | 80 comments

Confusing title. I thought this is about, you know, Shadow DOM (http://www.w3.org/TR/shadow-dom/).

conspiracy theory: W3C is creating standards with all the titles of articles criticizing their other standards.

At least for the layout issues, I believe with Grid Style Sheets[0] we have a solution. Use it for structure, CSS for "texture", React for UI and you have yourself a better web stack, today.

[0] http://gridstylesheets.org

I don't think this is a solution. I've been thinking about this for the past couple of days, after watching some Alan Kay talks and revisiting some of Bret Victor's articles.

I think the fundamental problem here is about structured semantic content and its presentation. When those two domains meet, it gets messy very, very quickly. At a certain point it gets hard to tell the two areas apart, especially when it comes to interactive applications.

Hardcore HTML advocates such as Zeldman seem to have the worldview of 19th century librarians (no offense intended). I find it outright irritating that a board could define some semantic elements (header, article, section, etc.) and expect the world to be happy with this limited array for expressing 'meaning' and 'intent'. And again, it's often hard to divorce the meaning of content from its actual presentation.

Yes, the problem is that CSS's structural presentation is ultimately tied to the DOM. Funny you bring this up, as I commented earlier here:

"GSS was created b/c our company's main product, the Grid (still in stealth mode), is doing some radical things with design of newsfeeds, we need layout to be completely decoupled from the DOM. A fairly developed Float / Flexbox-based layout becomes as much of a CSS affair as an HTML one; changing layouts requires a whole new set of div wrappers. CSS was designed to separate presentation from content, and that ideal has unforeseen manifold benefit when actually realized."

Here's an example, http://gridstylesheets.org/demos/apple/ notice the button & panel layout as you change the screen size. Now, view-page-source & notice how every element is a direct child of <body>, no parent-child nesting... Here's a recording of talk I recently gave at FluentConf that delves deeper into this: https://vimeo.com/91393694

You say you don't think this is a solution, but you don't say why.

If HTML's limited expressiveness is your gripe, I'd say React has already alleviated that for us. Components can be named very expressively, and your tree structure ends up reading very well. Really, HTML becomes the compile-to language.

Web components could step in and help this further, and there's no reason they couldn't be used within React to make even the output HTML more semantic.

In my humble opinion the best solution for layouts is CSS is the CSS Grid Layout Module[1]. Both powerful and easy to grasp. Sadly, it works only in IE (from version number 10, I believe)[2], but others[3][4][5] are getting there. And, of course, there's a polyfill[6].

1) http://www.w3.org/TR/css3-grid-layout/ - specification;

2) http://ie.microsoft.com/testdrive/graphics/hands-on-css3/han... - examples;

3) http://updates.html5rocks.com/2014/03/Get-on-the-CSS-Grid - Chrome/Opera/Blink;

4) https://bugs.webkit.org/show_bug.cgi?id=60731 - Safari/Webkit;

5) https://bugzilla.mozilla.org/show_bug.cgi?id=616605 - Firefox;

6) https://github.com/codler/Grid-Layout-Polyfill - JS polyfill.

I specialize in building responsive frontends and I've hit the limit of what CSS can offer me. I've learning how to use JavaScript to add:

- element-width media queries, instead of browser-width

- auto-centering two objects on the page

- and hopefully I can get it to watch a container and tell you how many children it has, or if it's a text element how many chargers it contains.

Imagine being able to switch responsive CSS styles for an element based on how wide IT was, instead of how wide the screen is. The problem is that some pages have sidebars, some don't but use the same widgets. A widget may be 'cramped' by other objects at a wide browser size, then snap down to a single column view and actually be wider on the page when the browser was narrower than before. This looks awkward and element-size-based styles would prevent that and allow TRUE atomic design.

Imagine being able to align items to other items on the page or to a grid that is superimposed over the browser window. Useful for modals and alerts and all sorts of 'off layout' content that you need to align. Much better than trying to use CSS to centre things because you can centre an object whose width or height you don't know or can allow to change after the page has loaded.

Imagine being able to set a different style on an input that had 21 characters using CSS because you knew how many characters were in the input field and could style for different character amounts? What about a playlist that has three pre-made sizes for list items that keeps reducing the size according to pre-made styles to make sure they all fit as you add more list items.

The problem isn't so much that CSS rules fall short of being powerful, it's not the rules we need to super-charge, it's knowing WHEN to apply the rules and using JavaScript to add real time feedback from the rendered page is the best way to do that right now. I'm already using custom data attributes and regular expressions in my CSS selectors and I need more logic to power them. I need to be able to measure objects and respond to them as data changes on the site with user interaction.

Basically, long story short, I want to mix THIS with THAT in the near future

THIS https://ballr.com/new_design/tables THAT http://staticresource.com/alijn/demo

Element queries are a great idea. It's a shame the W3C won't touch them with a 10-ft pole.

I think gridstylesheets aren't that brilliant, at least not as a general solution. They don't deal well with ambiguity or over-specific (impossible) solutions, leading to fragile layouts that have odd behavior in corner cases.

Furthermore, there's quite a few basic constraints that CSS implies that you'd need to reimplement in GSS (if we can call it that) all over the place to get a comparable layout engine, namely normal flow, margins, wrapping, justifying...

All in all, I'm not holding my breath for this to become a huge success.

Author of GSS here. The brilliance lies with guys like Badros (Cassowary), Ken Ferry (Apple Auto Layout), Alex Russell (Cassowary.js), etc.

GSS was created b/c our company's main product, the Grid (still in stealth mode), is doing some radical things with design of newsfeeds, we need layout to be completely decoupled from the DOM. A fairly developed Float / Flexbox-based layout becomes as much of a CSS affair as an HTML one; changing layouts requires a whole new set of div wrappers. CSS was designed to separate presentation from content, and that ideal has unforeseen manifold benefit when actually realized.

Cassowary powered constraints allow for layouts not possible with a CSS unable to resolve cyclic dependencies in layout arithmetic. Of course, you could easily shoot yourself in the foot & define fragile, ambiguous and/or impossible layouts. But, w/ great power comes great... I always prefer expressive freedom over easy-to-comprehend limitations.

GSS is very new - much is needed like better debugging, implementing floats, etc.. Constraint-based layouts isn't a silver bullet, it takes practice & thinking more like a programmer. Fortunately, Apple Auto Layout demonstrates the viability of all this craziness.

What's the browser support like?

Well, no browsers support it natively. It's a Cassowary-based layout engine implemented in JavaScript. AFAIK it works correctly in the last few versions of Chrome and that's pretty much it. It's not much more than a proof-of-concept, really.

It should work with all the latest stable browsers on both desktop and mobile. Some ugly issues linger with older IEs though

My apologies. I looked at it a few weeks ago and that appeared to be the case then. Glad you were here with more recent information.

This is really cool! Thanks for the pointer. I thought flexbox was cool but this has potential too.

I'm a bit confused by the potshots taken at React. React is a library for building components. The fact those components render down to DOM nodes is incidental. In fact the documentation[1] hints at other possibilities, like rendering to canvas elements or native iOS views.

1: http://facebook.github.io/react/blog/2013/06/05/why-react.ht...

I was unclear, but as I understood it he was taking a shot at the whole html/css situation we're in that makes React, or anything like it, necessary.

You're right! In fact, https://github.com/facebook/react-art is a React library we developed at Facebook for rendering graphics to Canvas, SVG, or VML, depending on what's fastest and what the browser supports.

It's in production currently. Documentation's lacking but go check it out if you feel adventurous =).

I work in digital TV, and we've been experimenting with using WebGL to build our interfaces lately as rendering the DOM on the GPU is so messy and complicated. Is there any prospect of a WebGL renderer for React? If not, how difficult would such a thing be to build by an eager third party? :)

(I work on React.) I don't know of anyone who's put work into a WebGL renderer, but it should be possible. There are a few pieces of React that still assume that you're rendering to the DOM but you can see that the react-art source is only around 600 lines for bindings to the underlying https://github.com/sebmarkbage/art drawing library so it shouldn't be too hard (knock on wood!).

Unless I'm missing something the problem with canvas based shadow dom widgets is there is no per element resize event so if the element gets resized there's no way for the element to know it needs to redraw its content. The only resize event in the browser is on window so sizing a column for example or having an element's size change based on adding or removing other elements does not generate any events the shadow dom element would have access to

If you use any renderer outside of the DOM then you need to implement your own layout engine. It means that you've got to figure out for each node that you output its left, top, width, height. CSS has its flaws but makes 95% of the use cases really easy to work with compared to any ofher mainstream UI abstraction.

As a simple example though, assume you wanted to make a Shadow DOM widget to show a visual representation of an audio sample, or any other kind of detailed graph. Something you arguably don't want to build a giant SVG tree for. Those seem like great things to do with shadow dom widgets... but ... they seem S.O.L without a per element resize event.

I suppose that's being a little over the top. As long as you make them a fixed size or manually call some 'redraw' function when your app notices they've been resized then you're fine. It's just part of the point of Shadow DOM is you're not suppose to have to do that. They should "just work" just like normal HTML elements and size and redraw themselves. It would be nice if there was a way to do that for more interesting canvas based widgets.

You might be interested in this then (Famo.us): https://news.ycombinator.com/item?id=7558261

We've looked at Famo.us too. In fact I've benchmarked the famo.us approach on our hardware, unfortunately for what we're doing CSS transitions appear to be marginally smoother.

You could use PIXI.js

Not dissing React, but the Shadow DOM is a leaky abstraction that sometimes needs to be violated (by accessing the real DOM directly) to get things like focus right. More info here: http://facebook.github.io/react/docs/working-with-the-browse...

You're saying "but the Virtual DOM is a leaky abstraction"?

There's some good points in here, but they are hidden amongst the rambling text. This could be a much stronger call to action if it weren't also a laundry list of the authors pet peeves.

Edit: the complaints about needlessly cascading styles and mixed styles defined by properties that are "only meaningful in some combinations" really resonate with me. I'd love to see him explore this in more depth.

I agree with most of the points, as needless complexity and especially complexity to "add simplicity" (as this seems to be the justification). I believe it's generally a side effect of backwards compatibility -- we'd rather add customization via complexity rather than breaking something that's fundamentally not working into simpler, saner parts. The former doesn't scale with time. Something has to give eventually.

I'm a little confused at how he praises Angular and React while simultaneously complaining about the addition of complexity in HTML and CSS to support misgivings. That's a good description of what both of those libraries are currently doing.

I can understand looking on component-oriented development or intelligent data binding here as "better" if the entire underlying system is totally replaced by these. Unfortunately you can't get away from the complexity below them even in the simplest of real world applications, nor should you (a fact Angular sort of embraces, except that you shouldn't be modifying the DOM). It exists and is therefore relevant if need to do things in the browser. The ultimate outcome of total DOM abstraction is something like ExtJS which is just fundamentally broken and unusable. Something is broken when the thing that was supposed to make you productive constructs walls for your protection that you must break through or work around just to do basic things.

I'm curious in general about the author's interest in Angular. It's become so much more complex than that little library Miško was showing off way back before it became big. There's so much magic going on these days that it'd be a nontrivial task to master using it.

I got the same feeling while reading this. Even if all of the author's pet peeves were warranted, and many of them seem to be, the rambling, unorganized style of writing makes the points seem less credible.

Maybe it was written that way on purpose, for some kind of effect. Or maybe (I'm guilty of this) it's just a blog, not an essay, and the writer didn't particularly feel like putting in the effort to edit.

But I think it would have been much stronger with some structure to the complains, so that the reader knows what he's getting into when he begins reading, and knows what the overarching point is, without having to piece it together himself.

The authors complaints - essentially that HTML+CSS are messy and unhandy - resonate with me. Of course, it's not surprising these things are crufty - html is ancient, and clearly wasn't designed for today's world; and the same holds for CSS. But just because the author mentions something that's true doesn't mean his conclusions make sense. His solutions sound good, but they're really superficial and hide mistakes at least as bad as those html+css make today.

There are two fundamental ways to improve the dom layout model's cruft: By cleaning up weird legacy issues, and by fundamentally changing the way it works (i.e. introducing new layout models, or splitting styling from layout etc.)

I think it's important to realize that removing cruft is virtually impossible. The cleanliness we seek to simplify our lives in making new things simply isn't as valuable as support for old things. Legacy matters; it's unhandy, but it's also valuable.

So let's make the realistic assumption that the DOM of today isn't going away. You can't clean it up; you can only add things that work more easiliy, and perhaps discourage old, confusing behavior. That means thinking about and settling on what this new behavior should be.

The author's idea of splitting layout from styling simply won't work the way he expects it to. He suggests styling text nodes i.e. via `table text` and not have typography related styles on tables themselves. Sounds neat, but this won't work with today's CSS inheritance rules. If both `table text` and `bold text` were to match, css chooses the more specific (disambiguating by css order) rule. That's really not what you wanted to have happen though - just because bold was defined first in css doesn't mean it's less important. Here, we want specificy in order of DOM ancestry, not selector specificity. In essence, CSS already does the split he imagines - most typography related properties inherit, others generally do not.

I'm not convinced that the OP's article really has anything insight worth mentioning. Sure, there's lots of legacy, but clearly we can't just dump that. Other improvements are possibly, but he doesn't make a clear case for any specific, clearly better alternative.

> "I think it's important to realize that removing cruft is virtually impossible."

With a browser from 1995 probably 95% of the popular websites are not usable. Truth is that backwards compatibility mostly reaches only a couple of revisions into the past as it’s the case with the web standards. And given how easy it is nowerdays to update a system, I wonder why it is not considered to make a clean cut and introduce a modern standard. The standards will simply co-exist for a couple of years until the new standard reaches a critical usage share.

The issue isn't whether old browsers can display new content, it's whether new browsers can display old content (or even old content mixed into new content).

If a new standard were to replace the old one, it would mean losing access to use swathes of the internet. Just look at how hard comparatively trivial upgrades of IPv6 or HTTP v2 are - and there you merely need to deal with ultimately replaceable machines - upgrading content formats just isn't easy.

Sure, as a webdev it's nice to focus on the shiny new stuff, but I'm under no illusions that the old stuff is going away any time soon.

Couldn't one simply leave a DOM renderer or converter in web browsers?

Sure. That's basically the extend, not replace strategy. Then you can choose various ways to extend.

* You could pick a completely different approach, and define interop points. This tends to have a steep learning curve. E.g. python interops with C very well, yet most people nevertheless avoid interop.

* You could define the old system in terms of the new system or vice versa. That way, you eventually have clear path to use only one system completely. However, it also means you need to at least support all the various crufty bits you may not otherwise care about. It's also not easy to learn.

* You could just extend the old system. You don't get to clean things up by hiding them behind interop or a layer of translation, but at least the learning curve isn't so bad - you only touch what you want.

That last bit is the basically the strategy that wins. Adding a new system is just such a pain unless it entire replaces the old system (which is almost impossible in practice if only for reasons of momentum), that it's really hard to go half way. Also, don't forget that "mere" interop is far from trivial since it's not just CSS, but also javascript's interaction with DOM+CSS that you'd need to emulate/interop with.

So that leaves us with things like flexbox: new techniques, but integrated into what we have rather than side-by-side with complex interop.

We need the possibility of strict separation of content and presentation and a powerful layout system. Something that removes all the clutter and mind juggling from the current process of developing websites and something that allows for robust wysiwyg editors (like Adobe InDesign).

All we want is putting text, shapes and pictures at certain dynamic positions on a screen. That is why I would propose a layout system that is based on positioning guides (straight or curved guide lines or shapes) rather than a box model. It would work like this: Given a set of initial guides which describe the screen shape one can define new guides which depend on the position of other guides. To define a vertical line at the center of the screen one would write: (defgd my-guide (between screen.left screen.right) (h-pos 50%)). Then one could place an object at a position along that line: (defobj my-object (anchor center) (guide my-guide) (pos (/ (- screen.bottom screen.top) 2)) (content "Hello" (class bold "World!")) (class headline1) (wrap-at screen.left screen.right) (padding 10px)). Instead of spelling out a content string one could, of course, refer to a variable which is stored in a separate resource. Furthermore, it would be helpful to have something like guide generators which can produce grids or arbitrary other shapes based on a given function (e.g. for tables and positions of other repetitive or self similar page elements).

Adobe is working on bringing the advanced technology to CSS3 by contributing code to Webkit/Blink (Safari, Chrome): http://html.adobe.com/webplatform/

Recently, Google Chrome dev team hinders the development by announcing the focus solely on "mobile improvements" for 2014 (don't apply contributed patches, removing already integrated CSS3 features)! That's a big shame and a farce (prevent proper competition to Google Docs?). http://arstechnica.com/information-technology/2014/01/google...

Both Apple and Microsoft already ship CSS3 Regions in their current browsers. Google recently removed it from Chrome/Blink (their recent Webkit fork).

Btw. Apple removed Shadow DOM as a reaction to this, the commit message is funny: https://news.ycombinator.com/item?id=7243122

And this is why web sucks at UI development and I enjoy doing native UI instead, every time I am allowed to.

It should never have gotten further than a document format.

Right now it sucks compared to where we could have been with proper UI layout markup and not the actual Frankenstein model of HTML/CSS/JavaScript, write once debug everywhere.

Some very convincing points about the flaws of CSS, but I'm still not sure what a better system would look like, and how realistic implementing that system would be.

Maybe the solution will come from new preprocessors (or existing ones like Sass) which will make it possible to write CSS in a completely different way without requiring browser vendors to adapt. Kind of like what CoffeeScript is to JavaScript.

The TeX boxes-and-glue model works well. It differs from the brain-damaged CSS model by allowing you to describe what happens between boxes (the glue). I don't see why it can't be adapted to the web browser.

I think the upcoming CSS flex box standard works similarly to TeX's boxes and glue in a lot of ways. I haven't dug in too deep though.

but I'm still not sure what a better system would look like

Perhaps some constraint system, eg: http://gridstylesheets.org/

Maybe, but preferably a system whereby impossible layouts are detected and reported, not "fixed" arbitrarily, and similarly, where ambiguous layouts are detected rather than implementation-dependant.

Also, I'd really like a system where a little more thought was given to practical layout issues, and GSS is extremely limited - even simple things like adjacency and containment needs to be manually specified in terms of positioning.

Layouts can be possible/impossible depending on screen resolution, available fonts, users default text size preference, zooming, etc.

So, reporting (some) impossible layouts can only be done at runtime. Telling the user "you cannot see this because some constraints cannot be made on this system with the current settings" may not be what users want.

Yeah, there's no black and white answer to this - but GSS really has a lot of those ambiguities. They're called constraints, but they're more like optimization targets, and while in simple cases it's easy to see which constraint gets violated first, in complex cases it's a little too much like spagetti code: theoretically deterministic, but too much to handle.

CSS also has "constraints" and they're also sometimes violated, but most constraints are never violated (e.g. normal flow blocks are always sequentially after each other even if they don't fit. Those that are violated are violated in consistent, predictable fashion: e.g. though a container vertically grows to fit its contents it may stop growing for various reasons, even if its children don't fit.

In GSS? Since every layout reinvents the wheel for the basics, all bets are off. Since the whole point is that there can be complex, multilevel interactions between the components it's not always clear which "constraint" is violated first, nor even that it may be necessary to violate those constraints.

Basically: I think GSS is too hard to reason about, making it admittedly more flexible, but too error prone compared to CSS. Furthermore, because it doesn't integrate with lower-level concepts like actual content, it's sometimes even less powerful that CSS - GSS can't for instance emulate CSS tables or even simple paragraphs that are no longer than necessary; for that (AFAICT) it delegates to existing layouts.

Then there's the fact that CSS breaks cycles quite rigorously. Usually it't not even possible to define them; and where it is the spec is fairly clear what needs to give. In GSS, I can't see any protection - you won't even really notice you've potentially got a problem until constraints do weird things for hard to predict reasons.

So, I think for most layouts GSS is wordier and more brittle than CSS, and where that's not the case I'd rather have a more robust, predictable system. In essence: the stronger, more flexible, closer to turing-complete a language, the worse. Weak is good. Limited is fast, predictable, optimizable, good for tooling.

GSS goes too far.

It's really sad that this isn't clear.

CSS was intended to be simpler than DSSSL but ended up being more complicated, harder(?) to implement and immensely less powerful. One thing that could work well would be to implement layout in JavaScript, i.e. making some layout properties like x,y,z co-ordinates available to JS and then letting it lay out the text boxes in a defined way with extensible hooks.

At least that would mean web developers would only have to learn one language, rather than two!

You have qooxdoo that does that.

Any of the native models developed back at Xerox PARC days.

Any links, perhaps?

Thanks :D

Warren Teitelman described a lot of the great work done at Xerox PARC in "Ten Years of Window Systems - A Retrospective View" in the book "Methodology of Window Management," Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985.

"Both James Gosling and I currently work for SUN and the reason for my wanting to talk before he does is that I am talking about the past and James is talking about the future. I have been connected with eight window systems as a user, or as an implementer, or by being in the same building! I have been asked to give a historical view and my talk looks at window systems over ten years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems. The talk focuses on key ideas, where they came from, how they are connected and how they evolved." -Warren Teitelman


It's a wonderful book with many interesting articles and working group discussions about window management and user interface architecture, that gives great perspective on a wide variety of approaches. I'm glad that it's finally available online!



This volume is a record of the Workshop on Window Management held at the Rutherford Appleton Laboratory's Cosener's House between 29 April and 1 May 1985. The main impetus for the Workshop came from the Alvey Programme's Man-Machine Interface Director who was concerned at the lack of a formal definition of window management and the lack of focus for research activities in this area. Window Management per se is not the complete problem in understanding interaction. However, the appearance of bitmap displays from a variety of vendors enabling an operator to work simultaneously with a number of applications on a single display has focussed attention on what the overall architecture for such a system should be and also on what the interfaces to both the application and operator should be.

The format of the Workshop was to spend the first day with presentations from a number of invited speakers. The aim was to get the participants aware of the current state of the art and to highlight the main outstanding issues. The second day consisted of the Workshop participants splitting into three groups and discussing specific issues in depth. Plenary sessions helped to keep the individual groups working on similar lines. The third day concentrated on the individual groups presenting their results and interacting with the other groups to identify main areas of consensus and also a framework for future work.

Part I of this volume gives the background to the Workshop, its scope and goals.

Part II consists of position papers, the invited presentations and an edited version of the discussion following each. The set of speakers covers a significant part of the expertise currently available. This section provided a useful summary of the state-of-the-art for the Workshop and highlighted the issues.

Each participant was asked to identify his major areas of concern prior to the Workshop. These have been condensed and integrated to give a view of the problems prior to the Workshop. Lists of issues were also generated from these contributions and the invited presentations. These formed an initial basis for the Working Group discussions reported in the next part.

Part III concentrates on the work carried out in the Working Groups with particular attention focussed on the Working Group conclusions and questions requiring further study.

Part IV presents the main conclusions of the Workshop and includes an Open List of questions requiring further study. This list indicates the current limits to the understanding achieved at the Workshop. As always, more questions were raised than conclusions reached. This part also includes a bibliography of the area and a glossary of terms used in the book.

The discussion sessions have been heavily edited. The Editors hope that no remarks have been attributed to individuals incorrectly. Copies of the typescript were sent to all participants for comment prior to publication.

The contents of this volume should not be considered as definitive conclusions but as a contribution to the study of methodology in human-computer interaction particularly with respect to single user workstations.

This book should be of interest to anybody with an interest in graphics and interaction in general. Many of the issues discussed have a more general applicability than the particular area under discussion. However, the primary audience is those directly involved in the area of the human factors and design of systems on high-powered single user workstations.

Postscript (and Display Postscript) worked quite well. PDF is also quite nice. We are just pushing HTML way past its original capability.

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

used PostScript code instead of JavaScript for programming.

used PostScript graphics instead of DHTML and CSS for rendering.

used PostScript data instead of XML and JSON for data representation.


I've worked on two user interface systems that used on constraints and data binding for layout and configuration, which worked very well.


Constraints and Prototypes in Garnet and Laszlo

Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.


One thing I like about Brad Meyers is that he's a strong programmer, as well as an excellent researcher, so he had a first-hand understanding of the real-world issues involved in programming languages and user interface architecture, unlike many academics who talk a lot of theory but never get their hands dirty. Brad Meyers understands where the rubber hits the road, and how important it is to have good tires.

At the time I worked on it, Garnet didn't have pretty graphics like Flash, but the underlying programming system had some advanced features that are sorely lacking from most modern user interface development environments.

Laszlo is an modern open source GUI programming system, with many of Garnet's advanced "natural programming" features like prototypes and constraints. Laszlo currently uses Flash as its virtual machine, but it's a much higher level way to program dynamic interactive web based applications, without using the proprietary Flash authoring tool.


Garnet had a true prototype based OOP system (somewhat like Self), which is great for gui programming, because guis have so many objects that look and behave like each other except for a few little customizations (like the layout, graphical style, data source and call-back behavior).

Garnet also had an automatic constraint system, which enabled you to simply define any attribute as a formula that depend on other attributes, without needing to worry about how and when the values were calculated. Garnet's constraint system automatically figured out the dependences of each formula, and automatically and efficiently recalculated and cached any values that needed to be updated, but only when necessary.

With constraints, you can make a button inside a window, and define its left edge to be ((parent.width - self.width) / 2), and it will automatically remain horizontally centered in the window from then on, without you (the programmer) having to worry about what to do when the parent window's size changes.

Without constraints, you have to manually write all the code that changes the button position whenever the window size changes, which results in code scattered all over the place in different classes and handlers and intermediate objects.

Constraints are much easier to use and more general purpose than resize handlers, springs and struts, complex MVC updating schemes, and other Rube Goldberg devices.

Constraints are especially useful for user interface programming, because they save you from having to write lots of annoying boiler plate and error prone code for handling updates (registering, chasing down dependencies, detecting changes, notifying updates, all happens automatically).

Constraints make GUI programming much easier, but they're also useful anywhere in your program where one value is defined in terms of other values that might change at any time.

Once you've tasted a programming language with constraints, you will not want to go back. Programming without constraints is like writing in machine language: error prone, low level, tedious, inefficient and mind numbing.

Constraints are like structured programming for variables: In the same way that it's better to use loops and conditionals instead of gotos, it's also better to use declarative programming that says what you mean, instead of imperative peeks and pokes and side effects.

Constraints let you write easy to read code, and concentrate on the interesting high level stuff that matters. You can go back later and change the layout of a complex GUI, without rewriting lots of fragile layout and event hanling code. Look at any MFC program to see how bad it can get without constraints.

Constraints are natural and close to the way you think, because they let you declare a variable and the formula that defines its value in one place, instead of scattered all around the code. They off-load the tedious task of tracking down and maintaining all the dependencies from the programmer to the computer, which is much better at that kind of stuff.

Garbage collection is like constraints: the computer can do a much better job than the human at performing the task perfectly, so spending some cpu time on automatic garbage collection and constraint maintenance is well worth the significant increase in programmer productivity and software reliability.

Garnet had a prototype based object system. It was implemented in Lisp with a system called KR (Knowledge Representation, classic AI "frames" with slots and inheritance). KR was extended with an automatic constraint system that parsed the formula expressions (written in Lisp macros), figured out the dependences, wired up and maintained the dependency graph.

An expression like "((parent.width - self.width) / 2)" would depend on self's width slot, self's parent slot, and parent's width slot. If any of them changed, then that formula would be automatically invalidated, and only recalculated on demand when it (or something that depended on it) is required.

The cool thing was that you can make a prototype object, like a button, which has sub-structures like a label, border, drop shadow, etc. The sub-structures can be constrained to the button's dimensions, the label is centered in the border, and the drop shadow floats below and to the right, so the button's layout is automatically updated when it moves or resizes.

The text color and border fill can depend on the button's "hilight" variable, so they automatically switch between bright and dark when you press the button (the input handler just toggles the "highlight" variable, and the graphics that depend on it are automatically updated).

Now that you've composed and constrained a button to look and feel how you want, you can use it as a prototype to make other similar customizable buttons instances. Each instance can itself override the prototype's graphical properties, label text, action, etc.

Instances of a prototype all magically inherit (instances of) the sub-structure of the prototype! It all just works the way you'd expect it to (with a lot of plumbing going on automatically behind the scenes). There's no need to make a separate class for each different style of button or action - prototypes let you customize any instance itself!

Like Garnet, Laszlo is an advanced open source user interface development environment that supports prototype based OOP with constraints.

Unlike Garnet, Laszlo deeply integrates recent trendy technologies like XML, JavaScript, Flash, data binding, networking, XML/RPC, SOAP, ReST, Java and Tomcat.

Laszlo has a class/prototype based object system, and it (currently) uses the JavaScript runtime in Flash as its virtual machine. But it's more than just another way to program Flash.

Unlike raw Flash, The Laszlo language is easy to learn and Laszlo programs are easy to read and write thanks to prototypes, constraints, declarative programming, and instance-first development.

I wrote that article about nine years ago, and OpenLaszlo never took over the world the way I hoped it would, but Max Carlson, one of its chief architects, is working on reimplementing the good parts in JavaScript/CoffeeScript, without all the baggage. It's a work in progress and not very well documented, but it embodies some wonderful ideas!


Oliver Steele, another of OpenLaszlo's architects, has written some great stuff about "Instance First Development", a declarative, prototype and constraint based approach to programming modular components that OpenLaszlo supports.







And of course the granddaddy of all constraint based user interface systems is Ivan Sutherland's Sketchpad:


I found the title a little unfortunate since "Shadow DOM" already means something specific in this space, namely http://www.w3.org/TR/shadow-dom/

> And which is easier: defining a hairy new category of pseudo-elements like :first-letter and :first-line… or just telling people to wrap their first letter in a span if they really want to make it giant?

Maybe I misunderstand but I definitely prefer :first-letter than having to wrap it dynamically. I don't see why anyone would prefer the latter.

I don't really agree with this critique. HTML defines the structure and content, CSS defines the style and appearance, and JS defines the behavior. The model is clear and even somewhat elegant.

Yes there is overlap, that is inevitable. Yes, you can always make it ugly and there are old vestigial features that you probably shouldn't use. These standards have a long, complicated history, but the end result is surprisingly consistent.

The different layouts in CSS (inline, block...) are powerful tools once you get used to them. They solve the problem of reconciling different layout models that are useful in different situations. And that's one hell of a problem that won't go away, even in alternate utopias. In fact most of the complaints here are just about practical solutions to inevitable problems.

I do both native development for windows and web development, and believe me, I'll take HTML/CSS/JS any day. IMO, the box model is extremely conducive to pushing you in the right direction for a clean layout, and maybe CSS is unwieldy because you shouldn't be using that many styles; i.e. it was meant to make coming up with a unique style for each button on your site a burden. I did web development as a kid using tables back when that was the way good looking sites were made, and believe me, this model is better, not because of what it enables, but because of what it inhibits.

Entirely valid complaints.

The question is if CSS+HTML+JS can make the leap to convincing near-native-UI somehow (I'm also dubious, but it's possible; something built using canvas and webgl in a manner very much like what pixi.js is currently doing; with all the 'responsiveness' of a native application, and barely using html/css at all seems possible).

...or if people will just continue the current trend towards native applications to replace generic multi-platform websites.

> The question is if CSS+HTML+JS can make the leap to convincing near-native-UI somehow

I use a MacBook Air 2012 with Chrome, and couldn't scroll the page. It is not ready for my laptop.

2010 macbook pro and I can't scroll the page without serious lag and jumping :/

My $2000 late-2013 rMBP suffers from the same problem. My 6 year old $800 Dell 1920x1200 laptop doesn't.

I guess that it's a MacOS problem.

> This is the first example in the MathML spec. Really. "Invisible times".

I thought web developers were all for semantic markup.

I don't understand the inline-block critique in "Thinking with Portals". What exactly is wrong with the Twitter widget?

There's probably nothing wrong with wiget per se, it just shouldn't have its markup spliced in the middle of the text.

"Don't shove your entire widget right between the words. You'd inherit styles, match new selectors and bubble all your events up through the text just for the sake of binding a pair of (x, y) coordinates."

"In reality, most styles don't actually cascade" If thats the case, you're probably doing something wrong.

This website is unreadable in Internet Explorer 11 - animated GIF as fullscreen page background.

Screenshot: http://s30.postimg.org/y8tm1yyc1/website_fail.png

"website_fail" is a bit harsh when you're using Internet Explorer in the first place...

It was not my intend to leak my local image filename of the screenshot. I just usd a random free image sharing website, usually they expose the file with a hash-key instead of the real filename.

I informed the news author of the website about this issue on a similar HN posting some months ago. Though, he hasn't fixed that fullscreen animation yet.

It's web gl.

Is he leaning towards just doing everything web app related in a canvas or webGL tag, and leave HTML and CSS to websites.

In the future, all apps will be built this way.

I guess the site itself avoids the dom by being non-functional in my latest firefox. well done, I say.

It comes up essentially blank if you have cookies blocked.

But, if you run with cookies blocked, you'd be used to that.

I don't block cookies by default and acko.net doesn't offer me any. it does however cause firefox to notice me of an insecure javascript operation.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact