Tuesday, March 31st, 2009
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
The big news for the week of February 23rd (yes, I'm that far behind) is a collection of changes about how video is processed. The changes revolve around the resource selection algorithm to handle cases where the src attribute of a <video> element is set dynamically from script.
Background reading on the resource selection algorithm: Re: play() sometimes doesn't do anything now that load() is async, r2849: "Change the way resources are loaded for media elements to make it actually work", r2873: "make all invokations of the resource selection algorithm asynchronous."
Other video-related changes this week:
- r2845 changes the definition of the
drawImage() method of the <canvas> element to allow playing a video on a canvas.
- r2847 defines that
<video> and <audio> elements delay the document's onload event.
- r2848 changes the wording of the ready states documentation to prevent duplicate
canplay events.
- r2852 changes the wording of the ready states documentation to prevent duplicate
playing events.
- r2853 fixes the order of events of autoplayed video.
- r2855 adds an
autobuffer attribute to <audio> and <video> elements. "The autobuffer attribute provides a hint that the author expects that downloading the entire resource optimistically will be worth it, even in the absence of the autoplay attribute. In the absence of either attribute, the user agent is likely to find that waiting until the user starts playback before downloading any further content leads to a more efficient use of the network resources."
Another big change this week is the combination of r2859, 2860, and r2861: you can now declare the character encoding of XHTML documents served with the application/xhtml+xml MIME type by using the <meta charset> attribute, but only if the value is "UTF-8". Also, the charset attribute must appear in the first 512 bytes of the document. Previously, the only ways to control the character encoding of an application/xhtml+xml document were setting the charset parameter on the HTTP Content-Type header, or to use an encoding attribute in the XML prolog.
In practice, this will make no difference to encoding detection algorithms; other UTF-* encodings are detected earlier (with a Byte Order Mark), and any other encoding would require an XML prolog. This is mainly to address the desire of a few overly vocal authors to be able to serve the same markup in both text/html and application/xhtml+xml modes. Background reading: Bug 6613: Allow <meta charset="UTF-8"/> in XHTML.
Other interesting changes this week:
- r2866 makes it clear that using tables for layout is non-conforming.
- r2868 makes it clear that
<canvas> elements must have accessible fallback content within them.
- r2870 drops the
<eventsource> element.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 1 Comment »
Tuesday, December 30th, 2008
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
The big news this week is a major revamp of table headers, following up from the last major edits last March. Ian summarizes the most recent round of changes:
- Header cells can now themselves have headers.
- I have reversed the way the algorithm is presented, such that it starts from a cell and reports the headers rather than generating the list of headers for each cell on a header-by-header basis.
- If headers="" points to a
<td> element, the association is set up, but I have left this non-conforming to help authors catch mistakes.
- Header cells that are automatically associating do not stop associating when they hit equivalent cells unless they have also hit a
<td> first.
- The
"col" and "row" scope values now act like the implied auto value except that they force the direction.
- Empty header cells don't get automatically associated.
- I have removed the wide header cell heuristic.
- I have made headers="" use the same ID discovery mechanism as
getElementById(), to avoid implementations having to support multiple such mechanisms.
- Finally, I have made the spec define if a header is a column header or a row header in the case where
scope="" is omitted.
- I haven't added summary="" on table; nothing particularly new has been raised on the topic since the last times I looked at this.
Accessibility advocates are disappointed by the continued non-inclusion of the summary attribute. Their reasoning is that "the summary attribute is a very, very practical and useful attribute," despite their own user testing that shows otherwise. As Ian put it, "I am hesitant to include a feature like summary="" when all evidence seems to point to it being widely misused by authors and ignored by the users it intends to help." As with all issues, this is not the final word on the matter, but it's where we stand today.
In other news, r2566 addresses a very subtle issue with fetching images. The problem stems from the following (arguably pointless) markup: <img src=""> A fair number of web pages actually try to declare an image with an empty src attribute. According to the HTTP and URL specifications, this markup means that there is an image at the same address as the HTML document -- a theoretically possible but highly unlikely scenario. Internet Explorer apparently catches this mistake and just silently drops the image. Other browsers do not; they will actually try to fetch the image, which results in a "duplicate" request for the page (once to successfully retrieve the page, and again to unsuccessfully retrieve the image).
Boris Zbarsky, a leading Mozilla developer, states
We (Gecko) have had 28 independent bug reports filed (with people bothering to create an account in the bug database, etc) about the behavior difference from IE here. That's a much larger number of bug reports than we usually get about a given issue. I can't tell you why this pattern is so common (e.g. whether some authoring frameworks produce it in some cases), but it seems that a number of web developers not only produce markup like this but notice the requests in their HTTP logs and file bugs about it.
r2566 addresses the issue by special-casing <img src> to allow browsers to ignore an image if its fetch request would result in fetching exactly the same URL as its HTML document:
When an img is created with a src attribute, and whenever the src attribute is set subsequently, the user agent must fetch the resource specifed by the src attribute's value, unless the user agent cannot support images, or its support for images has been disabled, or the user agent only fetches elements on demand, or the element's src attribute has a value that is an ignored self-reference.
The src attribute's value is an ignored self-reference if its value is the empty string, and the base URI of the element is the same as the document's address.
Other interesting tidbits this week:
- r2568 adds a
storageArea attribute to StorageEvent object. [StorageEvent deficiency]
- r2556 changes the processing model of the
<meta charset> attribute by requiring that it appear in the first 512 bytes of the document. For those of you playing along at home, <meta charset="..."> is the new <meta http-equiv="Content-Type" content="text/html; charset=...">. Both forms are fully supported in all major browsers. [Comparing conformance requirements against real-world docs]
- r2557, r2559, r2560, r2562, r2563, and r2604 add a variety of common markup errors to the list of errors that HTML validators may treat as minor. [Re: comparing conformance requirements against real-world docs]
- r2561 allows the
height and width attributes on <input type="image">, a construct that is already supported by all major browsers. [Re: comparing conformance requirements against real-world docs]
- r2601 adds an example of something that all browsers do anyway -- killing scripts that run too long.
- r2597 removes the notification API, which was kicked around in 2006 but never saw significant interest from either authors or browser vendors. [Notifications API removed]
- r2596 defines
window.close(), window.focus(), and window.blur(). The focus() and blur() methods have historically been used to produce "pop-up" and "pop-under" windows containing advertisements. Most modern browsers now control how and whether scripts can do this, and the HTML 5 specification goes so far as to recommend that "[u]ser agents are encouraged to ignore calls to this blur() method entirely."
- r2552 gives an example of embedding RDF metadata in XHTML. As the spec notes, this is not possible in HTML, although you could always use RDFa.
- r2595 gives an example of marking up a tag cloud.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 12 Comments »
Tuesday, October 14th, 2008
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
Most of the changes in the spec this week revolve around the <textarea> element.
Shelley Powers pointed out that I haven't mentioned the issue of distributed extensibility yet. (The clearest description of the issue is Sam Ruby's message from last year, which spawned a long discussion.) The short version: XHTML (served with the proper MIME type, application/xhtml+xml) supports embedding foreign data in arbitrary namespaces, including SVG and MathML. None of these technologies (XHTML, SVG, or MathML) have had much success on the public web. Despite Chris Wilson's assertion that "we cannot definitively say why XHTML has not been successful on the Web," I think it's pretty clear that Internet Explorer's complete lack of support for the application/xhtml+xml MIME type has something to do with it. (Chris is the project lead on Internet Explorer 8.)
Still, it is true that XHTML does support distributed extensibility, and many people believe that the web would be richer if SVG and MathML (and other as-yet-unknown technologies) could be embedded and rendered in HTML pages. The key phrase here is "as-yet-unknown technologies." In that light, the recent SVG-in-HTML proposal (which I mentioned several weeks ago) is beside the point. The point of distributed extensibility is that it does not require approval from a standards body. "Let a thousand flowers bloom" and all that, where by "flowers," I mean "namespaces." This is an unresolved issue.
Other interesting changes this week:
- r2314 ensures that the
required attribute only applies to form controls whose value can change.
- r2316 defines the
name attribute for form controls.
- r2317 defines the
disabled attribute for form controls.
- r2320 defines all the different ways that a form control can fail to satisfy its constraints. For example, an
<input maxlength=20> element with a 21-character value.
- r2322 defines exactly how form data should be encoded before being submitted to the server. I've previously mentioned character encoding in this series; this revision marks the first time that an HTML specification has acknowledged the existence of
<input type=hidden name=_charset_> method of specifying the character encoding of submitted form data.
- r2319 removes support for data templates and repetition templates. These were inventions in the original Web Forms 2 specification, but they were never picked up by any major browser.
Around the web:
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »