HTML, EME and Open Standards

Open Standards are standards (specifications of formats or protocols) that follow five simple rules.

They have to be:

1. subject to full public assessment and use without constraints in a manner equally available to all parties;
2. without any components or extensions that have dependencies on formats or protocols that do not meet the definition of an Open Standard themselves;
3. free from legal or technical clauses that limit its utilisation by any party or in any business model;
4. managed and further developed independently of any single vendor in a process open to the equal participation of competitors and third parties;
5. available in multiple complete implementations by competing vendors, or as a complete implementation equally available to all parties.

The importance of Open Standards is somewhat highlighted by its definition itself: an Open Standard can simply be used by anyone, without restrictions. This allows any developer to implement such a standard, and avoids user exclusion - anyone is free to use an Open Standard. This importance has been recognized though the years, and lately that recognition has reached into higher policy levels, with countries like Portugal mandating that the Public Administration must exclusively use Open Standards, as a way to ensure citizens unrestricted access to public data and services.

One good example of an Open Standard is HTML. Even if you're not very aquainted with technical issues, you probably already heard about HTML -- or at least seen a "Web address" (called URL) like "http://somesite.org/this.html". This happens because HTML is the "language of the web": each webpage is written in a format, called HTML, and since all the web pages are written in that same format, and because that format is an open standard, anyone can create a computer program (in this case, a web browser) that reliably receives the web page in that format and knows how to correctly display it on your computer screen. This is what makes it possible for you to see the same web page on your phone, your computer, your tablet, even if you are using different programs to see it. It doesn't matter weather you're using Android's web browser on your phone or Firefox on your computer, while your friend is using iOS's web browser and Safari on his Mac laptop. Everyone can see correctly a web page: that's one of the beauties of the Web, and that happens because HTML is an Open Standard.

So, what's this EME thing? And why are people fussing about "DRM in HTML"?

EME is a proposed specification that aims to "extend HTMLMediaElement" (which is a part of the HTML specification). What this means is that, if EME is approved, a part of HTML's current specification is going to be updated. The "new version" includes two kinds of changes: some mandatory and some optional. In its own words, "Implementation of Digital Rights Management is not required for compliance with this specification: only the Clear Key system is required to be implemented as a common baseline." W3C argues that this constitutes no problem, and that they are not adding DRM into HTML, because implementing DRM is not required. However, the fact that implementing DRM is possible (even if not mandatory) means that, if a website uses such an implementation, either your web browser also uses it, or you won't be able to see that part of the website (remember what I said before about the web being seen by everyone? That wouldn't happen anymore.) Of course, this wouldn't need to be an issue at all: if the specification allows for that implementation, its just a matter of all browsers implementing it, right? Wrong. The problem here is that the "specification does not define a content protection or Digital Rights Management system".

In other words: EME introduces the possibility to use things (DRM systems) that are not part of the specification, so the complete specification (a way for an independent party to implement all the specification) isn't available -- EME is not an Open Standard. And since EME aims to be inserted into HTML (by updating part of its specification), then HTML will have an extension (EME) that has "dependencies on formats or protocols that do not meet the definition of an Open Standard themselves". Yes, EME approval would make HTML stop being an Open Standard.

Summing up

HTML is an Open Standard, and that is good for everyone. So good, in fact, that some countries, like Portugal, mandate that public administrations can only use Open Standards. However, there is a proposal (EME) that, if approved, will make HTML stop being an Open Standard. That will have an high negative impact in Public Administrations, citizens and the overall web community -- which nowadays means the citizens of the world.

This approval would have an high social, political and cultural impact everywhere. From the current era of shared knowledge, easy access to information, and overall making the world more accessible, we might be heading towards the dark ages of the web. There is, of course, a solution: let's make W3C know that we oppose EME, and ask them not to approve it.

DRM in HTML5

Many people have doubts regarding how can possibly be an issue of having DRM on HTML, the foundation language of the entire web. One person in particular had the doubt of "how can it be possible that DRM (closed by its nature) is inserted into a standard?"

I have replied to her about it (in Portuguese), but I think that, with some adaptations and a translation, this text might also have a wider use for those of you trying to understand HTML, standards and DRM. Oh, and don't forget, click on the image in the right to sign a petition against DRM on HTML.

The "short answer"

You should attend to the Document Freedom Day 2013 celebration event nearer to you: they're happening starting today until April all around the world. There, I'm sure, there will be people knowing and willing to explain to you any questions regarding open standards in general and the "DRM in HTML" issue in particular.

The "long answer"

A standard should be considered open if it complies with a number of requisites. Here's the list (taken from this page, that explains each point better):

An Open Standard refers to a format or protocol that is:

• Subject to full public assessment and use without constraints in a manner equally available to all parties;
• Without any components or extensions that have dependencies on formats or protocols that do not meet the definition of an Open Standard themselves;
• Free from legal or technical clauses that limit its utilisation by any party or in any business model;
• Managed and further developed independently of any single supplier in a process open to the equal participation of competitors and third parties;
• Available in multiple complete implementations by competing suppliers, or as a complete implementation equally available to all parties.

Unfortunately not every format is an open standard, or, in other words, doesn't comply with the previous points. If the proposal to have DRM on HTML5 is accepted, HTML will stop being an open standard, since it will stop complying with the second requirement of the list.

In more detail: the proposal on the table is called EME (Encrypted Media Extensions). An HTML document can include EMEs, and the specification of EME enables the website to require a certain "Content Decryption Module" (CDM). And here lies the problem: CDMs aren't standards (much less open standards!) and the EME specification doesn't include or refer to any specification of any CDM. In other words: the definition of open standard we just saw isn't complied, because to implement HTML5 we have to implement EME, which has to accept any CDM, which isn't a standard and so we cannot implement.

In other words, with an example: I make a website, and put there a media object (video, for instance) using EME, and I specify in the HTML document that the EME object needs the CDM module (which is a form of DRM) called "OneTwoThree". Now, if you want to see that website, you need a web browser that knows how to undertand HTML5 and EME (both possible since there's the specification), and the browser then needs to get the CDM called "OneTwoThree" (imagine it as being a browser plugin, not unlike Flash) and use it to play the video. The problems are obvious now: what if the CDM only exists for one specific Operating System? What if the CDM isn't free? You know... the thypical problems of a non-open standard format.

Nokia buys Trolltech: something to worry about?

You probably know by now: Nokia is buying Trolltech [1]. I didn't talk about this yesterday, besides releasing a "crap" shout as I read the news for the first time. I read a lot, specially from folks from Nokia, Trolltech and KDE. I'm somewhat confident that this might not be as bad as it first seemed. Still, I have two major issues with this aquisition:

• Nokia actively lobbies in favour of Software Patents. This might not be an issue for now, but a culture clash might happen soon. Gladfully, QT is licensed with GPLv3, but yet, this can be a showstopper for both FreeQT and KDE.
• Nokia have a no Ogg, pro DRM position regarding HTML5. If they somewhat forces this to Trolltech (instead of doing the right thing, supporting Ogg, rejecting DRM), once again this can be a showstopper.
  

What this really means, in fact, is that this two issues concern me and a lot of others - and that they should be answered before this aquisition ends... or else there's some uneasyness Trolltech and Nokia will have to deal with.

[1] - http://www.nokia.com/A4136001?newsid=1185531

AxsJAX vs. Hijax

Google decided to Open Source yet another tool: a Javascript framework called AxsJAX, which aims to "add accessibility to AJAX-powered web apps". AxsJAX is already used in a couple of Google Apps, and is a set of Javascript tools that add accessibility tags to your AJAX webapp. This means that AxsJAX, spelled "AcessibleJAX" (to rhyme with AJAX), is only used if you have a recent web browser that has Javascript enabled and implements the drafts of W3C-ARIA, which, in other words, isn't an acessible framework at all. If you take into consideration the W3C Accessibility guidelines, you'll quickly see that depending on some yet-to-be standards (ARIA) or even in Javascript isn't being Accessible. Yes, you can add AxsJAX to your AJAX-powered webapp, but you must take into account that it will not make your webapp accessible... As a matter of fact I think it would be nice to have webapps using it, but on already accessible webapps.

Now, there's this silly idea that it's too hard to make an AJAX-powered webapp accessible. Developers talk about painful code to allow graceful degradation, and some are even crazy enough to actually prefer mantaining two webapps: one AJAX-powered and other AJAX-less. What's really wrong about this scenario is that it's pretty easy to design accessible websites, even AJAX-powered. Welcome to the world of Hijax.

Hijax (which is nothing more than a way to use AJAX) is just the way to design AJAX-powered websites. The steps are pretty simple:

• Design your webapp well


• Add all the AJAX you want by hijacking the requests

Now the thing is, what is "design your webapp well"? Welcome to the wonderful world of standards. You know, all those things that people hope to comply with without really trying? If you first understand standards, their design and purpose, you'll see that's really the easiest way to do things. On the web, the trick is simple: you have

• the data layer (HTML)


• the presentation layer (CSS)


• the interaction layer (Javascript)

Now, what standards teach you is that in HTML you should put all your data, and nothing more than that; in your CSS files the presentation layer and nothing more than that; in your Javascript all of your interaction layer and nothing more than that. Remember allways to avoid some mistakes: an anchor belongs to the data layer and not to the interaction layer, so doing stuff like <a href="javascript:"> is just shooting yourself on the foot. Now, if you have this scenario, you have your website (still without AJAX) and you can do all the funny stuff you like to do with Javascript. The good thing about this scenario is that if you disable the Javascript (or if you use a Javascript-less browser) all the blings, bells and whistles disappear, but all the data is there, and presented the way you design it to. Now, if you go one more layer and disable your CSS (or if you're using a web browser without CSS functionalities) you have all your data there (again), just as it should be, only without that stylish presentation you wanted to (which is pretty but useless to someone blind, anyway).

So, the thumb rule is simple: build your app as progressive enhancement, 'cause progressive enhancement automaticly guarantees graceful degradation.

Now, let's add AJAX (or the XHR component of it) into the equation. Most developers agree with all I've said until now: the need of a clear separation between HTML, CSS and Javascript, specially if you're talking about CSS's or DOM scripting. But when we talk about AJAX... they suddenly cast it aside. The problem is, basicly, that you're with the wrong mindset. Instead of thinking that AJAX is just a way to update parts of a page without refreshing, or, in the other hand, you think that AJAX is the spetacular awsome cool new thing that lets you update parts of a page without refreshing, you should look at AJAX as this new way of talking with the server asyncronously and deal with the page accordingly. Leave that "it's not a page, it's an app" thing, the app is what you built, but what you're serving is a page... even if it dynamicly changes itself over time (thanks to AJAX or not).

But I still didn't explain the Hijax part: how to add AJAX to the equation. Well, it's pretty simple indeed: just pick your non-AJAX pages, with links and forms that do requests, and just use JavaScript to intercept those requests and transform them into XHR.

This isn't meant to be an in-depht post about Hijax, more like "why you shouldn't be that excited with AxsJAX" than everything else. Anyway, if you liked the concept, just read Jeremy Keith's "DOM Scripting Blog" [1].

[1] - http://domscripting.com/blog/

Proper nouns and HTML

Rui wrote a post about the use of the "õ" character in XHTML. I tried to comment but something went wrong with it, so here's a post about it:

Propper Nouns are untranslatable, so my name is Marcos Marado wherever I am or whichever the language I'm talking is. The same way, Paula Simões is called Paula Simões either I'm talking about her in Portuguese, English or Japanese. So, if I'm talking in English and I want to refer to Paula, I should say "Paula Simões", and this doesn't mean that I'm "mixing languages": Proper nouns are universal, they have no nationality and are untranslatable. It's the same as "Internet", there's no translation for that. When you have to use such entities, you must write them this way:

&atilde; turns ã
&aacute; turns á
&agrave; turns à
&acirc; turns â

...and so on. There's nothing wrong in the way Paula writes her name in her website, nor does it affect the page's ranking on search engines (not that I believe that she's trying to apply any kind of SEO technique on her website).

Avoid PDF for On-Screen Reading

I wrote four or five times this post, and deleted it before posting. It had several different titles and different tags, but it allways sounded too harsh. So, stopping, taking deep breaths and only writing afterwords have some advantages.

You shouldn't embed PDF's on your website. Forcing users to browse PDF files makes usability approximately 300% worse compared to HTML pages. PDF is great for distributing documents that need to be printed. But that is all it's good for. No matter how tempting it might be, you should never use PDF for content that you expect users to read online. Using one of those stupid flash thingies to avoid embeding PDF's, but for the same purpose (displaying an embeded document) not only is still bad, it is in fact worse.

Thank you.

More info about this here.

No one is 24 years old!

I am 24 years old. OK, I've heard before that "hey! nobody is 24 years old!", I just didn't knew that the Portuguese Finances transliterated that!