Re: Document Object in SVG

On 3/27/13 9:25 AM, Richard Schwerdtfeger wrote:
> Anne would prefer we use the HTML5 Document Object for SVG when and SVG
> Document is operating in the presence of an HTML5 document.

To be honest, I'm not sure what this means....

> In that context we would need to
> define how we deal with Document Object methods that really don't apply
> to SVG which I don't think is a problem.

Indeed; the HTML spec should already be defining this for all the 
methods it adds to Document.

> Yet, there were concerns that
> this Mozilla may have an issue with that as they have been preserving an
> XML Document Object for SVG. We would like to hear your position.

So in Gecko right now there is a Document interface.  There are also 
SVGDocument and HTMLDocument interfaces that inherit from Document.

We don't have a concept of "HTML5 Document" vs some other Document; 
there is just a single Document interface, shared by all Documents.

As I said, SVGDocument inherits from Document in Gecko, so SVG documents 
are instances of Document but not of HTMLDocument.  I believe everyone 
agrees that this should stay that way (including the HTML5 spec, which 
makes HTMLDocument go away completely and moves all its methods and 
properties to Document).

The "activeElement" property in Gecko is on Document, so SVG documents 
already have it in Gecko.

In general, what the HTML5 spec proposes is that all things that are 
currently on HTMLDocument in Gecko live on Document instead.  I'm fine 
with most of that, with a possible exception for the named getter; we 
just haven't gotten around to it yet.  Of course if SVG documents want 
the named getter that can be added to them too; since the named getter 
affects instance objects directly there is no issue in terms of new 
web-visible prototypes or anything when that's done.

So in some sense, all of this discussion makes no sense at all in the 
Gecko context: there is only one Document interface, defined in several 
different specifiations, and SVG documents already implement that 
interface.  So there's nothing to worry about there implementation-wise.

 From a specification point of view, I guess the concern is that someone 
could implement the Core DOM parts of Document and implement SVGDocument 
but not implement the parts of Document defined in HTML, right?  To be 
honest, this doesn't seem terribly different from someone implementing 
most but not all of the Core DOM parts of Document; the main difference 
is that an implementor may not realize that there are more relevant 
Document things defined in HTML.  Addressing this can be done either by 
having the SVG specification explicitly require that the parts of 
Document defined in HTML be implemented, or that particular aspects of 
it are, or moving some of those parts to Core DOM...  I don't have a 
strong opinion for which one to go with.  But no matter which option is 
taken, this only affects non-browser implementation of SVG, since 
obviously browsers have to implement the parts of Document that HTML 
defines no matter what.  So I don't have a strong opinion on how this 
should be done.

Does that help?

-Boris

Received on Wednesday, 27 March 2013 14:30:35 UTC