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

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

From: Simon Pieters <simonp@opera.com>
Date: Fri, 13 Feb 2015 07:24:56 +0400
To: "www-style@w3.org" <www-style@w3.org>, "Benjamin Poulain" <benjamin@webkit.org>
Message-ID: <op.xtzf3uzlidj3kv@simons-macbook-pro.local>
On Fri, 13 Feb 2015 00:16:11 +0400, Benjamin Poulain <benjamin@webkit.org>  

> 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?

Simon Pieters
Opera Software
Received on Friday, 13 February 2015 06:25:30 UTC

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