Re: [css4-pseudo] The need for more powerful pseudo elements

I'm not really following your decorator concept François. Can you link me
to something that gives a better definition?

Tom


On Mon, Apr 29, 2013 at 6:34 AM, François REMY <
francois.remy.dev@outlook.com> wrote:

> > From: sam@cateches.is
> >
> > I disagree. Although it's ripe for abuse (like most things), this was
> > discussed in last week's thread "[css4-pseudo] multiple and
> > nested pseudo-element ordering"
>
> To be honest, I had a flag on this mail as a potential reply-to subject ^_^
>
>
> > The use case for me, though, was that I had a large amount of metadata
> > in data-attributes on an element and wanted to display tags after the
> > content (newspaper headlines are the context).
>
> Yes, this is a *much* better use case, without any doubt. But, still, you
> can solve it using only one after pseudo-element and decorators:
>
>   [data-content-access="premium"]::after {
>     decorator[premium]: premium-decorator;
>   }
>
>   [data-content-type="video"]::after {
>     decorator[video]: video-decorator;
>   }
>
>   [data-content-subtype="porn"]::after {
>     decorator[video]: porn-video-decorator;
>   }
>
> with premium decorator, video-decorator & porn-video-decorator being small
> markups that will represent your shadow DOM elements.
>
> The advantage of decorators is that they are way more powerful than
> generated content.
>
>
> > That way, I can create a series of ::after()s, each with its own
> > (small) tree based on metadata. This is especially helpful when some
> > of the metadata is generated via javascript after the page loads. We
> > don't want to create and append nodes, we'd just like to be able to say
> > .setAttribute("data-content-type","blog") and have the rest take care
> > of itself.
>
> It's not really the role of CSS to handle markup, if you want my opinion.
> But this advantage is preserved by the decorator solution, anyway, it's
> just the way get defined that is changed.
>
> I'm really concerned that with CSS-defined markup, we risk to let authors
> morph the layout DOM tree in subtle ways that could be really hard to debug.
>
>
> _______________________
>
> Disclaimer: I'm not a member of the CSS Working Group so don't take
> everything I say for a W3C opinion. I'm neither able nor mandated to
> represent this group's opinion ;-)