Categories
Specs

W3C HTML WG Decisions: hidden, longdesc, table summary, and the myth of hidden metadata

Recovered from the Wayback Machine.

In preparation for HTML5 Last Call, the HTML WG (Working Group) co-chairs have been rolling out several decisions—among them ones related to the img longdesc and table summary attributes.

The HTML decision on longdesc was based on the following observation:

The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don’t see this feature to be compelling, and the lack of user demand has been noticed by implementors.

The issue was later re-opened, primarily because of the collection of formal use cases, aggregated through the efforts of WG member, Laura Carlson.

I agree with the decision of re-opening the issue, but feel that the original decision against londesc to have been made in error. The co-chairs stated in the earlier decision that the use cases stated in the original change proposal to keep longdesc were abstract, rather than actual use cases. However, the existence, or not, of use cases has not been a noticeable decision criteria for most of HTML5. Why then this seemingly inconsistent demand for one attribute, when the same demand has not been made of other attributes?

As an example, where is the non-abstract use case for a hidden attribute? There’s was little or no interest in this attribute at the time it was created or renamed from “irrelevant” to “hidden”. The only time the attribute seems to have generated interest is when I filed a change proposal to remove it. The grand implementation plan for it is to set it’s default styling as “display: none”, and automatically add an ARIA value of aria-hidden—both of which can be done now, easily, and without having to use a special purpose attribute.

However, the WG co-chair decision on hidden was that implementors and authors were interested in the attribute. So, hidden stayed.

Yet authors also expressed an interest in keeping longdesc. We know from the discussions before the longdesc poll that people were interested in, even passionate about longdesc. Additionally, if we compare actual implementations between the two, there is broader implementation support for longdesc than hidden.

More importantly, unlike the hidden attribute, which duplicates simple to use and existing technology, there is no replacement for longdesc. If we consider that longdesc’s value is to hold a URI that points to a complex description of the image typically maintained in a separate web page, and to do so without providing a visual indicator in the page, no one has come up with an alternative that provides the same functionality that longdesc provides.

If the concept of deprecation was still supported in HTML5, the lack of alternative would have been obviously evident. Yet, elements and attributes can be moved directly from actively supported to actively discouraged, without regard for existing implementations. As Laura has so ably demonstrated—longdesc has seen use, has been implemented, and there is at least some support for the attribute.

The same can be said for table summary and the decision to make this attribute obsolete. Again, this attribute has a specific use: to provide a textual description of the visual infrastructure of an HTML table for complex tables. Like img longdesc, many HTML tables won’t need a summary attribute. When one is needed, though, there is no alternative to provide this information in the manner that summary provided—a text description that is primarily focused at those using AT devices, such as a screenreader.

Putting the information into the text is redundant, and will be irritating for most people reading the page. Frankly, web page authors just won’t do it.

Providing it in the caption is an inappropriate use of the caption element. We’re told to break the complex data table into simpler tables, but it’s not up to us to say what is or is not an acceptable table structure—not just to provide justification for making obsolete an existing attribute.

How about actual uses of summary? One reason for pulling both table summary and img longdesc is that both have been used incorrectly in the past. Well, without raiding Google’s data store, I’m reasonably certain we’d find the same thing can be said about most HTML 4 elements. Without having to resort to prescience, I’m also fairly certain the same will eventually be said of hgroupfigureasidesection, and article.

Another reason for pulling both longdesc and summary is that hidden metadata is bad. Hidden metadata…balderdash. There is no “hidden” metadata—all the data in the web page is “visible” to some audience. And no, the data doesn’t all have to be available to all audiences. One of the arguments against table summary is that supposedly the information would be useful for others, such as those with cognitive disabilities. However, providing an exact textual description of the table seems more like additional noise for those who have cognition problems than a helpful device. I’m not an accessibility expert, but from a commonsense perspective, I have a difficult time understanding how something that is supposed to help the blind is also going to help those with completely different challenges. Is accessibility really one-size-fits-all?

The other “hidden metadata” argument is that if people copy and paste the table, or the img, the resource will become separated from the accessibility aid. This has been used as a primary argument against longdesc because this attribute can include a relative link, which will break if used in a different domain. Well, I don’t know who copies HTML tables, but if they do, they’ll do so in source, and copy and paste the whole thing. And copying an image doesn’t mean view-source and then copying the img element—it means right clicking on the actual graphic, and then saving it to our computers for use elsewhere.

So, we have one attribute, hidden, that’s easily re-produced with existing technologies, and with little or no use case support other than a group of people saying they want it when it’s existence was threatened, and we have two others—img longdesc and table summary—that can’t be replaced with existing technologies and have real world uses, but we keep the former and get rid of the latter.

I hope I can be forgiven for saying that the decisions seem…inconsistent.

Categories
Specs Technology Web

Why read about it when you can play?

Earlier today I got into a friendly discussion and debate on Twitter about a new web site called W3Fools. The site bills itself as a “W3Schools intervention”, and the purpose is to wake developers up to the fact that W3School tutorials can, and do, have errors.

The problem with a site like W3Fools, I said (using shorter words, or course, since this was Twitter), is that it focuses too much on the negative aspects of W3Schools, without providing a viable alternative.

But, they said, W3Fools does provide links to other sites that provide information on HTML, CSS, or JavaScript. And, I was also told, the reason W3Schools shows up first in search results is because of uncanny use of SEO optimization.

Hmmm.

It may be true that W3Schools makes excellent use of SEO, and it may be equally true that W3Schools commits egregious and painful errors. However, neither of these account for what W3Schools is doing right. If you don’t acknowledge what the site does well, you’re not going to make much headway into turning people off the site—no matter how many cleverly named sites you create.

For instance, one of the superior information sites recommended by W3Fools is the Mozilla Doc Center, or MDC as it is affectionately known. Now, I’m a big fan of MDC. I use it all the time, especially when I want to get a better idea of what Firefox supports. But look at the work you have to put in to learn about a new HTML5 element, such as the new HTML5 hgroup element:

  1. Go to main page
  2. Click on HTML5 link
  3. Search through the topics until you see one that’s titled “Sections and outlines in HTML5”, which you know you want because it mentions hgroup
  4. Have a neuron fire and realize that you can just click directly on hgroup
  5. Go to the hgroup page, past the disclaimer about what version of Firefox supports the element, looking for an example of usage
  6. Realize there is no example of how to use hgroup
  7. Go to the original Sections and Outlines in HTML5 link
  8. Go past some stuff about elephants, looking for example
  9. Go past some bullets about why all this new sectioning stuff is cool, looking for an example
  10. Break down and use your in-page search to find hgroup
  11. Finally find an example of how to use hgroup

As compared to W3Schools:

  1. Go to main page
  2. Click on Learn HTML5 link
  3. Click on New Elements link
  4. Start to scroll down when you realize the new elements are listed along the left side
  5. Click on hgroup
  6. Look at example

One thing W3Schools does well is provide a clean, simple to navigate interface that makes it very easy to find exactly what you need with a minimum of scrolling or searching.

Returning to our comparison between W3Schools and MDC, we then search for information on SQL. Oh, wait a sec: there isn’t anything on SQL at the Mozilla site. That’s because Mozilla is primarily a browser company and is only interested in documenting browser stuff.

So then our intrepid explorer must find another site, this one providing information on SQL. And if they want to learn more about PHP, they have to find yet another site. To learn about ASP? Another site, and so on.

What W3Schools also provides is one stop shopping for the web developer. Once you’ve become familiar with the interface, and once the site has proved helpful, you’re more likely to return when you need additional information. Let’s face it: wouldn’t you rather use one site than dozens?

Screenshot of W3Schools page showing many of the topics

Let’s say, though, that you need information on CSS3. Well, you know that MDC covers CSS, so you return to the MDC site, and you click on the link that’s labeled “CSS”, and you look for something that says CSS3.

What do you mean there isn’t anything that says CSS3? What do you mean that transitions are CSS3—how am I, a CSS3 neophyte, supposed to know this?

Returning to W3Schools, I click the link in the main page that is labeled CSS3. Oh look, in the page that opens, there’s a sidebar link that’s labeled “CSS3 transitions”. And when I click that link, a page opens that provides an immediate example of using CSS3 transitions that I can try, as well as an easy to read table of browser support.

Screenshot of W3Schools CSS3 transitions page

W3Schools doesn’t throw a lot of text before the examples, primarily because we learn web material best by example. Remember that entire generations of web developers grew up with “View Source” as our primary learning tool.

But so far, I’ve only compared W3Schools to MDC. There are other useful sites that the W3Fools site approves. So I try the “Google: HTML, CSS, and JavaScript from the ground up” web page. When it opens, I click the link labeled CSS…

And I get a video about using CSS.

A video.

Remember in junior high or high school, when your science teacher would bring out the projector and you knew you were going to get a video? Do you remember that feeling that came over you? How you kind of relaxed, because you know the teacher wasn’t going to ask you any questions, and you didn’t have to write any notes, or even really pay attention?

I bet some of you even fell asleep during the video.

Videos are good for specific types of demonstrations—when something is complex, with many different steps, and the order of the steps and other factors have to be just so.

When it comes to CSS, HTML, and so many other web technologies, though, video is about the most passive and non-interactive learning experience there is. More importantly, if the video doesn’t have captioning, and most don’t, you’re also leaving part of your audience behind.

Now let’s return to the W3Schools site, this time looking at one of the CSS selector tutorials. The first thing you notice is that right below the example there’s a button, labeled “Try it Yourself”.

W3Schools screenshot showing the Try It button

Why read about it, when you can play?

One of the more annoying aspects of trying to learn about a specific HTML element, or a bit of CSS, is that you have to create an entire web page just to try it out. What W3Schools provides is that all important, absolutely essential, one button click to Try it out.

I’m not defending W3Schools. The site has played off the W3C title, though that doesn’t have a lot of meaning nowadays. More importantly, some of the material has errors and the site is resistant to correcting any of these errors, and this is unconscionable.

But you aren’t going to dent the popularity of the site without at least understanding why it is so popular. The W3Schools’ site is not popular because of SEO, and it’s not popular because of the W3 part of the name.

The W3Schools web site is so popular because it is so usable.

Categories
Specs W3C

Responding to Opera’s TPAC Minutes

TPAC is the W3C annual meeting where the various working group members gather in bloody battle to see who emerges victorious…and who then has to buy the beer.

I’ve just published my response—in my usual quietly thoughtful manner—to Opera employee notes from the meeting at RealTech.

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.

Categories
HTML5 Specs W3C

Correction to the HTML5 review procedure

In my earlier writing, I suggested that after October 1st, people with comments should send emails to the public-html-comment email list, as I thought this would be where Last Call comments would be addressed. Evidently, I was incorrect.

According to a clarification I received, all comments should be submitted to the Bugzilla database. In addition, any arguments should be presented in the Bugzilla database. The HTML WG will be tracking using the Bugzilla database, unless the resolution makes people unhappy, in which case the item will become an issue. When an item does become an issue, then the only way you can continue to participate is basically become a member of the group. Oh, any comment in the public email list is supposedly addressed, but discussion will most likely happen in the members-only email list.

I’m not sure how comments from other W3C groups will be handled—perhaps by Ouija board; maybe strips of paper tacked against a wall, and thrown darts.

If you get from my comments that I don’t like this process, I don’t. A bugzilla database is not the place to handle concerns or suggestions that aren’t editorial or corrective in nature. It’s difficult to follow the discussion, and most of the discussion takes place out of the public eye. In addition, you can’t thread the replies, which means everything gets smooshed together linearly, with a lot of message copying, and references to “Comment Number 14”. Bugzilla is also not the most accessible software in the world.

Relying on Bugzilla to manage Last Call comments sucks. It’s also demonstrative of a group that has not effectively dealt with conflict. Instead of dealing with the major issues—such as the continuing split of the document across W3C and WhatWG, or the disquieting trends reflected in accessibility bugs—the HTML WG has, instead, tried to get technology to take care of the problem. And you know something? Relying on technology in this way never works.

You can track Bugzilla Tracking, or you can subscribe to the email list, but I’d do so warily—it is going to get busy.