Re: SVGSVGElement.toDataURL()

On 3/11/13 10:53 AM, Robin Berjon wrote:
> It's just an interface.

No, because interface inheritance involves importing the whole proto 
chain, for example.

Right now the web platform has an invariant where something is 
instanceof HTMLElement if and only if it's in the HTML namespace.  It's 
not clear to me that this is a safe invariant to change.

Note that

   SVGElement implements HTMLElement;

is a somewhat different kettle of fish than inheriting from HTMLElement.

>    • Other languages can inherit from HTMLElement too.

But do they want to?  That's the question.  If there are things on 
HTMLElement that are not in fact HTML-specific, they should be moved to 
Element.

> If you move innerHTML to Element, what happens to all the other useful
> things such as outerHTML, insertAdjacentHTML, dataset, hidden, style...

Just so we're clear on the current state of the specs:

1)  innerHTML, outerHTML, insertAdjacentHTML are on Element.  See 
http://domparsing.spec.whatwg.org/#extensions-to-the-element-interface

2)  dataset and hidden are on HTMLElement because they're tied to 
attributes that HTML defines.  They could be moved to Element if core 
DOM defined those attributes.

3)  style is on HTMLElement but imo should move to Element.

> ? HTMLElement is the basic unit that I'd expect all elements in a
> browser context to support.

No, that's Element.

> Conversely, placing it on Element means that it becomes available in
> contexts in which people don't normally see it, such as regular server
> DOM stuff.

Why?  That seems like a very misguided way to look at this.  In 
particular just because it's in the spec doesn't mean a server DOM 
should implement (though I've certainly complained about "server" DOMs 
not having innerHTML and whatnot when I ran into it).  If we want to 
make it explicit, we can put the things like this on a partial interface 
that's explicitly labeled as only needing to be supported in "browser 
contexts" (that's not right, since we want .style on elements that come 
from an XHR responseXML, by the way).

> I'm not saying that SVG is HTML

You are if you're saying that every SVGElement is an HTMLElement.... ;)

> but at the very least in a browser
> context, even when standalone, it really should script in the same way.

Does that include all the DOM properties that just reflect content 
attributes, especially if those content attributes don't make sense for SVG?

It seems to me like the right way to handle SVG and HTML wanting to 
share some DOM bits that really don't belong on Element for whatever 
reason is to factor out all those bits onto an separate interface that 
both HTMLElement and SVGElement implement...

-Boris

Received on Monday, 11 March 2013 19:28:11 UTC