Simon Pieters

> > That is why I am proposing spec edits to explicitly specify a preload scanner. > > Great. I can work on such a specification. Is there interest for...

Thank you @chrishtr! Since specifying the speculative parser is only one part of the overall proposal for this issue, I think it's clearer to separate it out to a new...

@chrishtr yes, it's specified as part of https://html.spec.whatwg.org/#render-blocking-mechanism which was formalized in #7474 (cc @xiaochengh)

So maybe we can close this issue?

No, `` doesn't block the parser in the spec. https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inhead I had missed (or maybe forgotten) that Chromium now blocks the parser for in-body stylesheets. @hsivonen @annevk thoughts about this...

Looks good. I think some things can be tested, e.g. with reftest you can check that `` is the same as ``, and that `foo` != `foo`

For reference, this was fixed in Gecko in https://bugzilla.mozilla.org/show_bug.cgi?id=1595491

No, auto-sizing still happens. We also don't update `window.length` or allow the `object` to be targeted by links. Testing with https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14032 it seems WebKit and Chromium now create a normal...

Hmmm, I don't like including file extensions from the system registry... https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14043 shows which image file extensions get the "image" treatment in Chromium and WebKit. (The list of extensions comes...

It seems .swf also doesn't get a browsing context, though. Is the not-supported-plugin path a hardcoded list of extensions?