6 ms·

WebKit for Developers

318 points by paulirish 14y ago

leeoniya 14y 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?
- Surio 14y ago
  I can confirm this too. Can only be intentional
  - paulirish 14y 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.
    - paulirish 14y ago
      Addressed. I bet it was a focus() coming from inside the iframe slidedeck embed.
      - wasd 14y ago
        Still an issue.
    - arturkim 14y ago
      Weird bug indeed. Is that code provided by Google? It seems that 1953569843-viewer_core.js was causing that.
petepete 14y 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).
- Surio 14y 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 14y ago
  *sad panda* @hzr The switch to WebKit unfortunately means that Opera Dragonfly is no more. https://twitter.com/runeh/status/301616059729969152 https://twitter.com/runeh/status/301616059729969152 And yes, it is/was an amazing tool. My favourite web inspector by a mile.
cpleppert 14y 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.
- abarth 14y 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 14y 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 14y 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?
- paulirish 14y 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 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/ http://www.html5rocks.com/en/tutorials/games/abouttracing/
  - Mahn 14y 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 14y 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 http://trac.webkit.org/browser/trunk/LayoutTests) is a fascinating line of sight into the testing that goes on for the core.
eridius 14y 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-threaded-html-parser-and-background-blending/ https://www.webkit.org/blog/2259/last-week-in-webkit-threade...
- abarth 14y 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. :)
  - eridius 14y ago
    Oh? So the "Last week in WebKit" isn't actually in the nightlies yet? Interesting.
    - paulirish 14y ago
      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.
    - abarth 14y ago
      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.
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- wyuenho 14y ago
zobzu 14y 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 14y ago
  why?
taeric 14y 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 14y ago
  For context, check out the video of the presentation where I made this point: http://www.youtube.com/watch?v=kiPe7DPmEgE 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).
  - taeric 14y 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 14y 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 14y 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&list=PL_gU0T3qTDt-1nyGuNoqKW3N5BYDNlZ3y&feature=results_main http://www.youtube.com/watch?v=GGzmST5nNSM&playnext=1&#3... Some more really good tech talks @ https://www.airbnb.com/techtalks https://www.airbnb.com/techtalks
kybernetikos 14y 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 14y 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 14y 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 14y ago
Just curious - How close is WebKit in terms of complexity, to the Linux Kernel?
daredevildave 14y 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 14y ago
@paulirish FYI the link to CoreFoundation is invalid http://developer.apple.com/corefoundation/%3Cbr%20/%3E http://developer.apple.com/corefoundation/%3Cbr%20/%3E

318 points by paulirish 14y 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?

Surio 14y ago
I can confirm this too. Can only be intentional
- paulirish 14y 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.
  - paulirish 14y ago
    Addressed. I bet it was a focus() coming from inside the iframe slidedeck embed.
    - wasd 14y ago
      Still an issue.
  - arturkim 14y ago
    Weird bug indeed. Is that code provided by Google? It seems that 1953569843-viewer_core.js was causing that.

petepete 14y 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).

Surio 14y 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 14y ago
*sad panda* @hzr The switch to WebKit unfortunately means that Opera Dragonfly is no more. https://twitter.com/runeh/status/301616059729969152 https://twitter.com/runeh/status/301616059729969152 And yes, it is/was an amazing tool. My favourite web inspector by a mile.

cpleppert 14y 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.

abarth 14y 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 14y 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 14y 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?

paulirish 14y 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 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/ http://www.html5rocks.com/en/tutorials/games/abouttracing/
- Mahn 14y 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 14y 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 http://trac.webkit.org/browser/trunk/LayoutTests) is a fascinating line of sight into the testing that goes on for the core.

eridius 14y 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-threaded-html-parser-and-background-blending/ https://www.webkit.org/blog/2259/last-week-in-webkit-threade...

abarth 14y 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. :)
- eridius 14y ago
  Oh? So the "Last week in WebKit" isn't actually in the nightlies yet? Interesting.
  - paulirish 14y ago
    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.
  - abarth 14y ago
    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.
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
wyuenho 14y ago

zobzu 14y 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 14y ago
why?

taeric 14y 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 14y ago
For context, check out the video of the presentation where I made this point: http://www.youtube.com/watch?v=kiPe7DPmEgE 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).
- taeric 14y 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 14y 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 14y 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&list=PL_gU0T3qTDt-1nyGuNoqKW3N5BYDNlZ3y&feature=results_main http://www.youtube.com/watch?v=GGzmST5nNSM&playnext=1&#3... Some more really good tech talks @ https://www.airbnb.com/techtalks https://www.airbnb.com/techtalks

kybernetikos 14y 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 14y 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 14y 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 14y ago

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

daredevildave 14y 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 14y ago

@paulirish FYI the link to CoreFoundation is invalid http://developer.apple.com/corefoundation/%3Cbr%20/%3E http://developer.apple.com/corefoundation/%3Cbr%20/%3E