I'm writing a CSS book

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

contact

A brilliant Sony idea; new tests

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.

The official point of these retests was to find out how much time an update would cost me. In that sense it’s a failure: updating a mobile browser test table takes about as much time as writing it in the first place. Although an update requires less tests because I can retain some results from the previous rounds, the time won is lost again in correlating the test results with the previous version of the tables, making sure I didn’t make mistakes, and sheer bugginess.

Still, the new tables are here. In this entry I’d like to discuss a weird Android bug I found, and a brilliant idea by Sony. Let’s start with the positive news.

Sony’s label text idea

When I did my :focus test in the Sony Xperia S’s default browser (Android 4.0.4), I saw the following:

“Name,” “Address,” and “City” are label texts. If they aren’t visible on the screen, the browser shows them in the input fields themselves.

Bloody brilliant and elegant. Losing your way in a long form on a mobile device is quite common, and this feature will help a great deal.

To date I found this feature only on the Sony version of Android WebKit. I would like to congratulate Sony on an excellent idea, and request all other browser vendors to implement this feature at their earliest convenience.

An Android bug

The other remarkable thing is an Android bug that occurs in some, but not all, Android WebKits 4. It turns out that some Android WebKits 4 try to restrain block-level elements to 320 pixels (iPhone!), but that this restraining doesn’t work when text-align is not left or direction is not ltr.

Here’s a buggy Android WebKit 4 (Sony Xperia S, Android 4.0.4):

For comparison, this is how the test should work (Samsung Galaxy Note I, Android 4.0.3)

This bug is not particularly important. Also, it’s easy to solve by giving the element an explicit width. Still, it’s interesting because it once again proves that one Android WebKit 4 does not necessarily equal another one.