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.

Any element can be replaced with something more relevant

I only check into the doings of the HTML WG at the W3C once a week.

Most of my time is spent on my new book, Learning Node. Frankly, Node has been a refreshing change from the¬†smoky labyrinth¬†which is the HTML5 spec process. I’d check in with the Working Group less often, but I still hope to provide at least some moral support for those still slogging away.

You all do realize that the battle over longdesc is still being fought, don’t you? Oh, there’s other new battles, including some interesting ones over a new¬†path¬†object¬†added to the Canvas2D¬†spec (Eh? What?), and¬†encrypted media¬†(very long discussion about this one), but longdesc still remains the perennial favorite.

The issue now is keeping any decision about longdesc separate from decisions being made about ARIA attributes. At least, I think this is the issue. What caught my eye today was something Sam Ruby wrote to the group:

My biggest concern is resolving ISSUE-30. By that I mean done. There may be Formal Objections, but there won’t be new information, so at that point this Working Group is done subject to Director approval.

Put another way, I have zero interest in a provisional decision that
would likely lead to a reopening based on new information. At the
present time, I see two potential candidates for new information. One
is the subject of issue 204. The other would be somebody putting
forward a spec for something akin to an aria-describedAt attribute.

The reason I state that is that at the present time I see wide support
for the idea of obsoleting longdesc once there is a viable and clearly
superior replacement. Note: some may not believe that a viable and
clearly superior replacement is possible. Others may not believe that
such is imminent. But I worded what I said carefully to include such
people’s opinion.

So the task we face is eliminating all alternatives.

I can agree that resolving this issue, completely, should be a goal. However, Sam demands that those who support longdesc provide a surety that there can be no better alternative in the future, and that’s just impossible. There is no surety for¬†any¬†component or element of the HTML5 specification. I have no doubts that, at some future time, better and improved replacements can be found for¬†all¬†HTML5 elements, attributes, and various and assorted sundry APIs.

(Simple elimination comes to mind as a way of improving some of the new additions.)

No other element or attribute in HTML has undergone such rigid opposition and such rigorous support. I would feel better, much better, about HTML5 if any of the new objects, elements, and attributes received even a tenth of the inspection and discussion that has been afforded to lowly, simple little longdesc. Objects, such as Path.

And now, the gauntlet has been tossed: longdesc is our princess in the tower, the W3C the wicked sorceress, and the demand has been made that either a knight in shining armor rescue the poor damsel or she be dragon kibble.

Eliminate all alternatives to longdesc? How many years do we have, Sam?

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 a 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 an entire generation 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 website is so popular because it is so usable.

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?

Microsoft’s proposed namespace distributed extensibility in HTML5

Per Sam Ruby, Microsoft has submitted a proposal for distributed extensibility in HTML5, which features the use of namespaces.

The proposal uses reverse DNS names, but other than those ugly sons-of-bitches, it looks promising. There are some issues, including no support for innerHTML on namespaced elements, because they would end up defined as Element, not HTMLUnknownElement, but I don’t think that’s going to be a real problem in the wild. More importantly, I believe the proposal would handle the problems I noted in my last writing, about the¬†valid¬†use of namespaced elements and attributes in SVG. The issue with namespaced elements in SVG isn’t a made-up problem or one that is unlikely to occur: it is a real problem, it will occur in the future, and it does require real solutions. The problem is not going to go away because Ian Hickson clicks ruby shoes together and murmurs “There’s no such thing as namespaces…there’s no such thing as namespaces…” This absolute refusal to acknowledge something that has existed on the web for a decade is, frankly, unconscionable.

I wish I could say that the happy campers of the HTML WG are willing to at least enter into an open and unbiased discussion on the proposal, but I stopped believing in fairy tales, a long time ago. There is contention on this issue (namespaces for distributed extensibility), as noted in the past, in the current discussion, in the HTML WG bug database, related to the new RDFa-in-HTML proposal. Needless to say, the WhatWG members have responded in their typical, open and mature manner.

But here’s some cold, hard reality for Ian et al: this isn’t a proposal from folks like me, who have little say, and no power. This proposal comes from Microsoft. Microsoft, who still maintains a dominant position when it comes to browser use in the world. The HTML5 editor cannot simply ignore the proposal, pretend he doesn’t understand it, or rubber stamp it WONTFIX. Not this time.