The WHATWG Blog

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

Archive for the ‘Browsers’ Category

Styling HTML5 markup in IE without script

Saturday, January 17th, 2009

The previous post discussed how to enable styling of the new HTML5 elements in IE by using a simple script. However, if the user has scripting disabled, the layout would probably fall apart badly.

So that means if you care about IE users with scripting disabled, you can't use the new elements, right?

Not necessarily.

There are some tricks to work around the broken DOM and limited styling in IE:

  1. Know what the DOM looks like and target other elements than the new elements for styling.
  2. Use the universal selector (*) to target the right element.
  3. Use noscript.

What does this mean?

Target other elements for styling

Consider you have the following markup:

<body>
 <article>
  ...
 </article>
 <nav>
  <ul>
   ...
  </ul>
 </nav>
</body>

Instead of doing this:

* { margin:0; padding:0 }
body { background:silver }
article { border:solid; background:white; margin-left:10em }
nav { position:absolute; top:0; left:0; width:10em }

...do this:

* { margin:0; padding:0 }
html { background:silver }
body { border:solid; background:white; margin-left:10em }
ul { position:absolute; top:0; left:0; width:10em }

Now of course you're going to use other ul elements than the navigation, so how do we get more specific on which element to target? The obvious solution is to set a class or id on the ul element, but there's another solution which might be more convenient in some cases, which brings me to...

Using the universal selector

Depending on the situation, and whether you care about IE6 or not, you can use the universal selector to target the element you want.

Consider you have the following markup:

<body>
 <article>
  <header>
   <h1>...</h1>
   <p>...</p>
  </header>
  ...

...and you want to style the p that is in header, you would do this in the normal case:

article header p { font-weight:bold }

But in IE, the article, header, h1 and p elements are all siblings, so the selector wouldn't match.

So then one would expect this to match, but it doesn't (IE doesn't allow selecting unknown elements using type selectors):

article + header + h1 + p { font-weight:bold }

However, this matches:

body > * + * + h1 + p { font-weight:bold }

Using noscript

The above techniques shouldn't mess up other browsers (or IE when scripting is enabled), however if you prefer (or if something would screw up) you can use a separate style sheet for IE when scripting is disabled by just using the following markup:

<head>
 <!--[if IE]>
  <noscript><link rel="stylesheet" href="ie-noscript.css"></noscript>
 <![endif]-->
 ...

Conclusion

The above techniques might not be very scalable or might well impact maintanence, but the point of this article is to show that it is possible to use the new elements while still supporting IE with scripting disabled.

Posted in Browsers, DOM, Elements | 11 Comments »

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 »