The WHATWG Blog

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

Archive for the ‘Browsers’ Category

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 »

Google Tech Talk: HTML5 demos

Friday, September 26th, 2008

I gave a talk at Google on Monday demonstrating the various features of HTML5 that are implemented in browsers today. The video is now on YouTube, so now you too can watch and laugh at my lame presentation skills!

The segments of this talk are as follows. Some of the demos are available online for you to play with and are linked to from the following list:

  1. Introduction
  2. <video> (00:35)
  3. postMessage() (05:40)
  4. localStorage (15:20)
  5. sessionStorage (21:00)
  6. Drag and Drop API (29:05)
  7. onhashchange (37:30)
  8. Form Controls (40:50)
  9. <canvas> (56:55)
  10. Validation (1:07:20)
  11. Questions and Answers (1:09:35)

If you're very interested in watching my typos, the high quality version of the video on the YouTube site is clear enough to see the text being typed. More details about the demos can be found on the corresponding demo page.

Posted in Browser API, Browsers, Conformance Checking, DOM, Elements, Events, Forms, Multimedia, Syntax, WHATWG | 7 Comments »

Dlaczego atrybut alt można pominąć

Sunday, January 13th, 2008

This is a Polish translation of this article: Why the Alt Attribute May Be Omitted.

Prace prowadzone ostatnio nad specyfikacją atrybutu alt mają na celu gruntowną poprawę jego definicji, m.in. dokładne wyjaśnienie sposobów tworzenia poprawnego tekstu zastępczego oraz jasne sprecyzowanie wymagań autorskie.

Wymagania te określają sytuacje, w których konieczne jest użycie tekstu zastępczego, zastosowanie pustego atrybutu alt oraz, co najbardziej zaskakujące, kiedy atrybut alt można całkowicie pominąć. Jest to kwestia kontrowersyjna, ponieważ na pierwszy rzut oka wygląda to na próbę zachęcania do złego i sprzecznego z zasadami dostępności zwyczaju pomijania atrybutu alt, co wydaje się być kolejnym policzkiem dla dostępności w sieci. Jest to niewłaściwe rozumowanie, które należy przeanalizować ze szczególną uwagą tak, aby rozwiać wszelkie wątpliwości, jakie mogą powstać. Choć taka sytuacja wydawać się może uwstecznieniem jest to w rzeczywistości bardzo pozytywny zabieg.

W wielu sytuacjach tekst zastępczy jest po prostu niedostępny i nic nie można na to poradzić. Przykładowo, większość użytków serwisów wymiany zdjęć takich jak Flickr nie miałoby pojęcia jak, ani dlaczego, należy dołączyć tekst zastępczy, nawet gdyby Flickr dawał im taką możliwość. Chociaż wszyscy są zgodni co do tego, że wspaniale byłoby gdyby wszyscy użytkownicy stosowali tekst zastępczy (specyfikacja wyraźnie to zaleca), to większość z nich po prostu tego nie zrobi.

Należy zastanowić się nad problemem co zrobić w sytuacji kiedy tekst alt jest niedostępny i nie ma tak naprawdę sposobu żeby go wstawić. Przy obecnych wymaganiach stosowania atrybutu alt w HTML4 zaobserwować można próby spełnienia tego wymagania przez systemy, które podejmują próbę utworzenia tekstu zastępczego w oparciu o metadane obrazu.

Flickr na przykład powtarza tytuł obrazu; Photobucket najwyraźniej łączy ze sobą nazwę pliku, jego tytuł i nazwę autora; z kolei Wikpedia niepotrzebnie powtarza podpis pod obrazem. Problemem wynikającym z takiego podejścia jest to, że stosowanie takich wartości nie dostarcza ani dodatkowych ani użytecznych informacji dotyczących obrazu, co w niektórych przypadkach jest gorsze niż całkowity brak tekstu zastępczego.

Korzyścią płynącą z wymogu opuszczenia atrybutu alt zamiast pozostawienia po prostu pustej wartości jest jasne rozróżnienie pomiędzy obrazem, który nie posiada tekstu zastępczego (jak np. reprezentacja otaczającego tekstu w postaci grafiki lub ikony) a obrazem będącym kluczowym elementem zawartości, dla którego tekst zastępczy nie jest dostępny. Podobno Lynx i Opera stosują już takie rozróżnienie. Przy obrazach bez atrybutu alt Lynx wyświetla nazwę pliku a Opera pokazuje napis "Obraz", jednak żadne z nich nie wyświetla niczego przy obrazach z pustym atrybutem alt. Wciąż niewiadomo do końca czy takie rozróżnienie jest naprawdę użyteczne oraz czy przeglądarki mogą realistycznie je stosować. Kwestia ta jest otwarta do dyskusji jeżeli tylko ktoś dysponuje argumentami.

Sugeruje się też, że zrezygnowanie z bezwarunkowej konieczności stosowania atrybutu alt wpłynie na zdolność walidatorów do powiadamiania autorów o błędach i odbierze nam narzędzie pomocne w promowaniu dostępności. Jednak wykorzystywanie komunikatów o błędach walidacji jako narzędzia oświatowego nie jest ani jedynym ani najlepszym rozwiązaniem problemu.

O ile autorzy lubią wiedzieć kiedy przypadkowo pominęli atrybut alt, to bezwarunkowe wymuszanie użycia tego atrybutu przy wykorzystaniu tak prymitywnego narzędzia jakim jest walidator daje dokładnie przeciwne wynik, ponieważ zachęca do korzystania z generowanych automatycznie tekstów kiepskiej jakości. Zresztą nic nie powstrzyma narzędzi autorskich i sprawdzających zgodność ze standardami przed powiadomieniem autorów jeśli będą sobie tego życzyć.

Przyznając, że nie da się zmusić każdego do stosowania tekstu zastępczego i czyniąc atrybut alt opcjonalnym w standardach dokumentu nie traci się żadnych praktycznych korzyści płynących z dostępności. Nikt nie twierdzi, że zgodność z HTML5 jest tym samym co zgodność ze wymogami dostępności. Wiele rzeczy uważa się za spełniające techniczne wymogi HTML, a jednak ich niewłaściwe stosowanie czyni je niedostępnymi. Uczynienie atrybutu alt opcjonalnym nie jest sprzeczne z wymogami dostępności ani nie ma wielkiego wpływu na ich propagowanie. Opisuję tu tylko rzeczywistość mając przy tym nadzieję na zmniejszenie powszechności automatycznie generowanego tekstu alt kiepskiej jakości.

Posted in Browsers, Elements, Processing Model | 1 Comment »

Pourquoi le texte alternatif peut être omis (French)

Thursday, August 23rd, 2007

This article is a French translation of the article Why the Alt Attribute May Be Omitted.

La spécification de l'attribut alt a été retravaillée récemment, afin d'améliorer sa définition, en incluant une explication en profondeur de comment fournir le texte alternatif le plus approprié avec de réelles exigences éditoriales.

La spécification décrit des situations où le texte alternatif doit être précisé, où un attribut alt vide doit être utilisé et où, de façon plus sujette à controverse, l'attribut alt peut parfaitement être omis. Cette omission peut sembler être sujette à controverse, parce que au premier regard, cela ressemble à une tentative pour justifier la mauvaise pratique, contraire aux principes de l'accessibilité, qui consiste à oublier l'attribut alt ... Et à jeter un pavé dans la mare. C'est une confusion malheureuse qui nécessite qu'on s'y arrête un instant pour balayer les doutes qu'elle pourrait susciter chez bien des gens. Bien que cela puisse paraître rétrograde, la situation est ainsi bien meilleure.

Il y a bien des cas où le texte alternatif est tout simplement indisponible et où il y a peu de choses que l'on puisse faire pour remédier à la situation. Par exemple, la plupart des utilisateurs de sites de partage de photos comme Flickr n'auraient certainement aucune idée de quoi écrire comme texte alternatif, même si Flickr leur en offrait la possibilité. Et même si, bien sûr, tout le monde s'accorde à dire que si ce serait formidable si, comme la spécification l'encourage, tous les utilisateurs le faisaient, la plupart ne le feront tout simplement pas.

Le problème que nous venons de soulever est le suivant : que devons-nous faire dans le cas où aucun texte alternatif n'a été spécifié et où il reste virtuellement impossible à définir ? De nombreux systèmes actuels tentent de satisfaire la recommandation actuelle en matière de texte alternatif en générant ce texte à partir des métadonnées des images.

Flickr, par exemple, répète le titre de l'image ; Photobucket semble combiner le nom du fichier image, le titre et le nom de l'utilisateur - et Wikipédia reproduit de façon redondante la légende de l'image. Le problème de ces approches est qu'aucune d'entre elles ne fournit une information additionnelle utile à propos de l'image et, dans certains cas, cela est pire que de ne fournir aucun texte alternatif.

Le bénéfice que l'on peut retirer de permettre l'omission du texte alternatif, plutôt que de nécessiter une valeur vide est que cela permet de créer une distinction claire entre une image qui n'a pas de texte alternatif (comme une icône où une représentation graphique du texte environnant) et une image qui fait partie intégrante du contenu, mais pour laquelle aucun texte alternatif n'est disponible. Il a été dit que Lynx et Opera faisaient déjà cette distinction. Pour des images qui n'ont pas d'attribut alt, Lynx montre le nom du fichier et Opera le texte "Image", mais aucun des deux ne montre quoi que ce soit pour les images dont l'attribut est laissé vide. Il reste à déterminer si cette disctinction est effectivement utile dans l'affichage du contenu du "monde réel" et il y a réellement un débat à mener si vous avez des preuves à avancer.

On a suggéré que retirer la présence inconditionnelle de l'attribut alt affecterait la capacité des validateurs à montrer leurs erreurs aux utilisateurs et retirerait un bon outil de promotion de l'accessibilité. Cependant, utiliser les erreurs de validation comme un outil d'évangélisation de l'accessibilité n'est certainement une bonne façon d'envisager cette problématique.

Tandis qu'il est en effet très utile pour les auteurs de savoir quand ils ont oublié par erreur un attribut alt en cherchant à les obliger à l'utiliser de façon inconditionnelle, utiliser un outil aussi éculé qu'un validateur est contre-productif, car il encourage l'utilisation de textes générés automatiquement de pauvre qualité. Paralèllement, rien n'empêchera les outils de validation et d'édition web de signaler ces erreurs aux auteurs si tel est leur bon plaisir.

Aucun des bénéfices de l'accessibilité n'est perdu en acceptant le fait qu'il est impossible de forcer tout le monde à fournir un texte alternatif et en rendant l'attribut alt optionnel pour pouvoir s'assurer de la conformité d'un document. Personne ne proclame que la conformité au HTML 5 est équivalente à la conformité avec les recommandations d'accessibilité. Il y a de nombreuses choses qui sont considérés conformes techniquement en HTML, mais qui demeurent "inaccessibles" si elles sont mal utilisées. Rendre l'attribut alt techniquement optionnel ne se dresse pas contre les recommandations d'accessibilité, pas plus qu'il n'a un quelconque impact sur l'évangélisation de l'accessibilité. Il s'agit simplement d'accepter la réalité de la situation à laquelle nous faisons face, dans l'espoir de réduire la prolifération des textes alternatifs de mauvaise qualité générés automatiquement.

Posted in Browsers, Elements, Processing Model, WHATWG | 2 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 »