Re: agenda, 30 April 2015 SVG WG telcon

On Wed, Apr 29, 2015 at 7:27 PM, Amelia Bellamy-Royds
<amelia.bellamy.royds@gmail.com> wrote:
> Re Tab's agenda request:
>>
>> Agenda+: What if we just let SVG-in-HTML lowercase its names (rather
>> than having to preserve the camel-case).  What are the
>> downsides/compat risks?
>>
>
> I really don't think there is any problem with saying that SVG-in-HTML is
> case insensitive as far as markdown parsing goes.  We are never going to
> create element or attribute names that only differ by capitalization.
> Authors would still be advised to use the standard capitalization for
> maximum compatibility and ease of switching between inline and standalone
> SVG.
>
> The difficulty would probably come from some of the DOM methods.  Even for
> SVG-in-HTML, you need to use .createElementNS() and related methods.  Those
> are case sensitive, because they are based on XML.  Not sure how much of a
> headache/performance impact it would be to add extra rules for using those
> methods in HTML documents.
>
> In contrast, with querySelector() and related methods, the same method is
> either case sensitive or not depending on the type of element being matched.
> Which of course leads to the nasty bug in Blink/Webkit (where they use
> case-sensitive matching but automatically lowercase the input selector when
> in an HTML document, with the result that mixed case SVG selectors never
> match anything).  Making all elements case insensitive/automatically
> lowercased within an HTML doc would fix that bug, but at the cost of
> complicating the other DOM methods.

That's exactly the bug I'm talking about.  ^_^  We have a patch that
fixes this, but it does so by plumbing case-sensitivity throughout the
engine; it *works*, but it's nasty and we'd prefer to avoid doing
this.  If, instead of that, we just extended HTML's case-insensitive
tagname and attribute matching rules to SVG, we'd have a much easier
fix, and would probably match author's expectations better anyway.

Actually downcasing SVG-in-HTML elements and attributes would be even
better, but likely not backwards-compatible.

~TJ

Received on Friday, 1 May 2015 00:03:24 UTC