FWIW, I think it's fine to fix the things we can fix without doing a complete overhaul, especially if the overhaul isn't moving forward.

Would appreciate some feedback on the direction this is going @annevk. As it stands, this PR attempts to specify:

• When CSS style sheets become non-script-blocking
• (I'm pretty sure) when document.styleSheets, element.sheet, and style rules in general are available to scripts (Define more exactly when document.styleSheets is updated #696)

Building off of #696 (comment), with this PR I think the order of loading <link> style sheets would be as such:

1. Create the CSS style sheet
   • It should not be available to scripts in any way yet though
2. Obtain the style sheet
3. Queue a microtask to:
   • Fire a load/error event at the link element
   • Set the associated style sheet's "done" flag, if there is an assoc ss
4. (Somehow magically use the response body to create CSS rules for the style sheet)
5. "Add" the style sheet, making it available via document.styleSheets, element.sheet, and I think scripts in general (via its rules)
   .....
6. Finally later the microtask is queued, and the style sheet no longer blocks scripts

I think what you want is roughly this:

1. In parallel:
   1. Fetch the style sheet.
   2. Parse the style sheet.
   3. Queue a task to:
      1. Create "main thread" data structures, add them to the appropriate places.
      2. Set the done flag.
      3. Fire an event.

Hope that helps. Microtasks aren't the right fit here, since the work is happening "in parallel".

(Let me know if you still need detailed feedback on the existing PR, given the above.)

@annevk Ping for review /cc @domenic as well since it is somewhat related to #3544 (I plan on breaking that PR into stuff that can be merged now, and stuff that needs more work (critical subresource hairiness etc).

We talked on IRC about changing/refining directions a bit, so just for the record here, I'll also respond to a few points on this thread before pushing changes up later.

From what I can tell from the diff, you basically replaced "style sheet ready flag" with "style sheet done flag". "ready flag" ..... And although the PR appears to set the done flag more explicitly, the previous version was also OK-ish;

It is mostly a name change and more explicit "setting", yeah (original comment here), with the intention of more-clearly specifying the ordering of the error/load event and when scripting is unblocked.

and how CSSOM seems to assume that "CSS style sheets" always get created-and-added together, not separately.

I agree; it seems my first go at this rather weakly ensures a created style sheet is only added/available to scripts after the error/load event fires, stemming from an assumption WRT when these steps run in relation to the task queued in the para under concept-link-obtain, but that will be cleaned up!

or counter, or something to the Document object.

ACK. As discussed, a counter seems like a nice way to do it and bring some simplicity, and happens to be how Chromium implements this.

Ok I think I addressed everything :) Thanks for the heavy review churn here. Perhaps we can make this followup into a good first issue?

Latest commit here moves the link style sheet event firing after the ss gets "created", and guards both the creation and load firing with a success==true check.

@domfarolino do you want to try to write a commit message that summarizes all the great work here? One that tries to give a sense of both normative changes and editorial ones, and also points to any followup or related issues (such as my PR which this mostly replaces).

Looks like tests are in progress over at web-platform-tests/wpt#14899, so this looks ready to land to me!

Sounds good I will get on it!

Tests: web-platform-tests/wpt#14899. It might be worth testing the DOM manipulation task source => networking task source change a bit more however...

Bugs:

• Blink:
  • https://crbug.com/922716
  • (Somewhat unrelated): https://crbug.com/922618
• WebKit:
  • https://bugs.webkit.org/show_bug.cgi?id=193512
  • (Somewhat unrelated) https://bugs.webkit.org/show_bug.cgi?id=193497
• Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1520660

Task source changes seem almost untestable to me; I'd be curious if you come up with something. Maybe stochastic tests, but nobody likes putting those on their bots :-/.

Commit message:

Specify when style sheets no longer block scripts

 * Introduces new link loading infrastructure, specifically algorithms
   to fetch and process linked resources that are overridable by the
   individual link types
 * Specify the order in which style sheets are removed, created/added,
   their corresponding load/error events are fired, and scripting is
   unblocked from a loading style sheet
 * Replace "style sheet done" flag with Document's "script-blocking
   style sheet counter", which works in tandem with the "contributes a
   script-blocking style sheet"
   conditions, which replaces the definition of "a style sheet that is
   blocking scripts"
 * <link> load/fire events are fired from tasks queued on the networking
   task source
 * Handles much of what #3544 set out to do, minus defining and
   explicitly fetching a style sheet's critical subresources

Fixes #3610. 

Tests: https://github.com/web-platform-tests/wpt/pull/14899