Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Tests for SVG tabindex/focus/blur #10149
SVG defines focus/blur/tabindex as behaving the same as HTML.
This takes some tests from HTML and adapts to the SVG template used in the SVG folder. I included them in the interact folder as that page (scripting) is the one that defines which elements are focusable in SVG.
Apologies if I got the folder structure wrong. I believe I suppose to put the tests in the in the scripted folder.
Note: SVG say that the following are focusable by default:
I only included a test for the root-most SVG element, as SVG further defines that zoom and pan controls only work on the root most SVG element, so it will pass with or without that control.
I also assumed that video/audio with user controls meant the controls attribute.
These tests match the behavior of the HTML equivalents. Edge fails the tabindex tests when checking the content attribute as there is a non-tabindex related bug with attribute reflection in SVG where the canonical case is lowercase. Otherwise those tests would pass.
I couldn't find any HTML tests specific to blur() so I reused the composed test. blur() passes in Edge, but doesn't support event.composed.
I didn't add tests for dataset (which is in the same section of the spec) as there are already tests in HTML that detect dataset on SVG
requested review from
Mar 23, 2018
Thanks for this, David! (When I discovered Edge's
I agree it makes sense to put these in the
Additional tests still required for full coverage of this section (not necessarily in this PR, just keeping note):
Yeah, I think some of these would probably be a separate PR as they're not covered by the HTML versions either (presumably :focus is in a CSS test for example), and perhaps the existing tests in this PR would be enough to get the HTML PR merged for adding the mixin we require to move these definitions into HTML.
I'll look into an additional PR though that adds things that don't need to be in here. the
(Edge is fixing our reflect bugs. Now our tree work is done we're working on improving how we deal with attributes)
Re: should vs must: I don't think so. Edge passes them at least :D My understanding from HTML is most of the focusable by default elements are "should" anyway (or at least there is language about being up to the user agent/platform conventions, so it is probably fine to include them.
re: blank.html. The text mentioned valid (nested) browsing context, so I added a document. I guess I could add a data URI or such too but I just copied what was used in other tests and didn't want to deal with encoding quotes and angle brackets. I wasn't 100% sure if the definition meant if it is just an iframe with no html/svg document that it shouldn't be focusable.
Re: controls: do you mean zoomAndPan or video/audio, as it isn't 100% clean that the latter means the controls attribute?
Re: non root SVG: I thought I added a basic test for this but may be mistaken. I'll look into it.
Ah, I was thinking of the CSS test metadata. I'd like to get to the point of adding similar metadata for all SVG tests (plus SVG-specific metadata, like which processing modes the test is relevant to), but that will wait until we have an agreed-upon metadata system.
Ah, ok. Makes sense.
I meant zoomAndPan, but the general wording is used for both, and for the same reasons. For audio/video controls, the user agent is supposed to add controls even without the attribute if scripting is disabled, and may add controls regardless (in practice, that is usually with a context menu option), so again the focusability rule just focused on whether the controls are there.
But if the default behavior in HTML is to not make the element focusable just for context menu controls, then we can match that. Or leave out the no-attribute test & only test that the elements are focusable if the author has specifically requested user-agent controls.
You had a test of