HTML 5

The WHATWG Wiki portal has a nice section describing HTML vs. XHTML differences, as well as specifics of a polyglot HTML document that also would be able to serve HTML5 document as valid XML document. I’d like to review what it takes to transform an HTML5 polyglot document into a valid XHTML5 document: it appears, [...]

[Read more →]

I’ve started a page on the wiki to document the rationale for the decisions made about the HTML specification. There are two goals for this document: Explain why things are the way they are Explain the difference between multiple similar elements by providing example usages. One person can not possibly write the entire thing so [...]

[Read more →]

For a brief period today, there were no outstanding e-mails or bugs on the specs, and so I took that opportunity to transition us here at the WHATWG to the next stage of HTML5’s development: Last Call! This affects three specs at the WHATWG: HTML5 Web Workers Microdata vocabularies There’s also a version of the [...]

[Read more →]

Over the past few weeks, Google has been preparing and then running a usability study to test the microdata feature of HTML5. Methodology We first created three different variants based on the original microdata proposal: One based on what the spec said (documentation) One trying to put types in an explicit itemtype=”" attribute and moving [...]

[Read more →]

What’s the right way to spell “HTML5”? The short answer is: “HTML5” (without a space).

People in the WHATWG community have commonly referred to HTML5 as “HTML5” for quite a while. However, when the W3C HTML WG voted on adopting “Web Applications 1.0” the question about the title said “HTML 5”. Thus, the W3C HTML WG [...]

[Read more →]

The W3C Technical Architecture Group (TAG) is in the process of reviewing HTML 5. Noah Mendelsohn recently posted his initial, personal, not-speaking-on-behalf-of-TAG notes on HTML 5. Here are my initial, personal, not-speaking-on-behalf-of-WHATWG responses.

Limitations of the XML serialization

This may be old news, but I was surprised to see that document.write() is not supported when parsing the [...]

[Read more →]

Are you interested in reviewing HTML5 for errors?

1. Jump in! All feedback is welcome, from anyone.
2. Open the specification: either the one-page version, or the multipage version or the PDF copy (A4, Letter)
3. Start reading! See below for ideas of what to look for.

If you find a problem, either send an e-mail to the WHATWG list (whatwg@whatwg.org, subscription required), file a bug (registration required), send an e-mail to the public-html-comments@w3.org list (no subscription required), or send an e-mail directly to ian@hixie.ch.

If everything goes according to plan, all issues will get a response from the editor before October. You can track how many issues remain to be responded to on our graph.

What to look for

The plan is to see whether we can shake down the spec and get rid of all the minor problems that have so far been overlooked. Typos, confusion, cross-reference errors, as well as mistakes in examples, errors in the definitions, and major errors like security bugs or contradictions.

Anyone who helps find problems in the spec — however minor — will get their name in the acknowledgements section.

You don’t really need any experience to find the simplest class of problems: things that are confusing! If you don’t understand something, then that’s a problem. Not all the introduction sections and examples are yet written, but if there is a section with an introduction section that isn’t clear, then you’ve found an issue: let us know!

Something else that would now be good to search for is typos, spelling errors, grammar errors, and the like. Don’t hesitate to send e-mails even for minor typos, all feedback even on such small issues is very welcome.

If you have a specific need as a Web designer, then try to see if the need is met. If it isn’t, and you haven’t discussed this need before, then send an e-mail to the list. (So for example, if you want HTML to support date picker widgets, you’d look in the spec to see if it was covered. As it turns out, that one is!)

If you have some specific expertise that lets you review a particular part of the spec for correctness, then that’s another thing to look for. For example if you know about graphics, then reviewing the 2D Canvas API section would be a good use of your resources. If you know about scripting, then looking at the “Web browsers” section would be a good use of your time.

Staying in touch

You are encouraged to join our IRC channel #whatwg on Freenode to stay in touch with what other people are doing, but this is by no means required. You are also encouraged to post in the Discussion section on the wiki page for this review project, or in the blog comments below, to let people know what you are reviewing. You can get news updates by following @WHATWG on Twitter.

[Read more →]

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.”

[Read more →]

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:

• The <input placeholder> attribute that I discussed in episode 13 has three new conformance requirements: it must not contain newlines, browsers must strip newlines if present, and it may be empty.
• r2468 defines the concept of a document’s address, and r2469 defines the behavior of document.open() in terms of the document address.
• r2476 adds a new section for conformance checkers (e.g. the W3C validator) that lists common conformance errors that aren’t actually that important. Examples: <script language="JavaScript">, <img border=0>.
• r2478 and r2479 give guidance for WYSIWYG editors on how to fill in the <image alt> attribute if the user refuses to provide meaningful alternate text.
• r2486 restores the HTML 4 behavior of the <q> element, which is that browsers should insert quotation marks around the quoted phrase. [summary of massive <q> discussion]
• r2525 mandates that browsers add an Origin: header to all non-GET requests, including the much-maligned ping attribute. [Origin discussion]

Tune in next week for another exciting episode of “This Week in HTML 5.”

[Read more →]

Welcome back to my semi-regular column, “The Road to HTML 5,” where I’ll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.

The feature of the day is getElementsByClassName(). Long desired by web developers and implemented in Javascript libraries like Prototype, this function does exactly what it says on the tin: it returns a list of elements in the DOM that define one or more classnames in the class attribute. getElementsByClassName() exists as a method of the document object (for searching the entire DOM), as well as on each HTMLElement object (for searching the children of an element).

The HTML 5 specification defines getElementsByClassName():

The getElementsByClassName(classNames) method takes a string that contains an unordered set of unique space-separated tokens representing classes. When called, the method must return a live NodeList object containing all the elements in the document, in tree order, that have all the classes specified in that argument, having obtained the classes by splitting a string on spaces. If there are no tokens specified in the argument, then the method must return an empty NodeList. If the document is in quirks mode, then the comparisons for the classes must be done in an ASCII case-insensitive manner, otherwise, the comparisons must be done in a case-sensitive manner.

A Brief History of getElementsByClassName()

• September 2005: getElementsByClassName() Implementation Questions and followups discuss whether getElementsByClassName() should take a string with multiple classnames, and if so, what that would mean. Despite early protests, it was eventually decided that getElementsByClassName() should take multiple classnames in a single string, separated by spaces, and that the function should return elements that define all of given classnames.
• February 2006: “I see this is still an open issue.”
• October 2006: “This omnibus edition of your WHATWG mail includes replies to 50 or so separate e-mails about getElementsByClassName().”
• February 2007: “I landed support for this on the Mozilla trunk, and it will appear in upcoming Firefox alphas and betas. The array argument turned out to be quite a pain to implement, so we cut it.” Ian Hickson responds: “I’ve changed the spec to use a space-separated list. … I’ve dropped the array form altogether.”
• March 2007: John Resig puts Firefox 3’s implementation to the test in getElementsByClassName Speed Comparison.
• July 2007: “I suggest that participants in this thread reacquaint themselves with the discussion in the previous one before having it again.” Good luck with that.
• September 2007: “A popular and useful feature [in Opera 9.5] will be the addition of native support for getElementByClassName from HTML5.”
• December 2007: “Last week WebKit joined upcoming versions of Firefox and Opera in supporting [getElementsByClassName].”
• December 2007: “Currently getElementsByClassName is specified as always being case sensitive. This would be fine, except that the primary other use of html class names (CSS selector matching) is only case sensitive in standards mode. This leads to situations … in which CSS and getElementsByClassName match different results.”
• July 2008: Ian Hickson responds: “I’ve made it consistent with how classes work in CSS (case-insensitive for quirks and case-sensitive otherwise).”

Can We Use It?

Yes We Can! As you can tell from the timeline, getElementsByClassName() is supported natively in Firefox 3, Opera 9.5, Safari 3.1, and all versions of Google Chrome. It is not available in any version of Microsoft Internet Explorer. (IE 8 beta 2 is the latest version as of this writing.) To use it in browsers that do not support it natively, you will need a wrapper script. There are many such scripts; I myself am partial to Robert Nyman’s Ultimate GetElementsByClassName. It uses the native getElementsByClassName() method in modern browsers that support it, then falls back to the little-known document.evaluate() method, which is supported by older versions of Firefox (since at least 1.5) and Opera (since at least 9.27). If all else fails, Robert’s script falls back to recursively traversing the DOM and collecting elements that match the given classnames.

And in conclusion

getElementsByClassName() is well-supported across all modern browsers except IE, and a performance-optimized open source wrapper script can cover IE and older browsers.

[Read more →]