Re: [svgwg] Compatibility of focusability with HTML & platform conventions (#736)

The SVG Working Group just discussed `focusability compatibility`, and agreed to the following:

* `RESOLUTION: Defer to HTML for focusability of foreignObject content`
* `RESOLVED: Clarify the interaction of tabindex and focusable; make it clear this only applies if the UA supports focusable; support is not required; authors are discouraged from using it.`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: focusability compatibility<br>
&lt;heycam> github: https://github.com/w3c/svgwg/issues/736<br>
&lt;heycam> rniwa: inthe current draft, it mentions that SVG elements that are scrollable should be treated as if tabindex is set to 0, so it's focusable<br>
&lt;heycam> ... that's not what HTML does<br>
&lt;heycam> ... to decide whether something is scrollable, you must update styles and layout<br>
&lt;heycam> AmeliaBR: this list was based on the accessibility desires that scrollable should be focusable<br>
&lt;heycam> ... since this isn't an SVG specific feature, it's about HTML nested in SVG, we should be consistent with HTML<br>
&lt;heycam> ... even if that means deferring to platform conventions that aren't ideal<br>
&lt;heycam> emilio: to compute whether an element has scrollbars, you need to run layout.  but afaict the focusability of a scrollable thing only depends on style, not on layout<br>
&lt;heycam> ... if it *could* have scrollbars<br>
&lt;heycam> ... we do allow stuff with scrollable overflow to be focusable<br>
&lt;heycam> AmeliaBR: I think WebKit is the odd one out<br>
&lt;heycam> ... but it's an HTML issue<br>
&lt;heycam> ... I'm OK resolving to add a condition to that, that defers to HTML<br>
&lt;heycam> ... so element within a fO would be focusable accoridn gto the foreign language<br>
&lt;heycam> rniwa: the issue is more the consistency with HTML here<br>
&lt;heycam> emilio: I agree it should be consistent<br>
&lt;heycam> krit: anything else that could be scrollable?<br>
&lt;heycam> rniwa: HTML spec section 6.4.2 defines focusable area<br>
&lt;heycam> ... would be great if the SVG spec just delegates that to decide what's focusable<br>
&lt;rniwa> https://html.spec.whatwg.org/multipage/interaction.html#focusable-area<br>
&lt;heycam> RESOLUTION: Defer to HTML for focusability of foreignObject content<br>
&lt;heycam> AmeliaBR: second part of the concerns are more SVG specific<br>
&lt;heycam> ... the legacy focusable attribute<br>
&lt;heycam> rniwa: one thing that is unclear is the old SVG Tiny 1.2 talks about focsuable = true,false,auto<br>
&lt;heycam> ... new spec doesn't talk about any of the values<br>
&lt;heycam> ... it's unclear whether tabindex or focusable takes priority<br>
&lt;heycam> AmeliaBR: good criticism that we should have specified the interaction<br>
&lt;heycam> ... definitely want tabindex to take precendence<br>
&lt;heycam> ... only we mention focusable is to avoid breaking content that uses that attribute<br>
&lt;heycam> rniwa: do we still want to support the 3 values?<br>
&lt;heycam> heycam: do we still need to support that at all?<br>
&lt;heycam> AmeliaBR: it was working in Edge, at least<br>
&lt;heycam> rniwa: focusable=true is clear cut, to imply tabindex=0<br>
&lt;heycam> ... false, if it's set, it's like a noop<br>
&lt;heycam> AmeliaBR: focusable=false got used a lot since MS browsers were treating every inline SVG as a focusable item<br>
&lt;heycam> ... we can say focusable=false is respected, as long as tabindex overrides it<br>
&lt;heycam> rniwa: so your suggestion is to take the SVG Tiny 1.2 true/false/auto values into the spec, and allow tabindex to always override it?<br>
&lt;heycam> AmeliaBR: officially define focusable, but deprecated, with those three values<br>
&lt;heycam> rniwa: one tutorial I found says that focusable would override tabindex...<br>
&lt;heycam> heycam: but do we have any implementations of focusable?<br>
&lt;heycam> AmeliaBR: Edge does support it<br>
&lt;heycam> mstange: there's a Firefox bug, WONTFIXed 5 years ago<br>
&lt;heycam> ... saying it wasn't in SVG 2<br>
&lt;mstange> https://bugzilla.mozilla.org/show_bug.cgi?id=409404<br>
&lt;heycam> [some discussion about having it in the spec, allowed to implement, not required]<br>
&lt;heycam> rniwa: if Edge wasn't going to change, normative or not probably doesn't matter<br>
&lt;heycam> rniwa: I'm curious what Edge does in terms of priority between focusable and tabindex<br>
&lt;heycam> emilio: in the bug comment, IE &lt;= 11 only supported focusable, and not tabindex<br>
&lt;heycam> rniwa: can we agree on a non-normative note?<br>
&lt;heycam> AmeliaBR: I think we should have a normative thing, if you implement it, this is how it interacts with tabindex<br>
&lt;heycam> ... I wouldn't mind saying every browser should implement it but it's deprecated<br>
&lt;heycam> rniwa: question is whether implementors will implement focusable<br>
&lt;heycam> myles: I think the answer is no<br>
&lt;heycam> krit: I think the note in the spec should advise against using it<br>
&lt;heycam> RESOLVED: Clarify the interaction of tabindex and focusable; make it clear this only applies if the UA supports focusable; support is not required; authors are discouraged from using it.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/736#issuecomment-532964289 using your GitHub account

Received on Thursday, 19 September 2019 04:49:00 UTC