A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Disable scripts API (standardised cut the mustard failure handling)

wheresrhys
2016-01-28

Cut the mustard, recently a popular approach to managing progressive enhancement, means a page is placed in one of 3 states:

  1. full enhanced experience with scripts delivered and running
  2. synthesised non javascript experience, with scripts suppressed after performing a test of the browser’s capabilities
  3. actual non javascript experience, where the browser has scripts disabled

Browsers have <noscript> for delivering a different experience to 3. It would be useful if this mechanism could be used to deliver a noscript experience to 2 too. (see e.g. https://github.com/Financial-Times/ft-origami/issues?utf8=✓&q=is%3Aissue+is%3Aclosed+ctm+noscript and https://github.com/Financial-Times/o-tracking/issues/83 for the hurdles jumped over to try to achieve a similar effect)

What might work would be a javascript API that can be called to force the page into a genuine noscript state, halting javascript execution, the event loop etc. My initial thoughts would be something like window.disableScripting(), which would only have an effect if some strict criteria were met (e.g. must be called in the first inline script within <head>)

triblondon
2016-01-30

I like this idea. I can imagine there might be some complexities around things like:

  • What do you do if the disableScripting() call is not the last statement in the block?
  • What would be the effect on <noscript> elements already encountered when parsing the page

Could it be easier to reload the page? So disableScripting acts like a window.reload() but when the page is reloaded it has JS disabled?

Obviously this also opens the possible wider question of whether pages should be able to disable certain web platform features, which is Content Security Policy territory. I’m not familiar with CSP but I think this would disable JavaScript entirely:

Content-Security-Policy: script-src 'none'

So perhaps what is being hinted at here is the option for pages to dynamically adjust the CSP of the current page (presumably they would only be permitted to tighten the ruleset). The only problem is that typically developers who want to opt-out of JavaScript execution are doing so because the browser is out of date, and that may well mean that it also doesn’t support CSP (though obviously that equally applies to introducing a new disableScripting or equivalent)

Andrew