[css-typed-om] Should StyleMap be case sensitive?

[esprehn]

Some folks want us to make the platform more case sensitive. Since this is a new API, that means we would make it case sensitive. ex.

element.styleMap.get("background-color") // works.
element.styleMap.get("Background-Color") // doesn't work.

Unfortunately this also diverges from .style, ex.

element.style.getPropertyValue("Color") // works.
element.style.getPropertyValue("COLOR") // works.

@annevk @domenic @foolip @tabatkins

[foolip]

If I'm reading Blink's CSSPropertyParser.cpp correctly, element.style.getPropertyValue is always case sensitive, unlike e.g. element.getAttribute it doesn't depend on the document type. Presumably this code path could be reused if the new API is also case insensitive, where otherwise a new code path specifically to make the wrong case not work?

I'l defer to the people working on style in Blink. @wilddamon @rune-opera

[wilddamon]

I was looking at this recently when I was trying to consolidate the various ways of parsing names we have in Blink. style.getPropertyValue isn't case sensitive - you can see the call to toASCIILower for each character here (I also tried in dev tools, $0.style.getPropertyValue('wiDth') definitely works).

So I think we'd have to create a new code path to do this.

[annevk]

Would it be a completely new code path? Presumably the existing callers could ASCII lowercase early and from that point on you could have shared code. We've even thought of making the ASCII lowercase operation part of IDL since there are some other APIs where we could also use that kind of thing (all mostly for legacy reasons). (Unfortunately I don't recall which APIs at the moment.)

[foolip]

@wilddamon, oops, I typo'd above, I meant case insensitive of course.

FWIW, in the context of lowercasing in element.getAttribute and friends (which are now case insensitive compares in Blink, observably different when the stored attributes aren't lowercase) I have entertained the option of putting an "is-ASCII-lowercase" flag on the atomic string type that's set when returned from a toASCIILower operation, so that attempting to lowercase it again is a no-op. Without some tricks like that I'd worry about perf regressions from always (actually) lowercasing the input, but then I stopped working on the attribute stuff.

[ghost]

We (Blink) have a gperf generated case-sensitive hash for known CSS properties which are case-insensitive in the parser and existing CSSOM APIs. The input is made ascii lower-case before the lookup. It looks trivial to skip the lower-casing for new APIs.

[wilddamon]

Yeah, it's not a large new code path - we'd be able to split up that function and/or have a flag to skip the lowercasing loop :)

[tabatkins]

Since we don't really care which way this goes, we'll just decide it at the next meeting and be done with it.

[css-meeting-bot]

The CSS Working Group just discussed https://github.com/w3c/css-houdini-drafts/issues/309, and agreed to the following resolutions:

• RESOLVED: StyleMap for CSS properties is ASCII case-insensitive because that's how CSS property names are defined

The full IRC log of that discussion

<nainar> Topic: https://github.com//issues/309
<fantasai> GitHub: https://github.com//issues/309
<fantasai> TabAtkins: Should the StyleMap be case sensitive for property names?
<fantasai> TabAtkins: .style isn't
<fantasai> TabAtkins: It doesn't care about casing
<fantasai> TabAtkins: We do not care which way it goes, it's trivial
<fantasai> TabAtkins: So asking for opinions
<fantasai> fantasai: What does it even mean for it to be case-sensitive?
<fantasai> TabAtkins: Only accepts lower case
<fantasai> dbaron: Is it clear that the canonical case for CSS is lower-case?
<fantasai> ...
<fantasai> ?: Interaction with custom properties?
<fantasai> TabAtkins: Custom properties are always case-sensitive
<surma> s/?/surma
<fantasai> fantasai: I'll settle this for you, I'll object to treating CSS properties as case-sensitive.
<fantasai> dbaron: I think it would be really weird for this to be case-sensitive
<fantasai> dbaron: Don't want TypedOM to be different from other OM
<dbaron> dbaron: people sometimes pass properties to functions
<fantasai> RESOLVED: StyleMap for CSS properties is ASCII case-insensitive because that's how CSS property names are defined

[nainar]

Closing as this was added in #445