In a recent project a client asked for boxes with rounded corners and filled with a gradient; within an application targeted at smartphones.
On mobile devices it is important to keep things simple, for instance to keep the number of DOM nodes low. That rules out using additional elements for the corners. On the other hand, many mobile devices are featuring recent versions of web rendering engines. Dive into CSS 3.
Modern web development techniques offer a lot of possibilities to render boxes with rounded corners: e.g. border-radius, border-image, or SVG used as background. In this post I’m going to explore the support for them across different devices and runtime environments. You can skip to the results table if all you want is a quick overview.
As stated above, I want to achieve a box with rounded corners and a gradient that reaches from top to bottom, scaling to the height of the box. The example might be simple, but it is representing a common design goal.
State of affairs
As of today, several possibilities exist to develop applications for mobile devices using web technologies. Besides Palms webOS, PhoneGap permits to develop cross-platform applications with JavaScript, HTML, and CSS for the iPhone, Android, Blackberry, Windows Mobile, and Nokia WRT (support for webOS is upcoming). On Nokia devices there are two frameworks to create applications with web technologies: the built-in Nokia Web Runtime Widgets (Nokia WRT) and Opera-based Vodafone Apps Manager, which provides a runtime for W3C Widgets (heads up! Vodafone Apps Manager is WebKit-based on the Vodafone 360 H1/M1 devices, to complicate development a little bit).
While these runtimes provide the means to build applications using well-known technology to web developers, they also bring well-known problems to the mobile sphere: inconsistencies between rendering engines. Even though most of those runtimes are WebKit-based (with the exception of Vodafone Apps Manager), there is no [single] Webkit on Mobile, as PPK has pointed out. His comparison table shows the results of testing for various JavaScript and CSS features.
Freed from the burden of “making things work in IE” we can start using advanced CSS features to build interfaces for mobile applications – but hold on, it’s not as easy as desired. Due to the differences in capabilities of rendering engines and their versions, using CSS 3 features needs a lot of testing.
Test Setup
To keep things simple in the beginning, I’ve tested on two devices: a Nokia 5800 XpressMusic and a Nokia N97 (it might have played a role that I had those two at hand when writing the article
Both devices support Nokia WRT apps natively and W3C Widgets via Vodafone Apps Manager. The HTML file consists of boxes with different set of CSS properties. I’ve uploaded the packaged Nokia WRT Widget and the W3C Widget, too. You can test them for yourself on your Nokia, if you like.
On the 5800, Nokia WRT is based on WebKit build 413 (which correlates roughly to Safari 2.0), the installed Vodafone Apps Manager uses Opera Mobile build 1265. The N97 uses Webkit build 525 (introduced with Safari 3) and Opera Mobile build 1360.
Because the two devices show no differences in rendering (with one exception), all screenshots have been taken on the N97 with the exception of one rendering bug found on the 5800. All other rendering differences are existing between runtimes only.
Test Results
Result table
The result table provides a quick overview about the tested features and platforms. Detailed descriptions of the single tests can be found below.
Nokia WRT | Vodafone Apps Manager | |
---|---|---|
border-radius | yes, but not useful * | no |
border-image | yes | no |
CSS gradients | no | no |
SVG background images | no | yes, with rendering bug ** |
box-shadow | no | no |
opacity | no | yes |
CSS transitions | no | no |
* background overlaps border, blurry border on the N97, circular artifacts on the 5800
** SVG backgrounds stop being rendered after the corresponding element is scrolled out of the viewport
Cases 1/2: Simple Box
Case 1 simply uses a border
and a background-image
:
border: 1px solid #4a4a4a;
This renders equally well on both platforms, but is not very similar to what I want to achieve: The background gradient is barely visible, because the image used is fairly high and does not scale with the height of the box.
Case 2 is a little bonus, as it does not relate to box styling: it tests for support of CSS transitions. By clicking the box, the class “clicked” is added or removed. In rendering engines supporting CSS transition the width of the box will be changed smoothly. Neither Nokia WRT nor Vodafone Apps Manager support them, though.
transition-property: width;
transition-duration: 250ms;
-webkit-transition-property: width;
-webkit-transition-duration: 250ms;
}
.transition.clicked {
color: #0f0;
width: 270px;
}
Cases 3/4: border-radius and border-image
The third test adds border-radius
to the CSS declaration. This comes closer to the styling goal, but is not usable on both platforms: While it’s not rendered at all in the Opera-based Vodafone Apps Manager, the older WebKit engines of the 5800’s Nokia WRT adds circular artifacts to the corner, and the background overlaps the border on the N97. In addition, the border drawing is blurry on the N97 as soon as border-radius
is added to the declarations.
-webkit-border-radius: 15px;
-moz-border-radius: 15px;
Case 4 uses the same background image, but as border-image
. Again, Opera doesn’t support the property, but the WebKit-based Nokia WRT displays the box as intended: Sharp border, rounded corners, gradient from top to bottom. (Note: in contrast to the label on the box, the background property is set to white in this example).
border-width: 15px;
background: #ffffff;
border-image: url(box.png) 15 stretch;
-webkit-border-image: url(box.png) 15 stretch;
-moz-border-image: url(box.png) 15 stretch;
padding: 0;
}
Interestingly, the WRT application crashes, when the combined offset/border-width syntax (e.g. -webkit-border-image: url(box.png) 15/15px stretch
).
Cases 5/6: Gradients and SVG
The fifth box uses a different approach for styling the box: It uses a browser-rendered gradient (<a href="http://webkit.org/blog/175/introducing-css-gradients/">-webkit-gradient</a>
) for the background:
background: gradient(linear, left top, left bottom, from(#666661), to(#b0b0b0));
background: -webkit-gradient(linear, left top, left bottom, from(#666661), to(#b0b0b0));
Support for gradients in WebKit was introduced in april 2008, but is not supported on the Nokias. As expected, it doesn’t work in opera, either.
Case 6 uses a SVG as background-image which always scales to the available width and height. This technique has been described more than two years ago for Opera, and works well in Opera based environments. Even though this example doesn’t make use of CSS 3 , only Opera seems to be able to use SVG graphics as background images as of today. This holds true for browsers with built-in SVG rendering capabilities, too.
Cases 7/8/9: Cross-Platform Solution and Advanced Features
Examples 7 and 8 represent the attempt to combine the approaches from boxes #4 and #6: They use an SVG background-image
and a pixel graphic as border-image
:
border-image: url(box.png) 15 stretch;
-webkit-border-image: url(box.png) 15 stretch;
-moz-border-image: url(box.png) 15 stretch;
Because both WebKit and Presto (Opera’s rendering engine) only support one of the approaches, the box renders fine in both engines (also, border images always lay on top background images).
This would be a perfect cross-platform solution, if Vodafone Apps Manager wouldn’t show a nasty bug: The first time boxes with an SVG background are scrolled into the viewport, they are rendered properly. As soon as all boxes using the same SVG are scrolled out of the viewport, and then scrolled in again, the SVG won’t display any longer. I’ve added a video showing this behavior.
Case 8 just adds opacity
to the boxes, which is only supported in Opera, but slows down scrolling noticeable. Case 9 tests for support of box-shadow
, which is not supported by any of the runtimes used in this test.
Conclusion
In our small test, we actually found a solution that runs in both WebKit and Presto. Sadly, this solution is only viable if the box isn’t ever scrolled out of the viewport. The rendering problems affecting the solution can only be found in mobile versions of the rendering engines tested.
That means, support of a certain feature in the desktop version of a browser does not imply bug-free support in mobile versions. Drawing can be fuzzy or faulty. Examples are border-radius
in older Nokia WRT releases or the SVG rendering bug in Vodafone Apps Manager.
Despite the fact we don’t have to deal with “legacy rendering engines” on mobile devices, it is not possible to rely on modern features like SVG graphics or CSS 3 yet. Due to many forks of WebKit, and Operas restraint in implementing CSS 3 features, each usage of such features should be thoroughly tested across all different target platforms. Write code your device can handle, don’t try to bend the browser.
Another problem are slow rendering speeds on mobile devices. It might be impossible to use certain features, just because animations and scrolling get choppy, thus killing the snappiness of the user interface.
The Future
The newest version of Operas rendering engine, Presto 2.4 is already in beta state for mobile devices with Opera Mobile 10 (while the newest desktop version still uses Presto 2.2), and adds support for many CSS 3 features like border-radius, border-image, background-size, and CSS transitions. This will enable us to use all of the techniques that have been shown for WebKit in this post (border images, border radius, and box shadow). Using a combination of background-image, background-size, and border-image could provide a solution that degrades gracefully on older devices.
Also, CPU and rendering power of mobile devices will increase in the next years, providing faster rendering of HTML/CSS with smooth animations.
Thanks to the fact that developers don’t have to account for the market leader, the mobile browser/rendering engine market evolves way faster than the desktop browser market does. I am excited about the possibilities we have today and looking forward to the possibilities we’re going to have after the next releases of browsers an built-in rendering engines.
To Do
The plan is to make the tests more complete. One the one hand that means adding tests (e.g. the current test series lacks a test for -webkit-/-o-background-size, which would allow to scale the background image with the size of the box). Another interesting topic is support for CSS transitions.
On the other hand I would like to deploy the tests on as many platforms as possible. The next steps could cover packaging for platforms supported through PhoneGap and webOS.
If you would like to see a certain feature tested, I would appreciate a comment very much. Follow me on Twitter (void_0) to be kept up-to-date about my random findings in the mobile web dev sphere.