From Accessibility to Zope

Over the past few months the web browser industry has shifted up a gear. After years of stagnation and limited diversity the market is blossoming, first with Safari opening up to the mass-market of Windows, then Opera 9.5, then Firefox 3 and now Google Chrome. And soon, Internet Explorer 8, which is verging on counting as a real browser (so tacit congratulations for Microsoft are probably in order).

If you look at the features promised by Google Chrome there’s precedent for all of them:

• One Box for everything - Opera 9.5 / Firefox 3
• New Tab page - Opera 9.5
• Application shortcuts - Mozilla Prism
• Dynamic tabs - Opera 9.5
• Crash control - Internet Explorer 8
• Incognito mode - Stealther Firefox extension, InPrivate mode in IE8
• Safe browsing - Firefox 2, IE7…
• Instant bookmarks - Firefox 3
• Simpler downloads - Ok, I don’t know of a suitable precedent for this.

But that’s not really the point. What Google have done is cherry-picked the features to adopt in order to paint a clear picture of the way they see the web developing (and they are probably right, not least because they are pouring money into making it develop that way).

I wrote a webrunner (to borrow terminology from Mozilla) way back in 2001 or thereabouts, embedding the Internet Explorer component CHTMLView in a chromeless frame. The merit of the site-focused approach was obvious then even though my implementation was mainly just an exercise in MFC, and it was merely for a forum I used to frequent. The point is that not all webpages are equal. People don’t spend most of their web time “browsing”: 90% of the time they are just logged into the same sites and applications. Chrome’s user interface, architecture, and selection of features seem better prepared for this than any other browser on the market.

Google Chrome is a leap towards a much more minimal browser that knows you aren’t running it so that you can use a browser, you’re running it so that you can use websites. This web-centric future has been predicted so often, it comes as a shock to see that this is what it feels like, and that other web browser manufacturers have never taken the initiative to fully deliver on this promise.

I’ve just been reading the latest goss on Acid3 and I’ve come across the most wonderfully perverse announcement from Microsoft (this is a few weeks old, but it’s not like I regularly read Microsoft blags).

Since announcing that IE8’s renderer can pass Acid2, it transpires that they have a Catch-22:

To have IE8 conform to standards, you have to use a non-standard workaround.

Wow. I’d assumed Microsoft knew what standards were but couldn’t seem to achieve compliance. Not so! Turns out they can achieve compliance but they don’t know what web standards are!

The application/javascript MIME type has stopped working in my copies of Internet Explorer (6 and 7). Both now silently ignore scripts linked with type="application/javascript", which is as far as I have since determined the behaviour most people experience. Indeed I’ve only found very sketchy reports of it working at all.

Because I had no idea I was unique in being able to experience scripts linked in the RFC-compliant and IANA-approved way, I have used this MIME type on quite a few sites. So it’s good news, because I would never have spotted this otherwise. Happily, most of these sites are not yet deployed, and the rest only use Javascript for very trivial polish. There now begins a hunt to replace application/javascript with text/javascript on all my sites.

Obviously, I’m at a loss to explain why Microsoft has failed to offer a consistent platform for development and I feel quite aggrieved about it. If I hadn’t already boycotted Internet Explorer this would be a pretty good reason to start.

On the assumption that some other piece of software has by accident or design disabled - or had previously enabled - application/javascript, this is my list of candidates:

1. Microsoft Outlook 2007, installed for the first time on this computer this week.
2. Word 2007, also installed this week for the first time.
3. Some random Windows update I installed last weekend.
4. Access 2007, installed two weeks ago (but I think I would have noticed sooner if that had caused this change).
5. Removing something malicious with Spybot. I think it removed one or two dubious registry entries left over from an infection of Vundo/VirtuMonde last year, so it’s unlikely but there’s an outside chance of an effect.

With the news this week that Microsoft have a build of Internet Explorer that can pass Acid2, I wonder if I will be forced to eat my words when I suggested recently that Internet Explorer may be falling further behind with web standards, not closing the gap.

Well, we have an interesting opportunity to measure an aspect of that gap. A quick glance at Bugzilla shows that Gecko was able to generate a correct screenshot by 2006-04-17. Internet Explorer claimed correct rendering on 2007-12-12. The gap is 604 days for Gecko, but obviously, greater for other browsers who have been compliant for much longer.

If Internet Explorer 8 progresses anything like Gecko, there will be a large number of bugs still to fix. If Internet Explorer 8 progresses anything like Internet Explorer historically progresses, most of those bugs won’t get fixed. In other words, I’ll believe it when I see it. That might not be for 20 months and might not be available on Windows XP. In fact, if the same post on the IE blog they are keen to excuse themselves from commitment to specific web standards, offering only a general tone in favour of them but excusing themselves with respect to backward compatibility. Taken as a preamble to a compliant-looking Acid2 rendering, I take this to mean, “we may not deliver this in IE8″. I think everyone hopes they will, but by comparison, some of the Acid2 patches could have been in Firefox 2 but weren’t because Firefox 2 was built with a frozen earlier build of Gecko.

Meanwhile, Firefox 3 is drawing closer. My impression is that the gap between 2 and 3 is not huge, which (hear me out!) is because Firefox 2 was excellent and Firefox 3 struggles to improve upon it. The difference for users is relatively minor. Although the new approach to bookmarking is hugely refreshing I think many users, including my parents, just won’t get it.

The difference for developers is significantly less marked - the difference between having functional support for a technology that isn’t portable to IE and having good support for a technology that isn’t portable to IE is not something that will revolutionise the web. In fact, looking at the Firefox 3 for Developers page, the changes are disappointing and even worrying. In some ways it’s a return to the browser wars of the late 1990s when competition between browser vendors’ extensions demolished the concept of web standards.

• Support for aspects of HTML5 - there isn’t even a first working draft of HTML5. Although it was the WHATWG spec before, complying with a specification this early will mean that the implementation may not conform to the final specification, by which time, developers will be relying on the non-standard behaviour.
• APNG - APNG is a Mozilla-sponsored bastardisation of PNG to add animation. It doesn’t subscribe to the contract of PNG (which expressly forbids animation) and it isn’t negotiable properly because it hijacks PNG’s MIME type, extension and magic. This spells very bad news for the PNG format. In future it will be impossible to tell if a PNG is animated or not, and of course all legacy software will believe not. Despite the best efforts of a number of people, myself included, but most particularly Glenn Randers-Pehrson, Mozilla refused to adopt amendments which would resolve the conflicting standards and the PNG group failed to ratify APNG as an official extension. Although APNG was an ad-hoc solution to offer animated UI elements in Mozilla, it is being released and promoted as the new web standard for animation and MNG support, although a superior and established format, has been canned.
• Microformats - Firefox 3 builds-in support for Microformats, which could just as easily be a standalone Javascript library. There’s no reason why this should be built-in, except to create a de-facto standard in an API which Mozilla controls. Moreover it promotes microformats as a de-facto standard, which I’m not comfortable with, because I think Microformats are an ugly hack in lieu of a proper solution.

Web designers and developers are often heard to pour vitriol in the direction of Internet Explorer. I personally find myself cursing its name perhaps once a week. It’s always difficult to believe this is a product Microsoft is still trying to promote.

Contemporary GUI development toolkits require an HTML rendering component: Java has javax.swing.JEditorPane; KDE has KHTML; Gtk has GtkHTML. MFC and .NET have Internet Explorer. In this task it is arguably successful: despite being too heavyweight, buggy, and non-portable, it is at least fast and very simple to embed. The applications which use Internet Explorer tend to use it in restricted circumstances so that the largest class of failings - how it measures up to the wild wild web - are not encountered.

With Firefox 3 right around the corner and a total radio silence on a potential IE8, it’s worth considering how much Microsoft has to do to maintain its web browser’s competitiveness.

(more…)

Most mistakes web designers make stem from the assumption that the way they are seeing the site in their web browser is the way everyone else sees it. By using uncommon defaults in your web browser, you can ensure that you have left to the default only those aspects of a page which you had intended. I call this “misconfiguring” because it is intentionally configuring a web browser to display pages wrongly. If the page looks correct with such settings it is probable nothing has been left to chance.

It is common practice to test a web site in various web browsers, but this testing can give a false impression of the compatibility regarding different default settings. This is because almost all browsers have settled on a common out-of-the-box set of defaults. The user is allowed to override these defaults. Fail to anticipate this and your website risks visual problems for some users (perhaps 1% or so, to take a wild guess). Problems include:

• Character set issues, such as £ or the opposite, a broken character symbol (the question mark diamond in Firefox) rather than £.
• Specifying a font colour but not a background colour, causing clashes or even invisible text. Perhaps 10% of websites fail to specify a page background colour but assume that it will default to white.
• Linking images which are intended to composite onto white. This looks dreadful onto most other colours.
• Copy looking illegible due to tiny serif fonts (sans-serif is more legible on low-resolution screens).
• Body font clashing with image-based buttons and titles: serif and sans-serif fonts rarely mix.
• Pale-coloured boxouts. What appears pale is in fact a function of the background colour. A light pink box appears pale on a white background, but very bright on a black background, for which the corresponding effect would be a dark red box.

The browser defaults which you may want to change include

• Character set
• Background colour
• Text colour
• Font style
• Font size, although in theory you should avoid specifying this for accessibility reasons.

Misconfiguring a web browser is an art. It is perfectly acceptable to use the defaults a user specifies, as long as all of them are respected. While you should feel free to wholly b0rk a browser which you use purely for testing, it is more beneficial to misconfigure the web browser that you use for primary development. For me, this is the same web browser that I use for everything else, Firefox. Therefore the misconfiguration has to be something that isn’t wholly unusable to me. More importantly, the new defaults have to be ones that I would be unlikely to use for a website, otherwise I could still rely on my defaults.

Because I tend to use sans-serif fonts, white backgrounds and black, grey or blue text, and UTF-8 character set, my browser is set to default to serif, coppery-orange text on a mid-grey background. I’m experimenting with ISO-8859-11 (Thai) as my default character set, because this isn’t compatible with UTF-8 nor ISO-8859-15 for the most common problem area: £ and € symbols. It is compatible for ASCII-range symbols, so try UTF-16 if you are aiming for perfect incompatibility. I don’t specify font-size but I Ctrl-roll my mousewheel on occasion to watch how the site changes at different font sizes.

So my default browser settings look like this. If I ever see these styles on a page, I know I’ve failed to specify something.

More outstanding issues are biting me with Internet Explorer 7, specifically these two well-known issues:

IE doesn’t render table row elements <tr> unless they are added to an explicit <tbody> element. (The HTML and XHTML DTDs allow <tbody> to be optional/implicit.)

IE doesn’t accept XHTML attribute names as XML DOM setAttribute() keys, requiring instead HTML DOM HTMLElement member variable names. (The HTML DOM is defined as subclassing the XML DOM without overriding these methods.)

I’m now using the Internet Explorer Developer Toolbar, which comprises a few of the features of Firefox’s Web Developer Toolbar and Firebug extensions. It’s really helpful in diagnosing these IE issues.

Looking through some of the unofficial bug lists for Internet Explorer, you start to get an idea of just how far behind Internet Explorer still is.

In Internet Explorer, both 6 and 7, automatically reloading an <iframe/> breaks the tab order and makes IE focus the address bar instead of the next field when you tab.

I wonder if anyone else has spotted this; it seems triflingly minor, but the client is so keen on tab order working correctly that they want me to rewrite the <iframe/> with AJAX polling.

As I’ve now started to look at how some of my sites work in IE7, I discover that the main thing that has gone wrong is that the hack where you prepend CSS selectors with * html is now disabled. Of course I could have found this out six months ago but frankly, learning the particular quirks of an as-yet-unreleased and sickeningly broken user agent is not something I am going to invest time in.

Obviously, this means that for any site that IE7 breaks, it is failing on the standards-compliant CSS. But equally, as I noted before, not as many sites break as was expected. So that’s pretty good news.

But for the sites that do break, and future sites in general, the situation is a mess. It’s now necessary to split IE7 styles into different, conditionally included files, either by selecting on UA (which is unreliable) or use a gut-wrenchingly sickening IE misfeature called “conditional comments”. IE6 rules need to be moved too, as IE7 will have significant common ground with IE6 and you don’t want to have to maintain two copied of any rule that is shared.

Having rules split between different files makes it harder to work with, because in CSS you need to literally compare selectors to work out the precedence. * html is much easier to work with because you can place your IE rule right next to your real browser rule, and easily cross-reference the differences. Or if you change the real-browser rule, you can also amend the IE rule at the same time. More annoyingly, if you already have a tidy collection of CSS stylesheets importing one another with the @import statement, you have to either collect your IE styles in one file, or duplicate the tree for IE. Neither is very maintainable. The @import statement is not very useful anyway though, because CSS’s precedence rules don’t allow CSS to be modularised in an elegant way.

In Microsoft’s defence, they are looking for a painless route to standards compliance that in all honestly does not exist. But I apportion the blame entirely to them, for two reasons. First, it was they who let the situation regarding standards compliance get so out of hand first; in effect, they are five years too late in starting to take this course of action. Secondly, bundling IE with Windows is one of the most devastatingly damaging things they have ever done. The cost to businesses worldwide could run into hundreds of millions, if not billions of dollars, and this money is not even paying Microsoft shareholders: it’s being flushed down the toilet. Web designers to some extent profit from it at the expense of other businesses, but even so, we would rather not have to do it because we would then simply be able to achieve more. We would probably charge more or less the same, but all sites would be stunningly beautiful with rich interactivity.

CSS, has its own problems, of course, but these would have been very hard to predict all that time ago when it was drawn up:

• Selector-based stylesheets cannot be refactored without reference to a schema for the source document.
• CSS cannot deal with varying capabilities across implementations.
• CSS cannot be modularised, because selectors can very easily collide and supercede each other, dependent on the way the selector is described rather than the structure of the module. For modularised HTML/CSS ‘components’, you really need to prevent styles being overriden unless explicitly requested.
• CSS units cannot be specified as an arithmetic operation on unknowns, such as ‘(1em-3px)’. This means dimensions measured in ems (useful for text) are incompatible with lengths measured in pixels (useful for images).
• CSS has insufficient control of vertical positioning. The basic operations available are “the vertical order is the same as the document order”, “x is at this vertical position”, and with a bit of creativity with floating blocks, “x follows all of these”, plus one modifier, “all my descendants lay out relative to me”.
• CSS doesn’t allow constants. This means that you have to repeat constants, say colour codes or border styles, and change them in more than one place.
• CSS has some bizarre quirks. For example, it doesn’t include padding in the width and height dimensions, so if you increase the padding, you have to decrease the width correspondingly. IE for years did the opposite, which is totally wrong but much more intuitive.
• CSS selectors are lacking tidy disjunctions and assertions, things that exist nicely in XPath. It’s possible to work around these, but not necessarily succinctly.

If anyone’s keeping score, I’ve found my first snippet of code which IE7 handles flawlessly but FF2 does not.

It’s code for creating multiple recipient email fields with Javascript, such that creates as many as necessary and keeps the last field spare. Specifically this code is for deleting fields, which happens when you backspace or delete from a field which you’ve already emptied. This is modelled on how Thunderbird/Icedove’s compose window behaves.

function autoCompleteContact(e)
{
    var event=(window.event)?window.event:e;
    var target=(window.event)?window.event.srcElement:e.target;

    //catch backspace or delete on an empty field as deleting the field
    if (target.value == '' && (e.keyCode == 8 || e.keyCode == 46))
    {
        //don't delete the last field if it's empty
        if (target == recips[recips.length -1])
            return;

        //find the container element for all recipient input fields
        var recips_container=document.getElementById('recipients');
        if (!recips_container) return;

        //Javascript doesn't seem to provide an array remove()
        //so do effectively newrecips=recips.remove(target) manually
        var newrecips=new Array;
        for (var i=0; i < recips.length; i++)
        {
            if (recips[i] != target)
                newrecips.push(recips[i]);
        }

        //Don't remove the last field
        if (newrecips.length > 0)
        {
            recips_container.removeChild(target);
            recips=newrecips;
        }

        //Focus the last field
        recips[recips.length-1].focus();
    }

    ...

IE7 does it perfectly, FF2’s layout breaks and it starts showing the contents of the INPUT elements in the wrong place.