8 ms·
What forces layout/reflow in Chrome
- josteink 11y agoSounds like a ripe opportunity to write browser and implementation-specific JavaScript instead of trying to solve real world problems in a readable and reusable manner. This would be more interesting if it wasn't specific to Chrome only, but looked at the web at large. Maybe specs/things like this could be extended to be part of the standard instead?
- AgentME 11y agoAren't all of those properties/methods standardized to query something about the document that require it to be laid out? What do you think the standards are lacking here?
- josteink 11y agoIt may have been some of a gut-reaction on my part (and I'm willing to admit that), but my main gripe with documents like this is that at the moment tons of web-developers are targeting Chrome only. When something breaks in Firefox, Safari, Vivaldi, Edge or other browsers (because obviously it was never tested outside Chrome) their answer is usually "Just use Chrome". This is now not only happening at amateur-hour shows and quick Github POCs, but also at official products from big names like Google. Basically "This website best viewed in Chrome". Haven't we already been there? We saw how that worked out, didn't we? That sort of attitude is not healthy for the web at large, and documents like this will (IMO) further entrench that attitude, rather than the opposite.
- ultim8k 11y agoDevelopers (and me as one of them) seek their sanity. They try to achieve what they've been asked to, by following the specs. There are some browsers that are always up-to-date with the specs, and there are other browsers that still have 5 year old bugs to fix.
- josteink 11y agoIf those browsers are still in popular use, and you call yourself a professional web developer, you test and ensure things work in those old and terrible browsers too though. But like I said, there are plenty of amateur-hour gigs following your play-book. You decide which group you want to identify with. For me part, I know which I represent. And thus for a small rant: On a side note, I love how web-developers these days have the nerve to tell people how hard their job is because they have to support several browsers. Cry me a river. Nobody's job has ever been easier than yours. Do you have to deal with messages not getting through in a message pump when threads are involved? Do you have to deal with how GPU accelerated graphics frameworks magically sometimes not showing windows when run in a Citrix TS, but with faulty Intel GPU drivers on the server? Have you ever tried to figure out why your code isn't getting the correct registry-entries, which you can see is there in a mixed 32-64 registry mess? Why that setting a configured was never shell-expanded, causing your script to break 3 layers in? Have you ever tried to debug why the file you just released a handle for is still locked, by yourself? Etc etc. These things a million times every day. Web-developers have it so easy peasy as no other programmer in the history of programmers. I'll admit that's an opinion, but I'm pretty sure it closer to a fact. Signed someone who has delivered cross-platform products, on-premise software across several versions and decades, with demands that nothing should ever be broken no matter what.
- ultim8k 11y agoAnd yes my job is 'easy'. And I personally try to always serve legacy browsers too. And yes I will always complain until those browsers will finally fix their bugs and implement what the specs say.
- andybak 11y ago> If those browsers are still in popular use, and you call yourself a professional web developer, you test and ensure things work in those old and terrible browsers too though. That's not my decision to make as it impacts production costs. The person paying the bills should be the one that makes the decision and my job is to inform him of the probable costs and provide statistics so he can measure the cost vs benefit for his intended audience.
- gopowerranger 11y ago>at the moment tons of web-developers are targeting Chrome only. I'm a web developer and, in my 11 years of doing this, the only people I've ever seen do that are those experimenting with a new feature that only works in Chrome or rank amateurs. Knowledgeable web developers write code to standards, not browsers.
- kuschku 11y agoWhatsApp Web? Google Inbox? Very good examples that were unnecessarily "only works in Chrome". Changing your User agent also allowed you to use both in Firefox.
- Moter8 11y agoBoth of these did not allow other browser when they were released, today both work fine on FF. Details on why Inbox wasn't available at first are available in this thread: https://news.ycombinator.com/item?id=8606879 https://news.ycombinator.com/item?id=8606879
- kuschku 11y agoAnd still, for a few months two recent web products were limited to one browser, which is used by a minority, and is in many countries not even the largest minority.
- gsnedders 11y agoAnd still rely on UA hackery in Opera, which given in principle it relies on the same version of the Chromium Content API as the current Chrome release, it's fairly obvious it's a business decision and not a technical one.
- gsnedders 11y ago> Knowledgeable web developers write code to standards, not browsers. Really? I certainly don't try and work out how the spec says the document should render — I trust if browsers interoperably render the document the same, that's what the spec says. And I'm not someone scared of specs, having contributed to them for years and worked on browsers for years.
- nostrademons 11y agoYou can take a look at the diffs between this and what the list was in 2011 for Webkit: http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-... They look basically the same to me - this part of a browser layout engine hasn't changed much, and probably isn't likely to unless Chrome goes all GPU-rendering. And it includes Webkit browsers as well, so it's also Safari, mobile Safari, Opera, and Android Browser.
- paulirish 11y agoJust FYI: GPU can only used for accelerated compositing (animations) and rasterization (faster paint). We'll need new or async APIs for this stuff to significantly change things at the platform level. In the meantime, we have Virtual DOM and maybe a transactional API for read/write to help alleviate the common cases. Thx for linking up Tony's post btw!
- paulirish 11y agoThis stuff is 90% consistent cross-browser, but it's possible IE has a larger list, or smaller list. In retrospect, I coulda left off the "Chrome" specifier on it.
- _ZeD_ 11y agoI needed to know these "implementation details" between css layout and javascript also regarding css transitions: http://stackoverflow.com/questions/12088819/css-transitions-on-new-elements http://stackoverflow.com/questions/12088819/css-transitions-... tldr: you can "fade in" a new element only if you trigger a reflow at the right moment
- amelius 11y agoSpeaking about reflow, I'm wondering: if I have a piece of text that contains multiple paragraphs, and I change a single character in the text, will Chrome recompute the layout for all paragraphs? Is changing a character a O(1) operation w.r.t. the number of paragraphs?
- wingnut 11y agoI don't know, but proudly showcasing the fact you've got a hardon for a crappy dead hack like DFW is absolutely O(1)
- gsnedders 11y agoIt depends if it creates a new line (and therefore a new line box).
- paulirish 11y agoJust tried this out and the answer is yes. All subsequent elements will have layout recomputed. There is some room for optimization here (evaluate if the flow content requires new text-wrapping across lineboxes), but luckily these layouts are quite fast. Establishing containers as layout roots (generally fixed height/width and overflow:hidden) will constrain these sorts of costs.
- greggman 11y agoAnd are none of them cached? If I go var w = element.clientWidth; var h = element.clientHeight; Is that 2 reflows or 1? var w1 = element1.clientWidth; var h1 = element1.clientHeight; var w2 = element2.clientWidth; var h2 = element2.clientHeight; Is this 4 reflows, 2, or 1? --- reading this article (https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing?hl=en https://developers.google.com/web/fundamentals/performance/r...) it sounds like it's 0 reflows if nothing has changed. In other words it's all cached
- dmethvin 11y agoIf the layout isn't "dirty" from a change, then it doesn't need to reflow.
- paulirish 11y agoThey cause immediate reflow only if the DOM is dirty. In both cases it'd be a maximum of 1. This'd be 2: element.textContent = 'omg'; var w = element.clientWidth; elem.classList.add('ok'); var h = element.clientHeight;
- jffry 11y agoAnd it's especially bad if you interleave them all: var heights = lotsOfElements.map(function(el){ el.classList.add('ok'); return el.clientHeight; }); Better is to batch the DOM updates and reads, where you can: lotsOfElements.forEach(function(el){ el.classList.add('ok'); }); var heights = lotsOfElements.map(function(el){ return el.clientHeight; });
- dmethvin 11y agoFor specifics on which CSS properties affect layout, see csstriggers.com .
- idibidiart 11y agoFunny, Chrome uses link for rendering and the article talks about WebKit.
- idibidiart 11y agoFunny, Chrome uses Blink for rendering and the article talks about WebKit.
- dangrossman 11y agoUnder the heading "Other browsers"?
- andrewguenther 11y agoBlink is a fork of WebKit and still behaves largely the same. Chrome really hasn't done a whole lot to the underlying layout/reflow logic...yet.
- jimrandomh 11y agoOne related thing that's caused me some grief is that in Chrome, the cost of a layout is O(n) in the number of hidden elements; so if there's a large number of DOM nodes hidden inside a node with display:none, they still slow down reflows.
- paulirish 11y agoSomewhat. "Reflow" is typically what we call forced 1) Style Recalc and 2) Layout. Any hidden DOM elements have zero cost during Layout, as they are absent in the LayoutTree. However they can contribute to recalc, just while the browser confirms that they are still display:none.
- pcwalton 11y agoNote that in Servo a lot of reflows can be done off the main thread, not synchronously. Don't take this list as something that will be true for all time. Even if the APIs in question require synchronous reflows now because they return some data, it may be possible to introduce new APIs that receive the data in a callback. (The usefulness of these APIs depends on the engine having support for off main thread layout, of course.)
- magicalist 11y agoInteresting. How is something like e.g. reading offsetTop done asynchronously? The js would still need immediate access to the value.
- pcwalton 11y agoWe'd need a new API for it.
- paulirish 11y agoYes! This has me quite excited about Servo. Chrome is interested in async APIs for these as well. Random aside: Dart's DOM originally offered these properties only as async but developers were unhappy with the ergonomics so Dart ended up delivering the sync APIs. :/