Re: Document Object in SVG

OK. We will discuss this in the group.



Rich Schwerdtfeger



From:	Boris Zbarsky <bzbarsky@mit.edu>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
Cc:	public-svg-wg@w3.org, www-svg@w3.org, dbolter@mozilla.com,
            Dominic Mazzoni <dmazzoni@google.com>
Date:	03/27/2013 09:32 AM
Subject:	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