Re: Pseudo-selector for virtual elements

On Sun, Jul 11, 2010 at 12:09 AM, Andrés Sanhueza
<peroyomaslists@gmail.com> wrote:
> The HTML5 spec didn't added a <di> element to group <dt> and <dd>
> elements inside a <dl> because "that's an styling problem and should
> be solved with CSS".
I strongly disagree here: <di> would be 100% structural. Of course, it
will help to select the dt/dd groups for CSS styling, but that's only
because CSS Selectors are designed to select nodes of a tree based on
the tree's structure.

Personally, I strongly dislike HTML5's approach on this and some other
cases: IMO, markup authors should be able to explicitly mark the
document's structure (that's what the markup is for, after all); even
if some shortcuts are *allowed*. OTOH, the WHATWG seems to prefer
leaving as much as they can implicitly (like "a <dt> after a <dd>
implicitly starts a new entry") thus requiring CSS (and, to some
degree, other technologies) to have a deep built-in knowledge of those
HTML implicit structures. So much coupling makes both languages much
more brittle, and will trigger several problems to evolve either
language in a near-to-mid future.

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.

> 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.

> 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.

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

'foo' => blue; 'bar' and 'baz' => red.

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?

Received on Sunday, 11 July 2010 11:24:09 UTC