Yesterday I talked about background-attachment and its confusing mobile compatibility patterns. Today I’ll talk about the ulterior motive I had for this retest: Conditional Rules support, which basically amounts to @supports.
New or updated pages on QuirksMode.org.
| Mobile CSS tables 2013 | Site |
Yesterday I talked about background-attachment and its confusing mobile compatibility patterns. Today I’ll talk about the ulterior motive I had for this retest: Conditional Rules support, which basically amounts to @supports.
Recently I spent WAY too much time on background-attachment. Even though it’s not a tremendously important CSS declaration, I don’t see any reason not to inflict my pain on you as well. Besides, I retested the CSS Backgrounds and Borders module in all browsers, and that should count for something.
Yesterday I retested the resize event on touchscreen devices. Where the 2013 tests mostly showed a chaotic jumble, right now it’s becoming more clear where the resize event is heading.
The QuirksMode.org DNS entry did not work for about 55 hours, from Sunday 27th around 15:00 to midnight on Wednesday 30th. This is by far the longest time my site has ever been offline since it started (under a different name) in 1998. I’m not happy about it, but the matter was beyond my control.
Just now I published the retests of the CSS Images and replaced content spec, which includes gradients. It was during these tests yesterday that I discovered Android screenshots aren’t always trustworthy, and meanwhile I’ve got enough information for an update.
Many people advised me to take a screenshot of the screenshot. I did, and it shows the original screenshot correctly instead of repeating the problem. So this avenue of research does not lead anywhere.
Today I published my tests of CSS transitions in the desktop and mobile browsers. I created the test cases ages ago, but interpreting the results turned out to be tricky.
And here’s the first table updated according to the new IE8-and-up rule. It’s past time I updated the DOM Compatibility tables, even though they’re not as exciting as they were ten years ago.
Just now I published the latest touch action tests. There are no nasty surprises, although IE remains idiosyncratic.
The most common touch action is the single tap. When that action occurs, browsers fire off a whole slew of events, mostly in order to remain backward compatible with older sites that only use mouse events. Although there are quite a few deviations from the “standard” order of these events, they don’t matter much. The average script won’t break because the mouseover event fires before the touchstart event. Still, I documented all deviations. Who knows when this will come in handy?
I also studied the double tap, pinch-zoom, and scroll actions and found that browsers generally fire those events you would expect. The contextmenu event, which could serve as a useful proxy for a touchhold actions, is badly supported.
I also updated the mobile events page with the new information gleaned from these tests.
Enjoy.
6 November 2013
I published my research on the orientationchange and resize events on mobile. If you’re expecting plenty of browser incompatibility fun you won’t be disappointed.
Recently I updated the CSS Text and CSS Selectors tables to my latest mobile browser test array. I found a new Android bug and a moment of sheer brilliance at Sony.
During the past several weeks I’ve been busy writing tests and performing them, and now the result is here: the W3C DOM Core compatibility tables for desktop and mobile browsers. I wrote 185 tests plus a test harness, and performed them in 57 browsers (17 desktop and 40 mobile), for a total of 10,545 tests done.
26 August 2013
After too many months of not doing any testing at all, I’m gearing up towards a major round of compatibility testing. Today, I’d like to ask you if you know DOM Core tests that I need to run.
Just now I uploaded the Units and Values desktop and mobile tables. They contain tests for many useful units, such as em, mm, vh, calc() and much more.
Oh boy, units and values.
Most compatibility patterns are actually quite simple: a browser does or does not support a given unit. There are a few exceptions, though.
Just now I published the Images and replaced contents tables. By far the most important feature are gradients, and in general they’re tolerably well supported.
Yesterday I published the CSS2 and Backgrounds & Borders mobile tables.
CSS2 is the table that contains all properties that were never redefined in any CSS3 module. It includes such vital properties as display, position, and overflow. Backgrounds & Borders, despite the name, is mostly about backgrounds and a few miscellaneous properties. I test border-radius, but the other border-related property, border-image, is WAY too complicated for me.
On mobile there are three declarations that merit particular attention: overflow: auto, position: fixed, and background-attachment. Despite their apparent differences they have one important aspect in common: there is now an element that should be scrolled and moved (or not scrolled or moved) separately from the page as a whole. That turns out to be a challenge for many mobile browsers.
28 February 2013
This week I published the CSS2 and Backgrounds & Borders tables for desktop only. I found no surprises. That concludes my publications for this week.
CSS2 is the table that contains all properties that were never redefined in any CSS3 module. It includes such vital properties as display, position, and overflow.
The mobile tables are delayed because I’m waiting for a bunch of Nokia phones to arrive. I’m not sure when I’ll get them, but I hope to be able to continue the mobile tests late next week. Maybe I’ll publish another desktop table in the mean time.
And when I publish the mobile tables, oh boy, the stories I can tell. overflow: auto and position: fixed on mobile, baby!
Just now I published the desktop and mobile tables for the CSS Text module and related ones — think italics, underline, and letter-spacing, but also hyphenation and text-shadow.
Over the weekend I finished the first two CSS compatibility tables new style: selectors and columns. These tests are almost complete (a few selectors are missing), and have been executed in 40 or so browsers, desktop and mobile.
In the past month I’ve researched CSS gradients, and I can finally present my findings. As usual, there was no source that gives clear, concise, accurate information about the three syntaxes and the four rendering engines, so I decided to write it myself.
Here is the inevitable compatibility table. Below I excerpt part of my introduction to gradients.
Yesterday and today I worked on the CSS Compatibility Tables and retested everything in the latest crop of browsers. There is some improvement, but also a lot of stagnation.
In December I held a QuirksMode reader survey on Urtak. It had 69 questions, and about 59,000 answers were given by about 1,100 respondents. A few weeks back I published part 1 of my survey. Here’s the next few findings.
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.
In December I held a QuirksMode reader survey on Urtak. It had 69 questions, and about 55,000 answers were given by about 1,100 respondents. Here’s a partial summary of the findings.
If you’re bored during the holidays I encourage you to take my poll; it’ll help me understand who my audience is. Please answer as many or few questions as you like; although I’d like to ask you to answer at least 15 to 20 or so.
OK, it’s time for an experiment. I created a reader poll about QuirksMode, your testing habits as a web developer, and your devices.
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.
At the end of December I turned off comments for the QuirksBlog. As far as I’m concerned they’ll stay turned off forever, except when I actually want to ask a question.
I didn’t take this decision, the decision took itself while I looked on musingly. The time has come, and I give up a little bit of good stuff in order to get rid of a serious annoyance as well as comment spam.
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!
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.
13 April 2009
Permalink
| in Conferences, Site
6 comments
(closed)
I’m pleased to announce that Google has graciously agreed to sponsor my work on my compatibility tables. We’ve entered an agreement for this year; after that we’ll see what happens.
Therefore, if you go to the compatibility tables now, you’ll see a tasteful little sponsor bar at the bottom of every page with a well-known logo in it.
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.
Almost exactly eight years ago, Jeffrey Zeldman wrote To Hell With Bad Browsers, in which he implored web developers to start ignoring Netscape 4 because its standard support sucked majorly. Yesterday several large Norwegian sites placed a warning against IE6 on their pages.
Web developers from all over the world are following this initiative with interest. To Hell With Bad Browsers is obviously in for a remake.
Just now I added an IE6 warning to QuirksMode.org (not that my visitors need any; this site probably has the most browser-savvy audience in the world). I also wrote an upgrade page that attempts to explain the problem and its solution to end users.
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.
1 August 2008
Permalink
| in Apple, Coding techniques, Content, Touch events
14 comments
(closed)
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.
Lately, my Technorati page shows more and more odd links to my site on pages like this. The "Online Casinos News Life Luxury Reports" link at the bottom links to this site.
Can anyone explain why spammers think this is a good idea? I don't mind having a bit of extra traffic, but for the life of me I can't understand why spammers want this, too. This site is not an Online Casinos News Life Luxury Reports, after all.
Maybe I can make a lot of money with this. If people want to gamble online, I'm more than willing to accept their money. Maybe I should write a Texas Hold-em script. In fact, I think I did exactly that a few years back. Let's see if I can find the script.
Any clarification is welcome.
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.
Recently Google released the very handy Webmaster Tools app, with which you can see how many links to pages there are, plus quite a few other goodies. This allowed me to create a Top Ten list of the most popular pages on this site, as measured by incoming links.
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.
I implemented a Preferences page on which you can indicate your preferences for several QuirksMode.org features.
I promised to go into more detail about the redesign; here's the first installment in which I talk about some aspects of the CSS.
As you can see on this page, the QuirksMode.org redesign has gone live. It's not quite ready yet; right now I estimate that it's about 95% finished, but the remaining 5% will take a lot of time to implement, and therefore I decided to go live now instead of waiting another few weeks.
30 August 2006
Permalink
| in Conferences, Redesign
8 comments
(closed)
Although I'm almost ready with the promised redesign of QuirksMode.org, I'm nonetheless going to postpone it. There are two reasons:
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.
From today, Friday 28 July, until next Wednesday, 2 August, I'll be in the countryside where there is no Internet. This site is therefore closed in that period; anything that needs my personal intervention will have to wait until next Thursday.
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.
The commenting system has been restored on QuirksBlog and the Bug Report thanks to Joost Diepenmaat. I closed them off for this entry (I don't see much value in comments about the commenting system), but I have turned them on on my book announcement page so that you can congratulate me.
Update: The contact form has been restored, too. I don't promise to answer quickly, but I will answer eventually.
Right now chaos rules on QuirksMode.org, and I'd like to apologize for it. To name but a few things: comments are disabled, I'm at least one month behind with Bug Report entries, and the contact form has been closed down for months.
First the good news: this will change. I want to go back to the situation where QuirksMode is a normal, well maintained blog/resource site. Then the bad news: it might be another month before something actually happens.
Nakedness sweeps the Web thanks to Dustin Diaz. I myself definitely decline to go without a modest bit of garment, so the navigation and logo frames will remain styled, as well as the content pages. In order to support the Cause I did disable my homepage's style sheets.
The idea was to catch those bits of markup that don't degrade too well without CSS, and as you can see there are a few on my homepage. These will be fixed in the continuously upcoming redesign.
Update: styles restored. I felt too naked without them.
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.
Well, I'm back from all my holidays. My throat problems are mostly over, although I still don't have hot water in my house. Even so I'll start working again tomorrow, and I've spent a large part of the weekend in catching up on QuirksMode.org related matters.
Thursday night I returned from a relaxing holiday in Greece. I'd planned to do some work on Friday, before leaving for the countryside again on Monday.
Unfortunately Friday was a rather disastrous day. My central heating unit, which also provides my hot water, suddenly began expelling flames when I turned it on, and a hurriedly fetched mechanic told me it cannot be used any more due to the danger of carbon monoxide poisoning. No hot water, no showers, no shave.
Then the dirty, nearly windless air prevailing here in Amsterdam started working on my nose and throat, and right now I'm taking tea with honey, orange juice, and more such medicines in an attempt to stave off a cold.
All this means that I'm going to extend my holiday silence considerably. I'm disastrously behind on all jobs except for comment approval, but that's not going to change in the near future. No replies to the 200 or so mails still waiting for me.
If you need me, sorry, you'll have to have more patience; my unavailability has been extended for at least another week.
Today I leave for a two week holiday in Greece. As usual I won't touch a computer while I'm over there, so everything that requires my personal intervention will have to wait until at least Friday 19 August.
I'll be only patchily available during the rest of August, and I don't take any new job, no matter how small, paid or volunteer, before 5 September.
See you all later.
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.
Regular visitors may have noticed that my homepage has changed a bit in the past few days. The old one was too cluttered and contained too much information. Besides, it didn't have any space left for the new Elsewhere on the 'Net feature. So I significantly revised my main blog pages and the content they deliver to the homepage.
Like my recently started validation drive, the homepage restructuring is just one aspect of the full-fledged QuirksMode.org redesign I'm planning. Besides, the redesign set me thinking about separation of structue and content.
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.
27 June 2005
Permalink
| in Redesign, Validation drive
57 comments
(closed)
A few readers may have spotted the delicate gray text that appeared at the very bottom of my homepage last Saturday. It says "Valid XHTML 1.0". These few readers may even have drawn the correct conclusion: QuirksMode has started moving in the direction of valid XHTML 1.0 Transitional. Note: "moving in the direction of". For reasons I explain below this site will never be 100% valid, but I have decided to make an effort and see what happens next.
Besides, my content pages are long, long overdue for a cleanup, and I'm going to combine this sanitation with the switch to XHTML. Unfortunately the very first static page I edited gave raise to a fundamental question that I don't have an answer to. Therefore I submit one aspect of the maintenance of QuirksMode.org to a reader vote.
Today I leave for London to attend the @media 2005 conference. I will return home on Sunday. During that time this site is effectively closed: anything that needs my personal approval, as well as any mails I have to answer, will have to wait until next week.
Hope to see some of you at the conference, or maybe at Saturday's JavaScript get-together.
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.
Right now I have a large writing job (not a book, unfortunately), and it takes rather more time that I thought it would. Since I'm working on it almost every waking hour, I'm getting a bit tired of writing. That's the reason I'm not posting any blog items right now, and I'm afraid this situation will continue throughout March.
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.
I'm getting increasingly mystified by comments like this:
<a href="http://ssszcwyqwer.com/">oosgqx</a> poiuyt http://ghjklkpgaiequgo/
What is the point of these comments? Are they an extremely subtle sort of spam? If so, what's the purpose? The domain ssszcwyqwer.com doesn't exist, so generating traffic or a high search engine ranking for it doesn't make sense.
I understand spammers. I understand people who leave stupid comments. I don't understand people who leave incomprehensible comments.
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.
I thought I'd give you the current visitor stats for this site, gathered through the Reinvigorate system. Of course these figures are only valid for this site, and should never under any circumstance be used for any other site.
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.
Aside from the new domain name, the main reason I embarked on the QuirksMode.org project was that my old sites were becoming a nightmare to maintain and a mess to navigate. Rigorous information restructuring solved these problems nicely, but now that I've added two blogs to my site the problem is returning. Besides, I'm having difficulties making Movable Type do what I want.
As I promised a month ago, I have finally added the QuirksBlog to my site. It'll serve as my personal blog, not only for announcing new pages on this site and articles on other sites, but also for commenting on the web developers' world in general. In addition to this proud announcement, I'd like to give a general overview of where QuirksMode.org currently stands.
As I promised almost a month ago, I now proudly present the Bug Report system. Started as a simple sidebar on this page, the system aims to gather, explain and discuss any CSS or JavaScript browser bug.
I almost, but not quite, forgot that today is this site's first anniversary. Exactly one year ago I was very glad to finally publish it and put an end to an increasingly interminable development phase.
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.
New feature on my site: the Bug Report.
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.
I'm back in business, after a restful and relaxing holiday in Greece, a major network breakdown, a long weekend in the countryside, and lots of sipping alcoholic beverages on sunny terraces.
I've even done a few minor updates today:
createAttribute(). See the
W3C DOM Core tables - Attributes under createAttribute().document.createStyleSheet("javascript:'div{margin:0px;}'"); syntax
is the correct one for Explorer Windows. I didn't test this one.This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Monthlies: