Moments ago the joint effort of the W3C HTML WG and WHATWG resulted in publication of two documents in the W3C Technical Report space: HTML 5 and HTML 5 differences from HTML 4. I think I can safely say that the WHATWG community is very happy with the W3C publishing HTML 5 as a First Public Working Draft. Many thanks to all involved!
Version 1.0.6 of the Validator.nu HTML Parser has been released. The new version fixes a crasher bug in bytes to characters conversion, works around a crash when the ICU4J 3.8.1 UTF-7 decoder is in the classpath, improves error message wording and brings errors and warnings pertaining to legacy encodings up-to-date per the current HTML 5 draft.
This update is highly recommended for all applications that use the parser by giving it an URI or an InputStream. For applications that give the parser a Reader the update is not necessary.
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.
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:
<style scoped> support is broken due to spec ambiguity.<font> is not supported. The draft says the element will likely be dropped.<menu> elements are not supported due to implementability issues with the current spec text.style='…' is supported on all elements.Validator.nu has had a Web service API for a while. It has not had documentation, though. This has now changed: Validator.nu Web service API docs.