- From: Benjamin Poulain <benjamin@webkit.org>
- Date: Fri, 13 Feb 2015 00:44:56 -0800
- 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