I have earlier proclaimed markup an [necessary] evil. A more constructive way of putting it is to say that markup should always be minimal. You should use as much markup as you need, and no more. Markup is something we add to aid machines. Too much or wrong markup can do more damage as too little or too vague.

This design principle determines how to standardize markup. Unless the author knows something the user doesn't, the markup should not be there.

This principle obviously caters to the author's laziness, the admirable human trait not to do more than necessary. It is less obvious, but no less important, that it also empowers the user. More minimal markup means more flexible and accessible markup, assuming that the user agents do their job and actually act on their users' behalf. …

(more…)

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? …

(more…)

More musings on manned and machine space travel in Travel to Mars? I hope not.

The joys of a managed platform.

Well over four years ago Opera made the first native SVG implementation, with the first useful implementation the following year, and Safari and Mozilla got into the game. By 2007 SVG became a browser business and earlier limited use of SVG faded into the background. Roughly at the same time Safari came up with Canvas. Then as now SVG was commonly seen as the more conscientious but awkward elder brother of Canvas. …

(more…)

One common situation when registering a new account with a service (say my.opera.com) is that it requires email confirmation from you to activate that account. This is part of a handshake, where both parties present their credentials and confirm who the other one is. It is also a neat way for the service to make sure that the user has a valid email (to be blocked if a troll or spammer) which is also a universally unique identification. Two independent parties will never have the same email address while they could have the same username on different services (I am "jax" here, but on other sites someone else could have taken that username).

Unfortunately as often as not the confirmation request message to make sure that the user is not a spammer will itself end up in the user's spam folder since the mail program or service can't know that the email isn't from a spammer. …

(more…)

For many "accessible JavaScript" would be an oxymoron, but in principle JavaScript could be as accessible as anything else if the author was very careful or if the user agent would know more of what is going on. …

(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. …

(more…)

A link to the past

HTML is the Hypertext Markup Language. Hyperlinks is what made HTML special. When I came to the HTML Working Group, shortly after the browser war was over, the feud of the day was with XLink 1.0, which quickly had become a Recommendation through a flawed process. The HTML group wasn't happy about it, as they didn't think the specification fulfilled its design goals.

XLink had a complex history, originally it was meant to be an Extensible Linking Language to complement the Extensible Markup Language (XML). The specification ended up creating a number of attributes in the XLink namespace, 'link:type', 'xlink:href', 'xlink:role', 'xlink:arcrole', 'xlink:title', 'xlink:show', 'xlink:actuate', 'xlink:label', 'xlink:from', 'xlink:to'. The idea was that any XML language needing hypermedia functionality would mix in the appropriate XLink attributes.

When I left the HTML Working Group a few years later XLink was forgotten, but the HTML working group had made a very similar collection of floating attributes for XHTML2, 'xhtml:href', 'xhtml:role', 'xhtml:src', 'xhtml:about' and so on. The idea now was that any XML language needing hypermedia functionality would mix in the appropriate XHTML2 attributes. …

(more…)