Somewhere near the end of February I started working on my site again as a sort of therapy to get over my burn-out. I focused on the compatibility tables, which were in desperate need of an update; I hadn't published any major new versions since 2005. Besides, new browser versions are proliferating all over the place and people need to know what these browsers can and can’t do.

Today I can finally unveil my most ambitious update: the Events compatibility tables. All in all I think I spent two weeks’ of work on them; testing all common events not only in common situations, but also in unusual ones. A quick test of basic browser support for W3C and Microsoft events completed this series of tests.

continue reading

Just now I re-tested the CSS Object Model, both to accomodate IE8b1, FF3b4 and Safari 3.1, and because some of my earlier conclusions were wrong.

continue reading

In the past few days I've worked a bit on my compatibility tables. IE8b1 information has been added to the W3C DOM Core and HTML tables.

Furthermore I've taken the opportunity to present the CSS compatibility table better. I split the page into two tables, CSS 2.1 and CSS 3, and I added a few CSS tests. The table below shows the new tests and their browser compatibility.

Update: Added Safari 3.1 Windows information to the main CSS table only.

Finally, a question. Who knows of CSS 3 declarations that don't yet figure in the CSS table but are supported by at least one browser? (Nightlies don't count, but betas do.) Please leave a comment with declaration name and supporting browser. It'll help me get my testing priorities straight.

continue reading

A week ago W3C published the first working draft of the W3C CSSOM View specification (written by Anne van Kesteren), and I must say I'm very happy with it. Since I was testing stuff anyway I created a new compatibility table for most of the methods and properties specified in this document, and browser compatibility is already excellent.

That's no coincidence. This specification contains definitions for many properties (and a few methods) that browsers have already been supporting for ages (such as offsetWidth), and W3C has paid scrupulous attention to the current implementation. No more theorizing into the blue — just check what browsers do and describe it in the specification. Excellent idea.

continue reading

Rather to my surprise I started early on QuirksMode's spring cleaning. I removed about 50 pages that hadn't been updated since 2003 or 2004 and contained ancient and crappy scripts, or descriptions of old browser versions that nobody cares about today.

In addition I wrote a simple (but ponderous) script that finds out exactly which pages contain compatibility tables. I lost overview a few years ago, but this script reveals that there are currently 24 compatibility tables on my site. (There used to be 27, but I removed three.)

continue reading

I just finished updating the W3C DOM CSS compatibility table. With the previous version almost three years old, it was about time. In the past three years, Safari and Opera have started to seriously support the editing of style sheets, and the new table reflects that.

I decided not to study iCab any more. The new version 4 is rumoured to use the WebKit code engine, and a quick test of a few properties showed that this is likely correct. (Unfortunately the iCab site does not actually mention this fact, so I'm still not 100% certain that WebKit is really being used. On the other hand, 95% certainty is enough.)

The W3C DOM HTML Compatibility table has been updated, too. All in all browser differences are becoming markedly less; we're actually approaching the day on which there will be no (well, OK, few) incompatibilities left.

After more than two years I have resumed working on the DOM Compatibility tables. Just now I finished the Core table, which now includes information for IE 5.5-7, Firefox 2.0, Safari 3.0 Windows, Opera 9.5b, iCab 3.0 and Konqueror 3.5.7 . I removed IE 5.0 and IE Mac because these browsers aren't important any more.

I'm also in the process of creating new test pages which (I hope) will be easier to maintain than the old ones. I uploaded all new Core test pages, but I think that a few of the other tables refer to these, too. So I'm afraid that some test page links will be broken in the other tables; eventually I'll get around to fixing them.

I'm not sure exactly when I'll update the other tables, but I hope to get them finished before the end of this year.

Yesterday I finally got a new Linux machine with Konqueror 3.5.7 installed. (If that is not the latest version, please don't tell me. I don't want to know.) As a result I could finally start updating the compatibility tables, and as usual I started with the CSS ones.

While I was at it I upgraded the information to Firefox 2.0, Opera 9.5b and Safari 3.0 Windows. In general, compatibility has improved slightly.

A week ago I surprised myself by writing a simple drag and drop script in five minutes, without needing to debug even one single error. I enthousiastically started to write a QuirksMode page about it, until I realised that a mouse-only drag and drop script is distinctly old-fashioned these days.

Therefore I had to add keyboard compatibility, which took me five hours (mainly thanks to the confusing event situation.) Due to other pressing matters it took me five days to write the final version of the page.

It's finished now. So here's a drag and drop script in case you need it.

continue reading

I just wrote an Introduction to Ranges. Ideally this would be the start of an article series similar to my Event series. I'm not going to promise anything, though; I'm too thinly spread as it is, and I have no idea when I'll continue working on this series.

I've been working on a Range compatibility table, and even though it's not even remotely finished I'll officially unveil it now; chances are it'll take me quite a while to create proper test pages and test the dozens of methods and properties I haven't (yet) needed in my Range project.

I added a new page about importing the site navigation on all QuirksMode.org pages. The page is mostly about why I do what I do, and less about the how (besides, technically it's quite easy). The site navigation is a perfect example of what Jeremy calls Hijax.

I also put my trusty XMLHttpRequest functions online for future reference. No explanations on this page; I already treated them in section 10A of the book.

Just now I cut short my research to the two key properties keyCode and charCode. Of course I published the results, but I didn't go quite as far as I originally planned. The punctuation keys, especially, will remain a mystery for reasons explained on the page.

continue reading

Good news for my French readers: Christophe Bruggeman has taken the time and trouble to translate quite a few of my JavaScript pages into French. I quickly scanned his translations, and they seem to be adequate and accurate (though my French is a bit rusty, and I might overlook some details).

He copied my old JavaScript Table of Contents to his own server and started working from top to bottom. He isn't yet ready, but expecting him to deliver a full translation of everything on my site would be absurd: it's far too large, as I can testify.

Individual pages now contain links to the French translation, when available.

Thank you, Christophe, for your trouble. And remember, anyone can translate any page to any language, provided you keep to a few rules detailed on the copyright page.

As I think I said before, I am working on a redesign. In fact, I've been working on it for months, on and off, when the book permitted. Now that the book is ready I have more time to spend on it, and it's coming on nicely. (Oh, and before you ask, the frames will go. They've done their duty and I don't need them any more.)

Currently I'm going through all content pages and updating them; and since these updates go live the minute I finish them, I thought I'd give you an overview of what I'm doing.

continue reading

I'm in an ethical quandary. I've written a new browser detect script that's definitely better than the old one, but I hesitated for almost a day before publishing it. I'm afraid that amateur web developers will take the function and abuse it. Nonetheless, I decided to publish. I just hope I won't be sorry a year from now.

Here it is. It uses navigator.vendor wherever possible, because this property is much more reliable than the good old navigator.userAgent. I also ported the whole script to one neat object that can be dropped into any script.

continue reading

One of my fondest W3C DOM wishes is a getElementsByTagNames() method (note the plural "names") that returns elements with several tag names in the order they appear in the document. This is extremely useful in for instance my ToC script which needs all h3s and h4s in the order they appear in the source code.

When I discovered the compareDocumentPosition() method in Level 3 Core, I could finally write a custom script that works in most browsers.

Therefore I now proudly present my new getElementsByTagNames() script. It requires either sourceIndex or compareDocumentPosition to work fully, and since Safari 1.3.2 supports neither the script doesn't sort the elements in this browser.

iCab 3.0 is a surprisingly good, independent Mac (OS X and 9!) browser created by Alexander Clauss. It has good (though not perfect) CSS1 and DOM1 support, and to my surprise it even contains a speech browser. More than enough reason to recommend iCab to all Mac users that read my site, and to update my CSS compatibility table.

continue reading

I added a page about element dimensions, ie. the actual width and height of HTML elements. It contains a little test plus the inevitable compatibility table.

Quite unexpectedly I was able to add a site to my portfolio that had been shelved for nearly two years: the new website of the Concertgebouw in Amsterdam. In addition I'd like to draw attention to the new KLM site, in which I had a modest involvement and which contains an interesting CSS/JavaScript feature that I haven't yet seen anywhere else.

continue reading

It turns out that not all table elements are susceptible to opacity. The TR, especially, is obnoxious, and that's a pity because I really needed to set its opacity.

See the new Opacity setting page for the details and a test.

The new Firefox 1.5 (= Mozilla 1.8, as far as I understand) is the first one to support multi-column layouts. Of course I created a quick test page to study the effect.

Following the revelation of Safari's support for multiple background images I created a very simple page that tests this new feature. Safari indeed supports it; Explorer Mac shows the second background image, but not the first, and Explorer Windows, Mozilla and Opera don't show anything.

In order to keep our pages accessible to non-mouse users, we must use non-mouse events like focus or keydown in addition to mouse events like mouseover and click. I created the new Event pairs page and related tests to study this problem.

My conclusions are:

continue reading

There are two ways of changing the style of an element: changing the element's style properties or changing its className. I feel that the second option should be a Best Practice, since it honours the separation of behaviour and presentation, where a style change doesn't. After all, changing the style of an element in JavaScript means that your script file contains presentation information. That is not right: presentation instructions should go in the CSS file.

I wanted to make sure that changing the className doesn't lead to performance problems. My new style vs. className benchmark test clearly shows that it doesn't. In fact, changing the className is faster than changing the style in all browsers but Safari.

I'm very glad of this outcome, since I can now solemnly declare changing the className whenever you want to change the styles of an element a Best Practice, not only from a theoretical point of view, but also from a practical one.

I just updated the Quirks mode and strict mode page. I added a bit about the "almost strict mode" and test pages for font sizes in TDs.

I also found one new problem in the validation drive: most of my large compatibility tables liberally use the <wbr /> tag, which is invalid. I acknowledge the problem, I will note it in the validation texts, I will remove all other validation errors, but right now I'm not going to do anything more.

Like custom attributes, the <wbr /> tag requires some more thought. As my research shows, this tag is the least bad alternative for adding soft word breaks to pages; and the compatibility tables badly need soft word breaks.

I just finished a major update of the About page, which gives some information about myself and about QuirksMode.org.

Just now I implemented a 1500 characters maximum length for all comments on my QuirksBlog and Bug Report. Part of this reworking is a script that politely alerts the user when he exceeds this limit. I already discussed such a script in general terms in my JavaScript Triggers article on A List Apart, and of course I added a page that explains the script for all curious JavaScripters.

continue reading

I did the W3C DOM vs. innerHTML speed tests in Mozilla 1.75, Opera 8 and Safari 1.3. Little change in the first two browsers, rather more in Safari.

Two days ago Apple's team launched Safari 1.3, being part of the OS X.3.9 upgrade (once again named after a fierce predator, but I forget which one). Despite numerous bug fixes, the new release is marred by extremely serious onunload problems.

continue reading

Being cut off from the news hurts. I nearly missed the spectacular discovery that overflow: auto | hidden helps stretching up a container block to accomodate floating elements, something that until now could only be done through adding an HTML element.

I added a page about this technique, to record it for posterity and to emphasize that the technique works best with overflow: hidden because of an Explorer Mac problem, and also needs a defined width or height. This last point wasn't clearly mentioned in any article I read.

I did the W3C DOM tests in Mozilla 1.75 and Opera 8b and updated the tables. Mozilla doesn't show much progress (then again, it doesn't have to show much, it's already the browser that supports the W3C DOM best). Opera is on the move again.

continue reading

I just downloaded Opera 8b (from this location), and since I now have two new browsers I updated a few compatibility tables.

continue reading

Added two portfolio items: onzeCatering.nl and the DELA Uitvaartkompas (literally "Funerary Compass", but the name doesn't survive translation). Both are heavily form-oriented sites, and the first one uses a new idea for searching through large amounts of items which I hope to expand in future projects.

continue reading

According to my referers, many visitors find my site through Google while searching for "quirks mode". Naturally, this site has a rather high ranking on this query due to its name. Nonetheless, I hadn't yet added a page that explains the differences between Quirks and Strict Mode, which is probably what these visitors are searching for.

Therefore I finally added a page Quirks and Strict Mode which explains how to trigger them and some differences between these two modes.

Found out by accident that it's possible to style the text selected by the user in Mozilla and Safari.

Updated the wbr page with the ­ entity and a table outlining the resulting incompatibility soup.

Reader Michael McGrady was kind enough to send me a way of styling an input type="file", something that came in very handily in a project I was working on.

continue reading