Working Group Decision on ISSUE-95 hidden

Semantics

The hidden attribute is advocated based on the argument that it carries semantics. Proponents argue that the hidden attribute provides useful semantics—that of content that is not yet or no longer relevant. And it is posited that semantics should be expressed at the semantic layer (HTML), not the presentational or accessibility layers; otherwise tools have to guess from CSS.

There doesn't seem to be much dispute about the benefits of semantic attributes. It is not disputed that expressing semantics with a built-in element or attribute is more likely to be media independent, and more likely to afford universal access.

However, some dispute whether the attribute is truly semantic in nature. They argue that presentation is not semantics, that the specific proposed hidden presentation doesn't change meaning, and that the idea of irrelevant or hidden content is presentational construct. Some would go so far as to say that having attributes with built-in default presentation is a layering violation.

The fact that a semantic has a closely related default presentation does not by itself render it non-semantic. Many elements and attributes have default presentation which is deeply tied to their semantics. This is clearly true of many of HTML's classic block and inline elements. For example, the <p> element is by default a block with some margins, but this is closely related to its nature as a paragraph. HTML is by nature a language for documents and applications, so it is natural that some semantic concepts are closely tied to a particular presentation.

Some have argued that the semantics of the hidden attribute are false, that such content is not truly "irrelevant" because for example embedded scripts may execute. However, this mainly seems to make the case that the hidden attribute should not be used in such a confusing way. On the other hand, it was pointed out that HTML4 includes the idea of semantically hidden content with <input type=hidden>, and the hidden attribute merely generalizes this to all elements.

The bottom line comes down to this: is the concept of "irrelevant" or "semantically hidden" a meaningful semantic? Reasonable cases were made for both sides of the question. Therefore, this issue does not constitute a strong argument to either remove or keep the element.

A Common Pattern

It is not disputed that the hidden attribute captures a common idiom in Web documents and applications. Some specific examples of this idiom include hiding individual steps of a multi-step process.

Many viewed it as important to serve common interface idioms with built-in language functionality. Others conceded that this pattern was common, but that CSS+ARIA-based implementations would be sufficient. In addition, it has been claimed that the benefits of adding built-in attributes may exceed the costs.

To determine whether this particular common pattern should be served with a built-in attribute, it is necessary to investigate the feasibility of CSS+ARIA-based implementations, and the costs and benefits of native implementations.

CSS+ARIA-based Implementations

Advocates of removing the hidden attribute argue that implementing hiding is comparatively easy, and can be done with CSS and ARIA. However, it is disputed whether this alone is sufficient to omit a feature from the core of HTML5 itself. Some made the argument that for a semantic markup language, the availability of presentational and accessibility-layer alternatives should not preclude adding a declarative construct.

The main alternatives proposed were either setting "display: none" with CSS, or using the aria-hidden attribute, or using a stylesheet rule to cause aria-hidden to also result in visual hiding. Those in favor of keeping hidden argued that this was error-prone and unnecessarily complicated. Because visual hiding and hiding from assistive technologies use separate constructs, authors may mismatch them. It was argued that emulations of hidden="" can fail to correctly hide content in a media-independent way, resulting in a degraded experience for users of aural browsers and other AT tools.

While the downsides of CSS+ARIA-based implementations are not grave, there appear to be some genuine disadvantages. So the ability to achieve the functionality of hidden using CSS and ARIA is not a strong argument for removing hidden.

Deployment Costs

Opponents of the hidden attribute argue that the costs of implementing hidden across the whole ecosystem (html editors, authoring tools, validators, browsers, educational (materials) may be significant and may exceed the benefits of packaging a common idiom, even though the costs are not as high as in other cases.

However, there seems to be some evidence that many of the affected constituencies are willing or even eager to bear the cost.

Implementors of the of the leading browser engines, WebKit, Gecko and Presto, have expressed interest in implementing this attribute. Microsoft, the vendor of the remaining well-known browser engine, Trident, have not made any specific statements, but have not objected to it, even while citing other aspects of HTML5 as problematic.

There is some evidence that the hidden attribute is well-liked among authors. Searching the material available online confirms that the attribute is largely well received. In addition, of the many authors who have recently written or are currently writing books on HTML5, few have complained about the burden of documenting this attribute.

A final point is HTML editing software. Having any new global attributes is mentioned as a potential burden for authoring tools. However, others counter that without a new attribute, editors can't handle hidden-like functionality in an equally consistent and reliable way. If this semantic is carried by a variety of CSS properties and markup attributes, then editors would have a slightly harder task. In any case, there is no indication of any implementors of authoring tools commenting on this matter, and suppositions about how they may be impacted are less persuasive than direct input.

Overall, while it is true that any new attribute has deployment costs, in this case, many of the affected communities seem willing to bear the costs. And it is conceded that the costs are not as high as for other constructs. Thus, deployment costs are not a compelling reason to remove the hidden attribute

Accessibility

Many of the arguments in favor of hidden and against removing it were based on accessibility. Several WG participants cited expert opinion. It was pointed out that the use of semantically rich elements and attributes in general is an expressed desire of the W3C Accessibility (WAI) community. And in particular, the HTML WG's Accessibility Task Force opposes the removal of the hidden attribute.

In addition to citations of expert opinion, concrete arguments were made for improved accessibility. In particular, many pointed out that authors are much more likely to create accessible markup when the elements and attribute they would wish to use naturally provide for accessibility, rather than having to use additional markup or specific libraries to tend to accessibility. People are much less likely to create accessible markup if they have to add extra markup specifically to make it accessible, it was argued.

In particular, comparisons were drawn to the aria-hidden attribute, which partially serves the need to hide the content semantically, but requires authors to separately arrange to visually hide the content. It is argued that accessibility would be improved by providing a mechanism that handles visual hiding and hiding from assistive technologies at the same time.

Others countered that hidden may have unknown accessibility problems, either as designed or as it will be implemented, and there has not been sufficient investigation to show that there aren't problems. While it is true that there may be undiscovered problems, this is less concrete than the argument for benefits. In addition, the need for further review is not an argument for dropping a feature at this stage of the process. Last Call is one of the primary tools that Working Groups use to seek broader community review.

Benefits of Native Implementation

A number of specific benefits were claimed for a native attribute to support the functionality of hidden, as opposed to a CSS+ARIA implementation.

First, some pointed out that built-in markup is more likely to survive syndication or other contexts where whitelisting is likely, as compared to purely CSS-based implementations. Second, some mentioned that the hidden attribute reduces overall code size; while next to negligible at the individual page level, this could be a measurable difference over millions of page views.

Others cited broader benefits. It was argued that when a particular semantic, presentation, default behavior and accessibility presentation all go together, it's more convenient for authors to have a single construct to take care of all aspects. Doing so, the argument goes, avoids needless complexity. The case was made that having the hidden attribute would reduce incidence of media-dependent, buggy author attempts to emulate such functionality using JavaScript, ARIA and CSS.

Some downplayed the value of these benefits, but the claimed benefits were not rebutted. Thus it is clear that a native implementation of hidden would provide some genuine benefits.

Maturity

Some argued against hidden on the basis of maturity, for example that it is a good idea but "half-baked" and could be improved. The proper way to address flaws in the hidden attribute is to provide specific comments identifying those flaws. A general statement of half-bakedness is not a strong objection.

It was claimed that hidden lacks a transition plan, however it is clear that the strategies described under Degrade Gracefully in the old design principles draft apply.

Other arguments were based on lack of native browser-hosted implementations, or presumed future lack of adoption, or the lack of "unambiguous support". These are fair points. However, in the W3C processes, it is not expected that all features will be implemented prior to Last Call. Indeed, it is only after Last Call that a formal Call for Implementations is issued. It is during the Candidate Recommendation stage that we should prune features that seem promising, but do not gain a critical mass of implementation support and author adoption.

Some indicated specifically that the precedence of the hidden attribute relative to display: none and aria-hidden must be defined. Examining the draft, it seems that the precedence relative to display: none is defined in the rendering section; the rendering effect of hidden is defined as a rule in the user agent stylesheet, so the CSS cascade defines the precedence relative to other uses of the display property. The relationship to aria-hidden is indeed not defined. It seems this objection could be filed as a bug, since it is a simple matter to define one way or the other.

Overall, maturity considerations would argue somewhat in favor of removing the hidden attribute. Maturity must, of course, be balanced against other factors, and considered in light of the fact that it is not critical for removal to occur at this time.

Conclusions

A number of arguments were made in favor of retaining the hidden attribute. A plausible case was made that hidden captures useful semantics; it was not obviously stronger or weaker than the counter-arguments. The hidden attribute is agreed by all to capture a common idiom. Accessibility was cited by many as a benefit of the new attribute, and indeed a good case was made that accessibility would be improved overall. Other concrete benefits of a native hidden attribute were identified, including greater likelihood of surviving syndication, reduction in code size, and reduction of authoring complexity. These benefits were not successfully rebutted and argue in favor of keeping the hidden attribute.

There were also arguments made against the hidden attribute. It was argued that CSS+ARIA-based implementations of hidden-like functionality are good enough, and therefore no hidden is needed for this admittedly common pattern. However, some specific downsides to CSS+ARIA-based implementations were identified. Deployment costs were cited as a reason to remove the hidden attribute. However, many of the affected communities seem to believe they would benefit overall, and are willing to bear the costs. Overall, these arguments for removing the hidden attribute did not constitute strong objections.

One argument for removing hidden had more force—the maturity argument. The Working Group has in the past chosen to remove features from the draft for reasons of maturity. However, this factor was not decisive in itself, at least at this time, since the W3C Process allows further opportunities for review, implementation and feedback.

Overall, the arguments in favor of keeping hidden were stronger than the arguments for removing it. Only the maturity argument provided a strong reason for removal, and it is outweighed by the arguments in favor of keeping it. The hidden attribute is the type of attribute we should have in the spec at this point.