SVG Case Sensitivity (was: agenda, 30 April 2015 SVG WG telcon)

Hey–

I think we should make SVG elements and attributes case-insensitive by 
any means possible.

Among many other issues, 'viewBox' has bitten many people, and it's 
relatively hard to debug.

There may be conflicts with SVG and HTML elements, in parsing; if so, 
they should be resolved the same way <title> and <a> are.

There are a few classes of backwards incompatibility, including:

1) New content doesn't work correctly in older UAs: this applies to new 
features, or some changes to syntax. This is inevitable, and we can't 
evolve the language unless we risk this.

2) Existing content doesn't work in new UAs: this applies to changes to 
the existing language, behavior, or syntax, leading to breaking changes. 
This is generally to be avoided.

2a) Underspecified, non-interoperable features: this applies to features 
that had poor definition, and when the spec and test suites are 
clarified, some content will break for some UAs.

2a) Existing content with non-common features doesn't work in new UAs: 
this is the case for SMIL and SVG Fonts. This is roughly equivalent to 
optional features, another no-no. But if you don't have interop, it's 
usually better to drop the feature (though exceptions exist).


Case-sensitivity of SVG is a class 1 change. New content might not work 
in some older UAs, but older content will still work in new UAs.

I think we should do this. It's low-risk, assuming UAs (browsers, 
authoring tools, conversion libs) can be updated.

Regards–
–Doug

On 4/30/15 8:02 PM, Tab Atkins Jr. wrote:
> 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 Thursday, 7 May 2015 20:30:01 UTC