Re: [svg2] tabindex and defaults

There are some differences for tabIndex between
1.https://svgwg.org/svg2-draft/types.html#__svg__SVGElement__tabindex
and
2: https://svgwg.org/svg2-draft/interact.html#sequential-
focus-navigation-and-the-tabindex-attribute

1. There is a difference in casing.
1 defines it as 'tabIndex' while 2 as 'tabindex'. I assume it should be the
former since that follows HTML (and Erik's patch)

2. There is a difference in allowed value
The idl in 1 says that the default is 0, while 2 states that tabindex is
undefined by default. Should we follow 2?



On Mon, Jan 27, 2014 at 11:04 AM, Richard Schwerdtfeger
<schwer@us.ibm.com>wrote:

> Hi Erik,
>
> response below.
>
> Rich
>
>
> Rich Schwerdtfeger
>
> Erik Dahlström <ed@opera.com> wrote on 01/27/2014 10:21:34 AM:
>
> > From: Erik Dahlström <ed@opera.com>
> > To: "www-svg@w3.org" <www-svg@w3.org>
> > Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS
> > Date: 01/27/2014 10:21 AM
> > Subject: [svg2] tabindex and defaults
>
> >
> > Hi,
> >
> > I was reviewing the sections related to tabindex in SVG2 and have a few
> > comments:
> >
> >
> > 1) we seem to be duplicating some spec text:
> > https://svgwg.org/svg2-draft/types.html#__svg__SVGElement__tabindex
> > https://svgwg.org/svg2-draft/interact.html#sequential-focus-
> > navigation-and-the-tabindex-attribute
> > (last sentence in the paragraph)
> >
> > I'd suggest removing the sentence in the interaction chapter, but a link
>
> >  from there to the IDL might be a good idea.
> >
>
> Done.
> >
> > 2) in the algorithm to determine if an element has a "tabindex focus
> > flag",
> > https://svgwg.org/svg2-draft/interact.html#sequential-focus-
> > navigation-and-the-tabindex-attribute,
> > it's said that "The a element that has an xlink:href attribute must have
>
> > the tabindex focus flag set.".
> >
> > I'd like to see this apply to any elements that have a { focusin,
> > focusout, focus, blur, click, keydown, keypress, keyup } event listener
> > also. Suggested spec text "Elements that have an event listener
> registered
> > on one of the following user interface events: focusin, focusout, focus,
>
> > blur, click, keydown, keypress and keyup must have the tabindex focus
> flag
> > set.". I'm not 100% sure that the keyboard events should be included
> > though.
> >
>
> They left this out of the HTML5 spec. The concern I have is if you make
> the tabindex focus flag set without applying the tabindex attribute then
> you have to determine how that fits in the tab order. Are you suggesting
> this would be equivalent to tabindex="-1" unless the author explictly
> applies a tabindex value >=0?
>
>
>
> > And additionally "Elements that are the target of an animation whose
> begin
> > or end lists include an eventbase timing specifier triggered by the
> > following user interface events: focusin, focusout, focus, blur,
> click.".
> > I've intentionally left the keyboard events off here, due to that
> needing
> > further spec changes to work in that context anyway.
> >
> > The above is essentially what SVG Tiny 1.2 states for focusable=auto,
> > http://www.w3.org/TR/SVGTiny12/interact.html#focus.
> >
>
> Let me look at SVG tiny. Doug was going to add the keyboard navigation
> features of SVG tiny.
>
> >
> > 3) in the "being renderered" defintion, <defs> and other invisible
> > elements, e.g all the animation elements should be explicitly listed.
> Also
> > "some equivalent in other styling languages." is rather vague, and I'd
> not
> > consider SVG a "styling language". Vague statements make it harder to
> test.
> >
> >
>
> OK. I will take a look.
>
> > 4) I'd suggest moving the "being rendered" definition into the
> > https://svgwg.org/svg2-draft/intro.html#Definitions section.
> >
>
> agreed.
> >
> > --
> > Erik Dahlstrom, Web Technology Developer, Opera Software
> > Co-Chair, W3C SVG Working Group
> >
>
>