Just look at this little example:

The problem we see here is that WebKit anti-aliases its rounded borders. A nice idea, if it were taking the background into account. However, WebKit prefers to anti-alias the background against colour of the inside of the element in question rather than what's actually visible behind it. To make this clear, perhaps this example with a background image is helpful:

If you look closely, you'll notice that the portion of the background image that would be shown at the corner is displayed there. Resizing the browser window's width while watching the right corners may make this more obvious. I'd say this shouldn't happen.

Amusingly they don't have this problem in Firefox because they decided they'd be happy without anti-aliasing and thus avoided this opportunity for sloppy implementation.

Another thing that's rather unsatisfying about rounded corners is the way they are handled by img elements: A rounded corner is drawn but it is drawn beneath the image. So instead of cropping the image in a nice and round way, it gives something ugly. This is so obvious that I'd guess it's deliberate. But I wonder what the rationale behind it could be.

Mozilla (as of Firefox 2) actually outdoes WebKit in this respect as it doesn't only not crop img elements but also lets an element's background image 'underlap' beyond the rounded corners – and occasionally even outside the border!

Look at these issues on a separate page.

This screenshot comes from the Cyberduck web site and the CSS drawing the little red 'version 3' badge is this:

.version3 {
	background:url(./img/badge.png) no-repeat 100% 50%; 
	padding-right:25px;
}

Which makes this look pretty much like a padding problem once more. And even if WebKit's behaviour were according to the CSS spec, I'd say it needs changing because it'd be an example of the spec being bad or wrong…

Of course all these comments are utterly irrelevant as I don't know the spec by heart and I have no idea how to get meaningful results out of their bug reporter without having to read loads of stuff I'm not interested in. My judgement only comes from situations where (a) WebKit's behaviour seems unreasonable and possibly (b) other browsers' behaviour seems more reasonable.

A – IMO – glaringly obvious problem of this class is that WebKit simply kills the padding of inline items at line breaks. This has made multi-line menus look broken in WebKit for years if I'm not mistaken. Make your browser window narrow enough to get a line break below and judge yourself whether Safari or Firefox give a more desirable result rendering it:

Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra

Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra Abracadabra

There are 20px of horizontal padding on each box. To illustrate the problem further and to make sure Firefox (2) doesn't come out too well, I'll add this – which fails more for the direction:rtl usage than the Arabic in Firefox and highlights that WebKit 'loses' its padding at the end of the line rather than at the right.

الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية الصفحة الرئيسية

Look at this as a separate file. Or look at another instance of this problem.

The big disappointment at Apple’s recent developer conference was that they announced web applications as the way to develop applications for their new iPhone. I don’t think people seriously expected a full-blown SDK at this early point of the iPhone’s existence, but people were a bit annoyed by Apple pretending that web applications could compete with actual – presumably Cocoa based – applications.

While it is true, and proven over and over again by companies like Google or parts of the ‘web 2’ crowd, that you can do amazing things inside a web browser using JavaScript today, this still falls short of what native applications can do. The finer points of a good user interface are frequently lost when HTML and JavaScript are all people can use for their interfaces. Mac users need to look no further than their Dashboard to understand that. Dashboard widgets frequently don’t fit in with the system’s user interface standards. And don’t even get me started on how they quite reliably disappoint when it comes to aspects like localisation or number formats which are just taken as a given in ‘real’ Cocoa programming. I am sure that many of those aspects can be handled in web applications as well but doing so will require considerably effort.

And yet, I recently got the opportunity to help out with some CSS aspects of Karelia’s TeleMoose (née amaphone) iPhone web application. It delivers an iPhone optimised experience of amazon shopping: straightforward searches, usage optimised for the iPhone screen and – crucially – much shorter load times with the site coming in at 10-20% of the download size of the usual amazon site.

My first remark on this is that it is a joy. A joy to do CSS work without the what will IE6 do to this? question haunting you all the time and being able to use all the great stuff that WebKit supports – right down to rounded corners. That was quite cool.

Until Dan got to try things out on his iPhone fo real. Which revealed that iPhone’s Safari really doesn’t like two things: position:fixed and overflow:auto for items with a fixed height. With ‘doesn’t like’ essentially meaning ‘ignores’. And as the site was developed in the ‘Safari is your SDK’ spirit and was supposed to have elements fixed at the top or bottom of the screen with the page content scrolling above or below them, these CSS features were essential for making things work. Without them it’s not clear to either of us how we can display something like a search field or a button at a fixed position on the screen.

I ended up wondering what exactly Apple were thinking. As our knowledge is today – and it seems to be even richer than what Apple themselves now reveal about the iPhone’s browser – Apple didn’t just decide/manage to not have a SDK for the iPhone ready and allow third party applications. They furthermore seem to have disabled the very features in their web browser which could have enabled a web application (that is non-trivial / wants to display more than a single screenful of text) to create a decent UI.

With Apple presenting the web browser as the development environment for the iPhone I had fully expected a bit more commitment to that. All I can see is a tag to tell the iPhone to not render pages at the insanely wide width of 980px (a width which may be great for Apple’s recent redesign but which I usually find by far too wide for comfortable reading – particularly on sites with a fluid layout) and a few other simple display tweaks.

What I don’t see is a way to do anything that may make a web page seem worthy of a ‘designed for iPhone’ label. Like access to the orientation sensor say: most likely you don’t want to display a list vertically when the screen is in landscape mode – just as the iPhone’s iPod switches to CoverFlow mode on rotation because the list wouldn’t work well in landscape mode and CoverFlow wouldn’t work well in portrait mode.

Of course precise positioning of buttons at the bottom of the screen would be necessary for a good application, if only because it’s the only place where you can reach for buttons without covering other parts of the screen up with your fingers. But exactly that doesn’t seem to be possible. Ideally, I think, the iPhone should also allow ‘applications’ to replace or hide some of its browser UI chrome. Its screen may be large for a mobile device but it’s still quite small.

Have you done your own iPhone work? And discovered anything interesting or even solutions to these problems? Then please leave a comment!

And believe it or not, my cuddly elk Kalle has been all enthusiastic about the site’s name change. He ordered an iPhone, just so he can use it all day. Rumours go that he’s the one who pressured Karelia into altering the name.