Year: 2009

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.

Categories
HTML5 Specs

One table in a thousand

Continuing with the discussion on the table element, began in the last page of this series, another change I would make in section 4.9.2 of the HTML 5 specification is to the example tables. First though, I want to return to the summary attribute one more time, before moving on to other topics.

The decision about summary was based on an analysis of data pulled from web pages scraped from the internet[1]. What’s been ignored in the discussions related to the incorrect use of the summary attribute is that only about one in 1,000 HTML tables reflect correct HTML table use. So, accuracy when it comes to past use of HTML tables is just something that one can’t “accurately” assess. The raw data is interesting, but we can’t draw conclusions from it.

I found that rather than looking at raw data use, if we look at discussions people have had about the table summary attribute, instead, we find that the summary attribute has been taken very seriously, but its use isn’t necessarily showing up on the web, or in Google.

For instance, this bug report is for a CMS and is directly related to an incorrect table summary. The summary use is accurate, but the table structure was altered, and the summary needed to be changed to reflect this alteration. The table summary is also probably one of the better examples of why something like summary is necessary, including the important note that column 1 is not used. A sighted person would see immediately that column 1 is not used, so this information is redundant to the visually enabled. For those people who need to use a screenreader, though, if they didn’t know that column 1 is empty, they would end up getting some variation of “blank” for every cell in that column. The information about the second column is just as valuable, as it informs the person that column 2 has checkboxes, again something that a sighted person would see immediately.

Yet we won’t see this accurate use of summary on the web, because the CMS is primarily used for educational purposes, and most likely implemented behind a firewall. In fact, it would have to be, because most educational systems have to be protected because of legal issues to do with students and privacy. I worked on systems at both Harvard and Stanford, and they all involve quite complex data tables, and none of the web pages would be available on the internet. When you consider that both universities had government and school mandated accessibility requirements, I’m fairly sure that both would be using summary with data tables, but we wouldn’t see this use in Google.

I found the same discussion about accurate and effective use of the table summary attribute related to intranet use for states and counties, other companies, and other products (Google Search on table summary example accessibility). It could very well be that there is a significant number of good summary uses, but we’ll never directly see them because they’re behind a firewall.

This brings me back to the table examples in section 4.9.2 of the specification. To reiterate, the summary attribute remains. However, so do the other examples of table documentation. Providing examples is a good way to not only help people use HTML tables accurately, but it also enforces the importance of accessibility. In fact, I would modify and expand the section.

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.

However, I don’t like the example table, and will replace it. I also believe more example tables are needed, as multiple examples help drive home differences in the table documentation techniques. Unfortunately, adding more examples will make a long specification even longer.

Because of the increased length of the table example section (and example sections elsewhere in the HTML 5 specification), we’ll need to split out the examples into an HTML 5 Primer.

HTML 5 Specification Modifications

To **summarize: The summary attribute is maintained as a viable, active attribute, the existing HTML table examples in section 4.9.2 will be replaced with multiple table examples, all of which will, most likely, be moved to an HTML 5 Primer document.

Additional References

See the HTML/SummaryForTable Wiki page for more details on this topic.

[1] Ian Hickson’s recent email related to the topic.

*I don’t expect to see a lot of use of figure with HTML tables, and I’m not a keen fan of figure use in this way. I’ll cover figure in more detail in a future page.

**No pun intended

Categories
HTML5 Specs

When deprecate is obsolete

First up for my HTML5: A Story in Progress is Deprecated is now Obsolete.

It was an elegant process, for an elegant time. We gently pushed the no longer wanted attributes and elements over a hill and out of sight. We don’t have markup hills now, in HTML 5, we have markup cliffs. We haven’t taken attributes and elements over the hill, we’ve taken them to cliffs, and pushed them off. And the little buggers are grabbing hold of page designers and developers, not to mention authoring tools and user agents, to take with them on their way down.