Sangwhan: the more I think about it the more harmful I feel it is. What this tries to do is introduce a attribute to async loaded subresources to block the render. To prevent unstyled flashing. Which I an understand why they want to do it but I'm not so sure if the gains outweigh the harm. The risk is eg if a resource marked as blocking is incredibly heavy and you're on a slow network. Right now you get some progressive rendering, you can read unstyled text. Another thing is if an ad script is 'blocking', which it shouldn't, but.

Dan: who gets to say what's blocking?

Peter: on the tag

Dan: for instance publishers or websites could be compelled to set it as blocking by advertisers

Sangwhan: advertisers have every incentive to set it to blocking, because it guarantees they will have an impression. If the user quicky navigates away now they won't get an ipression. It would be in ad networks greatest interst to set it as blocking, but taht would be harmful because its a massive pile of js that is not relevant to the content.

Amy: how would that play with ad blockers? Would nothing load?

Sangwhan: the fetch fails if there's an ad blocker. If the fetch fails in their proposal then it's fine, shouldn't block it.

Peter: and they do accept you may still want to time out. Their use cases are weak. One is loading a font. Webkit used to do this with 30 second timeouts on fonts, and users were staring at blank pages while the font loaded. That was bad and you can control it with css, why add something else?

Sangwhan: if you do this with cjk fonts that's going to be fun... they're like 5mb

Peter: they can be. They give a use case of using a script to inject a stylesheet and you want it to be blocking. Seems like you're already kind of past the..

Dan: aren't all of these cases antithetical to the spirit of the web?

Sangwhan: it disobeys our previous stance on making everything async friendly. Suddenly this is adding a big block of sync in an async system. Feels like it would be abused too much.

Peter: example of wanting to block render on an async script load.. seems completely counterintuitive to me.

Sangwhan: if it's just to prevent the flashing of unstyled content, a weak story. The design should be revisited.

Dan: Sounds strong enough to leave feedback along those lines

Sangwhan: one way it could be approached with this design is the site does that but the user is presented with a dialog that indicates preference... seems like too much..

Dan: if the use cases are as weak.. who is asking for this? What's the pressure?

Peter: what user need is this serving? As far as I can tell the need is for developers to work around issues with frameworks

Sangwhan: if you have a massive SPA but a webpage that loads before that.. I guess that.. making a block and not showing the html part maybe makes sense? Still seems weak.

Dan: we should leave feedback

Peter: just wanting to make sure we have broader consensus [will leave comment]

Use case for font blocking is replicating controls already available in CSS: https://drafts.csswg.org/css-fonts-4/#font-rendering-controls-introduction

Blocking is bad do we really want to add more mechanisms to do this arbitrarily?

Discuss in plenary

left comment channeling Sangwhan's comments

Peter: they removed a large part of the functionality... now this only effects scripts and stylesheets... So curious as those are generally blocking things what does this do?

... they've added the ability to block rendering... doesn't block parsing but does run before rendering starts... I'm kind of OK with that.... opting in to async processing... don't understand what this does with stylesheets.

Dan: No signals on multi-stakeholder support. Does that matter?

Rossen: have we discussed having the multi-stakeholder thing automated ... so it's part of the form?... standing issue...

Tess: I like that idea...

Rossen: should be part of the template of the form.

Tess: multiple, interoperable implementations ++

Dan: I'll take a look at what we can do in the issue template

Peter: back to issue their use case still seems to be delibately blocking ... could be bad on a slow connection. Also numerous issues in CSS wg ... related to web fonts. We fixed that in CSS... I'm happy to let this proceed for script but not happy with it on style.

Rossen: +1

Peter: will leave feedback accordingly

Peter: sangwhan had concerns about handling of CJK fonts... blocking would not be good. CSS already has controls over web fonts loading.. so I was pushing "why this"....

... response doesn't make a lot of sense to me ...

Lea: I don't understand why they say "We are indeed pursuing CSS-based approaches to for rendering control with web fonts" - I think these solutions are out there and working for a while now.

Peter: agree. They do link to a CSS issue. Maybe looking to tweak it...

Dan: looks like this has been stuck since August...

Lea: we should look at the CSS working group thread...

Peter: it was discussed in CSS wg...

Peter: my understanding... won't block on "critical subresources" - my understanding is a style tag with an inline style sheet then that becomes blocking...

Lea: I believe so. Do they want to block for subresources as well?

Peter: only "critical" - only other import stylesheets. Doesn't sound like it's a change in behaviour.

Lea: seems like this is already happening...?

Peter: mainly the ability to add the blocking to the link tag which is currently not blocking.

...

Lea: looking at the explainer... "The user agent will not render any pixels ..." They are adding blocking=render to an async script...

Peter: Sangwhan amd I discussed the script use case and we were OK with it.

... remaining concerns were about style sheets... but if they are already blocking in all cases then ... ?

Lea: clearly it's not because people involved in this are not new to this whole thing.

Lea: suggest: "As currently written your explainer doesn't answer the question... "

Peter: in explainer they're talking about a script tag that injects a link tag and they want that to be blocking.

... so it's mostly about when tags get injected later.

Dan: if it's about when tags get injected that sounds useful. If it's mimicking existing behaviour but covering that case, can we close and say it looks good?

Peter: slightly concerned that adding more mechanisms to block rendering will increase time to first paint.

Lea: it's in the developer's interest to have fast loading pages... But there are now multiple subtly different mechanisms for blocking different things and that's difficult for developers.

Peter: use case of letting script inject style tags - will be used for feature detection e.g. - i would argue that should be handled by pure CSS. So this seems like doing CSS in JS in some cases...

Dan: can we raise these points - developer complexity and duplicating a functionality that CSS ought to be doing anyway - as part of our review? Satisfied with concerns?

Peter: that works for me.

Lea: yeah.

Peter: after the meeting I'll close it.