Categories
HTML5 Specs

The HTML5 longdesc attribute is finally home again

My HTML5 logo

I found out that the W3C had transitioned the HTML5 attribute @longdesc to Candidate Recommendation (CR) status from a tweet by John Foliot:

Yes, I believe I do owe John a beer. I owe a beer to all of those who fought to ensure @longdesc made it to CR—especially Laura Carlson, who worked so diligently on behalf of this attribute, and other HTML5 accessibility features.

Years ago I was heavily involved in the W3C HTML5 effort, though I was frequently at odds with Ian Hickson, HTML5’s sole editor at the time, and some of the Working Group’s management. Since then, the W3C has transitioned the care and management of HTML back into a group effort, leading to decisions such as giving @longdesc CR status.

I don’t agree with all W3C decisions, but my main concern has always been that the decisions reflect a representation of those who support or depend on the web—not just an elite few. The transition of @longdesc to CR status demonstrates that the HTML5 working process has, indeed, grown up.

Well done.

Categories
HTML5

If it had remained the irrelevant attribute

Recovered from the Wayback Machine.

The latest round of discussions related to longdesc (yes, still) was triggered by a revert request from Laura Carlson:

As you know the editor made changes to the hidden section [1]. This biases an open issue [2] as it directly implements a material change from a change proposal [3]. The Chairs specifically asked for justification for this change in their change proposal review [4]. If the proposal lacks justification, then the spec lacks justification.

The change redefined the meaning for the hidden attribute, from:

When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified.

Elements that are not hidden should not link to or refer to elements that are hidden.

It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.

To:

When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. User agents should not render elements that have the hidden attribute specified.

Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden. In both cases, such references would cause user confusion.

Elements and scripts may, however, refer to elements that are hidden in other contexts.

It would be fine, however, to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.

Similarly, a canvas element with the hidden attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden form element using its form attribute.

The change significantly redefines the meaning for the hidden attribute. Why did the editor make this change? One reason was, as Laura pointed out, bolstering a change proposal to obsolete longdesc in favor of a proposal to use aria-describedby pointing to a section marked by the hidden attribute.

This triggered two separate discussions—one related to making an edit to HTML5 specifically in favor of a change proposal currently under rather contentious debate; the second related to redefining hidden in such a way that aria-describedby would be allowed to point to it.

The revert request was successful, which now leaves the discussion about allowing aria-describedby to point to content marked with the hidden attribute, and this change’s impact, or not, on the decision to deprecate longdesc. I’m not going to get into the longdesc deprecate debate—my views on this are widely known and I’ve long been in support of keeping this attribute in the HTML spec. Instead, I want to focus on the change to hidden.

A recent post to the HTML-WG mentioned separating the aria-describedby/hidden issue into a separate survey (and there’s now an issue for it). However, I wanted to remind the HTML-WG co-chairs that they already decided this issue back in 2010.

In 2010 I made a request to remove the hidden attribute from HTML5. In the change proposal to support the request, I wrote:

The hidden attribute was once named the irrelevant attribute, supposedly because the attribute is used to mark the contents of whatever element it is attached as “irrelevant”. The attribute was renamed because, a) the irrelevant term was confusing, and b) techs misspell words like “irrelevant”.

Is the content truly irrelevant, though? Consider the definition for the attribute:

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

“An irrelevant element is not one that is active, receiving events, participating in the web page, or form submission. The only truly irrelevant page component is one that doesn’t exist. If people want a truly irrelevant page section, they should use the DOM to create and remove the element, as needed. There is nothing about the behavior associated with removing an element from user agent rendering that is made more meaningful using a single-purposed HTML attribute, rather than using a simple combination of CSS property and ARIA attribute. Both have to do with the presentation of the element.”

Presentation with the hidden attribute isn’t an incidental purpose, it is the primary purpose of the attribute. Rather than separate presentation and structure, it firmly welds the two.

My request to remove hidden wasn’t successful, based on the strength of arguments in favor. What were these arguments? The following is the primary one, from the counter-proposal:

Authors of web documents and applications often need to temporarily hide certain content from readers and users. Via a combination of script and CSS, such functionality is possible to build today, and there are hundreds of such implementations extant on the web. It’s clear that hidden=”” Solves Real Problems. Attempting to implement such functionality with JavaScript and CSS is fundamentally more difficult and error-prone than hidden=””. hidden=”” is literally the simplest thing that could possibly work, and thus we Avoid Needless Complexity in its design. By making it as easy as possible to author, and by defining uniform UA behavior (unlike bolt-on scripts which emulate this functionality), we preserve our Priority of Constituencies. Bolt-on 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. hidden=”” thus promotes Accessibility more than bolt-on alternatives.

In the survey deciding the issue of keeping hidden or not, several arguments in support of keeping hidden were given.

Cynthia Shelly wrote:

The existing mechanisms all miss one case or another, and it is complicated to understand when to use one over another. The new hidden attribute covers all the cases in a way that will make it much simpler to include markup on a page that is intended as input to a script rather than output to a user.

Gregory Rosmaita wrote:

a native solution which provides the means of marking content as not yet or no longer relevant, is highly desireable; while such a feature, of course, needs to be harmonized with what ARIA offers, it MUST be remembered that aria-hidden is part of a bridging vocabulary, which provides semantics and functionalities which native markup does not provide; the hiding and exposition of content that is not yet, or is no longer, relevant should not be left to scripting or an overlay such as ARIA, but should be an organic part of HTML5.

Jonas Sicking wrote:

I object to removing the hidden attribute as it would result in missing out of the positive effects listed in http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#Positive_…

My experience working with web authors for several years is that they tend to do what is easy, whereas accessibility often ends up coming second due to time constraints and unawareness.

By including the semantic hidden element, we both make it easier for developers to do what they want, since they can use the .hidden IDL attribute, and they automatically get the desired semantic meaning.

I think it’s very unlikely that as many people would add proper ARIA attributes, as would use the hidden attribute. I think this is the reason that the WAI-ARIA specification encourages developers of markup languages to add semantic elements and explicitly declares ARIA as a bridge technology. I also think this is why the HTML Accessibility TF has endorsed the hidden attribute.

Among the arguments was the assertion that the hidden attribute is equivalent to aria-hidden, but better because the hidden attribute was integrated into the HTML semantics, rather than be “bolted on” via ARIA. Since aria-hidden is used specifically to designate material that is not perceivable to any user, this adds weight to the interpretation of content that is marked as hidden is content that is irrelevant to all users—at least until such time the hidden attribute is removed (equivalent to setting aria-hidden to “false”).

The co-chairs agreed with those who argued in favor of keeping hidden, writing:

It seems that the hidden attribute serves a valid, broad use case. It has interest from implementors and authors.

A number of arguments were made in favor of retaining the hidden attribute. It was argued with partial success that hidden captures useful semantics. Many cited the accessibility benefits of built-in elements and attributes, including hidden. A number of other concrete benefits were cited, such as likelihood of surviving syndication. These positive arguments were in general stronger than the counter-arguments, and provided strong reasons to keep hidden.

There were also arguments made against the hidden attribute. It was argued that CSS+ARIA-based implementations of hidden-like functionality are sufficient, so no attribute is needed. Deployment costs were also cited as a concern. And the semantic nature of the attribute was cast in doubt. In general, these arguments did not overcome the counter-arguments, and are not strong reasons to remove hidden.

The maturity argument against hidden had more weight. 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.

In my opinion, the decision was not necessarily a model of clarity. However, I do believe that this 2010 decision answers the question whether aria-describedby can point to an element marked with the hidden attribute, and the answer is, No.

An attribute used to designate content that is available for scripting purposes is not the same as an attribute that is used to remove the content from visual display. Why? because one implies the same result regardless of type of browser accessing the page, while the other implies something completely the opposite.

My understanding of the decision in 2010 is that “hidden” meant that the material was irrelevant regardless of type of browser accessing the page. This is supported by the fact that at one point in time, the hidden attribute was named irrelevant. The reason the name of the attribute was changed was more one of expediency than change of semantics. The visibility of the content should make no difference on whether it is relevant or not.

As the HTML5 editor, Ian Hickson, wrote when he renamed irrelevant to hidden:

It’s not different from hiding content that isn’t necessary. That’s exactly what it is. It’s a way to hide content that isn’t currently relevant.

I challenged the hidden attribute years ago because it seemed to me it was nothing more than an elemental equivalent of display: none. However, others, including the co-chairs, disagreed with me, and agreed with the HTML5 editor: the hidden attribute had the additional semantics related to its irrelevancy.

Based on this decision two years ago, I’m at a loss to understand why the HTML5 co-chairs would consider an option to allow aria-describedby to link to this content so that it can be rendered by screen readers—in effect, to make the content in the element with the hidden attribute, relevant. Something cannot be both relevant and irrelevant at the exact same time.

Categories
HTML5 W3C

This week in HTML5 in verse

This week in HTML5…in verse.

So <time> is saved
though it may be changed,
and <data> is on the horizon.

<hgroup> is going,
you can hear it moaning,
as HTML5 continues to wizen.
Categories
HTML5 Specs SVG

This page isn’t valid…and who cares

I covered my recent experiments in using SVG in HTML in SVG in HTML. I linked two different example pages with SVG inline in HTML: one dependent on HTML5 parsing (Firefox nightly), the other using the library, SVGWeb.

There’s another difference between the two examples other than just their implementation. The first example, dependent on a browser parsing the page as HTML5, doesn’t validate. The example using SVGWeb, does. Yet, both pages display correctly, as long as you use an HTML5 enabled browser for the first. The odder thing is, neither page is “invalid”.

The HTML markup is fine for both, as is the SVG used. However, the Validator doesn’t like inline SVG at this time, because, we’re told, no browser implements SVG inline in HTML, yet. The SVGWeb example validates because the SVG is contained in a script block. The validation problems with the first example go beyond embedding the SVG element directly in the web page, though. The example also incorporates a metadata element in the SVG that contains RDF/XML.

Embedding RDF/XML into the metadata element is perfectly valid with SVG, and in fact, quite common when people attach Creative Commons licenses to their work. The HTML5 Validator, though, doesn’t really know what to do with this RDF/XML. Why? Because RDF/XML uses namespaced elements, and namespaced elements are taboo in HTML. Yet, SVG is acceptable in HTML5.

Herein we discover the paradox that is HTML5: XML allowed in HTML, but parsed as HTML; extensible namespaced elements that are valid in SVG/XML, becoming invalid when embedded in the non-extensible environment that is HTML5. HTML5 as XHTML likes namespaces. HTML5 as HTML does not like namespaces. But HTML5, as both XHTML and HTML likes SVG, and SVG likes namespaces.

Pictorially, the logic of this looks about as follows (which would not be valid if inserted into an HTML5 HTML document):

Ouroborous

Oh, what is a web designer/developer to do, who just wants to use a little SVG here and there? Enter, stage left, the HTML5 Doctor.

Recently the HTML5 Doctor was asked about attributes and elements from HTML4 that are now obsolete but conforming (or not) in HTML5. Won’t adding a HTML5 DOCTYPE while still using these elements cause the pages to be invalid?

The Doctor’s answer:

While validation is undoubtedly important for your markup and your CSS, in my opinion it isn’t crucial to a site. Allow me to explain, we recently received a couple of emails pointing out that this site doesn’t validate. While there were some errors that have now been corrected, a primary reason why is the use of ARIA roles in the markup. These attributes currently aren’t allowed in the current specification, however there is work underway to make this happen.

To illustrate this point let’s look at Google, the search giant. If you look at the source on Google’s search pages you’ll see they use the HTML 5 doctype.

<!DOCTYPE html>

However, those pages don’t validate because they use the font and center elements amongst others things that we already know have been removed from the specification. Does this mean that users stop visiting Google? No.

Remember too that the specification is yet to be finalised and may still be changed (thus breaking you’re perfectly valid docments), in partnership with this changes to the specification may not immediately take be implemented in the validators. We also need to bear in mind that HTML 5 takes a “pave the cowpaths” approach to development, meaning that the Hixie, et al will look at what authors already do and improve upon it.

The days of validation being an end all, be all, are effectively over with HTML5. By obsoleting (not deprecating) elements that were perfectly valid in HTML4; by not providing an extensibility path within HTML in HTML5, especially considering that new elements will arise over time—not to mention, the inclusion of perfectly legitimate namespaces elements in SVG— all, combined make “validation” a goal, but not an end when it comes to the web pages of the future. We’re more likely to define a set of supported browsers and user agents and worry more about the pages working with these, then be concerned about whether the pages validate in Validator.nu.

So, my one web page with the inline SVG works with the Firefox nightly, with HTML5 parsing enabled. It isn’t valid…but who cares?

Categories
HTML5 Specs

Opera’s TPAC Minutes

The annual TPAC meeting is when standards people involved with W3C specifications get together to see if they can more easily hammer out issue resolutions face to face, rather than in endless email discussions. I suppose we can liken the event to finally meeting that really hot person you connected up with on Facebook—it’s a big of a crap shoot whether anything useful comes of the meeting.

Opera was kind enough to provide company rep impressions of the different meetings, though the W3C is the only entity that can provide official reports.

Among the items I was glad to see was the decision—finally—to publish WebSQL as a Working Group (WG) Note. What that means, boys and girls, is that this spec is dead, and we can finally drop it from our list of HTML5 technologies. Of course it never was HTML5, but that’s beside the point.

The comment on Web Sockets doesn’t reflect the recent findings of security problems and browsers disabling support for Web Sockets. We can all learn from Web Sockets, and how the race to be first isn’t the same as the need to be best.

There was a discussion about redefining previously defined presentational elements such as <s>, <small>, and others as semantic elements. I was glad to see that this discussion happened, because it makes little sense to talk about backwards compatibility, and then redefine a presentational element for semantic use. However, no conclusions was reached, which I guess means that the group broke up and went off to have a beer.

Sometimes I think “semantics” is used as a sort of all purpose lubricant to stuff whatever some folks want into HTML5.

I was not happy seeing the following statement, about accessibility and HTML5:

The a11y Task Force made a list of user requirements (about 100). During the meeting Frank Olivier from Microsoft went through the requirements with the HTML WG and we organized them. It turns out about 10 of them are applicable to the HTML5 specification and are not addressed yet. The HTML WG Co-Chairs as well as the W3C Interaction Domain Lead put their foot down with respect to accessibility potentially delaying the HTML5 Last Call. It was made clear that HTML5 is time driven, not feature driven. So if the work on these requirements is not complete by May next year, it will not happen.

One area of major failing at the W3C is how accessibility has been handled. The W3C initiates working groups that create specifications such as Accessible Rich Internet Applications (ARIA), but even before this spec has a chance to be rolled out as a finished work, the W3C undercuts the work by demanding native implementation of most of the ARIA features in HTML5.

New semantic elements are added to HTML5 with the underlying reasoning being these are necessary for accessibility, but then the elements are not mapped to ARIA or to the accessibility API, leaving them basically worthless lumps of still not implemented technology—none of which can be styled, modified, customized, and few of which come anywhere close to what we have in existing JavaScript/ARIA/CSS implementations today.

The HTML5 Accessibility WG people seem to be spinning their wheels and dragging their feet, but the problem really is that the HTML5 editor keeps tweaking, adding, and removing things that impact on accessibility, forcing the group into a constant state of motion, just trying to stay in step with what’s going on.

The focus is on the “cool” stuff, like HTML5 video and captioning, at the expense of the more mundane, like alt, longdesc, table summary—yet the majority of web pages will never use any of the cool stuff, but will make use of the mundane. What makes this all even more fun is that because we don’t support that old thing deprecation in HTML5 working land, when something like longdesc is pulled, it’s just plain gone. End of story. It is now obsolete. There is no period where the attribute is deprecated, which not only would give folks a heads up about coming obsolescence of the attribute, but also provide an alternative for the attribute’s functionality.

However, seamless transitions are old fashioned—abrupt changes and disconnects are so much more hip.

The HTML5 co-chairs, rather than ensuring all voices are heard equally, have somehow managed to drive all useful discussion out of the HTML5 WG email list to bug reports, which has the advantage of being out of sight, out of mind. They’ve confused the Last Call commenting with bug reporting, encouraged outsiders to comment, but only if they become insiders for the group. They created a working group procedure that ties the working group up in procedures so that procedures are not discussed in the working group email list—which has now become an archive for bug reports, including some really cute ones that come in from the commenting form in the WhatWG HTML5 document, typically consisting of words like, This damn thing has broken my browser….FIX IT!!!!

So to participate in Last Call commenting you kind of have to become some kind of insider, though the whole purpose of Last Call commenting was to get comments from those outside the group…but hey, the majority of insiders in the HTML5 are outsiders, anyway, because the HTML5 WG co-chairs more or less just gives the HTML5 editor whatever he wants because, as we’ve come to find out, the HTML5 specification is being held hostage by a handful of browser vendors who really don’t give a damn what we need or want, because they’re too busy outdoing each other with cool stuff. Like Web Sockets.

Personally, I can’t wait for the official W3C reports on TPAC. Then I can really tell you what I think.