New or updated pages on QuirksMode.org.
I have retested the support for the new input types (<input type="number"> and such) in the desktop and mobile browsers.
All in all support has increased slightly since the last time I tested them, although Safari desktop, Chrome, and BlackBerry have seen some decline. Safari and Chrome have mainly done away with badly or buggily implemented types — it’s clear they’re rewriting significant parts of this module.
Last week I did some research on the resize event on mobile and tablet browsers. Executive summary: it’s a mess. And the best browser, surprisingly, is Samsung’s Dolfin.
My conclusions are, summarised:
Back in June I requested donations to pay for the time I needed to update the desktop browser compatibility tables. The community responded overwhelmingly. Today I present the first installment of my side of the promise: the event compatibility tables have been updated.
Donations are still very welcome, and now you know that this is the sort of thing your money is going to be used for.
I’ve written a Conference Organiser’s Handbook in which I share some of my experiences with organising conferences, and offer beginners the solid, practical advice that they need. It’s free; do whatever you like with it (except for copying it entirely to another URL).
Last week I updated the Mobile WebKit comparison table with four browsers: Safari 4,2 (on iPad), Android 3 (on Samsung and Motorola tablets), the BlackBerry PlayBook browser, and the WeTab browser.
The WhatTab? The WeTab. You probably haven’t heard of it, unless you’re in Germany. Bear with me.
On Monday and Tuesday I did some heavy-duty research into the new HTML5 input types and attributes, and I published a desktop and a mobile compatibility table.
Let’s start with some good news. The readonly attribute, which makes a form field read-only, is supported by all browsers, both mobile and desktop. Even IE9. Cool, huh?
The rest of the input story is worse. Much worse. Let’s put it like this: Obigo WebKit, a browser nobody but me has ever heard of, outperforms iPhone and Android.
Yesterday I received a Palm Pre 2, which, after some initial difficulties, I got to work. I combined it with the HTC Smart that I had received earlier, made sure the latest updates to Opera Mobile and Firefox were installed on my trusty Nexus One, and did some testing.
In recent weeks Firefox 4 beta 1 and Opera 10.60 were released, and I could also put my hands on a working Chrome 4. I added all these browsers to the compatibility tables, which are now all updated, except for the Events one.
29 June 2010
Well, I’ve revised the DOM CSS and the DOM CSS OM tables, too, and IE9 continues its march. It supports the standards!
28 June 2010
In the past few days I’ve been revising the CSS compatibility table with information about the latest crop of browsers. There’s no doubt about it: this is IE9’s show. It just supports nearly everything. No hassle, no buts.
Besides, CSS3 selectors are now fully supported by all browsers but one. And that one browser is not IE. It’s, curiously, Opera.
24 June 2010
I just finished my CSS3 background tests, and I’m happy to report that all browsers but one now support the module very well. Also, I’m pleased to report that all browser vendors but one have ditched the vendor prefixes and now support the pure, correct CSS3 properties.
All browsers but one. If you guess that that one browser is IE, you’ve guessed wrong. It’s Firefox.
I have updated the WebKit comparison table with data from Safari 5, Chrome 5, and Android 2.1. Improvements throughout!
Back in November I started complicated research into measuring the widths and heights of various interesting elements in mobile browsers. This research kept me occupied for months and months; and frankly I became a bit afraid of it because the subject is so complicated.
Besides, when I re-did some tests in March I pretty quickly figured out I’d made some nasty mistakes in my original tests. Back to the drawing board.
However, after a review round by some browser vendors and some rewriting it’s done now.
Today I present
A tale of two viewports — part one.
I explain CSS vs. device pixels, the viewport, several interesting JavaScript properties,
and the media queries width and device-width.
This piece is about the desktop browsers, because the mobile story is much easier to follow if you know exactly what happens on desktop. Later on I’ll publish part two, which is exclusively about mobile.
Well, a new year has started, and it’s tradition to give an overview of where you’re standing. So here’s mine.
As longtime readers may remember, I was totally burned out at the end of both 2007 and 2008. I’m happy to report that that trend has been broken; although I was glad to have a little holiday at the end of 2009, I returned to work without noticeable problems. So that’s good.
However, I have decided that certain aspects of my professional life are in need of a change; notably my public speaking and my compatibility tables.
Last week I’ve done the DOM Core tests in new browsers: IE8 final (in both IE8 and IE7 mode), Firefox 3.5b4, Safari 4.0, Chrome 1 and 2, and Opera 10a. I found no surprises.
After that I decided to continue with mobile browsers, of which I have 15 lying around on my desk. Unfortunately I could not test IE Mobile (old) because it supports only inline event handlers, Skyfire because it does not allow you to remove alerts, and the Opera runtime in the Vodafone widget manager for terrifyingly complicated reasons I still have to describe properly.
Still I managed to test the other twelve and found a few surprises.
In the past two months or so I’ve done a lot of compatibility testing, and I thought I’d give you an update.
I’m increasingly posting my real-time raw test results and announcing new versions of tables on Twitter; so if you’re interested in that data you can follow me.
3 February 2009
Permalink
| in Browser Wars, Chrome, Content, IE, Safari
35 comments
(closed)
There’s some browser news to discuss, and I thought I’d bundle it all in one entry. Maybe I’ll even do this more often; it seems a good feature for this blog. But I’m not promising anything!
This weekend I started testing some new browsers, and meanwhile I’ve updated the HTML and CSS tables. There were no surprises. I’m continuing with the Events tables, but they’re so large and sometimes so complicated that I’m not sure when I’ll finish.
In this installment we’ll take a look at IE8RC1 and some reactions to it, Safari 3.2, Chrome’s lack of a “Check for updates automatically” feature and Opera’s antitrust complaint.
I’ve updated the CSS Compatibility Table as the first step in a complete update of all Tables. Frankly, this was one of the more boring updates I’ve ever done.
I tested four browsers:
All in all a meager result for many hours of work. I suppose I should be extatic about how little browsers do wrong these days, but it makes my work considerably more boring.
Further updates are planned, but I’m not going to give a specific timeline for them; we’ll see how it goes.
Yesterday I walked into the local phone store because the “Temporarily Unavailable” sign had been removed from their “Get your iPhone here” poster. To my utter surprise they had six (6!) entire iPhones for sale, and no, there was no waiting list. I walked back home with a shiny new gadget, impatient to start testing it.
Meanwhile I’ve done some tests; now it’s time for a report.
Before we continue, let’s get the bad CSS news out of the way: Safari on the iPhone does not support position: fixed. Certain Other Browsers were ridiculed for this lack; Safari won’t be.
I’ve updated the CSS Table, the Core Table and the Events Table. In this entry I’m going to talk about JavaScript events on the iPhone. They’re — interesting.
This is worth a formal note: getElementsByClassName() is now natively supported by the most recent versions of Firefox, Safari, and Opera. I added it to the compatibility tables. Obviously, as long as Certain Other Browsers do not support it we can't yet really use it everywhere, but it's a ray of hope.
And you wrote your custom getElementsByClassName() function to keep an eye on native implementations, didn't you?
function getElementsByClassName(node,classname) {
if (node.getElementsByClassName)
return node.getElementsByClassName(classname);
else {
// your custom function
}
}
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.
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.
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.
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.
26 February 2008
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.)
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.)
27 November 2007
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.
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.
6 February 2007
Permalink
| in Content, Redesign, XMLHTTP
4 comments
(closed)
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.
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.
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.
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.
24 January 2006
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.
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.
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:
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.
29 June 2005
<wbr />
Permalink
| in Content, Validation drive
10 comments
(closed)
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.
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.
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.
24 January 2005
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.
10 January 2005
I just downloaded Opera 8b (from this location), and since I now have two new browsers I updated a few compatibility tables.
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.
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.
This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer.
You can also follow
him on Twitter.
Your donation to maintain this site will be gratefully received.
Upcoming speaking gigs:
Categories:
Monthlies: