Focus behavior in HTML had been under-specified for the past few years, and it was also quite confusing due to a variety of subtle differences between focusing methods, UA-specific behaviors, relation to the tabindex attribute, relations to shadow DOM, etc.
A few months ago Domenic filed a meta-bug that contains a list of things to fix so that we would have a good foundation for further additions to focus-related stuff, and to hopefully make focus in HTML make sense to browser engineers and web authors!
Types of focus
You may know that you can focus on stuff by clicking on them, tabbing, or calling focus() on it — but did you know that things might be focusable with one method but not with others? Domenic and Mu-An made a giant interactive list of HTML elements to showcase how they react to different methods of focusing, and can be tested from various browsers to show the difference between them.
To reflect the varying behaviors of focus in various UAs in the spec, we classified focusability into three types: “programmatically focusable”, “click focusable”, and “sequentially focusable”.
If an element is programmatically focusable, it will get focused when calling the focus() method on it or when putting an autofocus attribute on the element. In all platforms, all elements that are either click focusable or sequentially focusable are also programmatically focusable, so “programmatically focusable” is interchangeable with “focusable”.
If an element is click focusable, the element will get focused when it’s clicked. This has the same set of elements as “programmatically focusable” in most UAs/platforms. A notable exception is Safari where non-editable form controls (checkboxes, etc.) are not click focusable by default.
If an element is sequentially focusable, the element can be focused through “tabbing” — in most UAs this means pressing Tab/Shift+Tab (and in Safari, Option+Tab too!).
Previously the spec didn’t clearly differentiate “programmatically focusable” and “sequentially focusable”, didn’t even mention “click focusable”, and used the “tabindex focus flag” concept which was slightly confusing due to its relations with the tabindex attribute. So we updated it in this PR.
As you may know already, built-in elements like <button>, <input>, <a>, etc. all have a “default” focus behavior — they are focusable (or not) by default. When the tabIndex property getter is run on an element whose tabindex attribute is not explicitly set already, it will return 0 sometimes and -1 other times. Previously, the spec said to return 0 if the element is “focusable” by default (which type of focusable?), and -1 otherwise. But this wasn’t implemented anywhere, because of possible differences in which elements are focusable by default in various UAs. So now the spec actually checks if the tag name is one of the tag names included in a pre-defined list. This is quite awkward, but at least it’s interoperable! (PR is here.)
Now, what is the use of tabindex exactly? You can make an element focusable by setting its tabindex attribute to an integer. This will set the tabindex value, and thus impact the focusability of the element. If the integer is non-negative, the element is also sequentially focusable. You can’t, however, make an element not focusable at all through this attribute — there is no value you can set the tabindex attribute to on a <button> that will stop it from being focusable.
You can also modify the order of elements traversed with sequential navigation/tabbing — elements with a positive tabindex value will be traversed first, in ascending order (and in tree order in case of a tie), and then elements with a tabindex value of zero (or unspecified but the element is sequentially focusable by default), in tree order.
The autofocus content attribute is useful if you want to set focus on a form control element on page load. However, it had some issues such as:
The autofocus attribute was available only for some form control elements, and unavailable for other focusable elements like <summary>, <div contenteditable="true">, and <span tabindex="0">.
The behavior with an autofocused element in a page accessed with a fragment identifier (e.g. https://example.com/#foo) was not interoperable.
What should happen if there are multiple autofocused elements, and one of them is not focusable?
The HTML specification and the SVG specification were updated to resolve these issues by changes 1, 2, and 3. Now the autofocus content attribute and the autofocus IDL attribute are available on all HTML and SVG elements. The autofocus content attribute is not processed if its document has a fragment identifier, or has a focused element. If an autofocus element is not focusable, the element is skipped and another autofocus element is handled.
Shadow DOM and delegatesFocus
All of the previously mentioned concepts were already specced in the HTML spec in some way, albeit a bit unclear, not reflecting the actual behavior, etc. Focus behavior with shadow DOM, though, had not been upstreamed from the old Shadow DOM spec at all, so this part of the effort took the most time overall. Since some parts of the Shadow DOM spec on focus were unclear and needed more explanation, we also took a look at how it’s implemented in Blink to get the exact behavior down, and discussed with other browser vendors and web developers on whether we want to keep the implemented behavior or not in some cases.
A new concept added (PR 1, 2) by Shadow DOM is “delegates focus”, which is used when you want attempts to focus on a shadow host to not focus on the host itself, and instead delegate the focus to within the shadow tree (like <input type="date">!). In Blink, this delegation uses the sequential focus navigation order, but we think it is a bit weird and started a discussion on how this should actually work — finally changing the delegation to respect the protocol of whatever the focusing method is originally used. (That is, use sequential order if we used tabbing, otherwise use flat-tree order and respect click focusability if needed.)
Now that we have a good-enough spec for focus, we have a good foundation for future additions to focus. One new relevant proposal is “custom element default focusability”. As we’ve mentioned, built-in elements have a “default” focus behavior — even though they don’t have a tabindex value explicitly, they are still focusable (or not). When you’re making custom elements, though, currently there is no way to make them focusable by default, without setting the tabindex attribute. The proposal listed various ways this might be solved, and it was talked about in TPAC with a relatively positive response from various parties. Do check it out if you’re interested!
In summary, focus was and is still quite complex to understand. But, at least now there’s a clear source of truth for it, and the browser vendors are working to make it interoperable — implementing new changes to the spec as soon as they can. There are still lots of focus-related things that need to be specced (we’ve heard people mention focusin/focusout, more CSS selectors, etc.), so if you’re intrigued by this post, know that you can also contribute to fix more things like these!
Having an old and mostly confusing focus spec, different types of focus, and multiple uses for tabindex made things quite complicated when starting out. However, one of the trickiest parts of focus, in my opinion, is the fact that what is focusable/click focusable/sequentially focusable might differ in different UAs, and it might be dynamic as well! (E.g. in Safari what’s sequentially focusable changes if you hold down the Option key!) This means we need to make sure the spec is written to allow for differences, but is still, um, specific enough to make things not too ambiguous.
Overall, we’re happy with the result of this effort. We’d like to thank all the parties involved that participated in various ways: experimenting, reviewing spec PRs, implementing the changes, commenting/participating in discussions, etc. Special thanks to Kent Tamura (who wrote some parts of this post and did the autofocus specs) and Domenic Denicola (who kickstarted this whole effort, reviewed all the PRs, and suggested + reviewed this post).
Now we can focus on other parts of HTML Standard...
Based on a query of the HTTP Archive data set, containing the raw content of the top 1.3 million web pages, we find the relative usage of each HTML element. The fieldset element is used on 8.41% of the web pages, which is higher than other popular features, such as the video and canvas elements; however, the legend element is used on 2.46% of web pages, which is not ideal for assistive technologies. Meanwhile, the form element appears on 70.55% of pages, and we believe that if interoperability bugs were fixed, correct and semantic fieldset and legend use would increase, and have a positive impact on form accessibility for the web.
Fieldset standards history
In January 1997, HTML 3.2 introduces forms and some form controls, but does not include the fieldset or legend elements.
The FIELDSET element allows form designers to group thematically
related controls together. Grouping controls makes it easier for users
to understand their purpose while simultaneously facilitating tabbing
navigation for visual user agents and speech navigation for
speech-oriented user agents. The proper use of this element makes
documents more accessible to people with disabilities.
The LEGEND element allows designers to assign a caption to a FIELDSET.
The legend improves accessibility when the FIELDSET is rendered
non-visually. When rendered visually, setting the align attribute on
the LEGEND element aligns it with respect to the FIELDSET.
In December 1999, HTML 4.01 is published as a W3C Recommendation, without changing the definitions of the fieldset and legend elements.
Of the 26 issues filed against the specification, 17 are about rendering interoperability. These rendering issues affect use cases such as making a fieldset scrollable, which currently result in broken scroll-rendering in some browsers. These issues also affect consistent legend rendering which is causing web developers avoid using the fieldset element altogether. Since the fieldset element is intended to help people who use assistive technologies to navigate forms, the current situation is less than ideal.
HTML spec rendering issues
In April of this year, Mozilla developers filed a meta-issue on the HTML specification “Need to spec fieldset layout” to address the ambiguities which have been leading to interoperability issues between browser implementations. During the past few weeks of work on fieldset, we made initial proposed changes to the rendering section of the HTML standard to address these 17 issues. At the time of this writing, these changes are under review.
Proposal to extend -webkit-appearance
Web developers also struggle with changing the default behaviors of fieldset and legend and seek ways to turn off the “magic” to have the elements render as normal elements. To address this, we created a proposal to extend the -webkit-appearance CSS property with a new value called fieldset and a new property called legend that are together capable giving grouped rendering behavior to regular elements, as well as resetting fieldset/legend elements to behave like normal elements.
The general purpose proposed specification for an "unprefixed" CSS ‘appearance’ property, has been blocked by Mozilla's statement that it is not web-compatible as currently defined, meaning that implementing appearance would break the existing behavior of websites that are currently using CSS appearance in a different way.
We asked the W3C CSS working group for feedback on the above approach, and they had some reservations and will develop an alternative proposal. When there is consensus for how it should work, we will update the specification and tests accordingly.
We had also considered defining new display values for fieldset and legend, but care needs to be taken to preserve web compatibility. There are thousands of pages in HTTP Archive that set ‘display’ to something on fieldset or legend, but browsers typically behave as display: block was set. For example, specifying display: inline on the legend needs to render the same as it does by default.
The WebKit and Edge teams are aware of bugs, and we will follow up with them to track progress.
The fieldset and legend elements are useful to group related form controls, in particular to aid people who use assistive technologies. They are currently not interoperable and are difficult for web developers to style. With our work and proposal, we aim to resolve the problems so that they can be used without restrictions and behave the same in all browser engines, which will benefit browser implementers, web developers, and end users.
(If you’re interested in the IPR status of WHATWG standards this post is for you; otherwise, feel free to skip.)
One aspect of last year's working mode changes is the periodic publication of a Review Draft for each WHATWG Living Standard, as per the IPR Policy. The WHATWG published an initial five of these just now:
To get notified of future Review Draft publications you need to watch the Living Standard’s corresponding GitHub repository. You’ll find these repositories linked from the top of the standard.
Then you can filter the emails generated by watching this repository by looking for the subject-line prefix “Review Draft Publication:” which the WHATWG will consistently use as per the Maintainer Guidelines.
Watching the repository is the only way to get notified going forward. This blog post serves as an initial announcement and as a way to make everyone familiar with the process going forward.
Thanks for reading through three non-technical posts in a row. It will get technical again soon!
Posted in WHATWG | Comments Off on First set of Review Drafts published
The recent changes to the WHATWG are designed to help the web-standards development community work together across the broadest possible spectrum of developers, implementers, and end-users. As part of this change, we decided to move our standards from being licensed under the CC0 public domain dedication to the CC BY license.
This decision was not made lightly. We valued the alignment of CC0 with the original public domain dedication of the WWW project; the ease with which it allows remixing and refactoring of standards; and the way in which it allows copying of snippets or examples into software that implements or uses the standards.
While CC0 is beneficial in some ways, it also has some disadvantages. The lack of an attribution requirement may seem convenient, but it can also cause confusion in the standards community. For example, there are derivative specifications ("forks") that are not prominently identified as copies of WHATWG standards. Such unattributed forks create confusion both about the origin of the standard and about any applicable intellectual property rights (IPR) commitments. Use of the CC BY license makes it easier for implementers to trace what they are implementing back to the original source and its accompanying IPR commitments.
Additionally, CC0 is not approved by the Open Source Initiative. Although their reasoning is not very applicable in the context of the WHATWG, which has its own system for patent grants, this lack of approval from a prominent organization involved in defining "open source" can discourage participation.
Moving to CC BY addresses these disadvantages and also allows for a reduction in license proliferation. We were able to replace the custom license of the HTML Standard, which was a source of some confusion, with CC BY. CC BY still allows modification and redistribution, but adds on the relatively modest burden of attribution. We believe that, on balance, this change is the best path forward for the community.
Posted in WHATWG | Comments Off on Changing the copyright license for Living Standards
The WHATWG has been going great since it began in 2004, but without participation from all the browser engine implementers, was only partially meeting its goals. Over the last year, engineers and attorneys from the organizations behind Blink, Edge, Gecko, and WebKit have worked together to find a way forward that works for all the stakeholders.
The organizations behind the four major integrated browser engines — Apple, Google, Microsoft, and Mozilla — have developed an Intellectual Property Rights (IPR) Policy and governance structure for the WHATWG. This enables more people to collaborate on Living Standards.
The WHATWG day-to-day activities can mostly proceed as-is. Legalities are kept to a minimum and do not disrupt WHATWG’s culture of pragmatic collaboration. Very briefly:
The Working Mode has been updated to reflect the way the WHATWG operates.
The IPR Policy envisions WHATWG operating as a set of workstreams, each developing a Living Standard (or possibly a set of inextricably interdependent Living Standards). Contributors to workstreams make a binding promise to license their contributions and any patents covering them on a royalty-free basis; there is also a new mechanism to generate broader commitments on periodic snapshots of the Living Standards.
There is a Steering Group (see the whatwg/sg repository) to oversee the IPR Policy and to ensure that Living Standards are developed per the WHATWG Principles.
Why is this happening?
The WHATWG has operated successfully since 2004 with no formal governance structure, guided by a strong culture of pragmatism and collaboration. Although this has worked well for driving the web forward, we realized that we could get broader participation by being clear about what rights and responsibilities members of the community have. Concretely, this involves creating an IPR Policy and governance structure.
To stay true to our culture, we’ve created the most effective legal and governance policies we think can serve that purpose. The new Steering Group is empowered to implement the policies, address problems that arise, and to modify them to minimize problems in the future.
Overview of new structure and operations
The WHATWG remains a community. Contributions are invited from all, with no membership or fees. Communication is conducted in public, with proposals judged by their technical merit, the community, and implementers.
A noticeable change is a request to make a legally binding promise to offer a royalty-free license on any relevant patents, via our new Contributor and Workstream Participant Agreement. Functionally, this process is similar to signing a CLA when contributing to an open-source project. Once you’ve done that, we hope participants will notice the changes to WHATWG mainly as an exception handling mechanism, and not part of the day-to-day workflow.
To give employers and individuals a fair chance to review the agreement, the IPR Policy, and their patents, there's an initial grace period. Until January 11th, 2018, you can continue to participate and contribute even if you haven't yet signed the agreement. After the grace period is over, you'll have to sign the agreement to continue to participate. Of course, you're welcome (and encouraged!) to sign early.
There are a number of documents describing all this in detail:
Principles: These serve as a guide to participants, editors, and Steering Group representatives, and are meant to capture the essence of the WHATWG.
Contributor and Workstream Participant Agreement: This document secures an appropriate intellectual property commitment from participants. Those who work in the field of web technologies will need their employer to sign this as well. All contributors will agree to this (possibly automatically via their employer).
IPR Policy: This document describes new processes to publish Review Draft snapshots of Living Standards for patent review, exclusion, and commitment. This process is similar to that used by many other standards development organizations, but on a regular cadence instead of waiting for a formal draft or final publication. This document is primarily intended for lawyers.
Workstream Policy: This is a more formal document that defines terms and describes how workstreams are created and operate under the IPR Policy.
Working Mode: This explains how WHATWG works day-to-day — what editors do, how participants can file issues and suggestions, the criteria for making decisions about the content of Living Standards, and how to deal with disagreements. This document was published before the recent changes, but has integrated some small updates.
Steering Group Agreement: This is the contract among the founding Steering Group members, defining key terms and describing the WHATWG’s purpose, roles, and antitrust policy.
What effect will this have on the WHATWG’s standing as a standards organization?
It closes a gap, as standards organizations are expected to have an IPR Policy and governance structure. And with more implementers on board, it should also reduce the confusion around which version of a standard to use.
Who controls the WHATWG?
The community working there. Living Standards are informed by input from contributors, driven by workstream participants, articulated by editors, and coordinated by the Steering Group. If necessary, controversies are resolved by the Steering Group with members appointed from the organizations that develop browser engines. Substantive technical objections are considered and resolved by the Steering Group, consistent with the principles of the WHATWG.
The WHATWG continues to develop standards as a public community, with input from all. Anyone can contribute to standards here. Even with the Steering Group in place, editors still adhere to the Working Mode, making a judgment call as to whether a change or addition will have multi-implementer support. The main practical difference is that now there is a formal appeals path, in case a Workstream Participant disagrees with the editor’s judgment around multi-implementer support. Additionally, the founding members have helped the community put in place a legal framework to promote royalty-free licensing for Living Standards.
Does the WHATWG operate by consensus?
The WHATWG strives for rough, informal consensus among contributors when drafting Living Standards. After considering input from all parties, the editor of a Living Standard makes the judgment as to whether a feature has enough support behind it to include. Those disagreeing with the editor's judgment can, under what we hope are exceptional circumstances, appeal to the Steering Group, which does have a formal consensus policy.
What are Review Drafts and how do they relate to Living Standards?
The Living Standard is the living, changing standard with the most recent feedback incorporated. This is the document that developers and implementers should use, and that other standards organizations should normatively reference. Review Drafts are used by attorneys to determine if any patent exclusions are necessary.
Features in Living Standards that are controversial will be clearly labeled with a warning. They will be omitted from the next Review Draft if the controversy cannot be resolved in time.
I believe there are problems with a Living Standard, but the Editor does not agree. What can I do?
Present evidence that the standard does not accurately describe how browser engines interoperate today or how they will work in the near future, and convince other workstream participants to support your change proposal. If there is sustained disagreement in the workstream, appeal to the Steering Group to resolve the dispute.
I was not able to engage with the WHATWG productively in the past. Why should I try again?
The WHATWG now has a clearly documented Working Mode that makes the process more transparent and less surprising. Additionally, everyone is expected to abide by the Code of Conduct.
Can other organizations become part of the Steering Group?
If additional integrated browser engines beyond Blink, Edge, Gecko, and WebKit get significant mindshare and market share, the Steering Group is empowered to invite the organizations behind them to sign the Steering Group Agreement and participate there. This fits with the primary role of the Steering Group in resolving disagreements about whether something will be widely implemented in leading browser engines; apart from that, organizations in the community all participate in the same way.
Posted in WHATWG | Comments Off on Further working mode changes