Re: Improving SVG DOM: Modification request

Hi Dirk,

(2013/12/03 22:55), Dirk Schulze wrote:
>
> On Nov 25, 2013, at 2:19 AM, Brian Birtles <bbirtles@mozilla.com> wrote:
>> ...
>> (2013/11/21 0:56), Dirk Schulze wrote:
>>> ...
>>> I would like to suggest some modifications to the original proposal that makes it much more compatible to the current SVG DOM and backwards compatible to todays SVG implementations for the most part. Current implementations would not break on supporting basic functionality that is already in SVG today. Some of the modifications already exist as issues in the original proposal itself:
>>>
>>> * Remove SVG namespace. Elements or attributes explicitly created with SVG namespace will still end up with no namespace. Keep current object names (SVGNameElement)
>>
>> I think backwards compatibility is a concern here. namespaceURI is often
>> used to differentiate SVG elements from others. e.g. [1]
>
> I was about to ask for an example. I didn’t see the use of namespace like this before. Do you think it is common enough that we need to care about checks like this? We can special case createElement() with SVG NS to produce an HTML element. I don’t think that we can return an SVG *and* and HTML namespace. But...

Unfortunately I think this is pretty common. For example, if you look at 
the source for jQuery SVG[1] it comes up a few times. One time is very 
similar to the example I posted before, another, however is using the 
presence of elements with the SVG namespace to determine if there is any 
SVG in the document.

And that's just the first library I decided to check.

So, I think this change will break content. More investigation would be 
required before we could say if it's within acceptable limits or not.

>> If we can ensure all the differences between SVG elements and HTML
>> elements are removed at the same time then it might work. For example:
>>   - Make sure the xlink namespace is not needed for href (done)
>>   - Make className no longer a DOMAnimatedValue
>>   - Make sure 'classList', 'children' etc. are supported on SVG elements
>>   etc. etc.
>
> … as you said, we might not need to take care about that if we do the things you suggest. I had the same in my mind and especially className and classList are extremely rarely used in combination with SVG DOM.

The point here is that script that is assuming that "lack of the SVG 
namespace = HTML content" will expect things like className, classList, 
children etc. to work as they do for HTML content so these things have 
to work the same on SVG elements (which is difficult in the case of 
className).

Or are you saying it won't matter because no-one has ever tried to read 
or change classes programmatically on SVG except by using setAttribute? 
Maybe that's so, but I'd like to see some data for that. I know I use 
classList and className with SVG (although my code should be resistent 
to these particular changes[2]) so I'll be a little surprised if I'm the 
only one.

>>> * use unions to give some attributes a new meaning for an potentially new SVG DOM
>>
>> Can you explain this?
>>
>> I think, for example,
>>
>>    interface SVGRectElement : ... {
>>      attribute (SVGAnimatedLength or float or DOMString) x;
>>    };
>>
>> would be quite difficult for authors to deal with. Given a rect element
>> passed into a function you would have to test the type of every property
>> before using it wouldn't you?
>
> It gives them the freedom to choose to either use float, SVGAnimateLength OR DOMString. It is a bit more code to implement but should still be maintainable.

I think it gives you freedom as an author when you *write* to this 
property but if you want to *read* a typed version of the attribute on 
an arbitrary rect it's a real pain to test for three possible types and 
handle them accordingly. What do you think?

Best regards,

Brian


[1] http://keith-wood.name/svg.html
[2] e.g. 
https://github.com/mozilla/parapara/blob/master/editor/lib/js/parapara.js#L727 
which uses 
https://github.com/mozilla/parapara/blob/master/editor/lib/js/svgClassList.js 
as a shim when classList is not available on SVG elements.

Received on Wednesday, 4 December 2013 06:13:52 UTC