- 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>
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 -- Simon Pieters Opera Software
Received on Friday, 13 February 2015 08:23:03 UTC