Archive for the ‘Elements’ Category
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 »
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 »
Sunday, January 13th, 2008
The HTML5 content models became more lax in December in response to feedback from various people who found the stricter content model—especially the bimorphic content model of div—unhelpful. The notions “strictly inline content”, “structured inline content”, “block content” and “block or inline content but not both” (aka. bimorphic) are now gone.
The elements formerly known as inline are now phrasing elements in order to make a distinction with the display: inline; CSS property. Content models that previously accepted only block content or either block or inline but not both now accept both. Phrasing content and content formerly known as block content are now prose content when taken together. The practical effect is that the conformance requirements became closer to HTML 4.01 Transitional than Strict; the former requirement for strictness turned out to be hard to justify in face of actual authoring patterns and browser support for those authoring patterns.
The content model changes are now also reflected in Validator.nu. There are some known differences from the spec, though:
Posted in Conformance Checking, Elements, Syntax | Comments Off on Major content model changes in HTML5 (and Validator.nu)
Tuesday, September 18th, 2007
This is a French translation of this article : The longdesc lottery
Parlons maintenant de l'attribut longdesc. En HTML 4, il est défini comme un pointeur vers une longue description, pour une image complexe. Tout le monde peut apprendre à écrire une longue description pertinente. Il n'y a qu'un seul problème : dans les faits, personne ne s'en soucie, et celui qui s'en soucie se trompe.
Maintenant, quantifions le phénomène. En Août 2007, Ian Hickson a analysé un échantillon d'un milliard d'éléments <img> dans l'index de Google. Approximativement 1,3 millions (soit 0,13 %) avaient efectivement un attribut longdesc. Eh bien direz-vous, c'est normal : toutes les images n'ont pas besoin d'un tel attribut. Et vous auriez raison. Mais sans se soucier de savoir s'il est nécessaire ou pas, longdesc n'est pas utilisé si souvent : un seul pour une centaine d'image.
Maintenant, voyons dans combien de cas l'attribut longdesc est utilisé judicieusement. Bien sûr, ce critère est plus subjectif, mais on peut tout de même relever les erreurs les plus évidentes. Des 1,3 millions d'images qui avaient un attribut longdesc, ôtons celles ou l'attribut longdesc ...
- est vide
- n'est pas une url valide
- pointe vers l'image elle-même (c'est à dire la même url que l'attribut src)
- pointe vers la page sur laquelle on se trouve déjà
- pointe vers la racine d'un autre domaine
- est le même que l'attribut href du lien qui entoure l'image (le
longdesc est redondant, puisqu'il est possible de suivre le lien de l'image à la place)
Cela élimine purement et simplement 1,25 million (environ 96%) d'images du lot. Ce n'est pas 96% de toutes les images présentes sur le web - c'est 96% des 0.13% des images qui incluaient un attribut longdesc en première instance. Et lorsqu'on regarde plus attentivement aux 50 000 images restantes, (soit 4% de 1,3 million) les résultats empirent encore : des liens vers d'autres images, des liens brisés, des liens vers une description d'une ligne identiques à l'attribut alt, et des liens vers une page qui vous indique les dimensions de l'image, mais pas son contenu (Wikipedia, c'est bien de toi dont je parle). Si on extrapole à 1,3 million d'image, les 50 000 se réduisent à 10 000. Cela signifie que moins de 1% des images qui fournissent un attribut longdesc sont réellement utiles. Pas plus d'une image sur 100 est correcte (sur les 1% qui se donnent la peine d'essayer).
Parallèlement, les même personnes qui souhaitaient conserver l'attribut longdesc ont récemment réalisé quelques expériences de test par les utilisateurs. C'est-à-dire qu'ils ont testé avec quelle précision une vraie personne aveugle avec un vrai lecteur d'écran pouvait lire une vraie page web. Il s'est avéré que le sujet ne connaissait pas l'existence de l'attribut longdesc avant que le testeur n'en fasse mention. Peut-on vraiment lui en vouloir ? 99.87% des images qu'il avait rencontré n'avaient même pas d'attribut longdesc. Même s'il en avait eu connaissance, et qu'il en avait rencontré une par hasard, il restait tout même 99% de chances que les informations fournies ne présentent aucun intérêt. Il a ainsi plus de chance de gagner à la loterie.
Je ne dis pas qu'il n'y a pas là un réel problème qu'il faudrait résoudre. Il y en a bel et bien un. Les gens peuvent publier des images complexes qui nécessitent des alternatives textuelles tout aussi complexes. Les diagrammes, graphiques et autres photos très détaillées. Mais peu importe. « une image vaut mieux qu'un long discours » et tout ça ... L'attribut longdesc est, théoriquement, une solution à ce problème. Mais cela ne veut pas dire pour autant qu'il s'agisse d'une bonne solution et encore moins de la seule solution. Cela fait 10 ans maintenant que nous vivons avec longdesc et je peux vous l'assurer : cela ne fonctionne pas. Ainsi, pourrions nous éviter la levée de boucliers et commencer à parler d'une meilleure solution ?
Posted in Elements | Comments Off on La loterie du longdesc
Friday, September 14th, 2007
Let's talk about the longdesc attribute. In HTML 4, it's defined as a pointer to a long description for a complex image. Anyone can learn how to write a good long description. There's only one problem: virtually no one bothers, and virtually everyone who does bother gets it wrong.
Let's quantify that. In August 2007, Ian Hickson analyzed a sample of 1 billion <img> elements in Google's index. Approximately 1.3 million (0.13%) had a longdesc attribute. That's OK, you say, not every image needs a longdesc attribute. And you would be right. But regardless of whether it's needed or not, it's not being used that often: just over one in a thousand images.
Now let's look at how often the longdesc attribute is actually used correctly. Of course this is a more subjective question, but we can spot some obvious errors. Out of those 1.3 million images with a longdesc attribute, let's subtract the ones where the longdesc attribute...
- is blank
- is not a valid URL
- points to the image itself (i.e. the same URL as the
src attribute)
- points to the page you're already on
- points to the root level of another domain
- is the same as a parent link's
href attribute (i.e. the longdesc is redundant because you could just follow the image link instead)
That knocks out a whopping 1.25 million (about 96%) right off the bat. That's not 96% of all the images on the web; that's 96% of the 0.13% of images that included a longdesc attribute in the first place. And when you take a closer look at the remaining 50,000 (4% of 1.3 million), the results get even worse: links to other images, links gone 404, links to one-line text descriptions identical to the alt attribute, and links to pages that describe the image size but not its contents (Wikipedia, I'm looking at you). Extrapolating back to 1.3 million, that 50,000 shrinks to about 10,000. That means that less than 1% of images that provide a longdesc attribute are actually useful. No more than one in a hundred get it right, of one in a thousand that even try.
Meanwhile, the very people advocating for keeping the longdesc attribute have recently conducted some user testing. That is, testing how well an actual blind person with an actual screen reader can read actual web pages. It turned out that the test subject didn't know that longdesc even existed before the tester told him about it. Can you blame him? 99.87% of the images he'd ever encountered had no longdesc attribute at all. Even if he had known about it, and he had actually stumbled across one, he would still be up against 99 to 1 odds that following it would be worth his time. He has a better chance of winning the lottery.
I'm not saying there isn't a real problem to be solved here. There is. People can publish complex images that require complex text alternatives. Charts, graphs, detailed photographs. Whatever. "A picture is worth 1000 words," and all that. The longdesc attribute is, theoretically, a solution to this problem. But that doesn't mean it's a good solution, and it's certainly not the only solution. We've been living with longdesc for 10 years now, and let me tell you, it's not working out. So can we please get past the grandstanding and start talking about a better solution?
Posted in Elements | 40 Comments »