8 ms·

Shadow DOM

276 points by madisonmay 13y ago

gress 13y ago
In the future, all apps will be built this way.
- deleted 13y ago
  [deleted]
sgdesign 13y ago
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.
- ehsanu1 13y ago
  but I'm still not sure what a better system would look like Perhaps some constraint system, eg: http://gridstylesheets.org/ http://gridstylesheets.org/
  - emn13 13y ago
    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.
    - Someone 13y ago
      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.
      - emn13 13y ago
        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.
- gcv 13y ago
  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.
  - spicyj 13y ago
    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.
- vii 13y ago
  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!
  - ttty 13y ago
    You have qooxdoo that does that.
- pjmlp 13y ago
  Any of the native models developed back at Xerox PARC days.
  - Ygg2 13y ago
    Any links, perhaps?
    - pjmlp 13y ago
      Mainly videos Self http://www.youtube.com/watch?v=Ox5P7QyL774 http://www.youtube.com/watch?v=Ox5P7QyL774 Xerox Star User Interface http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=ODZBL80JPqw http://www.youtube.com/watch?v=ODZBL80JPqw Tektronix 4404 Smalltalk http://www.youtube.com/watch?v=8yxCJfayW-8 http://www.youtube.com/watch?v=8yxCJfayW-8 The Smalltalk-80 Programming System http://www.youtube.com/watch?v=JLPiMl8XUKU http://www.youtube.com/watch?v=JLPiMl8XUKU The Final Demonstration of the Xerox 'Star' computer http://www.youtube.com/watch?v=_OwG_rQ_Hqw http://www.youtube.com/watch?v=_OwG_rQ_Hqw Symbolics Hypertext Document http://www.youtube.com/watch?v=7DxYj32cvoE http://www.youtube.com/watch?v=7DxYj32cvoE
      - Ygg2 13y ago
        Thanks :D
    - SimHacker 13y ago
      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 http://www.chilton-computing.org.uk/inf/literature/books/wm/p004.htm 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.htm 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.
- protomyth 13y ago
  Postscript (and Display Postscript) worked quite well. PDF is also quite nice. We are just pushing HTML way past its original capability.
  - SimHacker 13y ago
    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. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
- SimHacker 13y ago
  I've worked on two user interface systems that used on constraints and data binding for layout and configuration, which worked very well. http://www.donhopkins.com/drupal/node/69 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/ 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. http://www.openlaszlo.org/ http://www.openlaszlo.org/ 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.
nwienert 13y ago
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 http://gridstylesheets.org
- jonahx 13y ago
  What's the browser support like?
  - chc 13y ago
    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.
    - bergie 13y ago
      It should work with all the latest stable browsers on both desktop and mobile. Some ugly issues linger with older IEs though
      - chc 13y ago
        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.
- jevinskie 13y ago
  This is really cool! Thanks for the pointer. I thought flexbox was cool but this has potential too.
- err4nt 13y ago
  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 https://ballr.com/new_design/tables THAT http://staticresource.com/alijn/demo http://staticresource.com/alijn/demo
underwater 13y ago
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.
- just2n 13y ago
  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.
- jawns 13y ago
  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.
underwater 13y ago
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.html http://facebook.github.io/react/blog/2013/06/05/why-react.ht...
- jonahx 13y ago
  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.
- chenglou 13y ago
  You're right! In fact, https://github.com/facebook/react-art 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 =).
  - davedx 13y ago
    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? :)
    - spicyj 13y ago
      (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 https://github.com/sebmarkbage/art drawing library so it shouldn't be too hard (knock on wood!).
shadowmint 13y ago
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.
- visarga 13y ago
  > 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.
  - rjd 13y ago
    2010 macbook pro and I can't scroll the page without serious lag and jumping :/
    - radicalbyte 13y ago
      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.
Kiro 13y ago
I don't understand the inline-block critique in "Thinking with Portals". What exactly is wrong with the Twitter widget?
- TeMPOraL 13y ago
  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."
Kiro 13y ago
> 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.
tech-no-logical 13y ago
I guess the site itself avoids the dom by being non-functional in my latest firefox. well done, I say.
- gavinpc 13y ago
  It comes up essentially blank if you have cookies blocked. But, if you run with cookies blocked, you'd be used to that.
  - tech-no-logical 13y ago
    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.
robmcm 13y ago
Is he leaning towards just doing everything web app related in a canvas or webGL tag, and leave HTML and CSS to websites.
pjmlp 13y ago
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.
3rd3 13y ago
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).
- frik 13y ago
  Adobe is working on bringing the advanced technology to CSS3 by contributing code to Webkit/Blink (Safari, Chrome): http://html.adobe.com/webplatform/ 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-plans-to-dump-adobe-css-tech-to-make-blink-fast-not-rich/ 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 https://news.ycombinator.com/item?id=7243122
frik 13y ago
This website is unreadable in Internet Explorer 11 - animated GIF as fullscreen page background. Screenshot: http://s30.postimg.org/y8tm1yyc1/website_fail.png http://s30.postimg.org/y8tm1yyc1/website_fail.png
- Gigablah 13y ago
  "website_fail" is a bit harsh when you're using Internet Explorer in the first place...
  - frik 13y ago
    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.
- slight 13y ago
  It's web gl.
  - timdorr 13y ago
    Which IE11 supports: http://msdn.microsoft.com/en-us/library/ie/bg182648(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ie/bg182648(v=vs.85)...
mrec 13y ago
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/ http://www.w3.org/TR/shadow-dom/
_pmf_ 13y ago
> This is the first example in the MathML spec. Really. "Invisible times". I thought web developers were all for semantic markup.
darsham 13y ago
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.
fhd2 13y ago
Confusing title. I thought this is about, you know, Shadow DOM (http://www.w3.org/TR/shadow-dom/ http://www.w3.org/TR/shadow-dom/).
- gcb0 13y ago
  conspiracy theory: W3C is creating standards with all the titles of articles criticizing their other standards.
whoisthemachine 13y ago
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.
emn13 13y ago
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.
- 3rd3 13y ago
  > "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.
ben336 13y ago
"In reality, most styles don't actually cascade" If thats the case, you're probably doing something wrong.

Shadow DOM

276 points by madisonmay 13y ago

gress 13y ago

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

deleted 13y ago
[deleted]

sgdesign 13y ago

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.

ehsanu1 13y ago
but I'm still not sure what a better system would look like Perhaps some constraint system, eg: http://gridstylesheets.org/ http://gridstylesheets.org/
- emn13 13y ago
  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.
  - Someone 13y ago
    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.
    - emn13 13y ago
      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.
gcv 13y ago
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.
- spicyj 13y ago
  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.
vii 13y ago
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!
- ttty 13y ago
  You have qooxdoo that does that.
pjmlp 13y ago
Any of the native models developed back at Xerox PARC days.
- Ygg2 13y ago
  Any links, perhaps?
  - pjmlp 13y ago
    Mainly videos Self http://www.youtube.com/watch?v=Ox5P7QyL774 http://www.youtube.com/watch?v=Ox5P7QyL774 Xerox Star User Interface http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=ODZBL80JPqw http://www.youtube.com/watch?v=ODZBL80JPqw Tektronix 4404 Smalltalk http://www.youtube.com/watch?v=8yxCJfayW-8 http://www.youtube.com/watch?v=8yxCJfayW-8 The Smalltalk-80 Programming System http://www.youtube.com/watch?v=JLPiMl8XUKU http://www.youtube.com/watch?v=JLPiMl8XUKU The Final Demonstration of the Xerox 'Star' computer http://www.youtube.com/watch?v=_OwG_rQ_Hqw http://www.youtube.com/watch?v=_OwG_rQ_Hqw Symbolics Hypertext Document http://www.youtube.com/watch?v=7DxYj32cvoE http://www.youtube.com/watch?v=7DxYj32cvoE
    - Ygg2 13y ago
      Thanks :D
  - SimHacker 13y ago
    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 http://www.chilton-computing.org.uk/inf/literature/books/wm/p004.htm 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.htm 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.
protomyth 13y ago
Postscript (and Display Postscript) worked quite well. PDF is also quite nice. We are just pushing HTML way past its original capability.
- SimHacker 13y ago
  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. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
SimHacker 13y ago
I've worked on two user interface systems that used on constraints and data binding for layout and configuration, which worked very well. http://www.donhopkins.com/drupal/node/69 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/ 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. http://www.openlaszlo.org/ http://www.openlaszlo.org/ 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.

nwienert 13y ago

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 http://gridstylesheets.org

jonahx 13y ago
What's the browser support like?
- chc 13y ago
  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.
  - bergie 13y ago
    It should work with all the latest stable browsers on both desktop and mobile. Some ugly issues linger with older IEs though
    - chc 13y ago
      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.
jevinskie 13y ago
This is really cool! Thanks for the pointer. I thought flexbox was cool but this has potential too.
err4nt 13y ago
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 https://ballr.com/new_design/tables THAT http://staticresource.com/alijn/demo http://staticresource.com/alijn/demo

underwater 13y ago

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.

just2n 13y ago
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.
jawns 13y ago
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.

underwater 13y ago

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.html http://facebook.github.io/react/blog/2013/06/05/why-react.ht...

jonahx 13y ago
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.
chenglou 13y ago
You're right! In fact, https://github.com/facebook/react-art 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 =).
- davedx 13y ago
  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? :)
  - spicyj 13y ago
    (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 https://github.com/sebmarkbage/art drawing library so it shouldn't be too hard (knock on wood!).

shadowmint 13y ago

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.

visarga 13y ago
> 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.
- rjd 13y ago
  2010 macbook pro and I can't scroll the page without serious lag and jumping :/
  - radicalbyte 13y ago
    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.

Kiro 13y ago

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

TeMPOraL 13y ago
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."

Kiro 13y ago

> 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.

tech-no-logical 13y ago

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

gavinpc 13y ago
It comes up essentially blank if you have cookies blocked. But, if you run with cookies blocked, you'd be used to that.
- tech-no-logical 13y ago
  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.

robmcm 13y ago

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

pjmlp 13y ago

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.

3rd3 13y ago

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).

frik 13y ago
Adobe is working on bringing the advanced technology to CSS3 by contributing code to Webkit/Blink (Safari, Chrome): http://html.adobe.com/webplatform/ 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-plans-to-dump-adobe-css-tech-to-make-blink-fast-not-rich/ 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 https://news.ycombinator.com/item?id=7243122

frik 13y ago

This website is unreadable in Internet Explorer 11 - animated GIF as fullscreen page background. Screenshot: http://s30.postimg.org/y8tm1yyc1/website_fail.png http://s30.postimg.org/y8tm1yyc1/website_fail.png

Gigablah 13y ago
"website_fail" is a bit harsh when you're using Internet Explorer in the first place...
- frik 13y ago
  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.
slight 13y ago
It's web gl.
- timdorr 13y ago
  Which IE11 supports: http://msdn.microsoft.com/en-us/library/ie/bg182648(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ie/bg182648(v=vs.85)...

mrec 13y ago

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/ http://www.w3.org/TR/shadow-dom/

_pmf_ 13y ago

> This is the first example in the MathML spec. Really. "Invisible times". I thought web developers were all for semantic markup.

darsham 13y ago

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.

fhd2 13y ago

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

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

whoisthemachine 13y ago

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.

emn13 13y ago

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.

3rd3 13y ago
> "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.

ben336 13y ago

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