Re: [svg2] tabindex and defaults

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
>