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

Re: [cssom] Serializing the :lang() pseudo class

From: Benjamin Poulain <benjamin@webkit.org>
Date: Thu, 12 Feb 2015 23:22:04 -0800
Message-ID: <54DDA61C.5070001@webkit.org>
To: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
On 2/12/15 7:24 PM, Simon Pieters wrote:
> On Fri, 13 Feb 2015 00:16:11 +0400, Benjamin Poulain 
> <benjamin@webkit.org> wrote:
>> On 2/12/15 12:30 AM, Simon Pieters wrote:
>>> On Tue, 10 Feb 2015 09:22:02 +0400, Benjamin Poulain 
>>> <benjamin@webkit.org> wrote:
>>>> Hi,
>>>> The serialization of :lang() just says to append "The escaped value.".
>>>> In Selectors Level 4, :lang() takes a list of identifiers and strings.
>>>> When we implemented :lang() in WebKit, we serialized each language 
>>>> range to the same format as its original input. For example 
>>>> :lang(foo, "*-bar") remains :lang(foo, "*-bar").
>>>> The reason to use string for serialization is the escaped asterisk 
>>>> is hard to work with when the string is converted to an identifier. 
>>>> Initially we wanted to convert every language range to string but 
>>>> we ran into compatibility issues since the argument used to be only 
>>>> an identifier.
>>>> Could this be clarified in the spec?
>>> It seems slightly annoying to remember what kind of token was used. 
>>> Would it be compatible to serialize as an identifier if possible 
>>> without escaping, and otherwise as a string? Or some other rule like 
>>> escape as a string only if there is an asterisk?
>> Neither options are strictly compatible with the current behavior. It 
>> is quite possible this would not break anything since it was not 
>> common to use escaped characters in language ranges prior to the 
>> asterisk.
>> If you are considering breaking existing behaviors, always 
>> serializing to string seems like a better long-term choice.
> I meant compatible with what Web content expects. Did you run into Web 
> compat issues with serializing as a string?
We never tried to enable string serialization by default, too many tests 
were affected.

I doubt many websites would be affected. In my experience, those APIs 
are mostly used by tools, not production content.
If you are okay with breaking backward compatibility, I would be happy 
to enable string serialization by default.

Received on Friday, 13 February 2015 07:23:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC