Category: Specs

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
Specs

Response to a recent posting in Google+

Recovered from the Wayback Machine.

My response to a recent post in Google+ by Ian Hickson:

You’re comparing apples to oranges, +Ian Hickson. There’s a world of difference between developing a specific piece of software and creating a specification.

In addition, you’re also incorrect with your understanding of the ‘tech lead model’. You may have worked on a lot of specs, but I’ve worked on a lot of projects for a great number of companies. What you’re saying is, well, hogwash.

Typically, software applications are defined for one specific use: a business use with well defined and finite customers who provide detailed instructions (user requirements) about what they want.

The tech team meets regularly with the users, and the users—or the group of people representing the users—are the ones that have the final say on the product.

There is usually an overall architect if the project is large—but they don’t just think up what’s needed on their own, and attempt to tell the users what they want. And the architect doesn’t work in a vacuum. The data people are the ones responsible for data design, and others are responsible for other decisions, such as types of equipment to purchase and software to use. Then there’s the testing team, the user acceptance folks, the documentation people, and so on.

I’ve worked on a couple of systems, including support for Saudi Arabia’s air force defense system, where the numbers of people in the team number into the hundreds. Someone playing King of the Mountain wouldn’t last a day.

It is very much a team effort.

And many of these teams work really well. I’ve been privileged to work with great teams at Boeing, Nike, Sierra Geophysics (a Halliburton subsidiary), John Hancock, and various other companies and government organizations. One key thing about all of the teams is the understanding of the importance of each team member, that no one is King of the Mountain, and cooperation and mutual respect is the name of the game.

The problem with your comment Ian, and others of like nature, is you really don’t have much exposure in the real world. You really haven’t worked that many jobs for many companies. You’ve insulated yourself in a tech bubble and you seem to believe if you say something with enough surety and confidence, others will believe you. True, some do, but primarily only among others like yourself, who typically haven’t a significant exposure to real world development.

You’re all spec wonks.

Being a spec wonk isn’t a bad thing, and brings its own expertise to the table—but it definitely doesn’t somehow magically make you all capable of understanding what everyone needs.

Because you’re all spec wonks, it’s especially important to get feedback and input from others who do have the real world experience you lack. But you just don’t see that. If anything, you seem to hold real world experience against people.

“Oh, I’ve done more spec work than any of these people. What do they know about specs?”

They may not know the mechanics of how a spec is worded, they may not have a lot of experience building browsers, but they definitely know what works outside the offices of Mozilla, Google, Opera, Microsoft, and Apple.

You know what’s funny, but in the teams I worked with, the most important player was the end user. We used to complain—loudly—if we couldn’t get access to reps from the business end. We needed these people because they knew what the application needed to do in order to be successful. We wanted to create successful applications.

The browser companies, they’ve forgotten all of this. They cater to a small portion of end users—most decidedly geek—and have ignored anyone else in their push to Be First with the latest gewgaw.

They incorporate stuff into browsers now that make them insecure and decrease their performance, but it’s all Cool and Stuff, and that’s OK for the tiny audience they only seem to care about. The only problem is, in the real world, we actually care more about security, reliability, performance, and accessibility than if the browser is all Cool and Stuff.

You have users wanting to be involved. You have experts from other fields asking, sometimes even begging, to be involved. You have other techs with vast experience—real world experience—wanting to be involved. Yet you throw it all away. And then you brag about it.

Sad

Categories
Media Specs

Mozilla reluctantly embracing H.264

Recovered from the Wayback Machine.

Interesting doings this week on the HTML5 video front.

Brendan Eich of Mozilla has stated the organization will now provide native support for H.264. In Video, Mobile, and the Open Web (also cross-posted at his personal web site), Eich writes:

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance.

Douglas Perry in Tom’s Guide writes:

For Google, Mozilla’s complaint is a dent for the credibility of the Chrome strategy and the pro-open source campaign. If Mozilla drops WebM entirely, WebM is practically dead. Firefox isn’t significant in market share on mobile devices, but it is the 25 percent wild card on the desktop. Google will only be able to help WebM survive with the support of Mozilla, which gives Google/Mozilla about 55 percent of the total browser market (according to StatCounter). Without Mozilla, WebM drops to 30 percent and H.264 rises to 70 percent of the market.

On her blog, Mitchell Baker writes:

For the past few years we have focused our codec efforts on the latter part of this sentence. We’ve declined to adopt a technology that improves user experience in the hopes this will bring greater user sovereignty. Not many would try this strategy, but we did. Brendan’s piece details why our current approach of not supporting encumbered codec formats hasn’t worked, and why today’s approach regarding existing encumbered formats is even less likely to work in the future.

Andreas Gal, director of Mozilla research, sums it up:

Google pledged many things they didn’t follow through with and our users and our project are paying the price. H.264 wont go away. Holding out just a little longer buys us exactly nothing.

Google has only its self to blame if (when) WebM follows Betamax and HDD into tech oblivion.

Categories
Specs

Any element can be replaced by something more relevant

Recovered from the Wayback Machine.

I only check in to 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, in 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 armour rescue the poor damsel or she be dragon kibble.

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

Categories
Specs Technology

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.