I just sent this e-mail to the WHATWG discussion mailing list where HTML5 is being discussed:

From: Manuel Amador
To: whatwg@whatwg
Subject: Removal off Ogg technology: preposterous

Allow me to be the voice of the small Web developer -- which I consider to be the foundation of the World Wide Web.

In reference to: http://html5.org/tools/web-apps-tracker?from=1142&to=1143

The recent removal of the mention of Ogg in HTML5 and the subsequent replacement of its paragraph with the weasel-worded paragraph that would make Minitrue bust their collective shirt buttons in pride:

<p class="big-issue">It would be helpful for interoperability if all+ browsers could support the same codecs. However, there are no known+ codecs that satisfy all the current players: we need a codec that is+ known to not require per-unit or per-distributor licensing, that is+ compatible with the open source development model, that is of+ sufficient quality as to be usable, and that is not an additional+ submarine patent risk for large companies. This is an ongoing issue+ and this section will be updated once more information is+ available.</p>

is a preposterous and gross mischaracterization of fact (dare I say lie). At the very least, it's FUD.

It pains me to state what is and has always been public knowledge, and is being intentionally ignored just to "get the spec published":

• The Xiph developers were extremely zealous and almost fiduciarily diligent in researching all possible patent threats to Vorbis technology, and for more than a year they found none -- they even did the research before beginning to code, explicitly to avoid submarine patents. I know, because I was subscribed to their mailing list and read status updates of this research, practically at the start of the project. I also know that big-name software houses and media players manufacture products with Vorbis technology, and none of them have been sued. It's been what, seven years now?
• The Theora codec has had its patents practically relinquished by On3 with a perpetual royalty-free license.
• Ogg and its audio/video codec technologies are the ONLY free software media technologies with implementations widely available on all consumer computing platforms -- from WM codecs to Linux DLLs, passing through the entire range of hardware (floating-point and fixed-point) and OSes.
• Without guaranteed Ogg support (whose integration in user agents I think I already established to be sort of a weekend-level junior programmer project at NO COST, due to the ready availability of the technology in all platforms), authors will be forced to use patent-encumbered technology. Remember MP3? Well, with HTML5 it's 1997 all over again.

Ian, revert. This compromise on basic values is unacceptable, whatever the practical reasons you have deemed to compromise for. If you don't revert, you will be giving us independent authors the shaft. And we will remember it forever.

Here’s the position paper of the Xiph foundation, the makers of Ogg Vorbis and stewards of all Ogg technology. Let me quote a paragraph from them:

So, how do you make Theora and Vorbis popular? Why, by the very same process that made MP3 so ubiquitous: by using it and by sharing it. Only by advocating the formats will you see interest from the corporations. There is no other way around it. Let me write that one more time: there is no other way around it. Backup your films in Theora. Backup your music in Vorbis. Share podcasts and videocats in these formats. And do not wait for tomorrow; do it now. And by now, I mean yesterday.

There’s a lot of companies out there who do not wish to see Theora and Vorbis succeed, and they don’t even have to make much of an effort to affect them. The masses out there with their expensive iPod toys don’t care about Vorbis or Theora. Most of them don’t even know what they are.

Note that HTML5 in no way required Ogg (as denoted by the word “should” instead of “must” in the earlier draft). Adding this to the fact that there are widely available patent-free implementations of Ogg technology, there is really no excuse for Apple and Nokia to say that they couldn’t in good faith implement HTML5 as previously formulated. Throw your own theory here: DRM, proprietary control, et cetera.

The WHATWG had an opportunity here to eliminate the plugin morass (so 90’s) in favor of a baseline format that each browser could implement. Just as HTML specifiedhinted at baseline formats for images (GIF and PNG), this should have been an opportunity to suggest or even specify baseline free audio and video. And there’s still a chance.

Please, please help this issue get more public scrutiny. But if you’re going to exert pressure on the WHATWG, be reasonable — read the archives first!. And don’t let special interests kill computing for all — now it’s time to take a stand!

Update: the discussion at the WHATWG list is centering around the fact that Microsoft, Nokia and Apple disagree on having Ogg technology mentioned on the spec, due (I loosely quote them) to the potential threat that submarine patents may pose. My personal opinion is that you don’t get any freer than Ogg, and there is no such patent threat because major hardware and software players (gaming companies and America Online / Winamp, for example) have already shipped at least Ogg Vorbis technology in the past. Until this conundrum is resolved, they’re taking Ogg technology off the table because they don’t want to implement it in their browsers.

Since moving forward with HTML5 is a consensus decision, the thing’s just not moving forward until a viable alternative to Ogg is found (or, maybe they can be convinced?). Both Opera and Mozilla have preliminary implementations of in-browser VIDEO tags that play Ogg media. Read the mailing list archives to see the arguments espoused in favor of / against the idea, and read the comments below.

It really bothered me that Nokia referred earlier this week to Ogg as a proprietary technology, blatantly stating something so untrue. It also bothers me that Apple has expressed concern against Ogg. Both companies make great products — my entire life I’ve only owned Nokia phones, I was thinking about the N800, and it’s in no small part thanks to Apple that I have hassle-free Zeroconf networking at home — but this clearly puts the small content producer at a disadvantage.

I just discovered the position paper that Mozilla, through Chris Double (the author of the VIDEO embedding tag in Mozilla software), will be presenting in a few hours on the W3C video workshop. Interesting read.

• It’s Safari.
• There’s no exposed filesystem anywhere.
• Heed sanctioned Web development best practices.
• In contrast to a PC, you may not have the full attention of your users.
• Build apps to provide quick, easy access to things user need.
• iPhone is different. People expect a different user experience. People will benchmark your Web site against the included apps.
• Make fast Web pages. People may be browsing using EDGE networks.
• Cookies are available.
• No Flash. No Java.
• No scrollbars. Finger gestures are to manipulate how the content is viewed (pan, zoom in/out).
• The tap is equivalent to a mouse click.
• Present your text in narrow columns to let the user avoid zooming in/out.
• People fatfinger. Design UI elements accordingly.
• There are pages compatible with iPhone, pages optimized for iPhone and iPhone Web applications.
• Shoehorn your content into single-purpose views. You can redesign centering your site around that, or you can build iPhone Web applications (mimicking the iPhone UI) for each specific type of view.
• iPhone applications should integrate with iPhone services.
• Make it obvious how to use your content.
• Minimize user input.
• Remove decorative crap.
• User-centric terminology.
• Provide dynamic feedback.
• Be consistent in your UI.
• Aim for instant display in the responsiveness department.
• Make your page/app resilient to network service interruptions.
• Avoid absolute positioning.

Here’s the set of guidelines. And here’s a set of metrics, layout guidelines and tips which don’t work well as a summary.

My personal tip: you can, and should, use CSS to make your page work differently in Safari. Do so; avoid falling in the trap of different markup for the iPhone.

From the World Wide Web Consortium Q&A blog, article titled Craft of HTML:

HTML is a practical art. In a professional context, it requires precise and extensive skills. As with many popular crafts, the vast majority of people do it on their own, but only a few do it for a living. The quality of products varies a lot.

Bruno Pedro has recently published Top blogs fail W3C Markup Validation. He has taken the top 20 list of popular weblogs and puts them through W3C validator. None passed markup validation. Then the author is encouraging people to take care of validation. The comments following the article express either frustration, anger or support. This article is a good illustration of the misunderstanding about HTML validation.

[...]

When you are a developer of a content management system, of an authoring tool, of a small widget, be sure to create all the fonction to sanitize the content in production and input. Maintaining the quality of your content is a better goal than a one time validation.

Reference of tools

• Wordpress XHTML Validator by Manuel Amador Briz
• MTValidate Plugin by Jacques Distler
• LogValidator by Olivier Théreaux

Incidentally, I validated my own pages and I found two validation issues related to the Creative Commons license (something about the XML namespace used by the code) so I just commented those stanzas out. Dear Lazyweb, how can I specify several valid namespaces for an XHTML document?

To the W3C staff: thanks :-). Much appreciated.

It is not. ACAP brings nothing to the table that isn’t already there and accessible for “content providers” (read: Web page owners). In theory, ACAP would solve two issues:

1. AJAX-powered Web sites
2. Caching on Web search engines as a method to “steal content”

The truth about AJAX and ACAP

Have an AJAX-powered Web site? Then you probably know search engines aren’t indexing your site properly.

The crux of the issue is rather simple: hyperlinks that point to javascript: actions don’t get followed by search engines. ACAP is advertised (on the aforementioned article) as a solution to this problem.

It’s not the right one. The right solution is for Web site builders to build sites that take advantage of AJAX, but don’t rely on it. This does not only benefit search engine users, but mobile users as well, since their devices usually can’t handle heavy AJAX. Hey, I own a Palm T|X and I know what I’m talking about.

Forms should POST and GET to valid locations. Form results should generate entire pages, unless a special argument is passed to request JSON or XML results through an XMLHttpRequest object. Hyperlinks should point to real pages, and be trapped.

Modern Web building toolkits like Django and Ruby on Rails provide the facilities to make this kind of development seamless. In the face of a correctly built Web site, ACAP brings nothing new.

Content caching: the “root of all evil”?

ACAP is also advertised as a way to let search engines and Web sites broker over which contents they should cache. As a marketing strategy, ACAP thus appeals to Web site owners who fear reduced visits because of search engine caches, and owners who suddenly yank lots of content from the Web to place it behind a paywall.

Hello? If you fear search engine caches, you need to look no further than to the humble META tag called NOCACHE!

And if you wanted only search engines to index your content, you’ve always been able to do this! Your publishing engine should already include measures to detect user agents, and you can combine this with “known good” search engine crawler IP lists.

Again, indexing of well-authored pages has never been a problem. Evven for greedy Web site operators.

The wrapup

All in all, ACAP is bad. It brings new complexity to the already complex Web. Furthermore, it is an opportunity for fraudulent Web sites to manifest fraudulent content that the users won’t find when they go to these sites. It should be stabbed in the back and left for dead.

Esta foto preliminar ilustra el progreso hecho en tres días de esfuerzo. Por supuesto, este ejemplo no es funcional porque aún no he programado. Sin embargo, lo que ven es un preliminar verdadero — no es un dibujo sino una página HTML en el navegador. Por cierto, hice los dibujos originales usando Inkscape, un fabuloso programa de dibujo vectorial para Linux.

Mencioné que todos los pasos de este proceso se ejecutan únicamente con software libre?

The front page

Así se ve la página frontal en este momento. Haz clic en la imagen para verla en mayor tamaño.

Lo que se ve

Noten que:

• el nuevo logo tiene un look Web 2.0
• se usan pocas tipografías: Verdana y Gill Sans. Gill Sans le da un extra “Web 2.0″; como pocas personas tienen esa tipografía instalada, las tipografías se cargan automáticamente vía estilos
• el artículo más reciente está prominentemente dispuesto y es fácil de distinguir
• la página muestra automáticamente contenidos populares de la sección correspondiente al artículo más reciente
• el tema presenta enlaces a los artículos recientes y relacionados en listas fáciles de identificar
• la barra lateral (a la que le falta un cuadro de publicidad) es limpia y fácil de leer
• el contenido más importante está en el primer pantallazo del navegador
• la navegación (búsqueda, migas de pan y páginas) están en la cabecera y son accesibles

Del segundo pantallazo hacia abajo aparecen más artículos bajo el título “Más noticias y artículos”. Este área contiene una lista de artículos recientes y populares de cada sección, y las secciones listadas están ordenadas en el tradicional orden inverso cronológico.

Lo que no se ve — o la importancia de los estándares Web

• todos los estilos de enlaces funcionan correctamente — los enlaces apuntados o enfocados se iluminan, y los enlaces visitados se distinguen visualmente de los no visitados
• el texto se puede redimensionar con los controles del navegador — la única parte que sufre problemas es la barra superior de navegación: se oculta parcialmente con tipografías muy grandes
• el sitio es completamente funcional con las hojas de estilo apagadas
• la diagramación es correcta y fluida en cualquier resolución — hasta 640×480 — y ya estoy trabajando en estilos para PDAs y computadoras de bolsillo
• los estilos de impresión están implementados, y estos automáticamente ocultan partes innecesarias para ofrecer impresiones rápidas y baratas
• el contenido es el rey, y recibe una posición ventajosa en la fuente HTML
• no se usa JavaScript — un par de extras basados en JS aparecerán más tarde, pero no serán requeridos
• sin Flash, y a pesar de eso, hip y elegante
• el sitio se ve correctamente en Firefox y Konqueror (y eso a pesar de que Konqueror agranda las tipografías un poco); esto significa que también se verá bien on Safari en computadores Apple -aún no he probado el sitio en IE7; sin embargo, sospecho que se verá correctamente, porque he evitado usos problemáticos de CSS en IE7; IE6 simplemente no recibirá ninguna consideración

Estas cosas no son caprichos míos. Tampoco son coincidencias afortunadas. Supe, desde el principio, que el nuevo sitio tendría que acogerse a estas características. Mi expectativa es que tendré visitantes discapacitados y usuarios móviles. Y, finalmente, la forma en la que el contenido se presenta responde fielmente a los requerimientos que establecí en el artículo anterior sobre la revista.

Sin exagerar, puedo decir que esto significa una cosa: es posible construir sitios Web efectivos con tecnologías sencillas y observando las normas públicas de la Web. Por eso pregunto: ¿por qué la gente insiste en complicarse la vida y falta a los estándares? Sospecho seriamente que es porque la mayor parte de “diseñadores Web” es gente poco seria y vaga que prefiere seguir construyendo sitios Web con código “espagueti” sin “desperdiciar” tiempo en conocer las herramientas de su propio oficio.

Conclusiones

Sé que no soy un genio del diseño, pero creo que sí “la muevo”. ¿Qué piensas tú?

These mockups illustrate the progress made in three days’ work. None of them are functional because no code has been written. However, I’ve already translated the graphical mockups into HTML — you can clearly guess that from the top strip. I made the original mockups using Inkscape, a remarkable SVG vector drawing program for Linux.

Did I mention every step on this series is executed using only Free Software?

The front page

Here’s how the front page looks like, right now. Click the thumbnail to see it in larger size.

Layout explanation

Notice that:

• the logo is now Web 2.0ish
• the font selection is quite spartan: Verdana and Gill Sans; Gill Sans lends the site an extra “Web 2.oomph”; since few people have Gill Sans, on browsers that support TrueType autoloading (none right now) it’s loaded via stylesheets
• the most recent article is featured prominently and easily distinguishable
• popular content from the recent article’s section is automatically featured as well
• leads to related articles are presented in easy-to-scan lists
• the sidebar (which lacks one ad) tries to be clear and easy to scan
• important content is completely above the fold (the visible area before scrolling down)
• the navigation (search, breadcrumb trail and pages) are on the top page, easily accessible

Mostly below the fold is a “More news and articles” tile. This tile contains a list of recent and popular articles from each section, ordered in reverse chronological fashion according to which section saw the last post.

Things you can’t tell from the mockup — or, the importance of Web standards

• all link styles are working correctly — tabbing or hovering into a link will light it up, and visited links are visually distinguished from new links
• the text is (almost) fully scalable using your browser’ controls — however, the top navigation suffers from hidden content at very large font sizes
• the site is fully functional with style sheets off
• the site lays out properly and fluidly at any resolution — up to 640×480 — and PDA and handheld computers are in the works
• print styles are already implemented, and they strip unnecessary output for fast and cheap printing
• content is king and receives an advantageous position in the HTML source
• no JavaScript is necessary or even used on the site; I will add some, though, because it’ll help ease things for capable readers
• no Flash, yet still elegant and hip!
• the site lays out properly on both Firefox and Konqueror (though Konq enlarges the fonts a bit); this means that the site will lay out properly on Mac Safari as well
• I haven’t tested the mockup on IE7; however, I’m nearly certain it’ll work well, because I’ve avoided IE7 gotchas; IE6 is out for me anyway

These points aren’t just capricious whims of mine. They aren’t a serendipitous coincidence either. I knew, from the start, that the site would need these features. I expect disabled visitors and people with mobile computers to access the site. And, finally, the site has been laid out that way to slavishly serve the goals mentioned on yesterday’s issue.

At the very least, this means people can build effective Web sites without resorting to complicated technologies or straying from Web standards. So why don’t they? I seriously think it’s because most Web designers out there are lazy bums who’d rather keep churning out spaghetti code without actually learning their toolset.

The wrapup

I’m no design wizard, but I think I get by. What do you think?

At least if you’re into Web development and design.

• Day 1
• Day 2
• Day 3
• Day 4
• Day 5
• Day 6

Nonces alone sound very stupid to me. Instead of having implemented nonces alone, what the WP team should have been doing all along is obvious: every action that is not idempotent should be done through POST. Technically, it’s quite simple. Programmatically, it’s harder to do than GETs. But surely coding GETs + nonces must be much harder than simply coding POSTs.

No one is discussing how useful nonces are. They are useful. But in the context of the greater picture, they’re used to avoid WP admins from being tricked — which is exactly why POSTs should be used as well. Sure, POSTs alone don’t buy us a whole lotta security. But they surely do buy us some.

(Please don’t tell me I haven’t read the whole thread. The fact that nonces were introduced does not contradict one iota the fact that POSTs should be used for destructive operations, and that’s it.)

Update: to visitors from the #wordpress channel: I updated the article, correcting statements of fact. I’m very glad to see that you’re receptive to the POST idea. It’s no surprise that it has been floated before as an issue.

An URI is not a file

Deal with it. An URI should represent a resource, and all its alternative representations. Use content negotiation to serve multiple languages or formats of the same resource.

To help you figure this URI mess out, try thinking about URIs as ISBNs or bar codes. You’d be surprised to know that URIs are defined to be very similar to these.

In the same light, try at all costs to create and maintain URIs so they don’t change. Use URL rewriting if you absolutely need to change URIs for your pages.

Microcontent is king

Good page titles, headings, anchor texts and other microcontent in your Web application pages are a big usability plus for your readers.

Don’t use “link here” or “click here” for links. Don’t use “Article” as a page title. Use headings to give structure to your HTML pages.

REST: what changes should be POSTed, what doesn’t should be GET

You can classify operations in your Web application in two categories:

1. Those that perform changes in the information kept in (or managed by) your application
2. Those that don’t perform changes (such as presentation pages, views or reports)

Use POST forms and avoid parameters (related to the operation) in URIs for the first category of operations. Use GET forms and URIs for the second. Here’s how and why.

Semantic pages matter

Don’t use presentational markup. Avoid use of presentational tags like FONT or CENTER. Most likely, what you’re trying to get to stand out is actually a good candidate to become a CSS class or ID. The more you place in your stylesheet, the less your pages will weigh. Plus, maintaining a slick, consistent look, and redesigning your site in the future will be way easier.

In the same light, avoid using TABLEs for lists, horizontal tabs and non-tabular information. Resort to properly styled UL or OL elements.

Learn the existing HTML tags, and what they’re supposed to be used for. It would be dumb to create a CSS class named “code” just to find out that there is a perfectly good CODE tag that can be used more directly, and styled through CSS.

Finally, don’t just bold text that’s supposed to be a title. Use one of the heading elements in HTML (there are six depth levels for you to use, so there won’t be any shortage!).

Accessibility is good for your readers (and, surprisingly, you as well)

Whether it’s because you want to achieve high rankings in search engines, or because you truly, truly care about people with disabilities, designing an application with accessibility in mind should be extremely important to you.

1. Use AJAX sparingly and always provide fallback mechanisms for those who don’t use JavaScript. AJAX should not replace standard interaction methods, and it should also not be used to break the “one page, one URI” rule (this is exactly why frames are being ruled out).
2. Lay out pages in an accessible fashion. Usually, content should go first in the HTML.
3. Add access keys, form labels and other accessibility measures. The first step should be using semantic markup.
4. Resort to Flash only when content you’re presenting is eminently audiovisual.

Have a WordPress blog? Having trouble with Section 508 and validation? Get the WordPress XHTML validator, and forget about validation issues!

Forgetting to terminate entities

The & character is reserved in HTML and XHTML. You can’t just place it on your code and expect it to be valid.

The & character is used to post entities in content. Entities represent special characters, such as &iacute; (that would be í). When writing an entity by hand, a common mistake is to forget the trailing semicolon. That unterminated entity is shown as a series of errors in the W3C Validator.

And how do you put a literal ampersand? Use &.

Ampersands in URLs

This is actually a variant of the former error. Basically, even if it’s text on an URL (for example, in an href attribute on an a tag), you can’t just put an ampersand there. You need to use the proper form (see above)

Neglecting to properly close a tag

In XHTML, some tags, like <br>, need to be closed inline. The tag should be written like this: <br/>.

Overlapping and context-sensitive tags

Some tags cannot go within others. For example, it is an error to include a <p> tag within another <p> tag. It is also illegal to start an <i> tag, then place any block-level tag (such as <p>) within it. Another common mistake is closing a tag before its children tags have been closed.

Watch out for errors, and validate your pages often! So long, folks!

Well, now, there’s a new reason… or, actually, it’s a pretty old one. Section 508 of the US Rehabilitation Act makes a few requirements for public Web sites and blogs, to improve accessibility for their users.

The first step, as with every Web deployment and maintenance effort, is ensuring that your site validates. Validation is paramount — otherwise, down the road, there are no guarantees that the accessibility practices and technologies on a site will actually work.

The problem with most blogs (especially WordPress) is that their contents are dynamic: content is generated, out of a database. So, it’s impossible to validate an entire dynamic site, in a practical fashion.

But rest assured, there’s a way out of this mess: for WordPress-based blogs, I’ve written a plugin named WordPress XHTML validator which lifts an enormous weight from you, the author. Using the XHTML validator, this is how you get from invalid HTML to valid HTML:

1. Validate your content: on your WordPress administrative interface, go to the Manage tab. Then click the XHTML validator tab. A fully automated procedure will validate posts, pages and comments, then present you with a list of invalid entries, which you can quickly edit by using the associated Edit links.
2. Validate your template: after you’ve validated all content, you should submit your front page, and a few archive pages, to the W3C validator. Then, manually fix the spots where your template has errors. It’s certainly possible that the WordPress XHTML validator missed some spots — at this stage, you’ll catch these errors.
3. Keep the plugin enabled: every time a new post or page is saved, a red box will warn you if it contains invalid XHTML. Good practice: save your post first, instead of immediately publishing it. That’ll give you a chance to catch any errors early.

So, that’s it for today. Get your blog valid and start working towards Section 508 compliance. Do it today: every day you gain may mean a couple thousand readers more satisfied. Keep this in mind: people don’t remember when everything went well, but they’ll surely remember when your site breaks.

Here’s my take on the issue: it’s very important.

Why is HTML/XHTML validation important?

If your content does not validate, your RSS feeds might be broken as well. Most feed readers will barf when fed broken XML/XHTML. That means fewer readers.

Validation is also important in another sense: when you focus on validation, you inevitably end up doing somethign about semantics in your markup. Everyone benefits from this, especially you, the author, because Google and other search engines benefit from semantic markup.

Plus, broken HTML/XHTML may render in unpredictable ways with different browsers. XHTML-based blogs may not even render under certain circumstances (we’re talking about the famous application/xml+html content type here). I don’t suppose you’d want to harm your readers’ reading experiences, do you?

To help you in your thankless task of ensuring that your WordPress blog always remains valid HTML/XHTML, I’ve written a special plug-in for it: the WordPress XHTML validator. Download it today!

By the way, thanks for the reference link, thTeong!