Computerworld - Although there are many reasons why the Web fails to render appropriately in browsers (see "When good browsers go bad -- and they all do"), the two main reasons today are browser bugs and ambiguities in the standards, says Ian Hickson, a software engineer at Google Inc. and editor of the W3C HTML 5 specification.
The emerging CSS 2.1 specification will be the first major W3C recommendation to address ambiguities and other "edge cases" -- real-world issues such as how browsers should react to invalid Web page content. HTML 5 will be the second.
"One of the big challenges is that the suite of standards we have right now are frequently not specified enough in certain circumstances," such as how to render a page when the markup is invalid, says Chris Wilson, platform architect for Internet Explorer at Microsoft Corp.
Hickson says that's changing.
"Until recently, W3C specifications tended only to talk about what should happen for the simple cases, without really discussing edge cases [such as] how to handle invalid content," he says. That left browser vendors no guidance when pages varied from the "main case" cited in the standard (see Hickson's example, below).
Today, the latest specifications for HTML and CSS are being held to a higher quality standard. "Nowadays, we are not only expecting a test suite covering all the required and optional features of the specification but also a certain number of implementations as well," says Philippe Le Hegaret, interaction domain lead at the W3C.
New standards must define what happens when erroneous content is found, and the working group strives to define all of the edge cases. "The standards community is also applying this level of quality to other specifications, like the Selectors API, Web DOM core and SVG," Hickson says.
But that quality comes at a cost: Finding all of those edge cases -- which can number in the thousands -- and defining them has been a long and arduous undertaking, Hickson says. Work on CSS 2.1 started in 1998, right after the release of Version 2.0, and it's still not finished. Work on HTML 5 started in 2003 and probably won't be final before 2012.
"There's a lot of talk now about the W3C really holding back innovation and progress. The working groups are just really, really slow," says Derek Featherstone, group lead at the Web Standards Project.
HTML 4 has an input element, which has a type="" attribute, which takes values like "text" and "checkbox." What should happen when you have an HTML input element with type="text" in a document is reasonably well defined: You display a text field.
What should happen with input type="checkbox" is relatively well defined. However, with script, you can take the type="text" attribute, and change its value dynamically, while the user is editing the control, so that it is type="checkbox." This is not a common thing to do, and the HTML 4 and DOM2 HTML specs are completely silent on what should happen when this case is hit.
The result is that different browsers do different things; IE will throw an exception, if I recall correctly, while Firefox will change the text field to a checkbox.
Another question is what should happen if the value is changed back. Should the value the user entered be put back in the text field, or should it reset to the default value? Or, if there is no default, should it use the value that would have been submitted for the checkbox namely, "on")?
-- Ian Hickson
Editor, W3C HTML 5 specification
Free Insider GuideCopyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
