Re: [csswg-drafts] [selectors] Add :before-load() pseudo-class (#4462)

As a high-level critique: this doesn't belong on a pseudo-class, as it isn't something that'll vary by element. It belongs in a MQ, like `(page-state: loading)` or something.


I'd have to go archive-diving, but I'm pretty sure we've discussed something like this in the past. I think there were two big strikes against it:

* You've already alluded to this, that there are several notions of "loading" that might be relevant, and it's kinda difficult to refer to them without weird terminology or being overly specific. And some notions of loading are page-specific, like "wait for this fetch to complete before showing this element".
* JS already has all the knowledge necessary to handle this itself, since it can respond to the relevant events and can add/remove classes from the root element accordingly.

Like you said tho, it is true that JS cannot *both* (a) have things invisible immediately on page load, and (b) fail-open by having them become visible if JS is blocked or errors. That would be a decent argument for providing this functionality in a MQ, with examples and warning text telling you how to use it "safely". (Which I suspect would be more natural anyway, as hiding things feels like an "exception" and thus is more natural to segregate away inside a MQ block, rather than hiding by default and putting your normal styles there.)


A big question is thus, what loading transitions would we want to care about? Almost certainly the 'DOMContentLoaded' event, and maybe the 'load' event; anything else?  The benefit of those two is that it maps cleanly to the `document.readyState` enum; a page starts in "loading", goes to "interactive" when `DOMContentLoaded` fires, and goes to "complete" when `load` fires.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Monday, 28 October 2019 19:06:32 UTC