Slashdot Mirror

• Firefox 2.0.0.14
  Total execution time: 32,393.8ms +/-6.4% - Full Result
• Firefox 3.0
  Total execution time: 5,442.2ms +/-2.4% - Full Result
• Internet Explorer 7
  Total execution time: 57,794.6ms +/-8.1% -

• Firefox 2.0.0.14
  Total execution time: 32,393.8ms +/-6.4% - Full Result
• Firefox 3.0
  Total execution time: 5,442.2ms +/-2.4% - Full Result
• Internet Explorer 7
  Total execution time: 57,794.6ms +/-8.1% -

... because it's not as though Webkit provides rich multimedia at all, and I guess Sprout could never provide any of those "struts" to build any applications at all...

Yep, that's right, delusional...

Simon.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

SproutCore is pretty impressive for building real JS web applications, although the story doesn't real end there.

There's a convergence of other improvements, such as HTML5, CSS, and SVG, that are filling a lot of the multimedia roles previously the domain of flash.

For example, WebKit already supports CSS transforms, gradients, client-side database storage, animation, HTML5 media, downloadable fonts, masks, reflections, etc.

A lot of these things are only available in WebKit right now, although they've all been proposed or will be proposed as web standards in the near future, and provide a nice glimpse at where the web is heading. Web 3.0 (or whatever marketing term people come up with) is clearly though going to be focused on multimedia.

Safari lacks the great plugins but http://nightly.webkit.org/ builds of Webkit have had it passing the Acid3 test 100% lately and blowing away other browsers in the SunSpider Javascript benchmark too. It's been getting faster almost daily. I'm on OS X Intel.
I normally use Firefox 2 because of the plugins, frustrasted with 3rc1 and rc2 breaking adblock. At least NoScript still works.

On a mac, it's simple to install and remove the WebKit nightly. It's literally just dragging and dropping a specially built application.

1. Make sure you have the latest Safari installed. WebKit doesn't touch the User Interface, so you still need Safari around.
2. Go to the Webkit Nightly Builds site and click to download the Mac OS X version.
3. If you have "Open safe downloads" wisely turned off, you will need to find the file you downloaded (probably named WebKit-SVN-r#####.dmg) and open it. The disk image will mount and you will see a gold version of the Safari compass icon labelled WebKit. If your browser auto-opens "safe" downloads, just switch to the Finder and you'll see that gold WebKit icon all alone in a window.
4. Drag the gold WebKit icon into your Applications folder. It will not conflict or erase Safari since it has a different name. You are now done with the install image; you can eject and trash the .dmg file from your download folder.
5. To use the nightly builds of webkit, launch the gold WebKit app rather than Safari. The first time you will be warned by Mac OS X's security feature saying this was an app downloaded from the internet, go ahead and approve the launch. You may also be warned about the incompatibility of some browser plugins. Everything else should seem identical to Safari.

Now, you'll only be using the webkit libraries when browsing with that gold WebKit icon. To prove this to yourself, you can visit the Acid3 test page using both Safari and Webkit without quitting either and see very different results. Safari still has major incompatibilities while WebKit seems almost perfect.

Finally, when you are ready to uninstall WebKit, quit the app and drag the gold colored icon from the applications folder to the trash. Or, drag a new version that you download the next day on top to replace the old nightly.

I kind-of thought that was the direction you were heading in, and was writing something along those lines yesterday (my time) but the start of my reply got lost because the new reply system will close edit boxes (destroying the text in them) if not careful, and I wasn't careful...

Since we are now in the realm of a thinking experiment, let me suggest that your approach will build all the non-front-end parts of your browser, since you have to prevent "leaks" of https URIs back to your (third party) browser, which would then act on them and probably result in waving warning flags or displaying surprising results. This is best observed through the HTML you get across connections to e.g. www.mac.com port 443. WebObjects juggles URI types in ways that are hard to "fight" with a https-to-http URI rewriting proxy. Several other backend systems will require your proxy to examine and dynamic scripts (ECMAScript for example) in order to prevent your "terminal" (displaying) browser from thinking it should connect to someone else's port 443.

You could alternatively use packet filter/forward systems, or DNS resolver tricks to make your "terminal" browser move *everything* through your proxy, but this approach requires a wildcard TLS certificate that your browser trusts.

The latter approach is effectively the same as trusting an ISP's (or hotel's... or corporate's...) intercepting proxy, and there is proof-by-existence that this is workable. SOCKS proxies are somewhat similar.

The former approach is analogous to the browser/GUI split among WebCore, WebKit and Safari, or WebCore, WebKit and OmniWeb (for example). The backend processing of fetching hypertext is decoupled from rendering and from the user-facing control plane. You could attack your problem in the front end by producing your own control plane (there are several open source starting points like http://webkit.org/ ) or in the back end, along the lines you are suggesting. There are trade-offs either way.

"PayPal has apparently claimed they won't block browsers" to me reads that PayPal realizes that blocking browsers is very hard to do, since there are few reliable ways to identify browsers other than via what they volunteer in requests, and most of those ways are disgustingly non-portable among the set of "secure" browsers they like. Apple's "solution" in the iTMS is to use its own markup language and transport that looks a lot like HTML but isn't really, and is designed to be non-interoperable with clients other than iTunes (in principle they could require the client to do unpublished algorithmic mutations as part of a three-way handshake, for example, which is also the approach taken by some sites to identify the capabilities of ordinary web browsers for actual interoperability reasons).

However, back to the original point, the key to solving interoperability problems created by "dumb" management decisions at popular web sites is to get a decent coder familiar with (and able to change) the guts of a browser to suffer the same problem enough that he or she codes a workaround and makes it available to you (and others).

On the other hand, if you really can write your own middleware proxy, especially if it is of general use rather than for solving one specific transient "dumb" management problem (i.e., PayPal's original announcement), then publish and share it!

• Faster startup,
• faster rendering and scripts,
• faster page loading,
• polished UI,
• more advanced/less buggy engine,
• cool experimental CSS.

• Faster startup,
• faster rendering and scripts,
• faster page loading,
• polished UI,
• more advanced/less buggy engine,
• cool experimental CSS.

• Faster startup,
• faster rendering and scripts,
• faster page loading,
• polished UI,
• more advanced/less buggy engine,
• cool experimental CSS.

I haven't found webkit to be faster. Even on webkit's own Sunspider javascript test, firefox3b5 is 30% faster than webkit nightly. (Tiger on my dual g5)

>As for the Acid3 test, Firefox 3 Beta 5 scores
>only 71/100 compared to 75/100 for Safari 3.1

>>If we're comparing a Firefox beta then we may
>>as well look at a newer version of Safari, too.
>>The latest nightly builds of WebKit get 100/100
>>on Acid3. http://webkit.org/blog/173/

Actually, that's not quite fair. Firefox 3 beta 5 is the final beta and it's basically done. It will be a shipping browser at the same time as Safari 3.1. Comparing shipping browsers with nearly simultaneous releases (only a few months apart) is an eminently reasonable thing to do.

- A

As for the Acid3 test, Firefox 3 Beta 5 scores only 71/100 compared to 75/100 for Safari 3.1

On the other hand Webkit http://www.webkit.org/ is open source, and the Mac was exploited through Safari. So this same case could be used as an argument that open source is more easily/quickly exploited.

Thank you for the link to Shaver's blog post. Indeed it is more reasonable than Rob Sayre's "sour grapes" post, although i find Ian Hickson's response to Shaver's blog post to be more reasonable still. (Worth reading if you missed it.) Also don't miss Maciej Stachowiak's Scenes From an Acid Test. It does touch on the careful approach they have taken. I wish we could peek behind the curtain at Opera to see what's really going on there.

If Safari can not pass Acid3 without hacks

Please read my comment again. This isn't about passing or not passing. If you don't meet the preconditions of the Acid3 test, then you simply don't know whether you passed or not because the results are inaccurate.

You could meet the preconditions another way — turn off font smoothing manually in your system settings and then take the Acid3 test. A bit inconvenient, don't you think?

If Apple found a flaw in Acid3, they should let the Acid3 dev(s) know, and possibly help them fix it.

They already talked about it before the fix was committed. See bug #17086.

The WebKit rendering engine has reached 100/100 on Acid 3.

FYI http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/

> What you are seeing here are not crazy hacks

Well, http://trac.webkit.org/projects/webkit/changeset/31322 would be a change which special-cases one particular font for different handling from all other fonts because that font happens to be the one Acid3 uses.

Either the thing that's being done with all the other fonts is OK (and the test is wrong, and there should be no need to special case) or the thing being done with all the other fonts is not OK, and this is a crazy hack...

This is not to say that all the changes are like this, by any means. But with the closed-source browsers, who knows?

http://trac.webkit.org/projects/webkit/changeset/31322

The WebKit folks have scored 100/100 on the test. But in the process of making WebKit conform, they found a bug in the test itself that would have forced a violation of the SVG standard to pass, so it wasn't possible to get a valid 100/100 on the test. That renders Opera's score invalid, and they're back to 99/100.

According to the WebKit people, though, this doesn't actually mean they've passed because the animation may not be as smooth as it's supposed to be. But the rendering itself matches the reference rendering perfectly.

Ok, you can now download Webkit to browse and see 100/100 on your screen.
http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/

So, by that metric, Webkit (aka Safari's engine) is the first to 100%.

Now we just have to wait to see who's the first to really completely pass with pixel-accuracy and smooth animation, and who's the first to release a final official version.

The plot coagulates; Webkit claims 100% support while the ACID test has been modified to conform to the SVG 1.1 standard. So Opera may not have a 100% result anymore.

Opera FTL!!!!!

They blew their wad too soon trying to steal WebKit's spotlight.

Download the latest nightly and see everything, in real living color on your computer now:

http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/

Oh and the test was updated like 3 hours ago which more than likely knocks Opera back to 99/100, but well no one knows for sure since all they have is a screenshot...

http://ln.hixie.ch/?start=1206578003&count=1

http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/

http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/

Safari is now at 99/100, and their code base will allow them to release a stable version first. Sure, opera "won" , but safari actually has a better implementation.

99/100 now ;-) Not that I really care all that much, but I actually use webkit (and test the nightly builds daily)...

http://webkit.org/blog/172/enabling-svg-animation-acid3-99100/

165MB is a HUGE amount of source code for something that you claim has a 'much smaller and cleaner' design and is "not all that large".

Firstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the websites drops that ~100MB to ~80MB. So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there.

Secondly, I didn't say that Safari is "not all that large". I said that browsers are not all that large. Download, for example, KDE, and see how small a part of it Konqueror is. You were characterising developing a browser as this monumental effort that required a special, painstakingly slow development approach. In reality, there are far larger codebases that are worked on at a much faster rate by many more people, with way less communication. Browsers really aren't anything special in this regard.

Thirdly, it's not just my claim about the relative sizes of the codebases. Check out the announcements (1 and 2) explaining the reasons for going with KHTML:

Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance

Weighing in at less than one tenth the size of another open source renderer, Konqueror helps Safari stay lean and responsive.

Do you think Webkit is ten times the size it was then? Or do you think Gecko is ten times smaller than it was then?

Instead of fixing the rendering of the 'Ahem' font, it seems to turn off font smoothing just to make it look like the reference rendering(note that it does it only for the web font). What about such bugs for other fonts?

Ahem isn't a real font. It's a dummy font that only has four glyphs and weird sizing. Its glyphs need to have very specific dimensions in order for the test to be accurate. Turning off font smoothing for this font in particular is enforcing those very specific font metrics. Yes, it looks like a hack, but that's far from the whole truth. In the real world, users that change their font sizes would also cause "failures" like this; the specific font metrics of the Ahem font are assumed by the test for accurate results. At worst, you could say it's a hack to set up the necessary conditions for the Acid3 test to run. These font metrics aren't part of the Acid3 test, they are a prerequisite for accurate results.

Bug 17086 is the bug you should be looking at for background. The question is whether or not antialiasing/font smoothing should have an effect on font metrics or if it should be clipped. It may turn out that the Acid3 test is updated to make this a non-issue.

What about such bugs for other fonts? Brushed under the carpet called Acid3 compliance.

Here you go misrepresenting your guesses as actual fact again. If you don't know the details, don't make accusations like that. Should antialiasing/font smoothing increase the size of text slightly or is that a bug? That's a difficult question to ans

Two big reasons that I know of: Firefox 3.0 and Mozilla 2

Most developers are concentrating on getting Firefox 3.0 finished right now. I don't know if people have tried to do too much or if the schedule was too optimistic, but some important features have had difficult getting polished up in time. Just today I read on the changelog that cross-site XHR has been removed, and there's a high chance it won't make it into Firefox 3.0.

But Opera is also dealing with that, and they're doing a lot better. The bigger reason is that Mozilla has been planning a huge refactoring, called "Mozilla 2", for quite a while (e.g. exceptions in C++ code, which were previously forbidden). Many changes needed for Acid 3 are being put off due to that. So much stuff will be changing so drastically that many developers feel it would be a waste to make changes now that will just be ripped out again right after Firefox 3.0 ships.

Mozilla 2 is expected to take at least a year, maybe two or more, so Firefox has once again been caught at a bad time. The wait for a Firefox build that pases Acid 3 is going to be even longer than that for Acid 2. Hopefully Mozilla 2 will be clean and modern enough that future changes can occur more easily.

Also, a small part of of it may be due to Mozilla not accepting bullshit like this.

Opera have said that they get 100/100, but they are not yet claiming victory. They are fixing a brand new implementation, that will be released 'soon', when it is ready. I imagine that the release will involve a ton of regression testing and code quality analysis.

Likewise Safari has various standards that the code has to adhere to. Reading the Webkit blog entries so far I get the feeling that it has not been enough merely to pass a test; there has been extensive consideration the best way to fix the code.

Yes, it's a race, but not at any cost, and the goal is not to just pass Acid3, it's to deliver a better browser.

Thus far, I'm optimistic that Acid3 is improving the overall code quality of the participating browsers.

The Webkit Nightly build. It's not as scary as running other nightlies... just go to http://www.webkit.org/ to download and try it out. The golden compass alone does it for me :)

The problem with races is that the teams do almost anything just to cross the finish line faster.

Do you have any evidence for this?

Any developer worth his salt knows that browsers are huge and complex applications and every change must be discussed, designed and implemented properly as to not impact something else and be modular, be properly commented and be clean and well written code.

No, browsers aren't actually all that large (the rendering engines for the Opera desktop browser and the mobile browser are the same), and you don't have to painstakingly discuss absolutely everything. Nothing would ever get done.

It's true that rushing to meet one goal can cause regressions elsewhere; that is what regression tests are for. And I don't know about Opera, but Safari/Webkit has plenty of them.

I think there is a very good chance of the code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which features are being thrown into the code.

So this is actually just wild-ass speculation and not something you have solid reasons to believe?

Yes, Safari and Opera are both moving fast. Extremely fast compared with Firefox and Internet Explorer. But that is because they are much smaller codebases. Gecko is huge and crufty. Changing one thing can have knock-on effects all over the place. Internet Explorer has three very different rendering engines attempting to remain compatible with years-old intranet applications.

One of the reasons Apple chose KHTML instead of Gecko for Safari was that it was much smaller and had a cleaner design. And that choice has paid off in spades, the turnaround on new features and functionality is extremely quick.

Opera have been focusing on the mobile market for a long time now, it's a core part of their business and a substantial portion of their revenue, so they've always kept the code small and manageable.

What you are seeing here are not crazy hacks, but the consequences of years of savvy architectural and management decisions. When you invest in clean design up-front, the cost of efforts like this is vastly reduced.

http://trac.webkit.org/projects/webkit/changeset/31322

Like this?

. // Workaround for strange CG antialiasing of the Ahem font. Limit to the Web font version.
          261 if (isCustomFont()) {
          262 RetainPtr fullName(AdoptCF, CGFontCopyFullName(m_font.cgFont()));
          263 String nameStr(fullName.get());
          264 m_allowFontSmoothing = (nameStr != "Ahem");
          265 }

What version is getting 96%?

WebKit nightly builds. Just go to http://nightly.webkit.org/, download, and run. It currently gets 96%, tomorrow's will get 98% or better.

Webkit is also up to 98/100 now. It'll probably be there within a day.

http://webkit.org/blog/

Actually, as of today, Safari is also at 98/100. See today's entry in the WebKit blog for more.

or try the Acid2 (no Data) Test from http://hixie.ch/tests/evil/acid/002-no-data/ that will fail as well.

(the Bug is http://bugs.webkit.org/show_bug.cgi?id=4911 )

Opera is based on webkit, the same engine safari uses - developed in large part by Apple. Look it up. http://webkit.org/ ...

Actually, it looks like the Windows version of WebKit isn't open source. Specifically, if you take a look at the build instructions, it seems to require a closed source (and non-redistributable) library called the WebKit Support Library, which is basically a Windows port of CoreFoundation and CoreGraphics.

Basically, you have two choices - reimplement CoreFoundation and CoreGraphics from scratch, or port WebKit over to a different framework. Neither of these is exactly easy, but fortunately Trolltech have done the latter for you with QtWebKit. (Of course, if you're going to use Qt, you could just have used KHTML, which was quite capable even back when Apple forked it.)

Richard Stallman would (rightly) not be happy at this situation, and arguably what Apple have done is forbidden by the LGPL (it's certainly one of the things that the LGPL is designed to protect against), but it's what we've got.

I do think Apple are starting to learn about give & take. See: http://webkit.org/

"Forget corporate blogs -- Apple doesn't seem to like anyone blogging about the company."

Except for Dave Hyatt?

Apple's more complex than anyone seems willing to admit.