Clarify focus management for SVG & define rendered/non-rendered elements #55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- incorporates the visibility/display section formerly in the Painting chapter - introduces new definitions and element categories (renderable versus never-rendered elements)
- Clean up & re-organize rendering tree definitions from previous commit - Expand and clarify how HTML keyboard focus model applies to SVG The keyboard focus section: - Includes normative requirements for which SVG elements should be focusable by default, with a little wiggle room for the Opera Presto behavior of treating links separately rather than as part of the main tab index. - Includes a normative requirement that user agents visually render keyboard focus. - Includes mention of the SVG Tiny 1.2 `focusable` attribute with recommendations that user agents support it (for the `true` value) but authors not use it. - Explicitly repeats (from HTML) the expectations that focused element should scroll into view and that a generic focusable element will fire a `click` event in response to the normal keyboard activation process.
Fixing broken links & unrecognized terms
- lowercase RFC keywords, cause apparently that's how we roll in SVG WG. No need to shout to prove we're serious. - mark the Rendering Tree section as ready for WG review
AmeliaBR
added a commit
that referenced
this pull request
Mar 12, 2016
Clarify focus management for SVG & define rendered/non-rendered elements
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request consists of two new sections, at least one of which (focus management) needs discussion & approval by the working group because it's introducing new normative requirements. Links are to compiled versions of the specs.
Rendering definitions:
Shouldn't be controversial. Gathers up content and implicit behavior into clear definitions. Some links/bookmarks in other specs may be broken by moving the section on display/visibility properties to the rendering chapter from the painting chapter.
Focus management
Addresses the issues brought up by @richschwer in Issue #50.
Introduces the following normative requirements (based on usability problems in current implementations of keyboard focus control in SVG):
focusableattribute, but authors should not use it. I wouldn't object to downgrading "should" to "may", but I don't think it would be a large implementation burden to add.In addition, I've added a few important clarifications / consequences which aren't new requirements (in some cases, text is directly copied from HTML) but are relevant to SVG authors:
:focuscan be used to change focus styles, but SHOULD NOT be used to remove visual focus indicatorspointer-eventsto also be keyboard-operable.tabindexshould issue aclickevent on keyboard activation.