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 biggest news this week is revision 2020, which standardizes the navigator object:
The navigator attribute of the Window interface must return an instance of the Navigator interface, which represents the identity and state of the user agent (the client), and allows Web pages to register themselves as potential protocol and content handlers.
Currently, HTML 5 defines four properties and two methods:
appNameappVersionplatformuserAgentregisterProtocolHandlerregisterContentHandler
This is only a subset of navigator properties and methods that browsers already support. See Navigator Object on Google Doctype for complete browser compatibility information.
Next up: Content-Language. No, not the HTTP header, not even the <html lang> attribute, but the <meta> tag! As reported by Henri Sivonen,
It seems that some authoring tools and authors use <meta http-equiv='content-language' content='languagetag'> instead of <html lang='languagetag'>.
This led to revision 2057, which defines the <meta> http-equiv="Content-Language"> directive and its relationship with lang, xml:lang, and the Content-Language HTTP header.
In the continuing saga of the alt attribute, the new syntax for alternate text of auto-generated images (which I covered in last week's episode) has generated some followup discussion. Philip Taylor is concerned that it will increase complexity for authoring tools; others feel the complexity is worth the cost. James Graham suggested a no-text-equivalent attribute; similar proposals have been discussed before and rejected.
Switching to the new Web Workers specification (which I also covered last week), Aaron Boodman (one of the developers of Google Gears) posted his initial feedback. This kicked off a long discussion and led to the creation of the Worker object.
Other interesting changes this week:
Administrivia: "This Week in HTML 5" now has its own feed.
Tune in next week for another exciting episode of "This Week in HTML 5."
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: Weekly Review
Earlier, I blogged about running the Validator.nu HTML Parser inside Hixie’s Live DOM Viewer using the magic of the hosted mode of the Google Web Toolkit. Back then, a compiler bug in GTW 1.5 RC1 prevented the parser from running as JavaScript in the Web mode. Google has now released GWT 1.5 RC2, which contains a fix for the bug.
So without further ado, here’s Live DOM Viewer with an HTML5 parser running as JavaScript in your browser.
Try pasting in the SVG lion or some MathML in Firefox 3 and Opera 9.5.
Known problems:
- SVG
use does not work in Firefox. Update: Fixed in Minefield nightlies.
- SVG does not render is Safari.
- IE does not support
createElementNS and, thus, does not work at all.
A big thanks for the GWT team for making this work!
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: DOM · Syntax
Welcome to a new semi-regular column, "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 biggest news is the birth of the Web Workers draft specification. Quoting the spec, "This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism." This is the standardization of the API that Google Gears pioneered last year. See also: initial Workers thread, announcement of new spec, response to Workers feedback.
Also notable this week: even more additions to the Requirements for providing text to act as an alternative for images. 4 new cases were added:
- A link containing nothing but an image
- A group of images that form a single larger image
- An image not intended for the user (such as a "web bug" tracking image)
- Text that has been rendered to a graphic for typographical effect
Additionally, the spec now tries to define what authors should do if they know they have an image but don't know what it is. Quoting again from the spec:
If the src attribute is set and the alt attribute is set to a string whose first character is a U+007B LEFT CURLY BRACKET character ({) and whose last character is a U+007D RIGHT CURLY BRACKET character (}), the image is a key part of the content, and there is no textual equivalent of the image available. The string consisting of all the characters between the first and the last character of the value of the alt attribute gives the kind of image (e.g. photo, diagram, user-uploaded image). If that value is the empty string (i.e. the attribute is just "{}"), then even the kind of image being shown is not known.
- If the image is available, the element represents the image specified by the src attribute.
- If the image is not available or if the user agent is not configured to display the image, then the user agent should display some sort of indicator that the image is not being rendered, and, if possible, provide to the user the information regarding the kind of image that is (as derived from the alt attribute).
See also: revision 1972, revision 1976, revision 1978, revision 1979, Images and alternate text.
Other interesting changes this week:
- revision 1951: define
window.top
- revision 1956: "User agents must not run executable code embedded in the image resource."
- revision 1958: more notes on what is a valid image (a surprisingly difficult question)
- revision 1965: allow
<a> elements to straddle paragraphs
- revision 1998: define what happens when you set
onclick='' on a document outside a Window
- revision 1999: define
javascript: in Window-less environments
- revision 2001: define 'directionality' in terms of the
dir='' attribute for cases where the 'direction' property has no computed value
- revision 2002: define processing for the second argument to
getDataURL() for image/jpeg
- revision 2004: specify how to handle transparent images in the
toDataURL() method
- revision 2008: make patterns required in the
<canvas> API
- revision 2016: when
<script type=''> is given, it must match the type of the script, even if the script is Javascript
- revision 2019: remove
autosubmit='' from the <menu> element
Tune in next week for another exciting episode of "This Week in HTML 5."
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: Processing Model · WHATWG · Weekly Review
Boagworld is a web design and development podcast based in the UK. In today's episode, they interview me about HTML5. In it, we discuss the current state of HTML5, some of the new features that are currently, or are being implemented, and what we can expect in the future.
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: Events
If you’ve investigated how browsers parse HTML, you’ve probably used Hixie’s Live DOM Viewer to see what happens. Wouldn’t it be cool, though, if you could experiment with the HTML5 parsing algorithm in the same UI? Well, now you can.
I was looking for a way to experiment with document.write() in the code base of the Validator.nu HTML Parser and I was looking for a way to let people see the parse tree output of the HTML5 parsing algorithm more easily. Instead of writing a test harness fully in Java, I thought it would be better to use the Live DOM Viewer and a browser engine as the test harness. The good news is that Google Web Toolkit makes it possible to put these pieces together, and the trunk of the Validator.nu HTML parser now comes with a document.write()-aware tokenizer driver and a tree builder subclass for GWT.
The bad news is that the Java-to-JavaScript compiler of GWT has a bug that blocks me from putting the result online as JavaScript. The Hosted Mode of GWT, works, though.
Here’s how you can run the Validator.nu HTML Parser in the Live DOM Viewer locally in the Hosted Mode of GWT (on Mac or Linux):
- Check out the source: svn co http://svn.versiondude.net/whattf/htmlparser/trunk/ htmlparser
- Download and untar GWT 1.5 RC1
- On Linux, install libstdc++5 and a JDK (Ubuntu's OpenJDK-based package worked for me).
- Edit the paths in
HtmlParser-shell (Mac) or HtmlParser-linux (Linux) to point to the location of GWT.
- Run
HtmlParser-shell (Mac) or HtmlParser-linux (Linux)
Known problems:
- The Linux version of GWT runs an outdated version of Gecko, and the rendered view doesn't work. The DOM view does.
- The Mac version of GWT runs a Web Inspector-enabled version of WebKit, but SVG does not draw.
document.write() semantics are right only for inline scripts.- Copying and pasting using keyboard shortcuts doesn’t work. (Use the context menu.)
- On Linux, GTW prints a lot of harmless warnings about not finding annotations. (I don’t know why that happens. The annotations should be among translatables.)
- Gecko (used by GTW on Linux) doesn't allow the creation of xmlns attributes in no namespace, so things stop working if you try to put an attribute called
xmlns on HTML elements.
- The DOM view on Linux doesn't report names with colons in them per the HTML5 spec.
(Aside: This code could have applicability beyond testing the parser. If the compiler bug were fixed or worked around, a script could document.write() a math element and an svg element to sniff if they are parsed according to HTML5 and if they aren't, move aside load event handlers, document.write() <plaintext style='display:none'>, wait until DOMContentLoaded, load the the already created html, head and body elements onto the tree builder stack and head pointer of the HTML5 parser to and reparse the content of the plaintext element as HTML5 and call the load event handlers. See Philip Taylor’s proof of concept with S-expressions.)
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: Syntax
Lachlan Hunt and I recently gave a presentation entitled Getting Your Hands Dirty with HTML5 at the @media 2008 conference in London. The audience was mainly front-end developers; the kind of people who are using HTML to make a living, so it was a great chance to get the message out about some of the new features that have been under development.
The talk covered the Design Principles under which HTML5 is being developed, how some of the features of HTML5 can be used to enhance common web sites, and how people can get involved with the development of HTML5.
The presentation seemed to go reasonably well, especially given that we had not met till the morning of the talk although we did have fewer demos than I would have liked, both due to technical problems in the talk and a lack of time to prepare. So, for those who were at the talk (as well as those who were not), here are a somewhat random collection of demos of the HTML5 features we mentioned:
If anyone who saw the presentation is reading this and would like to provide constructive criticism on the talk, I would really appreciate it; giving talks is fun so it would be nice to get better at it 
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: WHATWG
Since HTML5 is a large specification Ian and I, being encouraged by Dan Connolly from the W3C, wrote an introductory document to the offline Web application features in HTML5 — Offline Web Applications — which the W3C published earlier today. In summarized form, it explains the SQL API, the offline application cache API, and some of the related APIs, such as online and offline events.
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: W3C
Kai Hendry has written an HTML filetype plugin for Vim that allows you to use Henri Sivonen’s Validator.nu conformance checking (validation) service remotely to check the contents of any HTML document you edit in Vim and determine if the document is HTML5-conformant (valid).
Here’s a screenshot of it in use (note that it links to a full-size image that's easier to read).
The filetype plugin is also demo'ed in a screencast tutorial on editing Web applications that Kai has blogged about in a VIM IDE for Web applications posting on his blog (see the blog posting for a link to the video).
All that you need to do to install the Vim filetype plugin is to download the plugin source and save it into ~/.vim/ftplugin/html.vim. To use it to check a document, first do :make within Vim, then use :cope and :clist and :cnext and such to locate the errors (for more details, read the section of the Vim docs that relates to those commands.)
How and why it works
Vim has a set of “quickfix” commands that provide something that many development IDEs also have these days: A way to run a compiler or lint checker or other external tool on the contents of a file you are editing, and then to have any errors returned — along with the line and column numbers of the places in your file where the errors occur — as a list that you can then easily step through or jump through one-by-one and fix. It’s a very powerful feature.
Kai’s HTML filetype plugin provides a way to use Vim’s “quickfix” commands to do conformance checking of HTML5 files. The plugin is dead simple; it’s just two lines:
set makeprg=curl\ -s\ -F\ laxtype=yes\ -F\ parser=html5\
\ -F\ level=error\ -F\ out=gnu\ -F\ doc=@%\
http://validator.nu
set errorformat=\"%f\":%l.%c-%m
(Note that I've just wrapped the first line for the purpose of readability in this post.)
The makeprg option in the first line tells Vim what “make program” you want to use when checking HTML files. And the errorformat option in the second line tells Vim the expected format of error messages from that “make program” — so that it can parse the error messages to get the line and column numbers of the places in your file where the errors occur (the meanings of the various parts of the string used in that errorformat value are: %f, filename; %l, line number; %c, column number; %m, error message).
Interaction with Validator.nu
What Kai’s HTML filetype plugin does it to use as the “make program” the curl command-line HTTP client, and in turn, to have curl send a POST request to Validator.nu. The contents of that POST request are set by the parameters and values specified by the -F options passed to curl. Essentially what this does is to emulate what would happen if you used the form-based interface at the Validator.nu website to manually set the values of the various form fields in that interface. (Note that wget could be probably used here (with different options) to do the same thing.)
What Validator.nu does in return is to send a response with the list of errors — in a format that allows the list of errors to be easily parsed by tools that have built-in support (like Vim’s “quickfix”) for reading error lists that are in a regular format and doing something with them.
GNU-formatted error output
In this case, since the out=gnu parameter and value were passed to Validator.nu, the particular format in which Validator.nu returns the error list is the standard GNU error format that’s used by many applications (including that other editor, Emacs). This use case (enabling remote validation and error-evaluation with editing applications) is actually one of the main cases for which Henri added the GNU-formatted error-reporting option to Validator.nu.
Validator.nu + Vim = easy HTML5 conformance checking
The end result is that you get the error information back into Vim in a way that lets you more easily locate and fix the errors.
So setting just two options is all it takes in an editing application like Vim to enable Validator.nu to be used remotely like this (that is, to do integrated HTML5 conformance-checking and error-reporting within the editor). This seems to me to be a pretty good testament (another in a long list) to the utility of the Validator.nu service and to the foresight that’s gone into its design.
It guess it also says a lot about the utility of Vim and the foresight that’s gone into its design — but we all already know how great Vim is, right?
This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license
Tags: Conformance Checking
While the technologies used on the web have always been mostly free, with non-free technologies delegated to non-essential parts of the net, this has been changing fast, lately. The popularity of YouTube has demonstrated the pervasiveness of Adobe’s Flash, to an extent where not having Flash is one of the big downsides to any alternative operating system. And to possibly make matters worse, Microsoft is pushing its proprietary Silverlight technology. The founder of Mozilla Europe, Tristan Nitot, warns for “the dangers of the proprietary web”.
ZDNet.co.uk is reporting that at the Internet World Conference in London, Nitot warned that companies like Adobe and Microsoft might have an agenda with their Flash and Silverlight technologies. Even though at the moment these technologies are free to download, this might change in the future. “But maybe they have an agenda,” Nitot said, “they’re not here for the glory; they’re here for the money.” He also warns for the dangers of these companies withholding products from certain markets. As examples, he mentions Internet Explorer for the Mac/UNIX, and Adobe’s refusal to provide up-to-date binaries of Flash.
[Web developers should make] sure that Silverlight and Flash will always be available on all platforms [and] run decently on all platforms. You’re producing content for your users and there’s someone in the middle deciding whether users should see your content. If Adobe or Microsoft decide to compete with you and you’re using their technology, you cannot compete. If you consider proprietary technologies, think hard; are you really trading convenience in the short term with independence in the long term?”
Nitot continued that you pretty much need Flash these days in order to offer video online, but that this might change in the near future when HTML5 reaches maturity, which will do away with the need for Flash for audio and video content, because audio and video will be part of HTML5. He told ZDNet.co.uk after the presentation that Adobe’s Flash is not compatible with the open web, and that Adobe may open source it if Silverlight’s competition becomes too fierce.
Originally posted at: http://www.newmobilecomputing.com/story/19699/Mozilla_Warns_of_Flash_Silverlight_Agenda
Tags: Uncategorized
Well, I’m not sure about their claim to load pages twice as fast as IE7 and Firefox 2… maybe when javascript has overloaded your browser. Either way, Firefox 3 is faster than Safari by a bit, so it doesn’t matter much to me
Apple has introduced Safari 3.1, an update of the web browser for Mac and Windows, which supports the latest audio, video and animation standards. It’s the first browser to support the new video and audio tags in HTML 5 and the first to support CSS Animations. The upgrade Safari also supports CSS Web Fonts.
Safari loads web pages 1.9 times faster than Internet Explorer 7 and 1.7 times faster than Firefox 2, according to Phil Schiller, Apple’s senior vice president of Worldwide Product Marketing. Safari also runs JavaScript up to six times faster than other browsers, and is the first browser to support the latest innovative web standards needed to deliver the next generation of highly interactive Web 2.0 experiences, he adds.
Safari 3.1 is available immediately as a free download. The Mac version requires Mac OS X 10.4.11 or higher, a minimum of 256MB of memory and is designed to run on any Intel-based Mac or a Mac with a PowerPC G5, G4 or G3 processor and built-in FireWire. Safari 3.1 for Windows requires Windows XP or Windows Vista, a minimum of 256MB of memory and a system with at least a 500MHz Intel Pentium processor.
Originally posted at: http://www.macsimumnews.com/index.php/archive/safari_31_adds_support_for_html_5_tags_css_web_fonts/
Tags: Uncategorized
