WebKit for Developers | Hacker News Reader

WebKit for Developers

paulirish.com

318 pointspaulirish36 comments

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!

You can target them, write -webkit and then -apple, chrome will use webkit, safari will use apple due to the nature of css.

"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?

> So first, WebKit parses HTML the same way. Well, except Chromium is the only port so far to enable threaded HTML parsing support.

Nope. Recent WebKit Nightlies have threaded HTML parsing as well.

https://www.webkit.org/blog/2259/last-week-in-webkit-threade...

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. :)

Oh? So the "Last week in WebKit" isn't actually in the nightlies yet? Interesting.

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.

Peter's posts talk about everything that's going on in the WebKit project. The nightlies are just builds of Apple's Mac OS X and Windows ports.

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.

Still a neat article. I just find that point odd.

For context, check out the video of the presentation where I made this point: http://www.youtube.com/watch?v=kiPe7DPmEgE.

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.

I'm interested to see whether Opera's move to WebKit means the end of the Dragonfly suite of tools (which are fantastic, by the way).

Very good point. I am curious about this point too.

However, dragonfly is open source too. :-) So there's every chance someone will fork it and take it forward to keep it going on Opera (one hopes)

   *sad panda* @hzr The switch to WebKit unfortunately means
   that Opera Dragonfly is no more.

https://twitter.com/runeh/status/301616059729969152

And yes, it is/was an amazing tool. My favourite web inspector by a mile.

I'm a little surprised by this line, in reference to Chrome on iOS:

    "Also, for what it’s worth, JavaScript is so rarely the
    bottleneck on mobile that the lack of JITting compiler 
    has minimal impact."

But then I'm making HTML5 games so JavaScript performance is pretty much the only thing I care about.

Levi Weintraub has a really great tech talk hosted at airbnb, where he talks abouts all the different aspects of WebKit and it's components: http://www.youtube.com/watch?v=GGzmST5nNSM&playnext=1...

Some more really good tech talks @ https://www.airbnb.com/techtalks

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 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.

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.

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

Here's a trace of this page, for example: http://paulirish.com/i/dd8f40.png

A far more low-level view is available in about:tracing - More on that here http://www.html5rocks.com/en/tutorials/games/abouttracing/

+1 the timeline tool is great. Whenever you have performance issues in a web app and javascript is not the culprit, that's the tool to turn to.

in FF, on every page load the page scroll jumps to around the "Opera just moved to WebKit. How does that play out?" section. is this intentional?

I can confirm this too. Can only be intentional

Not intentional. I believe it's the embedded slide deck afterwards. I'll de-embed it for the time being. Weird bug, not sure whose it is, yet.

Addressed. I bet it was a focus() coming from inside the iframe slidedeck embed.

Still an issue.

Weird bug indeed. Is that code provided by Google? It seems that 1953569843-viewer_core.js was causing that.

Reading the article, it sounds like "its cool because now you only have to 'dev for webkit' and forget the rest".

Makes me uncomfortable.

why?

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.

@paulirish FYI the link to CoreFoundation is invalid

http://developer.apple.com/corefoundation/%3Cbr%20/%3E

Just curious - How close is WebKit in terms of complexity, to the Linux Kernel?

Reply on news.ycombinator.com