W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [cssom] Serializing the ">>" combinator

From: Benjamin Poulain <benjamin@webkit.org>
Date: Fri, 13 Feb 2015 00:44:56 -0800
Message-ID: <54DDB988.6080807@webkit.org>
To: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
On 2/12/15 9:22 PM, Simon Pieters wrote:
> On Fri, 13 Feb 2015 00:05:45 +0400, Benjamin Poulain 
> <benjamin@webkit.org> wrote:
>
>> On 2/12/15 1:22 AM, Simon Pieters wrote:
>>> On Tue, 10 Feb 2015 09:14:26 +0400, Benjamin Poulain 
>>> <benjamin@webkit.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> The serialization specification does not mention ">>" from CSS 
>>>> Selectors level 4: 
>>>> http://dev.w3.org/csswg/cssom/#serializing-selectors && 
>>>> http://dev.w3.org/csswg/selectors-4/#descendant-combinators
>>>>
>>>> What we have done in WebKit is serialize ">>" like the other 
>>>> non-space combinators (e.g. "foo>>bar" serialize to "foo >> bar").
>>>>
>>>> An other option is to canonicalize every descendant combinator to 
>>>> the space character.
>>>
>>> I've specified it to serialize as a space, for two reasons:
>> I am a bit surprised by this. I had the impression the WG favored 
>> ">>" over the space.
>
> Personally I see no reason to favor >>. The only reason I have seen 
> for it existing at all is that it makes for a "nice" family of 
> combinators >, >> and >>>. But it is possible that I'm missing something.
>
>> Plus web developers tend to report bugs when a serialized value 
>> differs significantly from the original selector.
>
> Yeah. On the other hand, it is common to normalize semantically 
> equivalent things in CSSOM.
>
>>> * It is compatible with legacy UAs that support space but not >>
>> How would legacy UI end up with a parsed ">>" in the first place?
>
> It wouldn't. I assumed two UAs, one with >> support and one without, 
> where the serialization from one is parsed by the other. I realize 
> that this might not be particularly relevant.
>
>>> * It avoids having to remember which one was used when parsing
>
> This is the stronger reason in my opinion. Also see 
> https://lists.w3.org/Archives/Public/www-style/2015Jan/0603.html
This is a very different case.
Here the selector has nothing special that needs extra storage, you can 
just defined a new ">>" combinator in the list of combinators. That does 
not require any memory.

In WebKit, I opted to use our bitflags for simplicity, but that's pretty 
much the same: it does not require any special treatment or any extra 
memory.

Benjamin
Received on Friday, 13 February 2015 08:48:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC