<link as=""> should be case-sensitive |
||||
Issue descriptionPer https://github.com/whatwg/html/pull/1449 it was decided that as="" in <link> should be case-sensitive, and use new special reflection semantics (see https://html.spec.whatwg.org/#reflect, "If a reflecting IDL attribute is an IDL enumeration type..."). Chrome does not currently respect this decision: https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4463 (should output "", the default value). We tried to overturn this in https://github.com/whatwg/html/issues/1665 but Mozilla and WebKit preferred the case-sensitive semantics. So we need to update to match the spec.
,
Sep 14 2016
I must say I'm a bit skeptical about going down this path, splitting the platform into an old case-sensitive part and a new case-insensitive one. It's true that some things are already case-sensitive, but even if we can't have full consistency it seems better to try to go as far as we can in one direction. In terms of compat risk, it's probably less risky to move things from case sensitive to insensitive. IDL enumerations are already supposed to be all lowercase, so it seems to me that the rules for reflecting IDL enumerations could just lowercase the input? (HTMLTrackElement's kind attribute comes to mind, I'm sure there are other cases where the spec would become clearer and more code auto-generated by reflecting as IDL enumerations, but that doesn't have to be tied to case sensitivity.)
,
Sep 19 2016
Yoav, can you bring this up on blink-dev? I'd still like this to be case-insensitive, but other may disagree.
,
Dec 16 2016
After 3 months of procrastination: https://groups.google.com/a/chromium.org/d/msg/blink-dev/TK0DRrZthUg/VRzxWPeRDgAJ
,
Mar 29 2017
,
Apr 10 2017
Seems like there's consensus to keep it case-insensitive in both Blink and WebKit. WONTFIXing. |
||||
►
Sign in to add a comment |
||||
Comment 1 by y...@yoav.ws
, Sep 13 2016Owner: y...@yoav.ws