The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Author Archive

« Previous Entries

Supporting New Elements in IE

Wednesday, January 7th, 2009

Internet Explorer poses a small challenge when it comes to making use of the new elements introduced in HTML5. Among others, these include elements like section, article, header and footer. The problem is that due to the way parsing works in IE, these elements are not recognised properly and result in an anomalous DOM representation.

To illustrate, consider this simple document fragment:

<body>
  <section>
    <p>This is an example</p>
  </section>
</body>

Strangely, IE 6, 7 and 8 all fail to parse the section element properly and the resulting DOM looks like this.

Notice how IE actually creates 2 empty elements. One named SECTION and the other named /SECTION. Yes, it really is parsing the end tag as a start tag for an unknown empty element.

There is a handy workaround available to address this problem, which was first revealed in a comment by Sjoerd Visscher. The basic concept is that by using document.createElement(tagName) to create each of the unknown elements, the parser in IE then recognises those elements and parses them in a more reasonable and useful way. e.g. By using the following script:

document.createElement("section");

The resulting DOM for the fragment given above looks like this:

This same technique works for all unknown elements in IE 6, 7 and 8. Note that there is a known bug that prevented this from working in IE 8 beta 2, but this has since been resolved in the latest non-public technical preview.

For convenience, Remy Sharp has written and published a simple script that provides this enhancement for all new elements in the current draft of HTML5, which you can download and use.

This script is not needed for other browsers. Opera 9, Firefox 3 and Safari 3 all parse unknown elements in a more reasonable way by default. Note, however, that Firefox 2 does suffer from some related problems, for which there is unfortunately no known solution; but it is hoped that given the faster upgrade cycle for users of Firefox, relatively speaking compared with IE, Firefox 2 won't pose too much of a problem in the future.

Posted in Browsers, DOM, Elements, Events, Syntax | 25 Comments »

Interview about HTML5 on Boagworld

Wednesday, July 2nd, 2008

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.

Posted in Events | Comments Off on Interview about HTML5 on Boagworld

Reverse Ordered Lists

Wednesday, April 23rd, 2008

One of the newly introduced features in HTML 5 is the ability to mark up reverse ordered lists. These are the same as ordered lists, but instead of counting up from 1, they instead count down towards 1. This can be used, for example, to count down the top 10 movies, music, or LOLCats, or anything else you want to present as a countdown list.

In previous versions of HTML, the only way to achieve this was to place a value attribute on each li element, with successively decreasing values.

<h3>Top 5 TV Series</h3>
<ol>
  <li value="5">Friends
  <li value="4">24
  <li value="3">The Simpsons
  <li value="2">Stargate Atlantis
  <li value="1">Stargate SG-1
</ol>

The problem with that approach is that manually specifying each value can be time consuming to write and maintain, and the value attribute was not allowed in the HTML 4.01 or XHTML 1.0 Strict DOCTYPEs (although HTML 5 fixes that problem and allows the value attribute)

The new markup is very simple: just add a reversed attribute to the ol element, and optionally provide a start value. If there’s no start value provided, the browser will count the number of list items, and count down from that number to 1.

<h3>Greatest Movies Sagas of All Time</h3>
<ol reversed>
  <li>Police Academy (Series)
  <li>Harry Potter (Series)
  <li>Back to the Future (Trilogy)
  <li>Star Wars (Saga)
  <li>The Lord of the Rings (Trilogy)
</ol>

Since there are 5 list items in that list, the list will count down from 5 to 1.

The reversed attribute is a boolean attribute. In HTML, the value may be omitted, but in XHTML, it needs to be written as: reversed="reversed".

The start attribute can be used to specify the starting number for the countdown, or the value attribute can be used on an li element. Subsequent list items will, by default, be numbered with the value of 1 less than the previous item.

The following example starts counting down from 100, but omits a few items from the middle of the list and resumes from 3.

<h3>Top 100 Logical Fallacies Used By Creationists</h3>
<ol reversed="reversed" start="100">
  <li>False Dichotomy</li>
  <li>Appeal to Ridicule</li>
  <li>Begging the Question (Circular Logic)</li>
  <!-- Items omitted here -->
  <li value="3">Strawman</li>
  <li>Bare Assertion Fallacy</li>
  <li>Argumentum ad Ignorantiam</li>
</ol>

Posted in Elements, Syntax | 26 Comments »

Why the Alt Attribute May Be Omitted

Thursday, August 23rd, 2007

The specification of the alt attribute was recently worked on to thoroughly improve its definition, including an in depth explanation of how to provide appropriate alternate text, with clear authoring requirements.

The requirements describe situations where alternate text must be provided, where an empty alt attribute must be used and, most controversially, where the alt attribute may be omitted entirely. This is controversial because at first glance, it seems like an attempt to endorse the bad and inaccessible practice of omitting the alt attribute, and thus yet another slap in the face for accessibility. That is an unfortunate misconception that needs to be carefully examined to settle any concerns people have. Although it may seem backwards, the situation is actually much more positive.

There are many observed cases where alternate text is simply unavailable and there’s little that can be done about it. For example, most users of photo sharing sites like Flickr wouldn’t have a clue how or why to provide alternate text, even if Flickr provided the ability. While everyone agrees that it would be wonderful if all users did – indeed, the spec strongly encourages that – most users simply won’t.

The problem being addressed is what should be done in those cases where no alt text has been provided and is virtually impossible to acquire. With the current requirement for including the alt attribute in HTML4, it has been observed that many systems will attempt to fulfil the requirement by generating alternate text from the images metadata.

Flickr, for example, repeats the images title; Photobucket appears to combine the image’s filename, title and the author’s username; and Wikipedia redundantly repeats the image caption. The problem with these approaches is that using such values does not provide any additional or useful information about the image and, in some cases, this is worse than providing no alternate text at all.

The benefit of requiring the alt attribute to be omitted, rather than simply requiring the empty value, is that it makes a clear distinction between an image that has no alternate text (such as an iconic or graphical representation of the surrounding text) and an image that is a critical part of the content, but for which not alt text is available. It has been claimed that Lynx and Opera already use this distinction. For images without alt attributes Lynx shows the filename and Opera displays "Image", but neither show anything for images with empty alt attributes. It is still somewhat questionable whether this distinction is actually useful and whether or not browsers can realistically make such a distinction with real world content, and that is certainly open to debate if you have further evidence to provide.

It has been suggested that taking away the unconditional requirement for the alt attribute will affect the ability of validators to notify authors of their mistakes and take away a useful tool for promoting accessibility. However, using validation errors as an accessibility evangelism tool is not necessarily the only, nor the best, way to address the issue.

While it is indeed very useful for authors to know when they have mistakenly omitted an alt attribute, attempting to unconditionally enforce their use, using a tool as blunt as a validator, is counter productive since it encourages the use of poor quality, automatically generated text. Besides, nothing will prevent conformance checkers and authoring tools from notifying authors, if they so desire.

No practical accessibility benefits are lost by conceding the fact that you cannot force everyone to provide alternate text and making the alt attribute optional for the purpose of document conformance. No-one is claiming that conformance to HTML5 equates to conformance with accessibility requirements. There are lots of things that are considered technically conforming in HTML, yet still inaccessible if used poorly. Making alt technically optional doesn't stand in the way of accessibility requirements, nor greatly impact upon accessibility evangelism. It just acknowledges the reality of the situation in the hope of reducing the prevalence of poor quality, automatically generated alt text.

Posted in Browsers, Elements, Processing Model | 46 Comments »

Automatyczne wykrywanie feedów (Polish)

Wednesday, June 27th, 2007

This is a Polish translation of Feed Autodiscovery, translated by Sebastian Snopek.

Ostatnio dodali?my typy linków do HTML 5. W szczególno?ci zdefiniowali?my mechanizm do automatycznego wykrywania kana?u syndykacyjnego. Automatyczne wykrywanie (Autodiscovery) sta?o si? rozpowrzechnione i szeroko stosowane od momentu swoich narodzin w 2002 roku, stosuj?c element link z powi?zaniem alternatywnym i atrybut type okre?laj?cym rodzaj kana?u.

<link rel="alternate" type="application/atom+xml"
      href="/feed.atom" title="Atom Feed">
<link rel="alternate" type="application/rss+xml"
      href="/feed.rss" title="RSS Feed">

Je?li chodzi o kompatybilno?? wsteczn? musimy zachowa? wsparcie, a szczególnie, zdefiniowa? t? metod?. Jednak?e, istniej? dwa g?ówne problemy z zastosowaniem powi?za? alternatatywnych:

Aby poruszy? t? spraw?, wprowadzili?my nowe powi?zanie kana?u, które wskazuje na to, ?e dokument jest kana?em syndykacyjntm. Pozwala to teraz na linkowanie do wielu kana?ów zawieraj?cych tre?ci, które nie s? koniecznie alternatywnymi wersjami strony. 

<link rel="feed" type="application/atom+xml"
      href="/feed/comments" title="All comments">
<link rel="feed" type="application/atom+xml"
      href="/feed/summaries" title="Article Summaries">

Oznacza to równie?, ?e nie trzeba precyzowa? atrybutu type , aby link by? rozpoznany jako kana? syndykacyjny, a przegl?darki mog? go nadal pokazywa? na li?cie subskrypcji.

<link rel="feed" href="/feed" title="Articles">

Inn? korzy?ci? jest to, ?e je?li kiedy? pojawi si? nowy format kana?u syndykacyjnego to nie trzeba b?dzie czeka? na aktualizacje przegl?darki nowym typem MIME, aby przgl?darka traktowa?a go jako kana?. Na przyk?ad: je?li czytelnicy twojego kana?u maj? wsparcie mikrofoormatu hAtom, mo?na przeprowadzi? subskripcje dokumentu HTML , który zosta? zalinkowany jako kana?. 

<link rel="feed" type="text/html"
      href="/feed.html" title="All comments">

Aby zachowa? kompatybilno?? wsteczn?, definicja alternate mówi, ?e je?li u?ywa si? go w kombinacji z atrybutem type z warto?ci? application/rss+xml lub application/atom+xml to jest on równie? s?owem kluczowym dla kana?u.

S?owo kluczowe kana?u mo?e by? równie? u?ywane w kombinacji z alternate mówi?c, ?e jest to kana? dla danego dokumentu. 

<link rel="feed alternate" type="application/atom+xml"
      href="/feed.atom" title="Atom Feed">

Jednak?e, wa?nym jest aby nie myli? tego z tym jak dzia?aj? arkusze alternatywne. Zachowanie rel="alternatywnego arkusza stylów" jest przypadkiem wyj?tkowym wtedy, gdy u?ycie alternate nie oznacza alternatywnej reprezentacji samego dokumentu. Je?li u?ywa si? go z arkuszem stylów, to warto?? type nie jest równa warto?ci kana?u.

<link rel="alternate stylesheet" type="application/atom+xml"
      href="/feed.atom" title="This is not a feed!">

Mozilla ju? raportowa?a bagi zwi?zane z implementacj? nowego powi?zania feedu a poprawki do rel="alternatywnych arkuszy" s? planowanie w nowym Firefox 3.0.

Posted in Browsers, Elements | Comments Off on Automatyczne wykrywanie feedów (Polish)

« Previous Entries