Re: Referencing the HTML spec.

Hi Rich,

here's my reply to your mail on public-svg-wg -  
http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0055.html.

On Wed, 13 Feb 2013 21:58:06 +0100, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:

>
>
> 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.)

Yes.

> 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.

This is about SVG not having the focus and blur events, right? I think SVG  
should have them. Feel free to add a complete list of the inconsistencies  
you found.

> 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.

Sounds good to me.

> 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?

It would be nicer if HTML could simply refer to SVG for which SVG elements  
are focusable by default. In fact that is what it seems to be doing  
already: http://www.w3.org/TR/html51/references.html#references lists SVG  
Tiny 1.2 as a normative reference. SVG Tiny 1.2 requires <svg:a> to be  
focusable by default. See  
http://www.w3.org/TR/SVGTiny12/interact.html#focus.

Do you think there's something missing still from the HTML5 spec wrt this?

> 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.

That should be fine.

> 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.

It's probably fine to have the methods available on all svg elements.

> 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?

This may need some tweaking for SVG terminology, but generally sounds fine.

> 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().

Fine with me.

> 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.

Could you elaborate on what that would practically mean? I'm mostly  
concerned about compatibility with existing content.

I think we should require 'focus' and 'blur' as events in SVG.

> 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.

Yes.

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 28 February 2013 22:17:34 UTC