Re: Selector Sugar

On Thu, Oct 9, 2008 at 11:53 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> ...with the :any pseudoclass being simple sugar that stands for any of the
> selectors contained within it.  :any should accept arbitrary selectors,
> separated by commas

Of course you just mean "should accept arbitrary selectors" here --
"#top-courses, #additional-courses" is already a single valid selector
that does what you want, no need to specify the commas specially.

I feel as though this might get complicated if you allow arbitrary
selectors to go in :any() (which should really be called something
like :match(), since it would operate on single selectors).  This
isn't just syntactic sugar, is it?  It really opens up the capability
to select things that are not currently possible to select.  It
basically allows arbitrary ANDing of selectors, when currently we only
have OR.  In other words,

A:match(B):match(C)...

will match anything that matches A and B and C and ... As a practical
example, consider something like

div span:match(span + span)

which matches a span that has a div ancestor *and* is immediately
preceded by a span.  I'm pretty sure there's no possible way to do
this with current CSS selectors, so it's not just semantic sugar.

You might have had somewhat different semantics in mind, though?

> since it's basically just performing a simple textual
> substitution in the selector.

Not if you allow arbitrary selectors to be put in . . . if you just mean that

foo :any(a, b, c) bar :any(d, e)

should be substituted for

foo a bar d, foo a bar e, foo b bar d, foo b bar e, foo c bar d, foo c bar e

then it's not really a pseudo-class, or at least doesn't behave like
one.  Is "div:any(.a, ::first-line) span" a syntax error?  Is
"div:any(.a +, .b ~)span"?  Is ":any(strong +, em ~) span" supposed to
parse the whitespace before "span" as insignificant instead of as a
descendant selector (which would be a change in the parsing model,
right?).

Should div:any(.a, .b) be allowed?  If so, should it be interpreted as
"div.a, div .b" (whitespace becomes significant!) or "div.a, div.b"?
If the latter, you would just ban the descendant selector from
beginning or ending one of the arguments to :any()?

What are the semantics of putting :any() in weird places?  Would it
work inside :not()?  (It should if it's syntactically a pseudo-class.)

If you're trying to envision this as a preprocessing sort of
directive, I'm pretty sure it would require core syntax changes,
unless you limited it very sharply.

I do think the first proposal would be nice, though, and likely not
problematic.  If I understand correctly, at-rules can be added without
changing the core grammar, as long as they nest braces properly.

2008/10/9  <brkemper@comcast.net>:
> Good point. But I was assuming the parser would need to be updated to deal with this either way.

I don't think it does, for @scoped().  At least not the core syntax.

> Regarding old browsers: They are virtually guaranteed to draw the page
> incorrectly if it has any of this sort of mark-up in it, because they will be
> ignoring large swathes of CSS inside the braces. So why bother trying
> to play nice with them? An author would need to be very careful with
> actually using this, only doing so when he or she is confident that it is
> likely going to a UA that can handle it (through UA-detection, perhaps,
> or by knowing the audience, or by controlling the UA that reads the markup).

Or, most generally, by waiting ten years or so.

Received on Friday, 10 October 2008 16:08:03 UTC