Serving hearty nuggets since 2001

WebKit Most Wanted

So, its been over a year and a half since I wrote about the features I most wanted out of browsers at that time. A lot has happened in the intervening time — browser manufacturers have released updates fixing many bugs; new and inventive work-arounds to problems have been discovered; I've changed in ways that make other items more important then those I outlined; Apple released the Safari browser and the associated WebKit framework.

It's that last item that brings me to this article. At the time I wrote the previous piece there was no Safari to take into consideration. When I read Safari developer Dave Hyatt's blog post asking for feedback on the state of WebKit (circa build 85) I thought I'd oblige.

First, a little background. Throughout the public beta process I found a number of specific bugs with various things that were implemented in WebKit. I'm happy to say most have been fixed, and only a few remain. The only downside to that quick action on Apple's part is that it makes a list like this difficult to write. As evidence look at how few of the initial responses to Dave's call for a list of Top Ten Problems only list two or three bugs. Even still I've managed to find ten items I think need work, some specific bugs, others missing features found in WebKit's and safari's competition.

The List

  1. Fix list-style-position:inside;

    The first problem on my list is just a simple display bug. It appears that setting list-style-position:inside doesn't indent the content of the list item in all cases causing the list marker and the first few chars of the list content to overlap. From my limited testing this happens with both UL and OL in cases where the values of list-style-type are incremental/counters. [Test case]

  2. Layered Flash and HTML based content is very quirky

    With the advent of the Flash parameter WMODE=transparent in recent version of the Flash plug-in you can now position html based content over Flash objects via CSS. This currently works in both Mozilla based browsers as well as IE/Windows. In Safari it almost works. It seems that while the initial draw of the content looks as expected once the flash movie starts animating it jumps to the front, as if stealing focus. [Absolute position test case] [Fixed position test case]

  3. Which Form to Submit?

    I have to admit I haven't really investigated this bug, and frankly, I haven't even hit view source to see how ugly the code is, but in this list I only have one this site acts funky bug and this is it. It seems that on a Bugzilla Query page habit dictates I enter some search string in the Summary field and hit enter. In Mozilla, IE/Mac & Camino this enter results in a search being kicked off. However, in Safari it seems that the last form on the page is submitted instead resulting in a field added to the query page that I'm already done with. Why use Safari to browse you ask? Well, its a lot easier to have the bug reports in one application and testing (especially in the case of crash bugs) in another.

  4. Accuracy of script variables given preference settings

    Two Flash bugs in a row? Is this really Haha, yes, it is. While I don't often use Flash, when I do I like it to degrade gracefully and generally not cause a headache trying to get it to work with the rest of my content. Unfortunately, when the Flash player is installed on a system but plug-ins are disabled in the safari prefs JavaScript still reports that Flash is enabled. This break well known sniffer scripts such as Colin Moock's Flash Plug-in Inspector and in many cases leaves a visitor without Flash content or any alternate content.

  5. Support for min- & max- dimensions

    Another carry over from my old list that still has yet to be fully realized — support for min-height, max-height, min-width, and max-width on more then just trivial scenarios. I find myself wanting to use min-height in a large number of cases where floating is used but I don't want (or can't) use clear on content after a floated element. In the case of IE/Windows I can usually get around this by setting a height on the given element instead and let its bastardized idea of overflow take over. No such luck in Safari making these properties all the more important. [min-height test case]

  6. Consistency in scripting/dhtml speed

    ...and make it fast, too! Not much more to say really. While I've never met a JavaScript performance test suite I really liked and thought was practical that doesn't mean Safari shouldn't handle these suites well. Generally Safari does pretty well with dhtml speed, but occasionally they'll be a site that Safari really lags behind Mozilla and IE/Mac. Here is one such test showing Safari 2 to 3 times slower. It lags behind in much of this stress test as well.

  7. Some method of opacity on arbitrary, non-PNG content

    This is the first item on my list that falls under the umbrella of but I can do it in X. IE for Windows has CSS filters, Mozilla based browsers have -moz-opacity, the CSS3 Color Module (now in CR) defines both opacity as well as RGBA & HSLA color units. At the moment, because I have elsewhere, I'd settle for any method to define this value.

  8. Provide JavaScript methods to get and manipulate selections.

    For some time now users of Internet Explorer have enjoyed the benefit text selection manipulation in the form of little 'add html' buttons adjacent to textareas in CMS applications and comment forms on well known blogging systems and sites like MetaFilter and Photographica. More recently this has also been possible in Mozilla, leaving Safari the odd man out.

  9. Provide some rich text editing component

    Dinky little textarea helpers are so last year. The current rage with web based CMS systems is embedded rich text editing components. While some have gone so far as to create plug-in based CMS editing modules to accomplish the task I'd much prefer a native replacement for a simple html textarea in much the same way that is possible via contentEditable in IE/Windows and Mozilla do it. Yes, there's considerable issues with deploying a front end using the editor de-jour but those can be dealt with on the back end. For not I just want a native rich text editor so I don't have to do that work, too.

  10. Support the JavaScript onerror event

    You don't have to go further then a past tutorial on this site to know I like the onerror event. While its not the most elegant method of dealing with scripting exceptions it works pretty well &mdash in principle. That principle falls flat on its face if JS supporting UAs don't support the event, and with it a number of scripts.

And an honorable mention must go out to (I'm sorry Dave, I know its UI, I know its successfully implemented in WebKit based UAs that are not Safari 1.0, but I just can't help mentioning) having a preference to set a minimum font size so that small type doesn't break apart.

So there it is, my Top 10 Problems with WebKit 85 list. I must say a huge thank you to Dave for both being and accessible personality these past few months and giving enough of a damn to solicit feedback and actually read it all (eventually, I'm sure). Apple done good at bringing you on board.