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

On Thu, May 7, 2015 at 10:42 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Well, beyond the existing conflicts of <style>, <script>, and <a>.
>> (<font> too, but that's dropped from SVG2, so who cares.)
>
> <textArea> is out too?

<textArea> was never in - it was an SVG Tiny element, and thus never
appeared in any web-compatible version of SVG.

> With respect to case-insensitive matching, I don't really understand
> why we simultaneously want to make these rather trivial changes to SVG
> while at the same time move to constructors for creating elements,
> which is even stricter than createElementNS() (literal has to be
> correctly spelled or you get an exception). If we want to move to a
> world where people write
>
>   new SVGRectElement
>
> why would we even bother making
>
>   document.createElement("RECT")
>
> work?

It's not about that, it's about making, say, "lineargradient {...}"
work, because you can case selectors any which way for HTML, and it's
confusing that you can't for SVG.

(And I'm still not convinced on constructors, anyway - they're so
verbose! And we would to have to fix so many of them!)

> Same for CSS, the majority of CSS already uses type selectors where
> the case matches up with the HTML. Is complicating it really worth it?
> We should bring the languages closer, but we shouldn't put the
> mistakes we made with HTML into SVG.

I don't think ascii case-insensitivity is a mistake here.

~TJ

Received on Friday, 8 May 2015 17:10:00 UTC