I'm writing a CSS book

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

contact

New CSS tests - CSS2 and Backgrounds & Borders

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.

background-attachment

background-attachment has three values; see also the test page in any desktop browser but Firefox:

• scroll, the default: the image scrolls with the page. (And no, the name has never made any sense.)
• local: the image scrolls with the element. This only makes sense on elements with overflow: auto.
• fixed: the image is positioned relative to the page as a whole and the element serves as a “window” on the image. Thus scrolling makes another part of the image appear.

Now on mobile it turns out that most browsers support either local or fixed, but not both. There are two exceptions: Symbian and Tizen, which support both, but both have bugs in one or the other.

Safari, Chrome, BlackBerry, and IE opt for local, while Android, Firefox, and most miscellaneous Webkits support fixed.I’m not totally sure why they made a choice instead of supporting both, but the data is clear.

Anyway, only Android 4.1 and higher and One support fixed perfectly, while perfect support for local is more widespread but by no means universal.

background-attachment will remain a pain point for mobile browsers for some time to come.

overflow: auto

If an element has overflow: auto and its contents are longer than the element is high, the element becomes scrollable. On mobile, there is the question of whether the browser supports the scrolling of such elements at all.

It turns out the answer is Yes, with exceptions Opera Mobile, Android 2, and miscellaneous WebKit-based browsers (as well as, of course, the proxy browsers Opera Mini and Nokia Xpress, which do not allow client-side manipulation and thus don’t support scrolling).

Not supporting scrolling of elements with overflow: auto is a design choice. However, in in that case you must make sure that the user can access the contents of the elements in another way. And it’s here that things go wrong: only Opera Mobile does so. The other browsers do not give their users the chance to read overflowing content.

As to Opera Mobile, it decided to stretch up elements with overflow: auto for as much as is necessary to show the content anyway. That’s not proper support of overflow: auto, but it’s a lot better than the alternative.

All other browsers support scrolling of overflowing elements, and is is always done by one-finger scrolling. The only exception I ever saw to this rule was old iOS versions, but since at least 5 (4?) Apple allows one-finger scrolling, too, instead of the curious two-finger scrolling it used before.

Speaking of Apple, it introduced -webkit-overflow-scrolling: touch in iOS5 in order to improve the UX of this scrolling. Of course I tested this property, too, and found that apart from iOS only BlackBerry 10 supports it.

Still, the question is not who supports this property, but why Safari’s and BB10’s default scrolling is so lousy that they need a special property to correct it. The answer lies in performance and memory: if every single overflowing element would have kinetic scrolling, it could bring the browser down. So that’s why they only allow kinetic scrolling after an explicit request from the web developer.

If this theory is correct, other browsers will slowly move from default kinetic scrolling to the property. Still, one wonders what happens when web developers start giving every single overflowing element on their sites overflow-scrolling. The problem may resurface, although we can now say it’s the web developers’ fault.

position: fixed

I already talked a lot about position: fixed, and it isn’t going to end any time soon. This time the news is good: a consensus has been reached on what position: fixed means on mobile, and Safari, Android 3+, Chrome, Opera Mobile 14 (the WebKit-based one), UC, Dolphin, One, Tizen, and Firefox support it correctly.

The position and dimensions of a fixed layer should be calculated relative to the visual viewport. Thus, a height of 20% means 20% of the visual viewport, and that means it changes when the user zooms. If you don’t understand what I mean, the best advice I can give you is to try the test page in one of the supporting browsers I mentioned above.

The position: fixed saga isn’t done yet, but it’s clear now that it’s going to end with all browsers supporting this system.