#1247: Question: can we better define the intention of the "disable scripting" user preference

Visit on Github

Opened Jul 21, 2026

See https://html.spec.whatwg.org/C#will-lazy-load-element-steps

In the note found in the above link, we disable lazy loading when scripting is disabled, to prevent scroll-spy tracking.

While this is well intended, it is largely ineffective when constrained to HTML lazy loading, as css contains multiple features that react to scroll (scroll timelines, scroll state queries, content visibility, to name a few), and those, in conjunction with background image sources, can replicate lazy loading scroll spy to various degrees.

This begs the question - should "scripting disabled" mean "prevent exfiltration of scroll position with image requests"? What else does this user preference mean? What do users expect from it, if at all, aside from the main effect of disabling scripts?

It's important to have a clear architectural view of it as each WG making its own decision on it is ineffective and creates leaks or inconsistencies.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1247

Discussions

Log in to see TAG-private discussions.

Comment by @domfarolino Aug 3, 2026 (See Github)

Thanks for filing this. +1 to this question; I can provide some more background as I raised the progenitor of this in the WHATWG Matrix chat.

We (Chromium) got a request to disable declarative WebMCP when scripting is disabled, so that a document with scripting disabled could not register WebMCP tools and expose them to normal documents, which could "run" the tools in the script-less documents. While I'm not opposed to this request, it got us thinking: what should and should not be allowed to happen in a document where scripting is disabled. Should it not be possible to register functionality that is "runnable" from another, colluding document that has scripts enabled? Is it about privacy and exfiltration instead?

Having clear criteria to check new features against when determining if they should be enabled or disabled with scripting would clear a lot of this up.

Comment by @marcoscaceres Aug 11, 2026 (See Github)

This sounds very "HTML security model" to me, to be honest. Is there a tracking issue on the WHATWG side?

Comment by @marcoscaceres Aug 11, 2026 (See Github)

We discussed this briefly on today's TAG call and, given @domfarolino's additional context, there might be a larger design principle about how features should work (or things to consider) when scripting in disabled. At the same time, it would be good to see what folks on the WHATWG side think, as they've presumably thought about this quite a bit when designing lazy load.

Comment by @noamr Aug 11, 2026 (See Github)

Thanks @marcoscaceres, opened https://github.com/whatwg/html/issues/12775 on the HTML side.