Very interesting article. I never really understood the nuances of the different WebKit ports (and once naively assumed that WebKit === WebKit). I also didn't have an appreciation for the amount of work going in behind the scenes. The link referenced in the article (http://trac.webkit.org/browser/trunk/LayoutTests) is a fascinating line of sight into the testing that goes on for the core.
This is why the webkit- prefix is nearly worthless. I've had a lot of problems where chrome and safari were rendering prefixed things differently and I couldn't target them individually, because they both use the same prefix. This is the whole point of having the prefixes!
"CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-."
Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right?
I'm one of the developers of threaded HTML parsing in WebKit. Threaded HTML parsing is only enabled in Chromium (for now). We're still working through the kinks. :)
It'd be better to think of it as "Last week in the WebKit project". As as the post points out, the WebKit nightly is only representative of the mac port of WebKit, which Apple mostly calls the shots on. In many cases Apple takes a conservative approach when enabling features that other ports may be implementing or experimenting with.
Shadow DOM is also turned on for Webkit nightly. This article makes Chrome sound so much more advanced when in reality Webkit is only a couple of weeks behind.
I also have never seen people using -khtml- and -apple- prefixes.
I've only dabbled with the Shadow DOM, so maybe I'm missing something, but I just tried it in a webkit nightly and it did not seem accessible. The link in the article seems pretty convincing, though I can't conclusively judge from that that it's not enabled yet.
Also, the "also" in "also turned on" seems a little bit out of place considering the sibling comment to yours.
I don't really get the initial point. The browser is, for most developers, a black box. And it should probably stay that way. Ideally, it is an exchangable black box.
TL;DR: to build efficient applications in the browser, you do need to understand how the browser works. Just like understanding how an operating system works will help you design good applications for the OS (especially when it comes to performance).
I think my concern is that more of us should just follow the standards and build a minimal document for the users. Obviously, those of us that need efficiency should know what we are doing. But, just as the vast majority of programmers today have high zero understanding of cache impact on algorithm performance, the vast majority have little understanding how browsers do their thing.
Is it worth knowing for other purposes? Well, I think so. It is worth knowing just to know, if no other reason. And it is also worth knowing in the cases where you are building something highly specialized. However, when I see things like the template tag making it in to webkit, we are no longer treating it as a blackbox where we focus on inputs and outputs. Instead, a growing number are getting to muck around in the internals.
Is this bad? I honestly can not say. However, I do know that from my perspective web apps have not been getting more impressive. Nor do I feel I am missing something from them. Seems if folks want items that are as efficient as you are alluding to, you should be doing a native application.
Does anyone know why there are two different font paths and how WebCore chooses which one to use? I assume the difference between fast and complex would be very platform dependent.
The fast path is for most languages where the text glyphs are placed in order. The complex path is for languages where the shape and size of a glyph depends on the characters around it. For example, Arabic text or Thai text would go through the complex code path. There are some other cases where the complex text path is used (I think "text-rendering: optimizeLegibility" forces the complex text path).
In Safari and most of the time on Chromium Mac, the complex code path is handled by CoreText. In other Chromium ports and on Blackberry, complex text is handled by Harfbuzz-NG, which is also used by Firefox.
The fast path is much faster and handles the common case. The complex path is, well, complex, but it's the "all sing, all dance" path that handles all the difficult cases.
Is anyone aware of any resources that shows you how to setup your machine to see how an HTML page is rendered in Webkit, step by step, like remote debugging?
The Chrome DevTools timeline gives a solid overview of the construction of each page. You can see the progression of grabbing network assets, Parsing HTML, Recalculating styles, Layout (aka reflow), Paint, Compositing
I'm working on a project to embed WebKit in vehicles. One of the things I'm interested in doing is running a suite of tests to ascertain things like compliance with various specs and performance. I see the 28k layout tests in the WebKit repo, but would be interested in any other tests -- especially those that can be easily loaded into an iframe.
