Re: [css-variables] Reopening the casing issue

On Tue, Jun 11, 2013 at 4:38 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> Hi,
>
> Everybody will hate me, maybe, but I just wanted to reopen for an instant the case of [css-variables] case sensitivity, maybe not the change the outcome but at least to present an issue I just faced where this was a very annoying problem: I used a CSS compressor.
>
>
> CSS compressors optimize CSS files by removing white space, but also by sorting properties and making the casing uniform. That way, encoder like DEFLATE can make more use of previous parts of the file to avoid data duplication. My issue was that when I write
>
>   selector { var-X: something; }
>
> most CSS compressors modify it into
>
>   selector{var-x:something}
>
> which caused it not to work somewhere else where I didn't use the compressor. The issue was not so obvious to spot, because X is not that different in upper and lowercase (but, to be honest, it was just a test, not sure if I would use 'X' as a custom property name for real).
>
>
> I can live with the option that only lower-cased variables should be used and are garanteed to be preprocessor-safe, but if I'm about to accept this limitation, the possibilities opened by differential casing become much lower. Wouldn't it be better to say that ASCII-case folding is done on the identifiers? That should cover the most common casing issues (I really hardly saw any identifier with non-ASCII letters on the web anyway).

Nope, nope nope nope.  Not gonna change this.  ^_^ Figuring out the
right casing rules was contentious and hard, and ASCII-case folding is
awkward when you mix in non-ASCII latin letters like accented letters
(not to mention, dependent on which normal form you use - ASCII A
followed by a combining accent would be treated differently than a
precomposed accented A).

Your preprocessor needs to be adjusted to not touch the casing of
anything related to variable rules.

~TJ

Received on Tuesday, 11 June 2013 12:42:28 UTC