- From: Eduard Pascual <herenvardo@gmail.com>
- Date: Mon, 12 Jul 2010 20:36:24 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Andrés Sanhueza <peroyomaslists@gmail.com>, www-style@w3.org
On Sun, Jul 11, 2010 at 7:27 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > [...] Ok, my bad. I looked at the issue from an authoring perspective, rather than the implementation's. I guess from your reply that, at the implementation level, pseudo-elements need to "exist" within the tree (I normally perceive pseudo-elements as only existing while their declaration block is being applied). OTOH, you are describing two possible solutions to the issue, which are quite a good proof that the issue is solvable. So it all boils down to choosing one of them (or something else). Seeing how both approaches are, on the best case, ugly, does it really matter too much which one we take? With either approach, any sane author will need to be explicit enough to avoid overlaps (and CSS3 Selectors are powerful enough to be so explicit). Hence this is mostly an arbitrary choice between "ugliness A" or "ugliness B". Here my guts make me lean towards whichever most resembles HTML5's parsing algorithms for bad-formed mark-up (taking each <::wrap> as an arbitrary unknown element), just to keep ugliness a bit uniform and hopefully enable some code re-use on the implementation side. In any case, now I am even more convinced that a request for a CSS feature to work-around the mark-up's inability to describe a structure is quite a symptom of a flaw on the mark-up language. In other words, the use cases should be addressed by HTML through explicit structuring elements.
Received on Monday, 12 July 2010 18:37:17 UTC