Re: Pseudo-selector for virtual elements

On Sun, Jul 11, 2010 at 4:23 AM, Eduard Pascual <herenvardo@gmail.com> wrote:
> On Sun, Jul 11, 2010 at 6:27 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> [...]
>> The problem is dealing with overlaps.  For example, given this code:
>>
>> <b>foo</b><i>bar</i><b>baz</b><i>qux</i>
>>
>> And these selectors:
>>
>> ::wrap(b,b) { color: blue; }
>> ::wrap(i,i) { color: red; }
>>
>> What color is each word?
>
> If my understanding of your ::wrap() idea is correct, then 'foo' and
> 'qux' should be blue, 'bar' and 'baz' should be red. The reasoning
> behind this is rather simple: CSS already has a well-defined mechanism
> to handle property "conflicts" (ie: multiple declarations setting the
> same property of the same object to incompatible values): most
> specific wins, and then last declaration wins among specificity tied
> declarations.
>
> Both selectors have the same specificity, so last declaration wins.

That doesn't actually address the overlap problem.  Yes, *after*
you've somehow resolved how to treat overlaps, then specificity and
the cascade work like normal.

This is how the HTML will look after creating the pseudo-elements in
the naive way:

<::wrap(b,b)><b>foo</b><::wrap(i,i)><i>bar</i></::wrap(b,b)><::wrap(b,b)><b>baz</b></::wrap(i,i)><::wrap(i,i)><i>qux</::wrap(i,i)></::wrap(b,b)>

The pseudoelements are misnested!  Now it's unclear which tag is
innermost in the overlap areas.  Is the <::wrap(i,i)> element started
before the <i>bar</i> implicitly closed and reopened around the
</::wrap(b,b)> tag?  That might mean that <::wrap(i,i)> is the
innermost pseudo for <i>bar</i>, but the outermost for <b>baz</b>,
which would create a different rendering than what you described (the
elements would alternate blue and red).

Or are the <::wrap(b,b)> pseudos created first, and then the later
<::wrap(i,i)> pseudos "steal" the relevant elements from them, so that
each element is only wrapped by a single <::wrap()> pseudo at a time?
That also produces a different rendering than what you described (only
"foo" would be blue, the rest would be red).

These choices also affect how the next case is handled.


>> I haven't yet solved this problem in a way that makes me happy, unfortunately.
>
> What does it take to make you happy? Personally, I have quite enough
> with things being well-defined and predictable (nearly an utopia in
> the web world), and that's what CSS Cascade gives. So, CSS Cascade
> makes me happy :P
>
> Sure, there will be cases where the result of applying Cascade won't
> be what the author intended. But then the author has several tools at
> his/her disposal, such as swapping the order of selectors, adding
> redundant stuff to the selector that increases the specificity, using
> more fine-grained selectors to match more specific stuff, etc.

As I've hopefully outlined above, the problem is precisely that it's
*not* well-defined right now, nor is it predictable.  There are
multiple possible ways to handle overlaps, and it all gets resolved at
a level above the cascade.


>> Further problems to ponder:
>>
>> <b>foo</b><i>bar</i><b>baz</b>
>> ::wrap(b,b) { color: blue; }
>> ::wrap(i,b) { color: red; }
>
> 'foo' and 'baz' => blue; 'bar' => red.

That one makes sense, since the <::wrap(i,b)> can correctly nest
inside the <::wrap(b,b)> pseudo.  But would your answer change if the
order of the rules were reversed?  A "nesting" approach to assigning
these would say no, but a "stealing" approach would.


>> <b>foo<i>bar</i>baz</b>
>> ::wrap(b) { color: blue; }
>> ::wrap(i) { color: red; }
>
> 'foo' => blue; 'bar' and 'baz' => red.

I believe this one is the least ambiguous, but it's still affected by
the choices you make to handle the previous cases.  I don't think
::wraps at a higher level in the tree should have any affect on
::wraps affecting a lower level - they should only interact when the
pseudos are conflicting as siblings.


> In all these examples, I don't think we can unambiguosly determine
> what an author might be attempting, but we can easily determine how
> would the cascade apply.
>
> Is it worth to break the cascading rules to deal with corner cases
> where we won't even be sure to be addressing correctly?

Again, resolving the issues I'm talking about takes place at a level
higher than the cascade.  *First* you figure out how the pseudos get
applied to the element-tree, *then* you cascade based on that modified
structure.

~TJ

Received on Sunday, 11 July 2010 17:28:40 UTC