I retested the CSS properties I discuss in chapter 5 of my book. Eventually these entries will be superseded by new ones in the context of the CSS module the properties appear in.
|
The background image does not scroll; the element serves as a “window” on the background image.
|
Static |
Jumpy |
4.1 |
No |
Static |
No |
No |
No |
Static |
Incomplete |
- |
Yes |
Buggy |
Static |
No |
Yes |
No |
Yes |
Static |
Ugly |
JumpyImage is readjusted after scrolling or zooming stops.
StaticBackground image is correctly positioned on page load, but does not change on scrolling.
- The Samsung Android 4 doesn’t support
fixed; the HTC does. This seems to be an Android version thing: 4.1 and up support fixed.
- Symbian supports it, but the effect is rather ugly.
- UC9 tries to support it, but mostly fails.
- NetFront is no-img, but also after a scroll.
- Firefox scrolls the image rather than jumping.
|
|
The background image scrolls with the element (and not the document).
|
Yes |
- |
No |
Yes |
No |
- |
No |
Yes |
- |
Yes |
Minimal |
- |
Yes |
Ugly |
Yes |
No |
Yes |
No |
Yes |
No |
Yes |
UntestableBrowser does not support scrollable elements.
- Symbian Belle moves part of the background image when you scroll the element, but the rest only moves when you scroll outside the element. Also, in the test page it gets confused with the previous example; apparently the scrolling layers overlap invisibly.
|
Extra mobile test
Percentages of the layout viewport width or height
50vw = 50% of viewport width
|
Buggy |
No |
No |
Yes |
No |
Yes |
No |
vv |
No |
- |
No |
No |
vv |
No |
vv |
No |
Yes |
No |
Yes |
vvUnit relative to the visual viewport, not to the layout viewport.
StaticWidths not updated when the viewport changes, for instance by changing the orientation
- Safari calculates these issues relative to the HTML element, it seems.
- Opera 14: weird numbers that bear no discernible relation to any viewport.
|
|
The smaller or larger of vw and vh
|
Incomplete |
Yes |
No |
No |
Yes |
No |
Yes |
No |
Incomplete |
No |
- |
No |
No |
Incomplete |
No |
Incomplete |
No |
Incomplete |
No |
Yes |
IncompleteOnly supports vmin.
|
|
An element in an active state.
|
No |
Incomplete |
Incomplete |
Yes |
No |
Yes |
Yes |
No |
No |
No |
No |
Almost |
No |
Yes |
No |
Incomplete |
Yes |
|
Styles should be applied ontouchstart and removed ontouchend.
To be honest, I don't see a lot of use for this selector on touchscreen devices.
- Android 2: Samsung supports it; HTC doesn’t.
- Android 4: Wow. All browsers support it BUT
- All browsers but Huawei leave the style until you touch the next item (Huawei removes it ontouchend)
- The Xperia, LG, and Huawei do not add active styles when you hold an element while interface elements such as select are still visible for another element. They only do active when interface elements are missing.
- Chrome 18 Samsung supports it; the Google version does not.
- Nintendo supports it, but only when you hold the element for a while. A simple tap is not enough.
- FF OS: the Geekphone supports it; the ZTE doesn’t.
|
|
An element in a hovered state.
|
Special |
Yes |
Yes |
Incomplete |
Special |
Almost |
Incomplete |
Desktop |
Yes |
No |
Almost |
Yes |
No |
Yes |
Yes |
Almost |
Yes |
Yes |
Desktop |
Yes |
Yes |
|
Normally the :hover styles are applied when the user touches the element, and removed when the user touches another element.
Special
Browser implements styles (and their removal) only on touchable elements; i.e. links, form fields, or elements with an explicit onclick event handler.
Desktop
Browser removes styles when touch ends; this is more in line with what the desktop browsers do.
- Chrome 31/Opera 18 removes the hover styles when context menus appear (i.e. when you hold your touch long enough). If they don’t appear, hover works normally.
- Opera 12 and Tizen do not apply the styles when you touchhold. Then it only shows the context menu.
- MeeGo: only after a short tap. Touchhold doesn’t give hover styles.
|