Is this thing on?

When you have "dinner at seven" it would be dinner at seven tonight unless that time has already passed, then it would be dinner at seven tomorrow night. If it were "breakfast at seven" then it would be tomorrow morning as most of us have breakfast in the morning and dinner in the evening. The way we specify dates is highly contextual and highly cultural, so artificial or natural intelligence will have a hard time figuring out what time it really is.

Read more...

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.

Read 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.

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

Just published my first SVG article on Dev Opera.

I came across a blog claiming that we're at war, based on Eskil having a good partisan gloat on a negative review of the Konqueror-based Nokia browser ("A special circle of Hell needs to be created..."). The blog entry is somewhat unfair as it discounts Small-Screen Rendering for reformatting pages and then goes to criticise horizontal scrolling, the very problem SSR was designed to counter (if you don't reformat the page on too small screens, you will get horizontal scrolling which wrecks havoc with readability), but I liked the site-by-site comparison.

I am fine with our "war", just like press coverage of the "second browser war" is good for anyone caring about browser rendering on the Web. That is, as long as the story is IE vs Firefox vs Opera vs Safari/Konqueror (vs the other browsers if the journalists are thorough enough). IE vs Firefox stories are less interesting, obviously for leaving out Opera, but in particular because as long as the story is about two boxers in the ring, why should anyone care about open standards?

An unsung browser innovator is OmniWeb and I also think that everyone at Opera who have ever touched a Mac have a soft spot for iCab. Yes, it is a competitor, but it has got that Opera spunk. It has the longest odds in the world but it doesn't cease to innovate, and it is deeply committed to standards. I don't have a Mac, otherwise I would probably have bought a licence, just on principle. If you got a Mac and 29€ to spare, you know what to do. While you're at it, download Opera for Mac and do a lot of those Google searches.

The original browser war was a traumatic affair for the Web, and in my view Netscape was a greater villain than IE, but both were pretty nasty and neither cared about Web standards unless it furthered their cause. The more the current "war" is reported, the more likely the best browsers will be installed instead of default browsers. So the second browser war is benevolent, may the best browser, be it IE, Opera, Firefox, Konqueror, or iCab win.

I conditionally put IE as a competitor and not an enemy, though it has had a chequered past. From IE6 to IE7 Microsoft has played fairly as I see it, they didn't in the past and who is to know if they will in the future.

The same goes for this reported phone browser war. More than on PCs the browser you will use on your phones is the one initially installed, good or bad. If there was to be a browser war Opera vs Nokia (KHTML) vs Netfront vs Minimo, so much the better. Minimo is lacking for other reasons, but as for standards compliance Gecko is a very decent competitor. Netfront isn't up to par with the desktop browsers in that respect, but is good enough to be counted in this company. Reviews comparing all of these, for small devices as well as the not-quite-small devices, would be good for open standards, the same open standards as on desktop browsers.

So again competition is good. If we were to declare war I would suggest War on WAP, at least it got this nice alliteration.

Opera 9.0 Beta is now available for download. For those of you who have regularly tested the 9.0 previews and weeklies the difference from those isn't that great (except in stability), but from 8.5 it is huge. There are new features and advances in standards. One that has truly progressed since 8.5 is SVG. While we don't have complete SVG Basic support yet, with full styling and scripting, we are close. Getting here has been a long journey. The first version of SVG, SVG 1.0, became a W3C Recommendation in September 2001. We had an interest in SVG even earlier, but the sheer size of the specification made us decide against it, it was hard to justify putting so much effort into a format that was going to need years to get a foothold in the market. We had done it with PNG before, but that was easy. The arrival of the Adobe plug-in decided the matter, why should we spend our remaining resources on SVG when there was a viable alternative? We weren't looking for a Flash competitor, which seemed to be Adobe's main drive until they bought Flash several years later. It definitely wasn't to make a Purity of Essence markup language not sullied by the real world like the HTML harlot – many working group members at that time were deeply hostile to the Web. The mobile companies were the next to turn on to SVG, and while there are clear benefits with SVG on phones, the gains can be even larger on a larger screen. We saw a vector graphics markup language as an adjunct to HTML, together they would become more than they were separately. Each language could provide what the other one could not. HTML augmented with CSS could do both text, layout, hypertext, semantics and more. But it couldn't do the simplest illustrations (except through brutal hacks), or graphs, or fancy boxes or headlines. As HTML was a W3C language and SVG was a W3C language you would have expected that these two were well integrated, that you could easily use one to enhance the other. That certainly isn't the case and this is a tremendous unfulfilled promise. It isn't all bad, the two languages do integrate with each other after a fashion. They can be looked at as feuding siblings, having them in the same room will cause torment, but they are family. Hopefully some years from now they will both grow up. How did it get to this state? One reason was attitude, another was timing, a third the participants. The way W3C works may also have had an influence. Many at the time believed that the Web was fundamentally broken, that it was better to have a fresh start. If the Web was broken, what was the point in integrating with it? Whenever SVG integrated with other specs, it was always to other new and still largely unused specifications. SVG wasn't to enhance the Web, it was to replace it. This was less ridiculous than it might seem now. The Web was war-torn and not in a very presentable state. To this day our Open the Web team is working on, or rather against, the Web of 1999. The timing was unlucky too. HTML 4 was done when SVG started, and in the following years that group was preoccupied on reengineering HTML to be on top of XML instead of (ostensibly) on SGML. In any case the climate for HTML, W3C's greatest hit, was chilly. There also seemed to be an implicit W3C assumption that XML made document integration automatic, and then that XML Namespaces would do so. For one reason or another the browser makers were not involved. Microsoft, that had an SVG precursor in the VML format, has just won the Browser Wars and could go back to sleep for another half decade. Netscape was busy changing its skin to Mozilla. We were turning our CSS browser into a DOM and CSS browser and, more hidden from view, a browser that could thrive in the most cramped devices. The actual SVG implementors didn't have any great interest in Web integration, for them this was just extra complexity with no direct benefit. We might have been one of those implementors. In the summer of 2002, mere months after SVG 1.0 was published, our lead SVG developer held an internal demo of a prototype SVG implementation that included the iconic SVG image of the time, the SVG tiger, looking the same way then as it does now. A bare-bones SVG feature set, much smaller than the extended SVG 1.1 Tiny we released in Opera 8, could have been a part of Opera 7. It would have been scalable vector graphics later to be animated, styleable, and scriptable, but not much more. But the great migration towards Presto had started, SVG had to wait. Further on there was a repeat of the Adobe plug-in story, as Ikivo made a great SVG Tiny implementation that covered our phone needs if not our cross-platform needs. Had it made any difference if we had given higher priority to SVG? For the standards, probably not. The odds were against it at the time, and we had little time to spare for W3C work. It might have increased the browser attention to SVG, but none would likely have come up with an actual implementation faster anyway. Web developers might have caught on to SVG a little earlier, but they would have been even more frustrated with SVG than they were with HTML+CSS. Today Opera 8 (but not Opera 9) suffers from what I see as a mistake in the specification: If there is anything in SVG a browser doesn't recognize, it is not allowed to show anything at all. For a hardcore graphics SVG implementation, like the one we were contemplating, that would in practice mean that unless the SVG was specifically made for Opera, we would not have been able to show it. Another and much larger problem is that even with this rule, which was made with the intent to make different implementations interoperable, the existing SVG products today aren't really compatible. We will eventually get this right, but it will take years of slog (déjà vu for any CSS enthusiast). When the SVG world and the Web world eventually did collide, that meeting was often acrimonious. It probably was unavoidable. While there was ideology on both sides to be dealt with, SVG as a standard needed some years on its own to find its standing. HTML, CSS, and DOM is today a fairly harmonious trinity, but that was not the case at the beginning. Early on Netscape had annexed HTML, CSS came from W3C and got its first real implementation in Opera, and while Netscape came up with JavaScript, Microsoft trumped it with a superior and more popular DOM. Neutral ground W3C DOM (which is more similar to the MS DOM), while formally the standard DOM created by Microsoft and Netscape together, wasn't really supported by either browser. Mozilla was the first browser to support W3C DOM, followed a few years later by Opera, Konqueror, and most recently iCab. Standards are the first casualty in browser wars, and it took a decade to mend them. But during all this hammering something else happened, the three specs began to fit. Fitting HTML and SVG the same way should hopefully mean less banging, and the signs are that they are slowly melding, and people from both camps are seing the mutual benefits (and, as many of us are commercial, the business cases). What is more intimidating is that this is going to be the easy part. Uniting HTML and SVG is a bit like uniting magnetism and electicity, there are other forces less mallable to the theory of the Grand Unified W3C.

A weekend in Glasgow. Scotland is neighbouring Norway and a direct flight from Oslo (though this being Ryan Air the bus ride to their airport takes longer than the plane trip itself).

The physical and cultural closeness makes it easy to forget that they live by different standards than we do. The difference is slight, phones work, they use 230V, they even switched to metric. All is fine until you try to put your round pegs in their square holes.

The phone is fine, but the laptop is getting progressively more needy. All for competing standards in the user interface.