CSS2 declarations

Back to the index.

CSS2 specification.

Here are those CSS2 declarations that have never been included in a CSS3 module. They include such basics as display, position, and overflow.

This is the mobile table. See also the desktop table.

Last major update on 5 March 2013.

Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10
border-collapse
 Yes Yes Yes Yes Yes Yes Yes
border-spacing
 Yes Yes Yes Yes Yes Yes Yes
caption-side
 Yes Yes Yes Yes Yes Yes Yes
  • Gecko-based browsers also support left and right.
Columns (tables)
 Yes Yes Yes Yes Incomplete Yes Yes Yes
  • When setting a border on a multicolumn, the WebKit-based browsers do not create a middle border, but the other browsers do. See page for screenshots.
  • Xpress does not apply borders, except for the middle one.
counters
To assign counters to headings or other elements 		Yes Yes Yes Yes Yes Yes Yes
Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10
display
 Yes Yes Yes Yes Almost Yes Yes Yes Almost
  • Xpress and Firefox do not support run-in.
empty-cells
 Yes Yes Yes Yes Yes Yes Yes
min/max-width/height
 Yes Yes Yes Yes Yes Yes Incomplete Yes Yes
  • One fails the min-width test: it doesn’t stretch the box beyond the regular width.
quotes
 Yes No Yes Yes No Yes Yes No Yes No Yes Yes
table-layout
 Yes Yes Yes Yes Yes Yes Yes
visibility: collapse
 No No Yes No No Yes No No Yes
widows and orphans
 No No No Sometimes Widows No No No Untestable Yes No
  • Opera Mobile 12 supports it on Android (12.10) but not on Symbian (12.00). Not sure if this is a version thing or an OS thing.
  • Seems Opera Mobile 14 supports widows but not orphans.
Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10

position

Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10
position: other values
static, relative, and absolute 		Yes Yes Yes Yes Yes Yes Yes
  • WebKit browsers have a minor bug; see page.
position: fixed basic support
Does the browser try to create a fixed layer at all, or is it just an absolutely positioned layer? 		Yes No Yes No Yes Yes No Yes Yes No Yes No Yes

Browsers that don’t support fixed treat it the same as absolute.

A Yes here says nothing about implementation quality; only that the browser made an effort.
position of fixed layer
Should be coordinates relative to the visual viewport 		Incomplete - Yes - Layout Yes Vertical - bottom weird Yes - Yes - Buggy Yes
  • Safari keeps the layers in position at low zoom levels, but starts to move the fixed layers at a certain point; though always slower than the actual scroll. On the iPhone iOS6 the point is around 400% zoom; on the iPad iOS5 it’s around 100% zoom. I don’t know if this is a difference between iOS 5 and 6 or between iPad and iPhone.
  • Opera Mobile mostly positions the layers relative to the layout viewport, but sometimes jumps to another horizontal position. Never to another vertical position, though.
  • On BlackBerry the vertical position is correct, while the horizontal one is relative to the layout viewport.
  • Symbian correctly positions the first layer (top/left: 50px), but I don’t understand the placement of the second layer.
  • IE10 scrolls the top-placed layer with the page when scrolling up, and the bottom-placed one when scrolling down. When scrolling the other way they more-or-less stay in the correct position.
Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10
dimensions of fixed layer
Percentual width and height should be relative to the current dimensions of the visual viewport 		Yes - Yes - Static Yes Vertical - widths weird Yes - Yes - Static Yes
Static
Dimensions determined relative to the initial visual viewport (at “zoom 100%” and are not changed. Text wraps when necessary.
  • On BlackBerry the vertical dimensions are correct, while the horizontal ones are relative to the layout viewport.
  • Symbian uses the correct heights, but I don’t understand where its widths come from.
behaviour of fixed layer
Should change width and position immediately and fluidly on scroll or move 		Yes - Almost Jump - Absolute Yes Yes - Awful Yes - Yes bug Yes - Wrong Yes
Yes
No browser does a perfectly smooth change. The layers grow and shrink with zooming (i.e. keep the same dimensions in CSS pixels), but snap to the right dimensions when zooming stops.
  • Samsung Android 4.0.3 and One have an extra bug where the right dimensions are only applied after an extra scroll.
  • Chrome does it right, but the layers may disappear entirely during zooming.
  • Opera Mobile mostly treats the layer as an absolutely positioned one, except in random circumstances.
  • Symbian’s behaviour must be seen in order to be believed. It starts from Jumpy, but then reduplicates layers, hides them, and generally behaves very badly.
  • IE10’s layers move slightly on every scroll and are then repositioned.
position: fixed final verdict
 Almost No Yes Almost No Buggy Yes Incorrect No Very buggy Yes No Yes Incomplete Yes No Buggy Yes

See the entries above for exactly what’s wrong with the various implementations.
Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10

overflow

overflow: auto is complicated on mobile because even when content is hidden from the user there must be some mechanism to reveal that content. Without that, the browser’s overflow implementation is severely compromised.

All browsers that allw the content to be scrolled, do so by the one-finger scroll that’s also used for scrolling the entire document. This gives birth to the tricky topic of scroll quality: is the browser’s default scroll good enough? If not, an extra property is needed.

Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10
overflow: visible and hidden
 Yes Yes Buggy Yes Yes Yes Buggy Yes Yes

Scrolling hidden should be impossible. Fortunately it is in all browsers.

  • In Opera Mobile the behaviour of visible and hidden depends on whether the text is wrapped because the user zooms. If the text is wrapped, the test element expands to contain all content.
  • Opera Mini expands all elements with visible, except on iOS.
  • In UC, changing the overflow dynamically causes the box to expand until it fits all the content.
Scrolling
of random elements with a one-finger touch 		Yes No Yes No Yes Yes No Yes No Yes Yes

Does the browser support scrolling of elements with overflow: auto? If not it should make sure the content of the overflowed element is otherwise accessible.

One-finger scrolling is supported by all browsers that support scrolling.
overflow: auto
Also scroll, but that value is useless 		Yes Buggy Yes Buggy Alternative Yes Yes Buggy Yes Buggy Yes Yes
Buggy
Browser hides part of the content on overflow: auto but doesn’t give the user any way of reading it. This is a hideous sin.
  • Opera Mobile 12 always expands the element to contain all content when overflow is auto or scroll. This is the least bad solution if your browser does not allow touch-scrolling of arbitrary elements.
  • In UC, changing the overflow dynamically causes the box to expand until it fits all the content.

Compare Opera overflow with HTC Android (text adjustment)

Default scrolling quality
 Bad - Good - Good Bad Good Bad - Bad - Good Bad Good

Whether the browsers’ default scrolling of elements with overflow: auto is any good. Excludes browsers that don’t allow scrolling.

The point of this entry is that only those browsers that have bad default scrolling quality need -webkit-overflow-scrolling: touch.
overflow-scrolling
Apple invention for emulating native scrolling. Prefixed 		Yes - No - Almost - No - No -
  • BB10 has hiccups.
Selector iOS Android Opera BlackBerry Nokia UC NetFront Dolphin One Tizen IE Firefox
5 6 2 3 4 Chr Mini Mob 12 Mob 14 6 7 PB 10 Xpress MeeGo Anna Belle 9 10

Tested browsers

Mobile browser test array 1.0.3; March 2013

iOS 5
WebKit 534
Default browser on iPad 2 with iOS 5.1.1
iOS 6
WebKit 536
Default browser on iPhone 4S with iOS 6.1.1
Android 2
WebKit 533
Default browser on HTC Legend, Android 2.2
Default browser on LG Optimus something, Android 2.2
Default browser on Sony Xperia S, Android 2.3.7
Android 3
WebKit 534
Default browser on Packard Bell tablet, Android 3.2.1
Android 4
WebKit 534
Default browser on HTC One X, Android 4.1.1
Default browser on Samsung Galaxy Note I, Android 4.0.3
Chrome
WebKit 535
18 on Nexus 7, Android 4.2.1
Opera Mini
Presto
Proxy browser
7.5 on Samsung Galaxy Note I, Android 4.0.3
7.1 on BlackBerry 9800 (OS6)
7.1 on Nokia E71 (SymbianOS/9.2)
7.0.5 on iPad 2, iOS 5.1.1
Opera Mobile 12
Presto
12.10 on HTC One X, Android 4.1.1
12.00 on Nokia E7, Symbian Anna
Opera Mobile 14
WebKit 537
14.0 on Sony Xperia S, Android 2.3.7
BlackBerry 6
WebKit 534
Default browser on BB Torch 9800 (OS6)
BlackBerry 7
WebKit 534
Default browser on BB Torch 9810 (OS7)
BlackBerry PB
WebKit 536
Default browser on PlayBook with OS 2.1.0
BlackBerry 10
WebKit 537
Default browser on Dev Alpha A device with OS 10.0.9
Xpress
Gecko
Proxy browser
2.3 on the Nokia Asha 311, S40.
This browser used to be called Ovi. Nokia developed it because it saw how succesful Opera was on Nokia’s own devices.
MeeGo
WebKit 534
Default browser on Nokia N950, MeeGo Harmattan 1.2
Originally slated as Symbian’s successor, MeeGo was ousted in favour of Windows Phone. Some devices were sold, however, and a Finnish company is trying to re-start MeeGo under the name Sailfish. And who knows? Ex-Nokia people have good operator contacts.
Anna
WebKit 533
Default browser on Nokia E7, Symbian Anna
The next-to-last Symbian build. I don’t think it was the prime Symbian build for long; it was replaced by Belle fairly soon. But it’ll be in some people’s pockets.
Belle
WebKit 535
Default browser on Nokia PureView 808, Symbian Belle SP2
The most recent Symbian build.
UC
WebKit 533
UC 8.6.1 on Packard Bell tablet, Android 3.2.1.
The largest Chinese browser. I’m testing the full variant, not the proxy.
NetFront
WebKit 530
NetFront Life 2.3.1 on Sony Xperia S, Android 2.3.7
NetFront, by the Japanese Access company, used to be big on proprietary Samsung and Sony Ericsson systems. It is now switching to WebKit from their own rendering engine, and to the gaming device and TV markets.
Dolphin
WebKit 534
Beta 1.3.1 on Samsung Galaxy Note I, Android 4.0.3.
Independent full browser for Android. The non-beta is a skin over the Android default browser. The beta uses their own WebKit port.
One
WebKit 534
3.5.2 on HTC One X, Android 4.1.1
Formerly QQ browser by the Chinese company TenCent. Domestic competitor of UC.
Tizen
WebKit 537
Default browser on Lunchbox prototype by Intel, Tizen 2.0.0a3
Tizen is an OS jointly being developed by Samsung and Intel. I expect Samsung to start producing devices this year, and it will get a few percent of market share.
IE9
Trident
Default browser on Nokia Lumia 800, Windows Phone 7.
IE10
Trident
Default browser on Nokia Lumia 820, Windows Phone 8.
Firefox
Gecko
18 on HTC One X, Android 4.1.1

General note on One, NetFront, and UC: the browsers I test are not particularly representative for the actual browsers that are used in the wild. Though some may be default browsers on Asian Android devices, most of them get their market share from being pre-installed on feature phones or game consoles.I’m working on getting more representative test devices.

Browsers by WebKit version:

530
NetFront
533
Android 2
Anna
UC
534
iOS5
Android 3 and 4
BlackBerry 6 and 7
MeeGo
Dolphin
One
535
Chrome
Belle
536
iOS6
BlackBerry PlayBook
537
Opera Mobile 14
BlackBerry 10
Tizen