The WHATWG Blog

This Week Day In HTML 5 – Episode 22

February 25th, 2009 by Mark Pilgrim, Google in Weekly Review

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 pace of HTML 5 changes has reached a fever pitch, so I'm going to split out these episodes into daily (!) rather than weekly summaries until things calm down.

The big news for February 11, 2009 is the addition of an algorithm to parse a color in an IE-compatible way. r2776 lays it all out:

Some obsolete legacy attributes parse colors in a more complicated manner, using the rules for parsing a legacy color value, which are given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will either return a simple color or an error.

1. Let input be the string being parsed.

2. If input is the empty string, then return an error.

3. If input is an ASCII case-insensitive match for the string "transparent", then return an error.

4. If input is an ASCII case-insensitive match for one of the keywords listed in the SVG color keywords or CSS2 System Colors sections of the CSS3 Color specification, then return the simple color corresponding to that keyword. [CSS3COLOR]

5. If input is four characters long, and the first character in input is a U+0023 NUMBER SIGN (#) character, and the the last three characters of input are all in the range U+0030 DIGIT ZERO (0) .. U+0039 DIGIT NINE (9), U+0041 LATIN CAPITAL LETTER A .. U+0046 LATIN CAPITAL LETTER F, and U+0061 LATIN SMALL LETTER A .. U+0066 LATIN SMALL LETTER F, then run these substeps:

   1. Let result be a simple color.

   2. Interpret the second character of input as a hexadecimal digit; let the red component of result be the resulting number multiplied by 17.

   3. Interpret the third character of input as a hexadecimal digit; let the green component of result be the resulting number multiplied by 17.

   4. Interpret the fourth character of input as a hexadecimal digit; let the blue component of result be the resulting number multiplied by 17.

   5. Return result.

6. Replace any characters in input that have a Unicode codepoint greater than U+FFFF (i.e. any characters that are not in the basic multilingual plane) with the two-character string "00".

7. If input is longer than 128 characters, truncate input, leaving only the first 128 characters.

8. If the first character in input is a U+0023 NUMBER SIGN character (#), remove it.

9. Replace any character in input that is not in the range U+0030 DIGIT ZERO (0) .. U+0039 DIGIT NINE (9), U+0041 LATIN CAPITAL LETTER A .. U+0046 LATIN CAPITAL LETTER F, and U+0061 LATIN SMALL LETTER A .. U+0066 LATIN SMALL LETTER F with the character U+0030 DIGIT ZERO (0).

10. While input's length is zero or not a multiple of three, append a U+0030 DIGIT ZERO (0) character to input.

11. Split input into three strings of equal length, to obtain three components. Let length be the length of those components (one third the length of input).

12. If length is greater than 8, then remove the leading length-8 characters in each component, and let length be 8.

13. While length is greater than two and the first character in each component is a U+0030 DIGIT ZERO (0) character, remove that character and reduce length by one.

14. If length is still greater than two, truncate each component, leaving only the first two characters in each.

15. Let result be a simple color.

16. Interpret the first component as a hexadecimal number; let the red component of result be the resulting number.

17. Interpret the second component as a hexadecimal number; let the green component of result be the resulting number.

18. Interpret the third component as a hexadecimal number; let the blue component of result be the resulting number.

19. Return result.

Information on exactly which attributes are subject to this algorithm is scattered throughout the spec. Here is the complete list:

• <font color>
• <frame bordercolor>
• <frameset bordercolor>
• <hr color>
• <table bgcolor>
• <thead bgcolor>
• <tfoot bgcolor>
• <tbody bgcolor>
• <tr bgcolor>
• <td bgcolor>
• <th bgcolor>
• <body text>
• <body link>
• <body vlink>
• <body alink>
• <body bgcolor>

The other big news today is the addition of a section on matching HTML elements using selectors. Some of these (:link, :visited, :active) will be familiar to anyone who has written a CSS stylesheet, but there are a number of new selectors that correspond to concepts introduced in HTML 5.

• :link and :visited match hyperlinks (<a>, <area>, and <link> elements with an href attribute).
• :active matches certain elements while they are being activated, like a button between mousedown and mouseup (or keydown and keyup)
• :enabled and :disabled match hyperlinks and certain other elements that can be disabled, like form fields
• :checked matches checkboxes and radio buttons
• :indeterminate matches checkboxes in the indeterminate state
• :default matches default buttons in forms
• :valid and :invalid match form fields that have constraints
• :in-range and :out-of-range match form fields that have range-based constraints (i.e. they can either overflow or underflow)
• :required and :optional match certain form fields
• :read-write matches editable form fields and other editable elements, and :read-only matches any element that is not read-write

Other interesting changes of the day:

• r2784 defines the rendering rules for the <area> element.
• r2789 changes the list of allowable separators of coordinates in the coords attribute of an <area> element. [discussion, test suite]
• r2777, r2779, and r2781 make a variety of tweaks to the non-normative rendering section that I covered in episodes 20 and 21.

Discussion of the day: What's the problem? "Reuse of 1998 XHTML namespace is potentially misleading/wrong". Take it away, Lachlan:

I believe the issue is that the XHTML2 WG think they have change control over that namespace URI and that we shouldn't be using it. Additionally, the latest XHTML 2 editor's draft is now using the namespace.

This issue has been discussed in depth around mid 2007. The problem is that XHTML5 and XHTML2 are completely incompatible with each other and they cannot possibly use the same namespace as each other.

But XHTML2 also has several major incompatibilities with XHTML1, which would effectively make it impossible to implement both XHTML 1.x and 2 in the same implementation, if they share the same namespace. XHTML 5, on the other hand, has not only been designed with compatibility in mind, success is dependent upon continuing to use the same namespace.

Basically, the only solution to this issue that should be considered is that we continue using the namespace and the XHTML2 WG use a different namespace.

I'm sure that will go over well with the 12 people who are still working on XHTML 2.

Tune in... well, sometime soon-ish for another exciting episode of "This Week Day In HTML 5."

The Road to HTML 5: character encoding ↔ This Week Day in HTML 5 – Episode 23