Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 4:16 AM, Rune Lillesveen <rune@opera.com> wrote:
> Currently, the HTML spec says that type selectors matches case
> sensitively for non-html elements like svg elements in html documents
> [1]. So according to the spec, and the implementation in Gecko, the
> rules below matches according to the prose:
>
> <!DOCTYPE html>
> <style>
> foreignObject { color: red }
> foreignobject { color: green }
> </style>
> <foreignOBJECT>Matches both rules. Case-insensitive match. Is
> green.</foreignOBJECT>
> <svg>
>     <FOREIGNobject>Matches the first rule because the parser
> normalizes to the camelCased form as per spec. Is red.</FOREIGNobject>
> </svg>
>
> This adds an implementation complexity to type selector matching.
> What's the rationale for matching the selector case-sensitively in the
> svg case?
>
> I'm sorry if I've missed previous discussions. I did see a few really
> long mails and threads about svg in html on this list, but weren't
> able to find the resolution for this in reasonable time.
>
> Should we change the spec in this regard?
>
> I did have a correct implementation for Blink, but was asked in the
> review [2] to match insensitively for non-html elements in html
> documents due to the complexity.
>
>
> [1] https://html.spec.whatwg.org/multipage/scripting.html#selectors
> [2] https://codereview.chromium.org/1099963003

The SVGWG just resolved to allow SVG elements and attributes to be
matched case-insensitively, like HTML.  We also resolved to try and
find a method to make parsing SVG case-insensitive in general.

For the latter, we're specifically interested in doing so when SVG is
embedded in HTML, and also having some way to indicate that a
standalone SVG should parse using similar rules (either a modification
of the HTML parser, or Anne's XML5 work, or something similar).  When
written in the XML syntax, it's fine for it to continue being
case-sensitive as it is today.

I presume this means that we'd start returning lowercased tagnames for
element in SVG-in-HTML.  Do we think that's a compat risk?  If so,
perhaps we can do something smaller, like having the
localName/nodeName/tagname attributes be getters that camelcase those
tagnames, but internally they're lowercased by the parser.  (It looks
like localName and tagname already differ in casing in HTML, so either
we store two strings, or we do the casing transformation in a getter
already.)

~TJ

Received on Thursday, 7 May 2015 21:05:39 UTC