CodeDread Blog » webkit

The Start Of Something Good?

Jeff — Fri, 07 Nov 2008 16:58:14 +0000

Apparently Steve Ballmer has publicly stated that Microsoft plans to look into Webkit… that’s news to me! Microsoft’s browser needs to support modern web standards: HTML4, XHTML, CSS, SVG and as much HTML5 as is ready for deployment.

But Microsoft has also publicly been “looking into” SVG for years and years, so I’m not going to hold my breath.

These days, Internet Explorer is the last browser I look at… as long as all my textual content is actually visible, then that’s just fine by me.

Google’s Chrome

Jeff — Tue, 02 Sep 2008 03:47:13 +0000

Google is going to release a new open-source web browser tomorrow (Sept 2nd, 2008) called Google Chrome. Lots of information contained in forty pages of this comic book. The rendering engine is WebKit, but it has its own JavaScript engine (V8) that compiles the JS into ~~byte~~machine code and uses more efficient garbage collection. It also follows the thoughts of the Internet Explorer team of putting the tab at the root of the UI and letting each tab be its own process (not just thread). Oh, it comes with Google Gears pre-installed too.

This all sounds good: security, stability, anti-phishing, sandboxing, ’superfast’ JS. Of course there’s only one true test though.

At first I was wondering if this was a fork of WebKit, but I think the only thing that would make sense would be for Google to work in parallel with WebKit (continually updating Chrome’s rendering engine with new versions of WebKit). Everything else would be part of the Chrome open source project. If you’re in the know, drop a line below.

Ok, I’m happy. A completely open source browser that supports SVG and is (sort of) co-sponsored by two big companies with lots of cash (Google and Apple).

SVG Web Stats 2.0

Jeff — Wed, 02 Jul 2008 06:36:49 +0000

I’ve made enough updates over the past week or so on my SVG Web Stats thing to call it 2.0. Here are a list of changes:

Added ability to dynamically filter out browsers you don’t want to see in the graph (uncheck it in the legend)
Added points of interest on the graph (hover to get a tooltip, click to view the associated link
Aggregated my data to the weekly level (to smooth weekend dips out)
Added some animation to the user interface
Added tooltips to the data series for browser identification (works only in Firefox and Opera)
Collapsed some older browsers so that the graph are more distinguishable.

Drag and scrollbar performance are blazingly fast in WebKit nightlies on my machine. Just how I imagined it when I first wrote this over two years ago. Opera 9.5, Firefox 3 and Safari 3.1 performance are not bad at all. It doesn’t perform well in Firefox 2.

I just noticed that the tooltips are broken in WebKit nightlies…

Note that the legend suffers from what I consider to be a bug in Opera and Webkit nightlies. In these browsers, the legend is ‘jittery’ when the mouse hits the checkboxes. Firefox and Safari do not have this behavior because I’m using FakeSmile, a JS implementation of SMIL. It seems to me like either mouseout events are firing when they shouldn’t or the animation wants to start over at its original value instead of where it is currently. I’m hoping some Opera SMIL guru can stop by.

If you missed the link above, click here to see the demo. I’d be curious to know if it works at all in Internet Explorer with Adobe SVG Viewer. I know it doesn’t work in IE+Renesis.

Mozilla Works on SVG Effects For Web

Jeff — Wed, 04 Jun 2008 02:45:50 +0000

Very cool stuff from roc. An interesting alternative to all the CSS properties being added to WebKit. Meanwhile, Microsoft is still plodding away on bog-standard CSS 2 – expect an update from them in August, if you’re still interested (if you are maybe you want to try a new plugin for IE?)

Apple’s Web Inventions

Jeff — Sat, 26 Apr 2008 01:43:32 +0000

The last two years have been explosive for WebKit development – the project has really accelerated, moving at a much faster perceivable rate than the other notable open-source web platform, Mozilla. I’ve been noticing more and more innovations that affect web developers from the Safari blog.

2008-04-29 – CSS Reflections
2008-04-24 – CSS Masks
2008-04-17 – CSS Canvas Drawing
2008-04-14 – CSS Gradients
2008-04-08? – CSS Transitions
2007-10-31 – CSS Animation (spec proposal)
2007-10-26 – CSS Transforms (spec proposal)
2006-12-21 – Text Fill and Stroke
2004? – HTML Canvas – thankfully this was quickly reviewed and thrown into HTML5 so that Opera and Mozilla could get into the act
Others -webkit-border-horizontal-spacing, -webkit-border-vertical-spacing, -webkit-margin-bottom-collapse, -webkit-margin-collapse, -webkit-margin-start, -webkit-margin-top-collapse, -webkit-padding-start, background-position-x, background-position-y, -webkit-tap-highlight-color (iPhone only), -webkit-text-security, -webkit-text-size-adjust (iPhone only), -webkit-line-break, -webkit-nbsp-mode, -webkit-rtl-ordering, -webkit-user-drag, -webkit-user-modify, -webkit-user-select, -webkit-dashboard-region (Dashboard only)

Is this a problem?

What’s troubling me is not that many of these inventions could have been done using SVG (which WebKit now supports quite nicely). I understand that XML is not for everyone and that a few CSS properties are easier to pick up to do what you want.

No, what troubles me is that a few of these innovations are not yet proposed as formal specifications so that they can be interoperably implemented in other browsers (Firefox, Opera). [Update: Correction - as Mark points out below, several of these have indeed been proposed as formal specifications - Bravo!] The point of the WHATWG effort was both to evolve HTML and to specify it in sufficient detail so that future browser vendors would not have to reverse engineer de facto browser behavior. Will the WHATWG eventually have to churn out CSS5?!?

On the other hand…

… Apple has a perfect right to introduce WebKit-specific CSS properties. WebKit is more than just a single web browser. WebKit is a platform and Apple obviously wants to put as many cool web development tools into the hands of its developers as possible. They’re already doing a good job at meeting existing open web standards – why not innovate on the side? Also, using CSS ensures that things can degrade gracefully, so you can’t quite fault Apple for ‘anti-competitve behavior’ like you could Microsoft and Netscape’s efforts during the First Browser War.

Unfortunately…

Unfortunately these inventions might have the same secondary effect: Forcing the other browser vendors to spend resources on reverse-engineering efforts in order to remain competitive. This could realistically happen before Apple gets a chance to propose these things formally to the W3C. [Update: See Mark's comment below]. It is much more likely to happen if WebKit were to become the dominant force on the open web.

WebKit is not yet the dominant web browser technology, but it’s fast on the rise. From all accounts, it is much easier to pick up and hack on than the Mozilla codebase. Let’s take a look at where it is being used:

MacOS Dashboard
Safari on MacOS
Safari on iPhone
Google’s Android
Adobe’s Integrated Runtime (AIR)
Qt 4.4+
Nokia S60 Browser

I’m sure readers can help me add to the above list too. I believe there is a plan for WebKit to ultimately take over Konqueror’s KHTML guts one day too, isn’t there? Ironic since WebKit evolved from KHTML in the first place.

So when will it be a problem?

Are we seeing any signs of a trend towards a WebKit-dominated web yet? There are already iPhone-specific websites. How long before Opera Mobile and Mozilla Minimo want to get in on that action and are forced to reverse-engineer? And I’m sorry, but looking at the source is not an acceptable alternative to a well-defined specification.

A tentative conclusion

After typing up this entry and proof-reading it, I tried to discern if I had any coherent conclusion and if I could figure out just what the heck I was saying:

Apple is not in the wrong for introducing WebKit-specific CSS properties, I think they learned their lesson from the HTML Canvas experience.
You also cannot fault Apple for its adherence to web standards. They are definitely doing their job here
It seems like they plan to propose these things as standards eventually, which is also a good thing.
I guess the only thing I can say is that I hope these proposals happen sooner rather than later, for the other browsers’ sake. [Update: As mentioned below, Apple has already proposed many of these things to the W3C as specifications, thereby alleviating most of my concern]. Apple should take a page from what happened to DOM Events: The fact that Netscape and Microsoft had two different event models resulted in the W3C proposing yet a third incompatible Event Model, which Microsoft still has not implemented eight years later. Those type of things just hurt web developers in the end.

WebKit Nightly: Now Smiling

Jeff — Tue, 15 Apr 2008 05:10:01 +0000

The latest WebKit nightly now has a decent amount of SVG+SMIL (animation) coverage. By my old school grading system, that gives WebKit a solid ‘B’ grade in terms of SVG support (75%). This is what I was talking about a few weeks ago and I’m quite happy to see it happen! If they cleaned up their regressions from a few weeks ago (some problems with SVG patterns, I believe), they might even crest 80%.

Webkit Nightly: Not Smiling

Jeff — Thu, 27 Mar 2008 05:08:05 +0000

After the announcement that the Apple developers have turned on their SMIL support in order to pass Acid3 test, I was excited enough to download the MacOS nightly and run through the SVG animation test suite. I was pretty disappointed.

Out of 58 tests involving animation, WebKit r31344 fails 54, gets 3 of the tests partially right and only gets 1 test to completely pass. To put this into ‘acid’ terms, this means that WebKit r31344 gets a score of 5/116 when it comes to SVG animation support (as compared to Opera 9.5’s 110/116). See my top-secret scoring mechanism here.

My concern at this point is that releasing such a nonconforming SMIL implementation into the wild will just frustrate authors and users. But I suppose there isn’t much SMIL out there at the moment. Here’s one data point, at least: My menus no longer animate properly in WebKit r31344, producing ‘fluttering’ icons… Is there a way I can turn off WebKit’s native SMIL when visiting my website? Does anyone know of any other sites out there using SMIL in their UI?

Anyway, I’m very much looking forward to future Webkit releases that will improve upon the SMIL implementation – and please release the build for Windows too. And I would be remiss if I didn’t congratulate the WebKit team for releasing a downloadable application that shows 100/100 on Acid3. Hopefully this post is just a little bit of cold water in the face to those fans thinking that WebKit is somehow “perfect”

Acid3: Neck-and-Neck

Jeff — Thu, 27 Mar 2008 01:52:22 +0000

WebKit and Opera are really scrambling to be the first browser to fully pass Acid 3. First, Opera claimed they were at 100/100 in a private build, then Ian corrected the test (based on feedback from Apple developers), presumably knocking Opera back to 99/100. And just now, the WebKit guys have turned on SVG Animation (SMIL) in their nightly builds, putting them also at 99/100. This was a surprise to me, since I had heard that their SMIL implementation was not ready for prime-time, so to speak. Oh well, this is great – now we have a second browser implementing SMIL natively and we can truly start pushing for interoperable solutions.

What does it mean for Apple and Opera fans? Probably a lot. What does it mean for web standardistas? Apple and Opera care (more?). What does this all actually mean for web developers at the moment? Not a single thing. Oh well, time to tally up my own similarly-meaningless SVG support score…

[Update 10:25 PM CST: Apple did it. They are the first to achieve 100/100 in Acid3 with a publicly downloadable browser (even if it is only for MacOS)]

Bugs From New Theme

Jeff — Thu, 21 Feb 2008 01:44:21 +0000

Sander asked me to post a list of bugs that I found as a result of working on my new theme. Here they are.

Mozilla Bugs

Bug 418164: Firefox 3 Regression: white-space:pre div forces browser window width
Bug 418305: Enhancement Request: Make Yellow-Screen-Of-Death Follow the Geneva Convention
410820: <svg> elements respond to mouse events when they should not (Not Reported By Me, But Important)

WebKit Bugs

Bug 15214: SVG link with target=”_top” opens new window (FIXED since r25729)
Bug 17423: Enhancement Request: Add support for xml:base
Bug 17424: WebKit Regression: SVG properly positioned only upon Redraw

My Own Fixes

Phil noticed that the side gradients weren’t being displayed in Opera 9.2 or earlier builds of Opera 9.5. I’ve since “fixed” that by explicitly setting the height of the divs to be 100% (with top:0; bottom:0;).
Sander reported that there was an annoying horizontal scrollbar in Firefox (also was in Safari). This was a result of me trying to get the menu to display workably in all browsers, including IE. I have since fixed this.
Sander also pointed out that the » (and «) entity is being shown literally in Opera. This is actually the right thing for Opera to do since XHTML doesn’t define any character references like HTML. I need to wrap my head around this and then either add the entity reference or update my WP theme. Haven’t got to it yet.

Is it sick that I enjoyed putting the site together and tweaking it for all the various browsers out there?

Webkit SVG Results In

Jeff — Tue, 24 Apr 2007 15:24:38 +0000

Thanks to Mike, I now have Webkit SVG results to show at my SVG Support page. Current (April 2007) Webkit builds score a 55%, which is roughly comparable to Firefox 3 nightlies. Firefox 3 adds support for some Filter Effects, while Webkit currently has better Text support. For a first release, this will be fantastic – congratulations to the Webkit team!