Chris Harrelson

What if the developer wants to only bring in or out a toolbar after a delay or certain number of pixels scrolled? For that reason I think an event might...

Hi, this issue has received significant discussion within the Chrome team. Our conclusion: Given all the compat risk, implementation difficulty and potential for developer confusion, Google doesn't think shorthand-ifying `position`...

Hi, reviving this thread. The intent to ship referred to above was approved to ship in Chrome 69 (https://groups.google.com/a/chromium.org/d/msg/blink-dev/QC5iefctcag/HZIo-dIZBAAJ). I have researched the HTML spec w/@pmeenan and identified a proposed...

> Note that there is no preload scanner in the standard, behavior of the preload scanner is not standardized, Right. That is why I am proposing spec edits to explicitly...

> though I'm not sure any browser wants the heuristics they use in the scanners to be restricted too much > > That is true. There's a fine line to...

> @chrishtr can you give an update of what has happened on this front for Chromium since [#1349 (comment)](https://github.com/whatwg/html/issues/1349#issuecomment-391475650) ? Here is what has happened since then: 1. The behavior...

I also updated [this page](https://github.com/chrishtr/rendering/blob/master/stylesheet-loading-behavior.md) with the latest status.

@zcorpan can you remind me of the latest status? Does the spec align with the Blink behavior to not start rendering updates until head stylesheets and scripts finish loading, and...

> @chrishtr yes, it's specified as part of https://html.spec.whatwg.org/#render-blocking-mechanism which was formalized in #7474 (cc @xiaochengh) Great thanks! That's just what I needed. > Or, I guess, the Firefox behavior...

> From what I understand from the above what's "blocked" are the tree mutations following the insertion of the stylesheet. You could still tokenize and prepare changesets. You just can't...