[css-cascade] Relax the restriction for @import to precede all other rules

[LeaVerou]

I've recently come across a number of cases where stylesheets were concatenated, making previously valid @import rules invalid. It was quite annoying to need to write code to hoist them manually.

Also, them having to be first means they cannot be used to import rules that should override other rules.
It also means that related code cannot be kept together, but needs to be scattered in multiple places.

Is there an implementation reason why these rules need to precede most other rules?
Would it be feasible in terms of web compat to relax this?

[fantasai]

Yes, there's implementation reasons. @emilio can give a proper explanation, but basically the UA wants to kick off loading all the stylesheets before it gets done parsing everything.

(Untagging cascade-4/5 since we're done with feature work in those levels. We're just blocked on fixing #4838 and #5864 before transitioning to CR.)

[tabatkins]

It also complexifies the "in document order" part of cascade; currently all the styles in a given stylesheet are grouped together in document order, so you can just check if two styles come from the same stylesheet or not, and only dive into their exact position in they do. If @import can go anywhere, this is no longer true, as rules from one sheet can go before or after rules from another sheet.

[emilio]

Yes, there's implementation reasons. @emilio can give a proper explanation, but basically the UA wants to kick off loading all the stylesheets before it gets done parsing everything.

The details here are that browsers want to speculatively load @import rules that appear on <style> elements (which are fairly common unfortunately). Since you don't want to run a full CSS parser straight from the HTML parsing stage, and we only want to deal with @import, all browsers have a crappy-ish parser to scan for those URLs (Gecko, WebKit, Chromium). Allowing at-import anywhere would mean that we would need to both teach those scanners better (to deal with everything that may appear before an import rule), and run them on the whole input in order to do the preloading, which is quite unfortunate.

[LeaVerou]

Thank you so much @emilio for hunting down those parts of the sources too!

Excuse my naïveté, but if the scanner remains unsophisticated and just drops the terminating condition for scanning @import, the main problem is false positives, right? I.e. preloading URLs that shouldn't have been loaded, because we matched an @import rule that isn't real. I'm not sure how a false negative could happen. And even for false positives, they would be exceedingly uncommon, so maybe it's an acceptable tradeoff?

[emilio]

The main issue is not dropping the terminating condition or what not. Right now those scanners stop scanning as soon as they find something unexpected. With @import being able to go anywhere, that means we couldn't do that (or alternatively that pages using @import at the bottom of a stylesheet would be slower, which is bad).

[fantasai]

Closing WONTFIX, @LeaVerou feel free to re-open if you feel it needs to be raised to the WG, but I think it's pretty clear we can't change this.