Archive for the ‘Weekly Review’ Category
Wednesday, August 26th, 2009
I hope you enjoyed your summer. My oldest son started kindergarten today. Let's talk about HTML 5.
When last we checked, HTML 5 was humming along towards Last Call in October. Much has been made of this date; I won't bore you with the details, except to say that HTML 5 is very close to entering the next phase of its existence. Regular readers of this blog already know that parts of HTML 5 are already shipping in major browsers. The recently-released Firefox 3.5 supports <audio> and <video>, offline web applications, the drag-and-drop API, and the <canvas> text API. (Technically Firefox 3.0 supported the <canvas> text API too, properly cordoned off in its own vendor-specific functions because the API was not finalized at the time. You can paper over the differences fairly easily.)
So what new and exciting stuff has been added to HTML 5 this summer?
Microdata
At the table in the kitchen, there were three bowls of porridge. Goldilocks was hungry. She tasted the porridge from the first bowl. "This porridge is too hot!" she exclaimed.
So, she tasted the porridge from the second bowl. "This porridge is too cold," she said.
So, she tasted the last bowl of porridge. "Ahhh, this porridge is just right," she said happily and she ate it all up.
— The Story of Goldilocks and the Three Bears
r3074 introduces the concept of microdata. Microdata is designed to allow authors to include additional semantics in their pages for which there is no appropriate HTML element or attribute. For example, HTML is not expressive enough to mark up a contact in an address book (complete with individual fields for name, street address, email, and phone number) or an event on a calendar (complete with start date, end date, and location). Instead of creating new elements and attributes for every possible vocabulary, you can use the microdata attributes to enhance existing elements.
There are a number of other technologies with goals similar to microdata, including microformats and RDFa. As Ian Hickson explained in the message "Annotating structured data that HTML has no semantics for" that introduced microdata, microformats are fine for specific formats but are not flexible enough to be parseable by a generic parser, while RDFa relies on CURIEs and XML namespaces in a way that would require changes to HTML parsing algorithms to work interoperably between text/html and application/xhtml+xml. (Forgive me if I didn't explain that very well. There was a lot of yelling and very little explaining once it became clear that RDFa was not going to be included in HTML 5, so I probably missed some of the nuances.) Work is ongoing to create an RDFa-in-HTML specification.
ARIA
ARIA stands for "Accessible Rich Internet Applications." It is an emerging standard for making web applications more accessible to people using assistive technologies (including, but not limited to, blind people who browse the web with the help of screenreaders). The basic technique is for authors to define "roles" and "states" on individual elements to indicate what sort of control the element represents. For example, HTML has no "treeview" control, but JavaScript libraries like Dojo let you include a treeview in your web-based application with a combination of generic HTML elements, a few images, and a whole lotta JavaScript. ARIA gives you a way to say that the "treeview" HTML element (which is probably just a <div>) is acting as a treeview (that's its "role"). Each item in the treeview can be in the "expanded" or "collapsed" state, and the state changes as the user interacts with the control. Major browsers, including Microsoft Internet Explorer (8) and Firefox (2+) will notice the custom role on the element and announce to assistive technologies that this <div> element is acting as a treeview. (In fact, Dojo already supports these roles and states, due to work funded by IBM.)
r3657 adds the section Annotations for assistive technology products to HTML 5. There are still a number of unanswered questions about how the custom semantics defined by ARIA interact with the native semantics defined by HTML 5.
Everything Old is New Again
As regular readers of this blog already know, HTML 5 goes to great lengths to specify existing browser behavior, even to the point of "willfully violating" other specifications. Vast stretches of the HTML 5 specification are devoted to elements, attributes, and scripting features that nobody likes but everyone is required to support. To that end, r3502 defines the <listing>, <plaintext>, <acronym>, <xmp>, and <dir> elements; r3133 and r3141 define the <marquee> element; r3155, r3403, r3409, and r3410 define document.all.
Other important changes include the location.reload() method (r3220), the textarea.textLength property (r3177), a new rollback() method for synchronous SQL transactions r3210), and the ability to upload multiple files at a time from a web form (r3544 and r3545).
Features Removed
"The food here is terrible!"
"I know, and such small portions!"
(variously attributed)
Everyone complains that HTML 5 is too big, but nobody has any reasonable solution for making it smaller. (Splitting it into multiple specifications to make it "smaller" is like cutting a pie into slices to give it fewer calories.) However, based on implementor feedback, HTML 5 has shed a few poundsfeatures this summer. To wit:
- r3555 removes the
<datagrid> element and its associated APIs. Originally envisioned as a two-dimensional editable "spreadsheet-lite," it was never implemented in any browser.
- r3621 removes the
<bb> element, which was originally designed to support "installing" web applications as standalone programs. There were a number of security-related concerns, and browser vendors flatly refused to implement it.
- r3342 removes any mention of what an optimal video codec would look like. Contrary to popular belief, this revision does not remove the
<video> element itself; the <video> element is alive and well and implemented in Safari, Firefox, Google Chrome, and an experimental build of Opera. However, it is true that there is no single video codec that is supported out-of-the-box by all browsers. Firefox and Opera only support Ogg Theora, Google Chrome supports H.264 and Theora, and Safari supports whatever QuickTime supports (which doesn't include Ogg Theora unless you install a third-party plugin).
Administrative Stuff
"Man didn't the right form."
"What man?"
"The man from the cat detector van."
"The loony detector van, you mean."
"Look, it's people like you what cause unrest."
— Monty Python's "Fish License"
When web servers send you HTML, they are supposed to label it as such with the HTTP Content-Type header. Each content type (an HTML page, a JPEG image, an MPEG-4 video) has its own "MIME type." MIME types must be registered with the IANA.
r3552 adds the registration information for text/html, application/xhtml+xml, text/event-stream, text/cache-manifest, and application/microdata+json. r3582 adds the registration information for text/ping.
Standards frequently include references to other standards. References can be "normative" or "informative." To quote RFC 3967 (a standard about creating standards), "a normative reference specifies a document that must be read to fully understand or implement the subject matter in the new [standard], or whose contents are effectively part of the new [standard], as its omission would leave the new [standard] incompletely specified. An informative reference is not normative; rather, it provides only additional background information." r3580 adds a list of references to HTML 5.
Tune in next week as we return to our regular weekly schedule of "This Week in HTML 5."
Posted in Weekly Review | 7 Comments »
Wednesday, May 6th, 2009
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.
In this article:
Introducing the <hgroup> element
Topping our list of changes this week is the new <hgroup> element:
The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.
Meanwhile, the <header> element has been redefined:
The header element represents a group of introductory or navigational aids. A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.
Here is an example of how these elements can work together in marking up a specification:
<header>
<hgroup>
<h1>Scalable Vector Graphics (SVG) 1.2</h1>
<h2>W3C Working Draft 27 October 2004</h2>
</hgroup>
<dl>
<dt>This version:</dt>
<dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd>
...
</dl>
</header>
Relevant background reading:
(Re)introducing the accesskey attribute
Next up in this week's changes is the reintroduction and reformulation of the accesskey attribute. In HTML 4, the accesskey attribute allows the web designer to define keyboard shortcuts for frequently-used links or form fields. In HTML 5,
All elements may have the accesskey content attribute set. The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element.
If the accesskey attribute is used on a non-link, non-form-field element, it defines a command, which has a specific meaning in HTML 5.
Also new in HTML 5: the accesskey attribute may contain a number of shortcuts, space-separated, and the new .accessKeyLabel DOM property contains the shortcut key that the browser ultimately chose.
One possible enhancement, not in HTML 5 but under consideration for HTML 6, is the use of more-than-1-character strings to define roles, such as accesskey="help". The browser could then choose the appropriate shortcut key based on the user's platform and preferences.
I plan to write up a more detailed history of the accesskey attribute in a seperate article. Until then, here is some background reading:
(Re)introducing the window.setTimeout and window.setInterval functions
The window.setTimeout and window.setInterval functions have been in a state of limbo in the HTML 5 spec, waiting for an editor to take them and split them out into a separate spec. No editor has come forward, so back into HTML 5 they go.
These timer functions are complicated by their unique history in browser-land. They can take basically anything as their first argument. If you pass a function, it will be executed after the specified interval. If you pass anything else, the browser will call toString() on the parameter and then evaluate it as a JavaScript expression in the context of the current window (or, if the timer function is called from a web worker, the current WorkerUtils object). There is also a little-known but widely supported third argument to setTimeout and setInterval, which passes arguments to the evaluated expression. Meanwhile, the second argument -- the timeout value -- can also be any datatype. Browsers must call toNumber(toString(timeout)) and round down to the nearest integer.
More <video> changes
It seems that each week in HTML 5 brings more changes to the <video> element. While this is not strictly true, it is certainly true this week.
Events
Speaking of events, there was a series of event-related checkins this week. The onundo and onredo events, usually triggered by the user selecting the Undo or Redo item from the Edit menu, have been moved from the Document to the Window. [3003] These events are important for all sorts of web applications (think Google Docs and then work your imagination outward).
r3004 adds support for the onbeforeprint and onafterprint events, which are supported in Microsoft Internet Explorer since version 5.
r3005 updates the global list of event handlers to include these new events, some video-related events, some storage-related events, and several others that have slipped through the cracks during the thrashing of these features.
Other interesting changes this week
- r3019: plugins (like Flash) release the storage mutex (i.e. the
document.cookie lock mentioned in episode 28).
- r3015 adds
.protocol, .host, .hostname, .port, .pathname, .search, and .hash properties to <a> and <area> elements.
- r3032: the default size of
<h1> elements depends on how deep it is nested within nested <section> elements.
- r2988: if the document's last-modified is unknown,
document.lastModified should return the current time.
- r2981:
<time datetime="valid-datetime"></time> should display the datetime value in the user's timezone and locale.
- r3054:
<input type=tel>
Around the web
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »
Thursday, April 23rd, 2009
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.
This big news this week is the <datagrid> element. This is a brand spanking new element introduced in r2962.
In the datagrid data model, data is structured as a set of rows representing a tree, each row being split into a number of columns. The columns are always present in the data model, although individual columns might be hidden in the presentation.
Each row can have child rows. Child rows may be hidden or shown, by closing or opening (respectively) the parent row.
Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices. Thus, the first row of a list is row "0", the second row is row "1"; the first child row of the first row is row "0,0", the second child row of the first row is row "0,1"; the fourth child of the seventh child of the third child of the tenth row is "9,2,6,3", etc.
The chains of numbers that give a row's path, or identifier, are represented by arrays of positions, represented in IDL by the RowID interface.
The root of the tree is represented by an empty array.
Each column has a string that is used to identify it in the API, a label that is shown to users interacting with the column, a type, and optionally an icon.
The possible types are as follows:
| Keyword | Description |
|---|
text | Simple text. |
editable | Editable text. |
checkable | Text with a check box. |
list | A list of values that the user can switch between. |
progress | A progress bar. |
meter | A gauge. |
custom | A canvas onto which arbitrary content can be drawn. |
Each column can be flagged as sortable, in which case the user will be able to sort the view using that column.
Columns are not necessarily visible. A column can be created invisible by default. The user can select which columns are to be shown.
When no columns have been added to the datagrid, a column with no name, whose identifier is the empty string, whose type is text, and which is not sortable, is implied. This column is removed if any explicit columns are declared.
Each cell uses the type given for its column, so all cells in a column present the same type of information.
The other major change to the spec this week is the <keygen> element. As I mentioned in episode 12, someone went to the trouble of documenting the <keygen> element, and there has been a surprising amount of discussion about it in the past six months. Simply put, the keygen element represents a key-pair generator control. You include it in a <form>. When your browser submits the form, the private key is stored in the local keystore, and the public key is packaged and sent to the server. [r2960]
Not much else went into the spec this week, but there's been a lot of interesting activity around the web.
- A new W3C Working Draft of HTML 5 is out. As I've mentioned before, this is just a snapshot of progress-to-date. By its very nature, it is out of date as soon as it's published, since the working group continues to progress while the webmaster gnomes are publishing.
- Also published: the latest draft of "HTML 5 differences from HTML 4", compiled by Opera's Anne van Kesteren.
- Mozilla bug 465007: "Harmonize content sniffing in HTML 5 and Firefox." The next version of Firefox will sniff images the way the HTML 5 specification recommends. I am still opposed to content sniffing on philosophical grounds, but philosophy doesn't get you very far on the open web, and documented heuristics are better than undocumented heuristics. And interoperable, documented heuristics are even better!
- Speaking of content sniffing, Adam Barth's [PDF] whitepaper, Secure Content Sniffing For Web Browsers, is an excellent read.
- Henri Sivonen's The Last of the Parsing Quirks is equally fascinating.
- Superset encodings [Re: ISO-8859-* and the C1 controlrange] is an incredibly detailed look into the insane world of character encoding.
- You can still help us review HTML 5! Your input is important!
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 8 Comments »
Monday, April 13th, 2009
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.
There has been very little spec-related activity this week, so I will briefly repeat Ian Hickson's request to Help us review HTML5 and then turn to a fascinating debate happening right now on the WHATWG mailing list.
The debate revolves around perceptions and expectations of privacy. Brady Eidson (Apple/WebKit) kicks off the discussion with Private browsing vs. Storage and Databases:
A commonly added feature in browsers these days is "private browsing mode" where the intention is that the user's browsing session leaves no footprint on their machine. Cookies, cache files, history, and other data that the browser would normally store to disk are not updated during these private browsing sessions.
This concept is at odds with allowing pages to store data on the user's machine as allowed by LocalStorage and Databases. Sur[e]ly persistent changes during a private browsing session shouldn't be written to the user's disk as that would violate the intention of a private browsing session. ...
- Disable LocalStorage completely when private browsing is on. Remove it from the DOM completely.
- Disable LocalStorage mostly when private browsing is on. It exists at window.localStorage, but is empty and has a 0-quota.
- Slide a "fake" LocalStorage object in when private browsing is enabled. It starts empty, changes to it are successful, but it is never written to disk. When private browsing is disabled, all changes to the private browsing proxy are thrown out.
- Cover the real LocalStorage object with a private browsing layer. It starts with all previously stored contents. Any changes to it are pretended to occur, but are never written to disk. When private browsing is disabled, all items revert to the state they were in when private browsing was enabled and writing changes to disk is re-enabled.
- Treat LocalStorage as read-only when private browsing is on. It exists, and all previously stored contents can be retrieved. Any attempt to setItem(), removeItem(), or clear() fail.
Ian Fette (Google/Chrome) explains how Google Chrome handles LocalStorage in "incognito" mode:
[W]hilst the [incognito] session is active, pages can still use a database / local storage / ... / and at the end of the session, when that [temporary] profile is deleted, things will go away. I personally like that approach, as there may be legitimate reasons to want to use a database even for just a single session.
Darin Fisher (Google/Chrome) follows up to clarify Google Chrome's behavior:
Chrome's "incognito mode" means -- is defined as -- starting from a clean slate (as if you started browsing for the first time on a new computer), and when you exit incognito mode, the accumulated data is discarded. That's all there is to it. The behavior of LocalStorage and Database in this mode is deduced easily from that definition.
Jonas Sicking (Mozilla/Firefox) explains his opposition to option 5:
My concern with this is the same as the reason we in firefox clear all cookies when entering private browsing mode. The concern is as follows:
- A search engine stores a user-id token in a cookie. They then use this token to server side store the users 10 last searches.
- A user uses this search engine to search for various items. Doing this causes the user-id token to be stored in a cookie.
- The user then switches to private browsing mode.
- The user makes a search for a present for his wife.
- The user switches back into normal browsing mode.
At this point it is still possible to see the search for the wifes present in the websites store of recent searches.
Something very similar could happen for localStorage I would imagine, where the user-identifing information is stored in the localStorage rather than a cookie.
Josh "timeless" Soref (core Firefox developer) explores the privacy implications of different options:
[Option 1: Disabling LocalStorage won't work because] Many sites will just assume that they know a given useragent supports localstorage, so they'll be surprised and break. This will mean that a user can't use certain sites.
[Option 2: Enabling LocalStorage with 0 quota] will enable sites to know that the user is browsing in private, which is probably also a violation of the user's trust model. If I were to be browsing in private, I wouldn't want most sites to know that I'm doing this.
[Option 4 or 5: Starting with existing LocalStorage data] means the site will know who you are (on average), and is almost certainly never what the user wants.
Jonas Sicking (Mozilla/Firefox) tentatively states
For what it's worth, I believe we're currently planning on doing 2 in firefox.
Brady Eidson concludes:
I strongly share Jonas' concern that we'd tell web applications that we're storing there data when we already know we're going to dump it later. For 3 and 4 both, we're basically lying to the application and therefore the user.
... So far I'm standing by WebKit choosing #5 for now.
Drew Wilson summarizes his thoughts on the matter:
I think the #1 goal for incognito mode has to be "maximum compatibility" -- let sites continue to work, which kills options #1 & 2. A secondary goal for incognito mode would be "don't let sites know the user is in incognito mode" -- this kills approach #1 and #5, and possibly #2 (depending on whether there are significant non-incognito use cases that also have 0 local storage quota).
For my part, I agree with Drew, and I would add this: I use Google Chrome's "incognito mode" quite frequently when I'm developing websites. It's an easy way to test from a "blank slate" with no cookies and no cache, and it's much easier than juggling multiple profiles. If data in my LocalStorage "bleeds" into incognito mode, this use case would become unreliable and web development would be harder for me. (Bil Corry makes this point too.)
On a more philosophical level, it's nobody's business that I'm in private browsing mode. (Scott Hess makes this point too.) If authors can detect it, I consider that a serious bug. (Imagine the ha.ckers.org headline: "Safari Hole Allows Sites To Detect 'Private' Browsing, Punish Users.") Even worse, if LocalStorage could be used as a "super-cookie" for less-than-honorable sites to track me from normal usage to incognito usage, then it's not really "private browsing" in any sense of the word that matters.
In the early days of Greasemonkey, there were discussions of whether Greasemonkey should send or provide some detectable signal to page authors that Greasemonkey was running and the user had active scripts modifying the current page. To which I replied:
If Greasemonkey makes any overtures towards allowing web publishers to "opt out" or override my browsing experience in any way, I will immediately fork it and make it my life's mission to maintain the fork as long as possible.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »
Wednesday, April 8th, 2009
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 for the week of March 30th is the addition of a synchronous database API to the Web Storage spec (which was split out from the HTML 5 spec a few weeks ago). This new API defines a DatabaseSync object whose methods return SQLTransactionSync objects. This directly mirrors the asynchronous database API, which had already defined a Database object whose methods return SQLTransaction objects. [r2958]
Another interesting change this week is r2921, which adds the placeholder attribute to the <textarea> element. I tracked the initial discussion of the placeholder attribute in episode 8 and noted its appearance in HTML 5 in episode 13. Previously you could only use the placeholder attribute on <input type=text>, <input type=email>, <input type=url>, and <input type=password>, but Thomas Broyer pointed out that Google Code (among others) uses placeholder text on <textarea> elements. Such sites could now theoretically migrate their current script-based solutions to HTML 5 markup.
Other interesting changes this week:
- r2928 recommends that browsers should reset the
text-indent property when rendering a <textarea> element.
- r2930 notes a strange edge case where paragraphs (
<p> elements) can end up overlapping each other if they are used as fallback content within an <object> element.
- r2933 adds event handler DOM attributes like
onclick to the WebIDL definition of the document object.
- r2936 allows the
spellcheck attribute to be present with no value, as a synonym for spellcheck="true". I first mentioned the spellcheck attribute in episode 23, and again in The Road to HTML 5: spellchecking.
- r2937 allows
<textarea wrap=off>.
- r2941 further tweaks the algorithm for parsing legacy color attributes, which is trickier than you might think.
- r2943 allows the
width and height attributes of an <img> element to be 0.
Around the web:
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »