I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

New CSS tests - selectors and columns

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.

New CSS tests

This is the first release of my new CSS tests. When I secured sponsorships from Microsoft, Google, BlackBerry, and Nokia I promised them to extend my testing considerably, and also to share my findings with WebPlatform. That sharing hasn’t happened yet, but the extension of my tests is in full swing.

I spent most of December writing new tests for many CSS modules. The going was slow; sometimes it’s not easy to figure out what the spec means, especially not if there are competing implementations. When January arrived and I had to return to conference organising, I had written about half of the planned tests.

Time was running out. I had a choice: either continue writing tests, and accept that they’d only be published from July on or so, or actually run the tests in the target browsers and publish quicker, but incomplete, results. I chose the latter.

So during the weekend I made the first changes to the CSS directory. The new CSS main page contains links to my new-style tests, as well as an index of all selectors, methods, properties, units, and values that I tested. The old main page will continue to exist for a while, since it contains material not yet treated in the new tests.

What you see there now is roughly one fifth of the tests I’ve written — and the tests I’ve written comprise slightly more than half of the tests needed. I aim to continue testing and publishing until I run out of tests. My plan is to publish one module per week, but I’m not sure if I’m going to make that. Therefore I published two this week.

We’ll see what happens next. I want to get something done, so chances are I’ll proceed fairly quickly. But you never know. Conference organising, and the fact that I’m in the process of buying a house, may interfere.

The remainder of this article will discuss some of my discoveries in the current round of testing.

Selectors

The selectors that caused me the most trouble were the dynamic UI State ones — :in-range/:out-of-range, :valid/:invalid, and especially :indeterminate. These selectors are for form fields that have certain restrictions, such as a range of numbers or a pattern.

The current crop of selectors comes from XForms, and that really says enough. Needless complexity for the sake of needless complexity.

In theory they’re a great idea; in practice they are hard to use and test. :indeterminate is the worst: it only works on radios (Opera, Firefox) and selects (Firefox) where no option has been checked/selected yet.

Now it’s hard to devise styles that work on radios and selects. Giving a width to radios leads to results on some browsers, but maybe other browsers support :indeterminate but not widths on radios. I wouldn’t know, not with 12 mobile WebKits (excluding versions) floating around. Besides, if you can’t style a radio, using :indeterminate makes no sense.

And what about a form field with a pattern but no content? Is it :valid or :invalid? I’d say it’s neither: it’s also :indeterminate. You don’t know yet if it’s valid or invalid. The spec doesn’t allow for that, though.

As far as I’m concerned there should be three dynamic UI state selectors: :valid, :invalid and :indeterminate. The first means: satisfies all rules of the input field; the second means: does not satisfy all rules; the third: unknown as yet. They should work in all circumstances where an input field has a rule. That rule can be a pattern, or a number for the number type (possibly with a range), any content for a required field etc. This would solve the current messiness.

Then there’s the case of :visited. It was discovered ages ago that this pseudo-class has a security issue: a malicious site owner can read out his links’ styles and thus find out which sites you visited. The problem was solved — but not in all browsers. Opera still has the security hole, as do a few elderly mobile WebKits, of which Android 2 is the most important.

Finally, :hover on touchscreens remains a problem. Most browsers apply the hover styles when the user touches an element, and remove them when he touches another element, but BlackBerry follows the desktop pattern and removes them when the user stops touching the screen, while Safari iOS and Opera Mini only allow links, form fields, and elements with event handlers to be touched and thus to show the hover styles. Not ideal.

Columns

Columns are supported perfectly by Opera, and almost perfectly by IE10. Firefox doesn’t support a bunch of stuff, and WebKit (as well as IE10) makes an ungodly mess of applying or avoiding breaks. You can see what I mean on the new CSS main page. The index list at the bottom uses columns, but of course I don’t want a column break to occur in one entry. Too bad: only Opera does as I tell it. The rest of the browsers doesn’t care in various ways.

Then the weirdest compatibility pattern I ever encountered in my entire career: column-span. The most modern WebKits (535+) do not support it, 534 mostly (but not entirely) does, 533 mostly not (but not entirely). I have no clue what’s going on. I hope I’ll be able to explain it later, when I’ve acquired more wisdom.

Oh, and the HTC Android 4.1.1 does not support it, while the Samsung Android 4.0.3 does. Both use WebKit 534. You see?

That’s it for now; more tests later.