Discussion:
[selectors4] multiple pseudo-elements per selector
(too old to reply)
Bruce Lawson
2017-06-21 16:02:15 UTC
Permalink
Raw Message
Hello fellow Stylistics

ever since I can remember, the line "A future version of this specification
may allow multiple pseudo-elements per selector."

What's the reason for that? What's the reason it's not currently allowed?
--
Bruce Lawson
www.brucelawson.co.uk
www.twitter.com/brucel
fantasai
2017-06-21 17:43:11 UTC
Permalink
Raw Message
Post by Bruce Lawson
Hello fellow Stylistics
ever since I can remember, the line "A future version of this specification may allow multiple pseudo-elements per selector."
What's the reason for that? What's the reason it's not currently allowed?
Pseudo-elements aren't just filtering which element is selected:
they actually create structure in the box tree. So if we have a
pseudo element attached to a pseudo-element, it creates a box
structure that doesn't currently exist, and pseudo-element box
structures can be particularly intricate and complicated to
implement since many of them don't fit into the box's tree
structure.

Therefore we intend to only allow specific combinations--those
that are needed for particular use cases.

~fantasai
Bruce Lawson
2017-06-21 17:57:00 UTC
Permalink
Raw Message
Thanks fantasai

so the reasons that multiple pseudo-elements isn't allowed is primarily
implementation complexity and (I assume) performance implications of that
complexity, rather than any philosophical objections?

Do any examples of specific combinations that are potentially allowable
spring to mind?

bruce
Post by fantasai
Post by Bruce Lawson
Hello fellow Stylistics
ever since I can remember, the line "A future version of this
specification may allow multiple pseudo-elements per selector."
What's the reason for that? What's the reason it's not currently allowed?
they actually create structure in the box tree. So if we have a
pseudo element attached to a pseudo-element, it creates a box
structure that doesn't currently exist, and pseudo-element box
structures can be particularly intricate and complicated to
implement since many of them don't fit into the box's tree
structure.
Therefore we intend to only allow specific combinations--those
that are needed for particular use cases.
~fantasai
--
Bruce Lawson
www.brucelawson.co.uk
www.twitter.com/brucel
fantasai
2017-06-21 18:17:16 UTC
Permalink
Raw Message
Post by Bruce Lawson
Thanks fantasai
so the reasons that multiple pseudo-elements isn't allowed is primarily
implementation complexity and (I assume) performance implications of
that complexity, rather than any philosophical objections?
Primarily complexity, rather than performance. But even if a particular
combination was relatively simple, we don't want to add features that
don't have strong use cases since even simple features require work
(spec, implementation, testing). The key thing to remember here is that
each combination would likely require its own code: only the parsing
bit could be handled generically, and that's a very minor fraction of
the work involved in handling a pseudo-element.
Post by Bruce Lawson
Do any examples of specific combinations that are potentially allowable spring to mind?
I remember there being use cases for some specific combinations,
but I can't remember what they were atm. ^_^;;

::marker::first-line definitely seems unlikely, though. =)

~fantasai

Loading...