W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Fwd: Case Sensitivity Issue and CSSOM

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 24 Jan 2013 10:05:50 -0800
Message-ID: <CAAWBYDARPQ030WGTXhehs96KnHRCWSsNBgJDMeOROcY-WhofGg@mail.gmail.com>
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>, WWW International <www-international@w3.org>
On Thu, Jan 24, 2013 at 7:17 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 23/01/2013 23:37, fantasai a écrit :
>> Given this, I'm leaning towards Richard Ishida's (?) suggestion that we
>> leave user-defined idents as case-sensitive and just grandfather in any
>> CSS-defined keywords as computing to their lowercase variants.
>> This would mean that
>>     @counter-style DISC { ... }
>>     e { list-style-type: DISC; }
>> turns into
>>     @counter-style disc { ... }
>>     e { list-style-type: disc; }
>> in the CSSOM even though
>>     @counter-style FOO { .. }
>>     e { list-style-type: FOO; }
>> retains its casing.
> What about this?
>    @counter-style DISC { ... }
>    e { list-style-type: disc; }

Given that "disc" is a built-in type, fantasai's desired behavior
means that those two would indeed sync up - the @counter-style rule
would override the "disc" type, and the 'list-style-type' property
would then reference it.

> I’m not sure what’s the exact behavior you mean. Is it as follows?
> "Iff a <counter-style-name> value is an ASCII case-insensitive match for one
> of the 14 CSS 2.1 values, normalize to ASCII lower case. Otherwise use the
> ident value as parsed."

Yes, I believe that's what she's referring to.

> Do we have types other than <counter-style-name> that mix user-defined and
> CSS-defined idents? Would they each have a fixed list of CI values? Could
> such a list expand in a future level?
> I’m trying to figure out the details here, but overall I like this idea.

Yes.  Custom properties are one (they're extra weird, because they're
actually a combination of a language-defined prefix and a user-defined
suffix).  Suggestions of similar have come up in the past, but not
adopted yet, such as @text-transform for defining custom
'text-transform' values.

The list would indeed expand over time, if we added new
language-defined values.  Adding new values to a syntax space that
we've intentionally exposed to user idents is always going to be
hazardous, though, so this doesn't make it much worse.

Received on Thursday, 24 January 2013 18:06:38 UTC

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