WebKit for Developers

http://paulirish.com/2013/webkit-for-developers/

by paulirish • 13 years ago

318 36 13 years ago

leeoniya• 13 years ago

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?

Surio2• 13 years ago

I can confirm this too. Can only be intentional

paulirish4• 13 years ago

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.

petepete• 13 years ago

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

Surio2• 13 years ago

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)

kmfrk• 13 years ago

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

cpleppert• 13 years ago

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.

abarth3• 13 years ago

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.

idealisms• 13 years ago

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.

ireadzalot• 13 years ago

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?

paulirish4• 13 years ago

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/

Mahn• 13 years ago

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

maerek• 13 years ago

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.

eridius2• 13 years ago

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

abarth3• 13 years ago

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

eridius2• 13 years ago

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

wyuenho• 13 years ago

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.

magicalist• 13 years ago

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.

zobzu• 13 years ago

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

Makes me uncomfortable.

Volpe• 13 years ago

why?

taeric2• 13 years ago

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.

igrigorik• 13 years ago

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

taeric2• 13 years ago

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.

zenocon• 13 years ago

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.

buildnship• 13 years ago

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

kybernetikos• 13 years ago

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!

jaredmcateer• 13 years ago

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

eric-hu• 13 years ago

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

WayneDB• 13 years ago

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

daredevildave• 13 years ago

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.

autoreverse• 13 years ago

@paulirish FYI the link to CoreFoundation is invalid

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

WebKit for Developers

Related Stories