Re: Improving SVG DOM: Modification request

On Nov 25, 2013, at 2:19 AM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi Dirk,
> 
> A couple of brief thoughts here:
> 
> (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...

> 
> 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.

> 
>> * 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 Cameron had two suggestions here:
> 
> interface SVG2RectElement : ... {
>   attribute (float or DOMString) x;
> };
> 
> or
> 
> interface SVG2RectElement : ... {
>   attribute float x;
> };
> (with setAttribute if you want to set a string)
> 
> We've come across this problem in Web Animations too where you want the 
> numerical property for convenience and the string for flexibility. 
> Perhaps we need a platform convention here?

I would be fine with a platform convention. I just don’t want to duplicate all SVG elements and have half of them in the SVG NS and half of them in the HTML NS. I think we can put them all together into the HTML NS with just some slightly changes/additions.

Greetings,
Dirk

> 
> Best regards,
> 
> Brian
> 
> 
> [1] 
> https://github.com/mozilla/parapara/blob/faa3985643ee9598ff7833257f5059a53be2f9b1/wall/public/walls/js/wall.js#L372
>

Received on Tuesday, 3 December 2013 13:55:48 UTC