

Shadow DOM - madisonmay
http://acko.net/blog/shadow-dom/#hackernews

======
fhd2
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
conspiracy theory: W3C is creating standards with all the titles of articles
criticizing their other standards.

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

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

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

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

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

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

Here's an example,
[http://gridstylesheets.org/demos/apple/](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](https://vimeo.com/91393694)

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

1: [http://facebook.github.io/react/blog/2013/06/05/why-
react.ht...](http://facebook.github.io/react/blog/2013/06/05/why-react.html)

~~~
chenglou
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
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
(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!).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
3rd3
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
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...](http://arstechnica.com/information-
technology/2014/01/google-plans-to-dump-adobe-css-tech-to-make-blink-fast-not-
rich/)

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)

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

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

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

------
mrec
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/)

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

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

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

------
shadowmint
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
> 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
2010 macbook pro and I can't scroll the page without serious lag and jumping
:/

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

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

I thought web developers were all for semantic markup.

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

~~~
TeMPOraL
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."_

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

------
frik
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
"website_fail" is a bit harsh when you're using Internet Explorer in the first
place...

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

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

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

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

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

