Hacker News Reader

Comment by c-smile | Hacker News Reader

All this is over-engineered IMO.

It is just enough to add support of behavior property to CSS:

      my-toggler {
         display:block;
         behavior: MyToggler url(my-components.js);
      }

As soon as browser will see <my-toggler /> in markup it will call function MyToggler() with 'this' set to the element in file my-components.js. That's what I did in my Sciter[1]. It was proven as quite useful and easily understandable yet implementable in 100 lines or so of native code.

The value of shadow DOM is also quite doubtful to be honest. It is shadowed from whom and for what purpose? User don't care about DOM structure ... Programmers? They are OK with that.

[1] http://sciter.com

View on HN

> All this is over-engineered IMO.

It's complicated in order to provide a lower-level API so that libraries can take advantage of different features and provide more opinionated ways of creating custom elements. Polymer is an example of a library which provides a simpler (but slightly more opinionated) API on top of custom elements.

> The value of shadow DOM is also quite doubtful to be honest. It is shadowed from whom and for what purpose? User don't care about DOM structure ... Programmers? They are OK with that.

The Shadow DOM provides style isolation, which is convenient to developers mixing-and-matching components, and can also be a performance boost as browsers can optimize for the fact that styles don't cross the shadow boundary. It also provides a bit more isolation for when you are writing code to discourage components from reaching into each others' private implementation.

> The Shadow DOM provides style isolation ...

I've proposed once @ www-styles concept of style sets: the @set construct.

Style sets mechanism solves two principal problems of CSS:

1. They allow to define local and independent style systems for elements in the same DOM tree.

2. Style sets allow to reduce computational complexity of style resolution. In classic CSS all style rules that used by the document are placed in the single ordered table. Task of finding list of matching selectors for the element has computational complexity near O(n), where n is a number of rules in the table. And style resolution of the whole DOM tree is O(n * m * d) task. Where m is a number of DOM elements and d is an average depth of the tree. Style sets allow to reduce significantly n multiplier in this formula.

http://sciter.com/css-extensions-in-h-smile-engine-part-i-st...

> to provide a lower-level API ...

I haven't seen any requests from framework/platform developers.

In contrary, the feature to call particular function when particular element appears in the DOM was actual from the time of first framework appearance. People were trying to solve it with DOM mutation events but they did not go through - too expensive, etc.

Past attempts at component models for the web have used CSS as the hook instead of a script call. For example, Mozilla's XBL and Microsoft's HTC. This way of doing it is a security hazard because it makes CSS into active code instead of just passive styling. Many sites had problems where they were willing to include CSS from a third-party source for user customization, and ended up with XSS security holes.

If you do it carefully and get all the details right, you end up with something like Custom Elements and Shadow DOM, both of which are ultimately not that complicated.

> to include CSS from a third-party source for user customization, and ended up with XSS security holes.

So custom components cannot be included from third party sources? If they can then this is exactly the same problem.

And in general idea of including third-party CSS from source you cannot control is even worse. Same thing is about JS.

That `behavior` thing can use 'same origin' rule as we have now for any other JS code.

The behavior that defines name of a function (in any language) that can setup the element in various ways: e.g. it can be used with React, Angular, Vue, you name it.

> So custom components cannot be included from third party sources? If they can then this is exactly the same problem.

They can, but you can separately decide whether to support components from arbitrary off-site sources (most sites wouldn't) vs accepting styling for arbitrary off-site sources.

> That `behavior` thing can use 'same origin' rule as we have now for any other JS code.

There is no same-origin restriction for JS included directly with the <script> tag. Most websites are not designed to expect the <stye> tag to be a backdoor <script> tag. If you mean to invent some novel security restrictions on JS running in the same frame, trust me, it will end up more complex than Custom Elements.

> It is just enough to add support of behavior property to CSS:

That's been done before: that's how XBL works in Gecko.

Having now worked with it as both API consumer and API implementor for a while (going on 15 years now), attaching behavior via CSS like that has some really nasty aspects to it. For a start, if you create a "my-toggler" element via createElement, it won't have the behavior attached (because style doesn't get resolved for elements outside the DOM). And if you insert it into the DOM inside a display:none subtree it won't have the behavior, becase style resolution is optimized out inside display:none subtrees. There are various other issues; I don't really have time to write them all out right now.

But suffice it to say that this way of attaching behavior via CSS has been considered, implemented, shipped, used extensively, and found wanting.

Reply on news.ycombinator.com