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

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

From: Simon Pieters <simonp@opera.com>
Date: Fri, 13 Feb 2015 09:22:32 +0400
To: "www-style@w3.org" <www-style@w3.org>, "Benjamin Poulain" <benjamin@webkit.org>
Message-ID: <op.xtzljur1idj3kv@simons-macbook-pro.local>
On Fri, 13 Feb 2015 00:05:45 +0400, Benjamin Poulain <benjamin@webkit.org>  

> 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  

Simon Pieters
Opera Software
Received on Friday, 13 February 2015 08:23:03 UTC

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