W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Opera's Proposal for :context Selector

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 16 Jul 2008 16:15:51 +0200
Message-ID: <487E0297.5000806@lachy.id.au>
To: Bert Bos <bert@w3.org>
Cc: www-style <www-style@w3.org>

Bert Bos wrote:
> On Saturday 12 July 2008 23:05, Lachlan Hunt wrote:
>> Bjoern Hoehrmann wrote:
>>> Could you explain why those other specifications are a concern at
>>> all, and you can't just say the :context pseudo-class matches an
>>> element if and only if some other specification identifies it as
>>> the context ele- ment in a given selector evaluation context?
>> Only because I didn't think of doing it in that way.
> 
> Björn's definition makes sense, but it is much too abstract to be 
> useful. I can understand ':focus' and '::selection', because I have 
> indeed given elements the focus and selected text in a document. 
> But ':context' matches all elements (never parts of elements?) that are 
> somehow "special" as defined by the source document. HTML doesn't 
> define any such elements, nor does XML, so what does?

HTML5, which now defines scoped stylesheets, does have such a special 
reference element, which is the parent sectioning element of the style 
element.

> If there are concrete elements that are useful to select (first element 
> on the page, previous element with the focus, longest element without 
> children, element with the fewest vowels, whatever), than invent a name 
> that describes those element.

Consider this example:

<body>
   <section>
     <style scoped>...</style>
   </section>
</body>

In this example, the reference element (or "scope element") is the 
<section> element.  There needs to be a way to match that element 
easily, without requiring the author to add an id to it.  I would call 
that a concrete element that is useful to select.

>> I have written 
>> a revised version based on your suggestions.  It will now require
>> both Selectors API and HTML5 to eventually define which element is
>> the context element, which won't be difficult if this proposal is
>> accepted.
>>
>> http://lists.w3.org/Archives/Public/www-archive/2008Jul/att-0023/Over
>> view.html
> 
> It seems you want something like the \G in Perl's regular expressions. 
> Why don't you define it in the Selectors API as a special notation 
> accepted by the querySelector() function?

I wanted it to be a selector, instead of a special syntax, for several 
reasons:

1. Inventing a special syntax would effectively alter the grammar of
    selectors as used by the API. Doing that either means that either:

    a. Implementers would need to change their selector parsing,
       which I would then need to define.

    b. The string needs to be pre-processed in order to generate a
       conforming selector, which will effectively need to insert a
       selector into the sequence that only matched the correct element
       (or at least behave as if it did).

    I wanted to avoid such complexities, at least for version 1.

2. Using a pseudo-class allows it to be combined with other simple
    selectors in a sequence, which allows more powerful selection
    possibilities.  e.g "ul:scope>li" selects all child LI elements
    if and only if the scope element is a UL element.

3. It allows for it to be used in other places where selectors are used,
    such as HTML5 and possibly XBL, instead of being restricted to just
    Selectors API.

> (It seems to me you shouldn't need it at all. The problem seems to be 
> that x.querySelector(":root") doesn't return x. That looks strange to 
> me: you pass a tree and a pattern, and you get something outside the 
> tree!? But I'm not an expert on that spec...)

The API doesn't change the way in which an element is evaluated against 
a selector; it's still evaluated in the context of the entire document. 
  All it does is limit the collection of elements that are evaluated 
against it.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Wednesday, 16 July 2008 14:16:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT