Author: Shelley Powers

Categories
Standards

Simpler is better

Manu Sporny and Ian Hickson have had an interesting, and telling, exchange about RDFa and microdata in the HTML WG list (see the opening email for the thread). In one of the emails, Hickson writes about why he created a whole new microdata section, rather than incorporate RDFa:

By “technical problems” I mean problems with the design, as opposed to
editorial problems. They’re primarily usability issues, which are to some
extent subjective. I make no apology for having an opinion on what makes a
usable language; it’s my job to have such an opinion.

Generally speaking, my position on this topic is a straightforward one:
simpler is better.

One asks: what is simple about creating an entirely new metadata solution, when there are two viable ones (microformats and RDFa) with both history and use? A new microdata section with predefined vocabularies that will be out of sync with their outer specification counterparts before the ink on HTML5 is even dry?

I haven’t touched on the microdata section of the HTML 5 specification in my little story on HTML 5 yet, because that one, in particular, is really key to everything that is wrong with the HTML 5: the specification and the process. It all really boils down to Ian and a few of his friends having opinions, and the power to enforce those opinions on the next version of the web. There are no checks. There are no balances. There is nothing but an illusion of equality and fairness.

What’s obscene is that no one really likes the microdata section, not even Ian himself. Oh, a few of his buddies manfully came out with the appropriate murmurs of delight, but none of these folks are interested in metadata. More importantly, where there is universal application of microformats and RDFa, there is no implementation that supports microdata (though I imagine one will be tossed into Opera quickly, just for spite).

In the end of the thread, when last I looked, Sam Ruby has vetted Manu Sporny’s RDFa alternative HTML 5 specification. So what does that mean? Your guess is as good as mine, but in my opinion, it does not mean that RDFa has a fair chance, any more than creating specification text for a new description of the summary or alt attributes, means these will be given a fair chance. If any of this comes down to a vote, I have no doubt that the WhatWG folks will be able to swing a majority. After all, client side data storage is sexy, summary attributes for screenreaders is not.

Having a majority does not mean that the best decision wins.

Categories
HTML5 Specs

HTML5: Canvas must go

Latest in my HTML5, A Story in Progress: Separating Canvas out of HTML 5.

Recent discussions about Canvas and accessibility should highlight the importance of pulling the Canvas object API from the HTML 5 specification. The HTML WG went outside its charter to incorporate the Canvas API into the HTML 5 specification. Keeping it in is not good for the HTML 5 spec, nor is it good for the Canvas element.

It wasn’t up to the HTML WG to insist that the Canvas element either be included in the HTML 5 specification or some other formal working group. The group can’t just grab things in, willy nilly, like crows grab a piece of tinsel because it sparkles in the sun. Oh! Me want! Me want!

Categories
HTML5 SVG Technology

Separating Canvas out of HTML5

The HTML 5 specification is too large, that’s a given. Too large, and too diverse. With the merge of the DOM into the specification, as well as an attempt to cover two different serializations, not to mention the microdata section, it’s difficult to describe the HTML 5 spec as an “improvement on HTML 4”, which is what the HTML WG’s charter specifies. Kitchen sink comes to mind, and kitchen sinks don’t make good specifications.

One simplification of HTML 5 I would make is to remove the Canvas section from the specification. Instead, I would reduce the Canvas section down to coverage of the syntax for the Canvas element, similar to what’s happening with MathML and SVG, but remove the guts of the object to a separation specification. Or don’t move the Canvas object to a separate specification, but don’t leave the object in HTML 5.

I read through results of the three votes associated with Canvas, or should I say, “immediate mode graphics API”. Two of the votes had to do with the WG charter and creating a tutorial about the Canvas element, and one was specifically about splitting the Canvas element out.

The vote was overwhelmingly against splitting the element out, but also against not updating the charter to reflect the fact that including the Canvas element is outside of the group’s current charter. Frankly, this was undisciplined, and at that point in time, the W3C Director should have stepped in to remind the group about what the charter is, and the importance of adhering to it.

Looking again at the vote about not splitting the Canvas object into a separate specification, you can see immediately that few people are really enthusiastic about keeping the Canvas element in the HTML 5 specification. However, they were even less enthusiastic about doing the work necessary to split the Canvas element into a new specification, and developing a group to support the new spec. Being disinterested in starting a new working group does not make for a compelling argument for keeping Canvas in HTML 5.

Now we’re seeing problems arise by that bad decision. There have been numerous recent discussions about Canvas and accessibility, and it isn’t difficult to see that work on Canvas accessibility needs to continue, probably for a significant period of time; possibly long enough to impact on the timeline for the Last Call for HTML 5.

In addition, there is a very real concern that the same governments that mandate against JavaScript because of accessibility will also mandate against Canvas for the same reason, because Canvas is dependent on JavaScript. Yet the Canvas element is integrated into the HTML 5 specification. The end result could be a slower roll out of HTML 5, perhaps even a reluctance to adopt HTML 5. I hesitate to say there may be a ban against HTML 5, but there is that possibility, too, slight as the risk is.

Most importantly for the folks who like the Canvas object, it’s now tied to the same schedule of the HTML 5 specification. This means that if we want to expand the Canvas object at same later point, we have to do so in conjunction with a new version of HTML. This tie-in makes absolutely no sense. When you consider the increasing capabilities being built into Flash and Silverlight, Canvas also needs room to grow. Now, the HTML WG has effectively boxed it in, limited its future expansion, and probably helping to hasten its future obsolescence. Of course we still have SVG, which is not integrated tightly into the HTML 5 specification, and can continue to grow and expand. Good for SVG. However, I happen to believe that it’s healthy to have both graphics capabilities—but only if both have room to grow.

It wasn’t up to the HTML WG to insist that the Canvas element either be included in the HTML 5 specification or some other formal working group. The group can’t just grab things in, willy nilly, like crows grab a piece of tinsel because it sparkles in the sun. Oh! Me want! Me want! If people are interested in the object, they’ll work to help standardize its use. If they aren’t, then it will continue as it has in the past, based on informal agreement among four of the top five browser developers. At least then it won’t get stuck being permanently embedded in an HTML specification.

Categories
Diversity

Women in open source at OSCON

Excellent presentation at OSCON by Kirrily Robert: Standing out in the Crowd about women in open source.

One very interesting graphic in the presentation shows that 80% of women in open source noticed sexism or gender discrimination, compared to only 20% of men who noticed. This pretty much backs up what I’ve found every time I’ve pointed out diversity problems: all of the guys tell me how wrong I am.

What’s wrong with this picture?

Categories
HTML5 Specs

One Table

Next up in my series HTML5: A Story in Progress is a final discussion on the table summary attribute, as well as new discussion on the HTML5 table examples, and the introduction of an HTML5 Primer. Read more at RealTech: One Table in a Thousand..

By providing the differing, and I feel complementary table documentation techniques and examples, we’re also, indirectly, enabling better data collection activity in regards to summary in the future. If the issue with the perceived incorrect use of summary is that people don’t understand how to use summary, then in the future we should see correct descriptions of the table using one of the other techniques, without seeing an associated correct use of summary. I hypothesize, though, that we’ll see a positive correlation between correct use of HTML tables, and correct use summary, most likely used with a correct use of caption, or figure legend.