The WHATWG Blog

This Week in HTML 5 – Episode 9

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.

• r2305 covers editing a <textarea>.
• r2309 defines the rows and cols attributes.
• r2310 defines the wrap attribute. (Long supported by Netscape and still supported in Internet Explorer, the wrap attribute has never been standardized until now.)
• r2311 defines the maxlength attribute.
• r2312 defines the required attribute, also new in HTML 5.
• r2313 removes support for the accept attribute, which has always been problematic and its (limited) potential has never been implemented. This only affects the <textarea> element; <input type=file> elements still have an accept attribute that controls what types of files may be uploaded.

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:

• Anne van Kesteren gave an interview on the state of several bleeding edge web standards.
• Simon Pieters ponders what to do about nested <h1> elements.
• In response to Olivier Gendrin, Anne van Kesteren points out that the CSSOM standard defines a window.media attribute. Unlike CSS media types, window.media would be directly queryable from Javascript.

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

Posted in Weekly Review | 2 Comments »

Validator.nu HTML Parser 1.1.0

Monday, August 25th, 2008

I have released a new version of the Validator.nu HTML Parser (an implementation of the HTML5 parsing algorithm in Java). The new release supports SVG and MathML subtrees, is faster than the old version, fixes bugs, is more portable and supports applications that want to do document.write().

The parser comes with a sample app that makes it possible to use XSLT programs written for XHTML5+SVG+MathML with text/html.

Warning! The internal APIs have changed. Please refer to the Upgrade Guide below.

Change Log

• Made the SAX, DOM and XOM parser entry point constructors default to altering the infoset instead of throwing when the input needs coercing to be an XML 1.0 4th ed. plus Namespaces infoset.
• Isolated Java IO dependent code from the parser core. The parser core now compiles on Google Web Toolkit.
• Refactored the tokenizer to use a switch branch per state instead of method per state.
• Made various performance tweaks to the tokenizer.
• Implemented support for MathML and SVG foreign content. (Note that the SVG part is based on spec text that has been commented out from the spec at the request of the SVG WG.)
• Made the parser suspendable after any input character.
• Made it possible for custom TreeBuilder subclasses to request parser suspension. (Applications wishing to implement document.write() should provide their own TreeBuilder subclass and a document.write()-aware replacement of the Driver class. Look in the gwt-src/ directory for sample code.)
• Made changes to the parser core to make it more suitable for mechanical translation into other object-oriented programming languages that have C-like control structures but not necessarily a garbage collector (with focus on targeting C++). This work is not complete.
• Made the HTML serializer do the right thing when input represents a conforming XHTML+SVG+MathML tree. (Results may be bad for non-conforming input trees.)
• Developed sample programs for converting between HTML5 and XHTML5 when the input is known to be conforming.
• Provided an XML serializer so that the sample code no longer depends on the Xalan serializer.
• Improved API documentation.
• Fixed bugs in the tokenizer, tree builder and the input stream character encoding decoder.
• Made coercion to an XML infoset work according to the HTML5 spec.
• Added ID uniqueness checking.
• Various other fixes.

Upgrade Guide from 1.0.7 to 1.1.0

In all cases, you need to check that your application does not break when it receives SVG or MathML subtrees.

If you use the parser through the SAX, DOM or XOM API and do not pass an explicit XmlViolationPolicy to the constructor of HtmlParser, HtmlDocumentBuilder or HtmlBuilder:

If you really wanted the old default behavior, you should now pass XmlViolationPolicy.FATAL to the constructor.

If you did not really want to have fatal errors by default, you do not need to do anything, since ALTER_INFOSET is now the default.

If you use the parser through the SAX, DOM or XOM API and do pass an explicit XmlViolationPolicy to the constructor of HtmlParser, HtmlDocumentBuilder or HtmlBuilder:

You do not need to change your code to upgrade.

If you have your own subclass of TreeBuilder:

The abstract methods on TreeBuilder now have additional arguments for passing the namespace URI. You should upgrade your subclass to deal with the namespace URIs. (The URI is always an interned string, so you can use == to compare.)

The entry point for passing in a SAX InputSource has moved from the Tokenizer class to the Driver class (in the io package), so you should change your references from Tokenizer to Driver.

If you have your own implementation of TokenHandler:

Please refer to the JavaDocs of TokenHandler. Also note the new separation of Tokenizer and Driver mentioned above.

Posted in Syntax | Comments Off on Validator.nu HTML Parser 1.1.0