Is this thing on?

Minimal markup seen from a data point of view rather than a document point of view.

I wouldn't say it is XML's fault as such, but it being used for a purpose it is less than ideally suited for, a consequence of early oversell (those who remember 2000 would know what I talk about).

There is another lesson that is web-relevant. Big dataset like these shouldn't be naively be tagged into an XML format and presented as is on the Web. This is because in a web setting the overhead for each element is rather large as the DOM will be applied to it, allowing arbitrary dynamic mutations. It is easy to overwhelm even the most powerful processor this way and zap all available memory.

Where we are

Four years ago I wrote a small piece on conditional comments in IE7, and whether there should be an institutionalised Opera CSS hack, in the style of @opera or @browser opera. While IE's standards support isn't stellar, it is still better than it was four years ago, and the desire to make specific hacks for the shortcomings of IE, Opera, or any other browser hasn't gone away and is unlikely to go away in the next decade either. This entry is triggered by a comment this Friday asking for Opera conditional comments. For all the talk about the ills of browser sniffing, and using capability detection instead, it is not going to go away. In that case wouldn't it be better to make browser sniffing less bad?

Read more...

There is one basic document functionality that none of HTML, CSS, nor SVG can do. None can represent one box, another box, and a link between the two.

Read more...

Following up the discussion on Accessible drag and drop using WAI-ARIA, I think HTML5 may be a huge win for accessibility. HTML4 was filled with good intentions, HTML5 should be filled with good implementations.

HTML4 became a W3C standard 11 years ago. By now we should have plenty of implementation experience with the standard, user agents, web developers, and authoring tools and what has actually made the Web more or less accessible. Ideally there should be an audit of all the HTML4 features for their impact on accessibility, whether they were designed for the purpose or not.

We also have extensive implementation experience. Accessibility was central to the design of Opera from the very beginning and part of the company culture, but that doesn't mean every initiative was a success. Other browsers and tool makers should have learned something the last decade as well. Accessibility enjoys considerable goodwill among developers, most want the Web to be accessible, but to turn good will into good products first we need to make the implicit knowledge explicit, what failed as much as what succeeded and why it failed.

Read more...

Even after the death-of-XHTML2, syntax debate still dominates the day. Here is my contribution.

The XML story

In the beginning was SGML. There is a lot to be said about SGML so I won't. HTML was specified to be an application of SGML, but that never happened in practice. Among browsers Opera kept the pretence of supporting SGML for the longest time, causing us a lot of trouble because Opera behaved differently from every other browser. DocBook is another known SGML application, but in general SGML was no success.

About a decade ago a small group of people started a reformulation of the old SGML standard, First they did it outside of the W3C and later, when the success became apparent, within the W3C. The story of this simplified SGML, now known as XML, may be best told via the annotated XML, by Tim Bray, one of the principal authors. Essentially XML is angle brackets and a number of production rules on top of Unicode (for a fuller description see Comparison of SGML and XML).

Read more...

Should-read article: Accessible drag and drop using WAI-ARIA

The keyboard-friendly design of Opera was one of the things that attracted me to the browser in the first place, and one I am disappointed with the slow progress with. Keyboard-wise Opera today isn't substantially better today than Opera 3, or at least Opera 7. In some cases it is better (like spatial navigation when it works), in other cases it is worse (I still haven't found how to recover the Alt+Z history view, one of Opera's greatest inventions). I don't think Opera does any keyboard-only or keyboard-augmented usability testing.

Opera's lack of progress is one thing, but in the Web sphere things are actually getting worse. Early on you could do keyboard-only browsing most of the time. If the site used frames it was very awkward and it was better to use any mousing device available, and you had the occasional idiot who used 'onclick' functionality to recreate actual links, either because he didn't like the colour or underline of links or simply because he could.

Most of those idiots have discovered CSS by now (there should be a Hall of Shame site for those who haven't), but in these webapp ajax gidget 2.0 days recreating the user interface is the game of the day, and that usually means breaking the keyboard.

One of the tasks you can't reliably do with the keyboard today is drag and drop, and that goes for navigating to dynamically generated submenus and choices as well.

In my view the raging accessibility question shouldn't be whether the 'alt' attribute is optional or mandatory, but how we can make the Facebooks of the future accessible.

This ties in with HTML5 and the obituaries over the dead discontinued XHTML2 spec. XHTML2 and XForms were designed with accessibility in mind, HTML5 was designed primarily with web designers in mind. For a devoted keyboard user that should make the preference easy, right? Not so. The HTML4 spec, like XHTML2 and XForms, is filled with well-intentioned accessibility features, but those features are no good if they are not used.

An attribute like 'longdesc' can make an inaccessible picture into a device-independent and accessible textual representation of that picture. All the designer has to do is to spend a couple hours for each picture describing them in detail what they depict and what they are used for in an as context-independent way as possible. For some reason most web designers opt not to do that.

Given the choice between having Facebook and similar sites mostly usable or the WAI site and a couple other special interest sites perfectly accessibly marked up, Facebook is the winner. If the spec can give designers the features they crave and then behind the scenes give the browser or the assistive tool the information they need to cater to their users we have a winner. The HTML5 work with drag and drop looks very promising in this regard.

What the HTML5 spec doesn't cover, and which Opera has struggled with in its extensive keyboard support, is how to handle the conflicting interests of the web application developer and the user agent, be it a browser and/or assistive tool. As an example Opera uses the A key to navigate to the next link, what if that key is used by the application? In a keyboard not having the A key another key is used instead, or the user can configure his own keyboard mapping, so it wouldn't make sense to make a collection including A "reserved key" unavailable for the application. So who should win in a battle of A, the web application or the user agent? CSS has covered a similar conflict in the Cascade (the C in CSS), essentially default < author preferences < user-important preferences. For a User Agent I believe the best option is to let the UI be overridden by the web application (otherwise the application won't work in that environment) but have a mechanism to override the application when needed.

Related, given the great variety of keyboards, some user mechanism to remap keyboard mappings is necessary not only for the user agent, but for the web application as well.


Here is a demo of keyboard-accessible drag and drop in action.

This post is a reaction to xErath's comment to an earlier rambling.

Originally posted by xErath:

There's enough info online about the deficiencies of ooxml. I don't need to quote them here.

Just to have it over with, we agree. I may be a Microsoft groupie at heart, but I don't have time for OOXML. People who want to discuss OOXML should feel free to do so, elsewhere. More interesting is this part:

HTML5 is a big patch over HTML4, made to be backwards compatible with the complete mess that is the web.

ODF on the other hand is a clean approach to define an abstract model of document formats. Then ODF has many features that html5 will never have nor will make any sense. I doubt html5 will ever include native spreadsheets support, slide transitions, page footers and headers... you name it. ODF will not support local databases nor globalStorage.

First, I have come to realise that the phrase "it is a complete mess" is a shorthand for "it works very well, and I don't think it should". In fact the Web is a remarkably sane place. We have millions of monkeys making Web code every day, and it works. The Web is more like an ecosystem than an engine, you don't stop and "repair" it, it is survival of the fittest. If you look at Web code written today and ten years ago the old code was worse and still achieved less. The Web has evolved and it keeps evolving.

Read more...

It was natural to start off a series on web elements with a vilified element that never made it into any web standard and never will, the spacer. Often elements are made for minute details that nobody, man or machine, are interested in. Should abbr or acronym be used? Who cares, except the poor web developer confused by reading the literature and trying to do the right thing.

spacer is an element signifying nothing, containing nothing, and displayed as a rectangle of nothing. It is a pure layout hack. You know the the drill. The correct and proper element to use is object, or use img if you have to for compatibility reasons. The spacer is not to be used. And this is a pity. The wonderful thing about spacer is that you know it is a hack and that it is completely devoid of meaning.

When we do Small-Screen Rendering or a voice representation of a page the goal is to remove the useless stuff and present the useful stuff as well as possible. But what is useless? If a tiny image is stretched horizontally or vertically we assume it is a spacer element and remove it. We are practically always right, but still it is guesswork. For all we knew we could have removed useful information. If that img had been a spacer instead we could have removed it with no remorse.

As it happens there is a convention to express that an img has no real significance. The img element has an obligatory alt attribute, if set to an empty string it is a signal that it has no text equivalent and is thus, in the grand scheme of things, useless. <img src="image-address" alt=""> is just another way of saying spacer with a little more colour.

What about object? This is an element that slices and dices but unlike img there is no way to state the difference between <img src="image-address" alt=""> (i.e. this image is expendable) and <img src="image-address"> (i.e. the designer hasn't considered how the image shall be used in other contexts). <object data="image-address"></object> can mean either of these things, we just don't know. Our options are either to make a guess or to force the decision on to the user.


object is the most general and expressive element with the most flexible fallback. Given <object id="a"><object id="b"><b>Markup</b></object></object> the object with id=b will be shown if and only if the object with id=a can't be shown. If neither can be shown <b>Markup</b> will be shown instead. But only the author knows if the fallback is important or not. Unlike the HTTP q property ("q" is for quality) we can't know if the two id=a and id=b objects are equivalent (e.g. Flash and SVG versions of the same graphics) or if id=b is a barely adequate substitute or worse (e.g. a poster imploring the user to download the Flash plugin).

What can we learn from that? The lowly spacer isn't just more expressive for its purpose than the worker img element, it beats the folk hero object. I am not proposing to introduce the spacer element into "polite company", this ugly duckling won't turn into a swan. CSS can do the same job better, though you need Opera if you want to fully represent what the spacer element can do, and much more flexibly. CSS is the language for layout hacks.

But spacer has many of the properties a good element should have. Its use is clear, you won't use it unless you mean it. It tells something the web designer knows the user agent needs to know but can't truly on its own (that this element is used purely for layout purposes). We don't need to know why this layout hack was added, just that it is a layout hack that will not transfer to other layouts.

One common statement from the WAP advocates (who, like the World War I veterans, are getting fewer by the year) is that WML is a more compact language than (X)HTML. Not so. It is a simpler language, you don't need an as advanced browser to handle it, but the WML source is actually more bloated than HTML precisely because it is a simpler language. Since WML 1 doesn't even have the headline elements ('h1' to 'h6'), you can't use code like <h2>A subhead</h2>, you have to do something like <big><big><b>A subhead</b></big></big>. Not only do you lose the useful information that "A subhead" is a headline, you need more markup to say less.
There are some byte optimisations, WML align="c" is shorter than align="center", though using CSS would be even shorter than either of the two. HTML has some inefficient quirks, 'strong' and 'b' are used for the same purpose, and 's' and 'strike' are two elements for the same visual effect. Sometimes old-style WML too use more verbose syntax, like <anchor>link text<go href="url"></anchor> for <a href="url">link text</a>. More usefully WML has a compressed non-XML format confusingly called "binary XML" that gives considerable savings when the page is sent uncompressed from server to client. When sent compressed the gains would be minor.
The WAP graphics format WBMP is the only uncompressed format you will find on the web. Again designing for simplest possible processor doesn't make for a compact format. The saving grace is that only black and white are allowed, WBMP images are supposed to be tiny, and that it doesn't matter much if the data stream is compressed anyway.
Now, in the real world a WML page may be a few KB, while the source code for a news site like cnn.com might run into over a hundred, with the graphics clocking in hundreds more. Surely the WML page gives more news for the byte. Yes, it does, but that is not due to WML being a more compact format, but due to the WML page being crafted for small size. An equivalent HTML page will always be smaller, and an HTML+CSS page smaller still.
So why is the news page so huge? In a word: over-specification. If you look at the source code of a typical news page you will have a hard time finding the news items themselves for all the markup. Not only will you find the source filled with fonts and nested tables, the same effect is specified multiple times. Why is this so? Obviously the economics of serving and receiving web pages has not had a major role in the design. News sites have learned to serve simpler and smaller pages in times of major events where the surge of interest might overload the server, but when the crisis is over they return to the old design. The pages may be bloated, but they are tested and they generally look the same in every browser. Furthermore the code in some cases have passed the point of no return, they have grown so complex that any change will have unforeseen consequences. This particularly applies to JavaScript. Removing lines of script requires reading and understanding the existing body of code, adding even more lines does not. The script is now destined to continue growing until it collapses under its own weigth.