Intent to implement and ship: blocking=render on inline scripts

[Noam Rosenthal]

Contact emails

nrose...@chromium.org

Explainer

None (this is a small change to an existing feature)

Specification

https://github.com/whatwg/html/pull/10035

Summary

Currently <script blocking="render"> requires a `src` attribute, even if this `src` is a data URI. This is an unnecessary constraint, as e.g. inline module scripts that import other script should still be able to render-block. See https://github.com/whatwg/html/issues/10034

Blink component

Blink

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Positive (https://github.com/whatwg/html/issues/10034#issuecomment-1881423778) Gecko folks confirmed that this can be included in their positive review for <script blocking=render> (which is not yet implemented)

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No (will add as part of the implementation)

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1514881

Estimated milestones

Shipping on desktop

123

Shipping on Android

123

Shipping on WebView

123

Anticipated spec changes

See https://github.com/whatwg/html/pull/10035

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5200457540829184

This intent message was generated by Chrome Platform Status.

[Rick Byers]

Hi Noam,

This seems pretty trivial to me. The spec change is trivial and presumably any review feedback will only be editorial (not functional), so I'm OK not blocking approval on the spec PR landing. But could you get a WPTs implemented and at least ready to land (eg. along with the implementation CL) before we approve please?

Thanks,

   Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYaABsXrGwCs5h14Vq5OJCStmPN-ki62-2NCQ6r79C9r9A%40mail.gmail.com.

[Noam Rosenthal]

On Wed, Jan 10, 2024 at 3:32 PM Rick Byers <rby...@chromium.org> wrote:

Hi Noam,

This seems pretty trivial to me. The spec change is trivial and presumably any review feedback will only be editorial (not functional), so I'm OK not blocking approval on the spec PR landing. But could you get a WPTs implemented and at least ready to land (eg. along with the implementation CL) before we approve please?

Of course, already done:

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

[Noam Rosenthal]

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag.

[Daniel Bratell]

LGTM1 - I agree that this is small enough to just proceed.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZ8P1YZJ9Bhp4ZPo5RuRVkgkoCYdGi7K3kM58a7rSN%3Dcw%40mail.gmail.com.

[Rick Byers]

Thanks Noam, LGTM2

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag.

I guess technically it's a new platform API so our guidelines require it. But given how tiny and low risk it is, I wouldn't personally object if you hadn't used a flag. But we all know web compat can be very surprising sometimes and it looks like using a flag was pretty trivial, so I'd personally err on the side of keeping the flag, even though that means another clean-up CL later.

[Noam Rosenthal]

On Wed, Jan 10, 2024 at 3:47 PM Rick Byers <rby...@chromium.org> wrote:

Thanks Noam, LGTM2

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag.

I guess technically it's a new platform API so our guidelines require it. But given how tiny and low risk it is, I wouldn't personally object if you hadn't used a flag. But we all know web compat can be very surprising sometimes and it looks like using a flag was pretty trivial, so I'd personally err on the side of keeping the flag, even though that means another clean-up CL later.

Great, perhaps the best way forward is with a flag that's starting as "stable" from the get go and we can later remove it.

Thanks!

[Yoav Weiss]

LGTM3

Thanks,

   Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYaABsXrGwCs5h14Vq5OJCStmPN-ki62-2NCQ6r79C9r9A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Michal Mocny]

On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal <nrose...@chromium.org> wrote:

On Wed, Jan 10, 2024 at 3:47 PM Rick Byers <rby...@chromium.org> wrote:

Thanks Noam, LGTM2

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag.

I guess technically it's a new platform API so our guidelines require it. But given how tiny and low risk it is, I wouldn't personally object if you hadn't used a flag. But we all know web compat can be very surprising sometimes and it looks like using a flag was pretty trivial, so I'd personally err on the side of keeping the flag, even though that means another clean-up CL later.

Great, perhaps the best way forward is with a flag that's starting as "stable" from the get go and we can later remove it.

Just curious-- is this the same as a "kill switch" (default enabled flag)? (which are already included in the guidelines)

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYY5oPs8hcY55ePbav55pLU1fJqU5b_zbcbyLc_51AdwQg%40mail.gmail.com.

[Noam Rosenthal]

On Wed, Jan 10, 2024 at 5:25 PM Michal Mocny <mmo...@google.com> wrote:

On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal <nrose...@chromium.org> wrote:

On Wed, Jan 10, 2024 at 3:47 PM Rick Byers <rby...@chromium.org> wrote:

Thanks Noam, LGTM2

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag.

I guess technically it's a new platform API so our guidelines require it. But given how tiny and low risk it is, I wouldn't personally object if you hadn't used a flag. But we all know web compat can be very surprising sometimes and it looks like using a flag was pretty trivial, so I'd personally err on the side of keeping the flag, even though that means another clean-up CL later.

Great, perhaps the best way forward is with a flag that's starting as "stable" from the get go and we can later remove it.

Just curious-- is this the same as a "kill switch" (default enabled flag)? (which are already included in the guidelines)

Yea, though the kill switch is 6 lines and the feature itself is 7 lines (albeit web-facing) so the value is marginal :)

[Daniel Bratell]

The value comes from being able to do it remotely, by pushing an updated finch configuration rather than rebuilding and upgrading everyone's binary. 

If we have misunderstood the risk, or if there is a critical bug. We make every feature developer pay the (small) cost of adding a flag to save everyone a ton of effort for the hopefully rare occurrences when it is needed.

/Daniel