Re: DOM 4 request

I see.  So, for FF, in the context of the SVG Document, you would not be
able to access the HTML5 Document Object attributes in the parent document
unless they were in the generic DOM4 generic document object? IOW only
script bound to the parent HTML document would be able to gain access to
HTML document object interface specific functions?

Rich


Rich Schwerdtfeger



From:	Dirk Schulze <dschulze@adobe.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
Cc:	Anne van Kesteren <annevk@annevk.nl>,
            "annevankesteren@gmail.com" <annevankesteren@gmail.com>,
            "public-canvas-api@w3.org" <public-canvas-api@w3.org>,
            "www-dom@w3.org" <www-dom@w3.org>, "www-svg@w3.org"
            <www-svg@w3.org>
Date:	03/11/2013 09:26 AM
Subject:	Re: DOM 4 request



Hi,

On Mar 11, 2013, at 6:18 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

>
> Rich Schwerdtfeger
>
> annevankesteren@gmail.com wrote on 03/11/2013 06:21:28 AM:
>
> > From: Anne van Kesteren <annevk@annevk.nl>
> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> > Cc: www-svg@w3.org, public-canvas-api@w3.org, www-dom@w3.org
> > Date: 03/11/2013 06:22 AM
> > Subject: Re: DOM 4 request
> > Sent by: annevankesteren@gmail.com
> >
> > Resending with corrected addresses.
> >
> > On Mon, Mar 11, 2013 at 11:18 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:
> > >> Please let us know if the DOM working group would support adding
this
> > >> attribute [(activeElement)].
> > >
> > > It's already supported for SVG at the moment. HTML simply extends the
> > > Document interface and does not create one specific for HTML. In
terms
>
> Hi Anne,
>
> The issue is that SVG can run in standalone documents. For this reason we
have the following situation:
>
> Here is the current Document object reference in SVG2:
> Document element Interface:
https://svgwg.org/svg2-draft/struct.html#InterfaceSVGDocument
>
> Here is the DOM4:
> Document element Interface:
http://www.w3.org/TR/2012/WD-dom-20120405/#interface-document
>
> Here is the HTML5
> HTML5 Document element Interface:
http://www.w3.org/html/wg/drafts/html/CR/dom.html#the-document-object
>
>
> > > of dependencies, HTML and DOM have a mutual dependency already (as
> > > unfortunate as that may be). And actually, SVG must have a dependency
> > > on HTML too for script scheduling and execution.
> >
> We agree that SVG has a huge dependency on HTML for scripting and
introducing tabindex to SVG2 has really brought a lot of these issues to
light in the SVG working group. Yet, the HTML5 Document object interface
has a lot of features that really don't apply in a standalone situation.
Here are a few
>
>  readonly attribute HTMLCollection embeds;
>  readonly attribute HTMLCollection plugins;
>  readonly attribute HTMLCollection forms;
>
>            attribute EventHandler onblur;   (SVG has a different handler
name for this - onfocusout)
>
> So, are you suggesting that we simply take the HTML5 Document Object
interface and basically address the mapping issues like return null for
objects that have no applicability to SVG in a standalone environment?

WebKit does not differ between Document from DOM and partial Document from
HTML. SVGDocument just inherits of "HTMLDocument". Independent if it is
standalone. I do not know how we handle the cases above at the moment.

Looking at the Firefox source code, it does not look like this is done at
Mozilla. FF seems to have an "XMLDocument" which does not have HTML
specific methods and attributes.

>
> If so, then we should also coordinate with the HTML WG and WhatWG on
ensuring clear specification of how this may be populated in the presence
of an SVG document in HTML. I am sure the browses have addressed a lot of
this but it has not been clearly spec'd to my knowledge.

It would need a lot of clarifications how this is supposed to work on SVG.
And it doesn't even seem to be implemented this way broadly. A cleaner
solution seems to be to move the necessary methods and attributes to DOM
and let all XML languages use it. MathML would be another candidate where
it could make sense.

Greetings,
Dirk

>
>
> Rich
> >
> > --
> > http://annevankesteren.nl/
> >
>