Referencing the HTML spec.

I have been working on writing up tabindex in the spec. (No I have not
disappeared). What is important about tabindex is that sequential focus
navigation needs to flow in and out of the SVG documents. It also means
that we have to make use of things like the Document Object and Window
Objects as well as definitions like browser context from HTML. It also
means we need to work in the absence of an HTML document. I have been
discussing this with Cam and we would like to put these questions and
assessments to the list for your feedback:

So, some questions for discussion:

1. Do you agree that the way event listeners are registered in SVG and HTML
should be the
same? -- both should support `element.addEventListener("click", ...)` and
`element.onclick = ...`.  (The latter needs some spec work still, but
implementations all support this.)

2. There are some inconsistencies between the events SVG defines to fire
and those in HTML.  We need to be harmonizing these and
should do it for SVG 2.

3. It is not clear how the document and window interfaces align between SVG
and HTML both when SVG is a standalone document and when it is contained
within an HTML document. Currently, per spec, if your implementation
supports HTML then all top-level SVG documents also implement all of the
things that HTML defines on Document.  If your implementation does not
support HTML, then it does not.

What we really need is a way to say "if your implementation does not
support HTML in general, you need to implement these particular bits
from HTML".  One way to do that would be to duplicate the IDL members
for the bits that we want, but refer to the HTML spec for their
behaviour.  Then we can state in SVG that these duplicated IDL bits are
required only if the user agent does not implement HTML altogether.

Cam suggested the following intorductory text:

   Conforming SVG interpreters are not required to implement HTML;
   however, some specific features of HTML are required to be
   implemented.

And then later in the spec:

   A conforming SVG interpreter that does not also implement HTML
   must implement the following IDL fragment:

     partial interface Document {
       readonly attribute Element? activeElement;
     };

   The activeElement attribute must have the same behavior as
   described in HTML.  [with a link to HTML's definition of
   activeElement]

So the idea is: if the UA implements the HTML specification, then there
is no need to require anything further about activeElement, as HTML
should require the document.activeElement property to exist (by its own
IDL fragment) and for it to have particular behaviour.  If the currently
required behavior in HTML for activeElement is insufficient for SVG,
then we should file bugs on HTML.  If the UA does not implement the HTML
specification, then we need to have our own IDL fragment like the above,
but then just point to HTML's activeElement behaviour for the one we
just defined.

4. When HTML refers to tab navigation it indicates the elements that can
receive focus without using tabindex. Examples are command, input, and
anchor elements. Cam and I think this is fine if the UA does not implement
HTML and therefore won't be doing anything with <html:input> elements for
example, then it doesn't matter if they are focusable by default or not.

Yet, in terms of defining that <svg:a> is focusable by default, we might
need to get HTML to change there -- either by having a hook that we can
refer to from SVG to state that <svg:a> is focusable by default, or just by
HTML defining it so. Do people agree we should define this in HTML?

5. The HTML5 spec. defines how to process browsing contexts. IOW documents
in a document when it comes to sequential navigation. Do people agree we
can just refer to the HTML5 definition of browsing context? This will also
be important when we embed <iframe>s in and SVG document per the face to
face.

This was the approach I was going to take when adding tabindex.

6. Two methods we need from HTMLElement are focus() and hasFocus(). We need
to be able to use these whether an HTML document is present or not. Should
we request that HTML move these two methods up to Element? If not then we
can add them both to the
SVGElement interface and have the definitions of focus() and hasFocus()
refer to HTML's definitions.

What is the preferred course of action? I don't know if we want focus on an
arbitrary Element.

7. tabindex is a global attribute in HTML which means it can apply to ANY
element - but only if it is being rendered.

This text from HTML:
"An element is focusable if the user agent's default behavior allows it to
be focusable or if the element has its tabindex focus flag set, but only if
the element is either being rendered or is a descendant of a canvas element
that represents embedded content, and only if neither the element nor any
of its ancestors are inert."

A good example is <title> which would not receive focus in HTML. So, my
recommendation is that we make it global and make the same stipulation
about it needing to be rendered and only if neither the element or any of
its ancestors are inert. Inert has to do with dialog boxes stealing keys.
We could reference the HTML5 definition of inert.

People agree with this approach?

8. Browsing Context and needed methods/attributes

Part of what is needed for sequential focus navigation is to deal with
browsing contexts. HTML5 defines browsing contexts as:
http://www.w3.org/html/wg/drafts/html/CR/browsers.html#browsing-context

If we follow this it means that we need to

 * establish a Document and Window object for SVG
 * manage things like activeelement
 * refer to the HTML spec. for their definition.

We would like to refer to the HTML5 definition and put some wording where
we would require a window object to exist and for there to be a browsing
context with some suitable prose. We would like to link to HTML for these
concepts/requirements. Are people in agreement with this?

For instances where we do not have HTML simply define the required partial
interface be implemented as above for activeElement and Focus().

9. Inconsistencies in naming between method names and event names e.g. blur
() vs. onfocusout

We should not be distracted by onfocusout, which is the name of both the
content
attribute you can put in the markup <g onfocusout=""> and the property
in the DOM `g.onfocusout = function() { ... }`.  The name blur() here is
the action to perform, and whether it results in an event named "blur"
or "DOMFocusOut" being dispatched as a result of the element losing
focus is a separate issue.

We need to rationalize  the events listed in interact.html so that they
align better with implementations and with HTML.

10. SVGDocument vs. Document

Use approach above of defining the IDL fragments to
use when the implementation does not support HTML more broadly is a
viable one.  That way, if the SVG implementation does not support HTML,
you won't have a document.forms property in the DOM, but if you do
support HTML then you do.  If you've written an SVG document that uses
no HTML elements, then your document.forms collection is going to be
empty.

People Agree?

Rich