Re: [dom] Comments on heycam's new SVG DOM

On Aug 9, 2013, at 1:36 AM, Cameron McCormack <cam@mcc.id.au> wrote:

> Tab Atkins Jr. wrote:
>> Some comments on the proposal at
>> <http://dev.w3.org/SVG/proposals/improving-svg-dom/>.
>> 
>> 1. The proposal currently says that SVG elements in either HTML or the
>> null namespace opt into the new DOM.  This appears to be because of a
>> belief that createElement() run in an XML document creates an element
>> in the null namespace.  Per spec, at least, this is wrong -
>> createElement() always puts elements in the HTML namespace, so we can
>> just drop the "null namespace" part and only care about the HTML
>> namespace.
> 
> As I saw it, there were two advantages to allowing the elements to be in 
> either the HTML namespace or no namespace.  One is createElement doing 
> the right thing, regardless of whether you were in an HTML or XML 
> document, though as you point out if it's meant to put things in the 
> HTML namespace always, then that's one advantage removed.  The second 
> was to allow
> 
>   <graphics>
>   </graphics>
> 
> in image/svg+xml documents, rather than requiring
> 
>   <graphics xmlns="http://www.w3.org/1999/xhtml">
>   </graphics>
> 
> (Or <svg>, if you don't buy in to the need for a new root element.)
> 
>> 3. I'm not convinced on the<viewport>  element.  I have found it
>> slightly clumsy before that some attributes are only useful on the
>> root<svg>  and others are only useful on nested<svg>s, but I don't
>> know how bad this is.  Shrug, I can be convinced either way.
> 
> Three alternatives to <viewport>: continue allowing <svg> as the 
> viewport establishing element inside an SVG fragment; allow <graphics> 
> in the middle of the document; add the viewport-defining attributes to <g>.

Hm, we discussed putting elements like <circle> in the normal HTML flow. Maybe these elements that have an HTML ancestor create a viewport automatically. This way it might be easier to define that they contribute to the CSS boxing model.
The crux is again with elements like <g> that has no dimension. At the end it should not be that different to <div> elements with auto sizing.

> 
>> 4. I strongly agree on the clean break between old interfaces and new.
>>  There are too many things where we'd either need clumsy overloads, or
>> do really bizarre subclassing, or just add new "good" names for
>> attributes.  (For example, there's no non-hacky way to change rect.x
>> or a.href to let you avoid the baseVal/animVal stuff.)
> 
> Per IRC discussion, we need to look into "value objects" from ES.next, 
> to see if they might be able to solve this problem.  If they can, I 
> wonder if that solves much of what this proposal aims to achieve.
> 
>> 5. I don't like the precise shape of the length/etc new stuff.  The
>> functionality is great, but the API shape is different from what we
>> were aiming towards for CSS, and is somewhat clumsy in some aspects
>> (as you note in an issue).  We should just work together with CSSOM
>> and define something consistent.  Maybe this is something for FXTF?
>> (I don't care where it happens, I just want us to coordinate.)
> 
> I agree we should coordinate to have things represented the same as in 
> CSSOM.
> 

We already have some attributes that got transformed to presentation attributes. I think we should drive this indecent of the decision on Camerons proposal. We discussed this in Sydney as well, and I am very much supportive to replace the SVG DOM with CSS OM. But this means we would need to work on CSS OM 2 sooner than later. We should contact the CSS WG on that.

Greetings,
Dirk

>> For example, the CSSWG knows from experience that things which start
>> out as simple values often expand later to become list-valued or
>> map-valued, and shaped its proposal to allow for this kind of
>> expansion in a natural way.  For example, list-valued properties
>> actually return an object for just the first item, but with a .l
>> property hanging off that returns the whole list.
>> 
>> On a related note, one of the possible directions we've thought about
>> for the CSSOM Values API was just defining all the values interfaces
>> as subclassing DOMString, so you can still interact with the value as
>> a string, but can also hang off properties like .px (for lengths) or
>> .red (for colors).
>> 
>> Taking these together, we can, for example, have .transform be a
>> DOMString subclass.  I guess it has [PutForwards] on it so it can be
>> set to a string directly.  It exposes the transform properties for its
>> first item, and has a .l property on it to expose a (live?) list of
>> transforms.
> 
> Also per IRC, I don't think this is a great way to go, unless value 
> objects solve some fundamental problems with string-ish objects: you 
> can't compare two string-ish objects for string equality using "==", 
> since that would compare object identity, and "!" would always return false.
>

Received on Friday, 9 August 2013 05:58:40 UTC