Shadow DOM
acko.net
acko.net
- 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
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.
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.
"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
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.
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.
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.
1: http://facebook.github.io/react/blog/2013/06/05/why-react.ht...
It's in production currently. Documentation's lacking but go check it out if you feel adventurous =).
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.
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'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.
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.
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.
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.
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.
* 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.
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).
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
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.
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.
Perhaps some constraint system, eg: http://gridstylesheets.org/
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.
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.
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.
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!
Self http://www.youtube.com/watch?v=Ox5P7QyL774
Xerox Star User Interface http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=ODZBL80JPqw
Tektronix 4404 Smalltalk http://www.youtube.com/watch?v=8yxCJfayW-8
The Smalltalk-80 Programming System http://www.youtube.com/watch?v=JLPiMl8XUKU
The Final Demonstration of the Xerox 'Star' computer http://www.youtube.com/watch?v=_OwG_rQ_Hqw
Symbolics Hypertext Document http://www.youtube.com/watch?v=7DxYj32cvoE
"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
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
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!
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Preface
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.
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.
http://www.donhopkins.com/drupal/node/69
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.
http://www-2.cs.cmu.edu/~garnet/
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.
https://github.com/mcarlson/rheses
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.
http://blog.osteele.com/posts/2004/03/classes-and-prototypes
http://c2.com/cgi/wiki?InstanceFirstDevelopment
http://lua-users.org/lists/lua-l/2007-10/msg00379.html
http://www.donhopkins.com/drupal/node/124
http://don.fed.wiki.org/view/prototype-based-programming
https://ssl.weepee.org/lps-5.0.x/docs/developers/introductor...
And of course the granddaddy of all constraint based user interface systems is Ivan Sutherland's Sketchpad:
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.
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.
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.
I use a MacBook Air 2012 with Chrome, and couldn't scroll the page. It is not ready for my laptop.
I guess that it's a MacOS problem.
I thought web developers were all for semantic markup.
"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."
Screenshot: http://s30.postimg.org/y8tm1yyc1/website_fail.png
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.
But, if you run with cookies blocked, you'd be used to that.