Decorators shemekerators

Decorators as described in the Web Components Intro have been more or less dropped - as described they are kind of a non-starter - there are some conceptual and performance concerns. However, there have been numerous attempts and requests with lots of use-cases that people thought they solved, so it’s probably worth discussing whether there is something worth pursuing investigation/further efforts there. Lots of conversations are attempting to be had via twitter, but with 140 character limit this seems a little unproductive. Unfortunately I’m tied up and unable to detail things, so I’m going to start this thread and hope that people share use cases and concerns productively to get the ball rolling.

Don’t forget that /TR/ links are evil ;). Latest editors draft does not even contain decorators.

The explainer tells how decorators could work, but doesn’t say what problem they solve. What problem is it that decorators solve? Especially in light of the is="" attribute for custom elements, which definitely allows you to “enhance or override the presentation of existing elements.”

Surprised, given all of the twitter hubbub that no one is sharing use cases, so I will share the one I see that is currently unmet and that decorators would (poorly in the current design IMO but at least it was an interesting first waffle) possibly help address/is worth addressing:

HTML provides DOM structure, CSS deals with presentation - except that despite the promise, CSS and the box tree are actually still pretty intertwined with the HTML… We’ve gotten better over the years and Web Components allow for more expressive markup – that all helps a lot, but the idea that you can really control presentation via CSS once you have your HTML is still kind of – not entirely true. The CSS WG knows this and it has already introduced some very basic ideas like ::before and ::after which create boxes that aren’t DOM, but can be styled, and has been working for years on things like layouts, pagination, grids, etc.

In many orgs (like mine) one group is full of engineering minded folk who write JavaScript, another is full of visually minded folk who write CSS - and HTML is something of a battleground. You need engineering to generate markup and keep it reasonably well synced with the script and designers need to style it… But more than that, designers still need structure that doesn’t really have meaning for purely presentational purposes (today). This seems wrong. Web Components help this separation quite a bit, but they don’t solve it. Creating DOM from CSS seems kinda – well… not great. But creating and fiddling with the render-tree, that seems totally sane to me. Part of the issue, as I say, is that the render-tree today has no API or anything other than, DOM. The great thing about DOM is that it has a serialization that is easily groked - perhaps if there were a simple render-tree serialization that you could apply via CSS to do things like ‘wrap that bit over there so I can style it up’ or something that might make sense?

So, decorators were supposed to allow (high performance) dynamic application of presentation to elements regardless of their state. Just one of the challenges I can think of with them actually working out are unapplication. If your decorator happens to care about state in any way at all, the idea of unapplication becomes fundamentally hard - when does it matter? when doesn’t it matter? when are we talking about the same instance?.

I remember Dimitri once giving an example of you hypothetically wanting to run script inside of your decorator which might force the author to walk down non-obvious paths (event listener registration with any DOM node outside of the decorator caused unwanted effects of the listener sticking around after the decorator was unapplied, storing state of a decorator was hard especially if unapplied/repapplied quickly). Even the notion of separating state of the decorator from the element would cause issues of having to figure out isolation, which could come with performance penalties.

In 2011, I think there was more favour of exploring a better mode of DOM projection rather than worrying about decorators and the challenges of per-instance DOM with state to hang state off of. Even now, no one seems to quite have the appetite for championing decorators nor seeing them through and I personally don’t see their value (sorry, Brian!).

I remember Dimitri once giving an example of you hypothetically wanting to run script inside of your decorator…

This is what I was saying above - that idea seems really problematic… But the idea of having CSS that creates/massages the render-tree seems perfectly sensible to me.

In 2011, I think there was more favour of exploring a better mode of DOM projection

I’m not sure I understand what you mean here - are you saying render-tree, not DOM?

and I personally don’t see their value (sorry, Brian!).

Definitely don’t be sorry to me… I hear a lot of people saying “What happened to decorators” and “that’s a shame”… I do think there were use cases some people had and I’m just asking to collect them and see if there is something worth pursuing. Maybe not, and that’s ok too - I was prompted by numerous tweets to bring it here in the first place

Decorators don’t feel like they should be tied to web components. I there’s some render-tree abstraction at some level that lets us add auto-generation/removal of render-tree decoration to generated DOM, that seems good. But implicating script (which is what we’re doing here) is clearly insane.

What if we took a lighter approach where decorators were essentially styled, pseudo-element bundles? Let me illustrate:

<decorator name="ribbon">
  <template>
    <div><div></div></div>
  </template>
  <style>
    @decorator ribbon {
      div {
        content: attr(title);
        ...
      }
    }
</style>
</decorator>

We could allow developers to apply decorators like so:

<section title="Ribbon Title" decorators="ribbon other-decorator"></section>

As I mentioned - there are numerous CSS proposals to do something like this (for example http://dev.w3.org/csswg/css-template). It was actually something that held up regions as well… The one thing that they are all lacking/tend to miss IMO is that CSS is a kind of terrible language/syntax for attempting to describe structure of any kind. I think that there is something key here - in this case, it decorative structure we are talking about, not semantic (I think). I have suggested before that perhaps being able to link to a series of templates that use a ML for something like a box tree rather than HTML might be better. I don’t know, when I look at this I still don’t feel like that approximates the right sort of idea, feels jumbled/convoluted to me: It looks like normal HTML, but… not, the roles don’t seem clear, etc. Seems like a nightmare of stuff to work out/confusion/complexity still.

See, I feel doing structural, element descriptions in CSS is the far more convoluted path that embeds something totally alien in stylesheets. At least with HTML it’s no problem when you included structure, styles, and script in one document.

One use case that I have in mind is to add functionality to content editors without screwing around with the DOM (too much). Say you want to build an editor that’s richer than the usual dumb “rich text” stuff, and you might want every structural item inside the editing surface to have extra affordances, e.g. for move/delete/insert but also set ID, change whatever properties, etc.

You could use components for the content of your editing surface, but you then have to serialise the recursive shadow when you want the content, they all need to monitor their ancestors for editability, etc. It’s doable but clumsier.

true…it does provide performance, design, and security implications and it should not be taken lightly. That said, it is powerful and I can see use cases for content driven sites with JavaScript limitations and visualization enhancements using these with pseudo selectors. I am not saying this is good or bad but I am curious given the use cases I can dream up what others might dream up as well.