Archive for the ‘Weekly Review’ Category
Friday, January 30th, 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. Despite it being almost February already, this episode will focus on changes and discussion from the week of January 12th. (Very little constructive progress was made between the 1st and the 12th.) I'll follow up with another summary for the week of January 19th, then I'll resume normal weekly updates on Monday.
The big news for the week of January 12th is r2633, which defines the indeterminate attribute on form controls.
The input element represents a two-state control
that represents the element's checkedness state. If the
element's checkedness state
is true, the control represents a positive selection, and if it is
false, a negative selection. If the element's indeterminate DOM attribute
is set to true, then the control's selection should be obscured as
if the control was in a third, indeterminate, state.
The control is never a true tri-state control, even
if the element's indeterminate DOM attribute
is set to true. The indeterminate DOM attribute
only gives the appearance of a third state.
Internet Explorer and Safari already support the indeterminate attribute.
The other news I want to highlight this week -- just because this sort of weirdness tickles me -- is r2616, which tries to tackle the following difficult situation:
- A user fills out a form and presses the submit button.
- The browser POSTs a form and begins parsing the response.
- In the course of parsing the response document, it encounters a
<meta charset> attribute that is different from the encoding defined or inferred from the HTTP headers.
If this were the response from a GET request, the browser might re-request the page so it could restart parsing with the new character encoding. But doing that after a POST would be like double-submitting the form, which could have serious consequences on the back end. (Technically, the difference is between idempotent operations like GET and non-idempotent operations like pretty much everything else.) So browsers should never re-request the page after a POST, and they'll just have to muddle through as best they can with the character encoding they have. [bug 6258]
Other interesting tidbits that week:
- r2672 states that relative URLs in CSS in HTML documents are not reresolved when the base URL of the HTML document changes. This is just one of those incredibly weird things that web authors do that just makes you want to strangle them en-masse and scream "DON'T DO THAT!" But they do do it -- God knows why -- and it has been a source of pain for browser vendors because no standard has ever defined what they should do in this situation, so naturally they all do something different. [Background: Issues concerning the <base> element]
- r2674 defines a way for web authors to include documentation inside
<script src> elements -- that is, inline documentation for external scripts.
- r2679 adds a number of browser interface elements to the HTML 5 spec, including
window.locationbar, window.menubar, window.personalbar, window.scrollbars, window.statusbar, and window.toolbar. These previous undefined properties are already supported by all major browsers except Internet Explorer.
Tune in... er, in a few hours... for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »
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 »
Thursday, December 18th, 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 r2529, which makes so many changes that I had to ask Ian to explain it to me. This is what he said:
Someone asked for onbeforeunload, so I started fixing it. Then I found that there was some rot in the drywall. So I took down the drywall. Then I found a rat infestation. So I killed all the rats. Then I found that the reason for the rot was a slow leak in the plumbing. So I tried fixing the plumbing, but it turned out the whole building used lead pipes. So I had to redo all the plumbing. But then I found that the town's water system wasn't quite compatible with modern plumbing techniques, and I had to dig up the entire town. And that's basically it.
"Amusing, in a quiet way," said Eeyore, "but not really helpful."
Basically, the way that scripts are defined has changed dramatically. Not in an terribly incompatible way, just a clearer definition that paves the way for better specification of certain properties of script (and noscript). Let's start with the new definition of a script:
A script has:
- A script execution environment
-
The characteristics of the script execution environment depend
on the language, and are not defined by this specification.
In JavaScript, the script execution environment
consists of the interpreter, the stack of execution
contexts, the global code and function code and
the Function objects resulting, and so forth.
- A list of code entry-points
-
Each code entry-point represents a block of executable code
that the script exposes to other scripts and to the user
agent.
Each Function object in a JavaScript
script execution environment has a corresponding code
entry-point, for instance.
The main program code of the script, if any, is the
initial code entry-point. Typically, the code
corresponding to this entry-point is executed immediately after
the script is parsed.
In JavaScript, this corresponds to the
execution context of the global code.
- A relationship with the script's global object
-
An object that provides the APIs that the code can use.
This is typically a Window
object. In JavaScript, this corresponds to the global
object.
When a script's global object is an
empty object, it can't do anything that interacts with the
environment.
- A relationship with the script's browsing context
-
A browsing context that is assigned responsibility
for actions taken by the script.
When a script creates and navigates a new top-level browsing
context, the opener
attribute of the new browsing context's
Window object will be set to the script's
browsing context's Window object.
- A character encoding
-
A character encoding, set when the script is created, used to
encode URLs. If the character encoding is
set from another source, e.g. a document's character
encoding, then the script's character encoding
must follow the source, so that if the source's changes, so does
the script's.
- A base URL
-
A URL, set when the script is created, used to
resolve relative URLs. If the base URL is
set from another source, e.g. a document base URL,
then the script's base URL must follow the source, so
that if the source's changes, so does the script's.
- Membership in a script group
-
A group of one or more scripts that are loaded in the same
context, which are always disabled as a group. Scripts in a script
group all have the same global object and browsing context.
A script group can be frozen. When a script group is
frozen, any code defined in that script group will throw an
exception when invoked. A frozen script group can be
unfrozen, allowing scripts in that script group to run
normally again.
The most interesting part of this new definition is the script group, a new concept which now governs all scripts. When a Document is created, it gets a fresh script group, which contains all the scripts that are defined (or are later created somehow) in the document. When the user navigates away from the document, the entire script group is frozen, and browsers should not execute those scripts anymore. This sounds like an obvious statement if you think of documents as individual browser windows (or tabs), but consider the case of a document with multiple frames, or one with an embedded iframe. Suppose that the user clicks some link within the iframe that only navigates to a new URL within the iframe (i.e. the parent document stays the same). The parent document may have some reference to functions defined in the old iframe. Should it still be able to call these functions? IE says no; other browsers say yes. HTML 5 now says no, because when the iframe navigates to a new URL, the old iframes script group is frozen -- even if there are active references to those scripts (say, from the parent document), browsers shouldn't allow the page to execute them.
The main benefit of this new concept of script groups is that it removes a number of complications faced by the non-IE browsers. For example, it prevents the problem of scripts suddenly discovering that their global object is no longer the object that they think of as the Window object. Script groups are also frozen when calling document.open(). Freezing script groups also defines the point at which timers and other callbacks are reset, which is something that previous versions of HTML had never defined.
And after all of this ripping up and redefining, HTML 5 now defines the onbeforeunload event, which is already supported by major browsers.
Other interesting tidbits this week:
- r2533 adds support for passing structured data between documents with
postMessage(). [structured data discussion]
- r2536 defines the
NameCreator, NameDeleter, NameGetter, NameSetter, IndexGetter, and IndexSetter anonymous methods, which are used by browsers internally to manage lists of named or indexed properties (e.g. form.elements, per-element custom data attributes, or the pixel data of a canvas).
- r2537 explains that you can not click something while you're already in the process of clicking it. (Technically speaking, it makes the
click() method non-reentrant.) [nested click() discussion]
- r2538 clarifies that non-interactive elements that are not usually focusable, but that do currently have focus (via the
tabindex attribute), should simulate onclick events when the user presses ENTER. This may seem like a minor point, but it is important for building keyboard-accessible web applications. [onclick discussion]
- r2539 notes that buttons (and their values) are not submitted with other form data unless they were the button that submitted the form. [button submission discussion]
- Silvia Pfeiffer posts thoughts on video accessibility and links to this collection of video accessibility requirements on the Mozilla wiki.
- Nine years in the making, the second major edition of the Web Content Accessibility Guidelines is now officially a W3C Recommendation. The guidelines are supplemented by a comprehensive techniques document, for example Using
alt attributes on img elements. HTML 5 also includes a section on using the alt attribute, but in general you should defer to WCAG 2.0 because it was written by experts.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review, WHATWG | 2 Comments »
Wednesday, December 10th, 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 the disintegration of HTTP authentication from HTML forms (which was last week's big news). As I predicted, the proposal generated a healthy discussion, but a combination of security concerns and concerns about tight coupling ultimately did in the proposal.
In its place, r2470 includes the following conformance requirement to allow for the possibility of someone specifying such a scheme in the future (hat tip: Robert Sayre):
HTTP 401 responses that do not include a challenge recognised by the user agent must be processed as if they had no challenge, e.g. rendering the entity body as if the response had been 200 OK.
User agents may show the entity body of an HTTP 401 response even when the response do include a recognised challenge, with the option to login being included in a non-modal fashion, to enable the information provided by the server to be used by the user before authenticating. Similarly, user agents should allow the user to authenticate (in a non-modal fashion) against authentication challenges included in other responses such as HTTP 200 OK responses, effectively allowing resources to present HTTP login forms without requiring their use.
Continuing with the web forms work, the <input> element has gained a new type: a color picker, marked up as <input type=color>. Browser vendors are encouraged to integrate this field with platform-native color pickers, as appropriate. As with all new input types, browsers that do not explicitly recognize the new type will default to a simple text field.
The <audio> and <video> API continues to churn rapidly. Implementors should probably ignore it altogether until it's been stable for two consecutive weeks. To wit: r2493 removes the pixelratio attribute, originally proposed to allow authors to override the display of videos known to be encoded with incorrect an aspect ratio. r2498 adds the playing event, fired when playback as started. r2489 drops the HAVE_SOME_DATA readyState. I will try to write up a comprehensive summary of this API once its stabilizes.
Other interesting tidbits this week:
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review, WHATWG | 1 Comment »
Tuesday, November 25th, 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 radical proposal for integrating HTTP authentication with HTML forms. r2432 defines a new token for the WWW-Authenticate header: "HTML".
A common use for forms is user authentication. To indicate that
an HTTP URL requires authentication through such a form
before use, the HTTP 401 response code with a WWW-Authenticate challenge "HTML" may be used.
For this authentication scheme, the framework defined in RFC2617
is used as follows. [RFC2617]
challenge = "HTML" [ form ]
form = "form" "=" form-name
form-name = quoted-string
The form parameter, if
present, indicates that the first form element in the
entity body whose name is the
specified string, in tree order, if any, is the login
form. If the parameter is omitted, then the first form
element in the entity body, in tree order, if any, is
the login form.
There is no credentials production for this
scheme because the login information is to be sent as a normal form
submission and not using the Authorization
HTTP header.
This idea has been kicked around for more than a decade. Microsoft wrote User Agent Authentication Forms in 1999. Mark Nottingham asked the WHATWG to investigate the idea in 2004. Better late than never, Ian Hickson summarizes the feedback to date. No doubt this new proposal will generate further discussion. No browsers currently support this proposal.
Other interesting tidbits this week:
- r2429 adds the
<input type=search> form field. [<input type=search> discussion]
- r2440 allows the
multiple attribute to appear on <input type=email> and <input type=file>. [<input type=email multiple> discussion]
- r2423 specifies how
<object> elements are submitted in forms. Unbeknownst to me, this feature was present in HTML 4 and is supported across multiple browsers. If a plugin exposes a value getter, the name of the <object> element is submitted with the value exposed by the plugin. [<object> form submission example, Mozilla bug 188938]
- r2434 seriously revamps the concept of "vaguer moments in time." r2433 notes, correctly, that there is no year zero in the Gregorian calendar. r2437 further refines the calculation of dates before 1582. [date and time discussion]
- r2426 clarifies the fallback behavior of the
<object> element.
- r2427 documents existing browser behavior in sending all attributes and attribute values to a plugin invoked from an
<object> element. Previously, HTML 5 has specified that only specific parameters were sent, but browsers consistently send all attributes, so there it is.
- r2424 explains the intended audience of the HTML 5 specification itself.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 7 Comments »