This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23509 - Media-specific scripts (<script media="">?)
Summary: Media-specific scripts (<script media="">?)
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-14 21:25 UTC by Ian 'Hixie' Hickson
Modified: 2016-03-16 14:38 UTC (History)
3 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2013-10-14 21:25:03 UTC
(The big unanswered question with the proposals below is how to handle changes in the media — e.g. orientation changes, zoom. A solution for that really is needed before we can make progress here.)

On Thu, 16 May 2013, Yoav Weiss wrote:
>
> Arguably, the biggest problem in responsive Web design today is the fact
> that many resource loading mechanisms are media query agnostic, and
> download resources upfront regardless of whether they will be used or not.
>
> One of the biggest resources in question (right after images) is external
> JavaScript. JavaScript also has secondary performance effects, beside its
> download size, since parsing and running it are also time (& battery)
> consuming operations.
>
> Currently authors that want their scripts to load only under certain
> viewport sizes are forced to use JS based script loaders, which have the
> side-effect of preventing these scripts from being parsed out by the
> preloader.
>
> I believe that an HTML based solution would be a better fit, will be easier
> to use by authors, and will enable preloaders to do their job and preload
> these scripts.
>
> Common use-cases for avoiding the load of JS based components based on
> layout are:
>
> * JS based maps, which don't fit in a narrow layout
> * Social widgets, which don't fit in a narrow layout
> * Mobile/desktop oriented UI libraries
> * Ad placements
>
> I was thinking along the lines of adding a `media` attribute to the
> `<script>` element.
> Doing that raises several interesting questions:
>
> * What will be the execution order of these scripts if the media conditions
> of the page change?
> * Should `media` be permitted for scripts with no `defer`/`async`
> attributes, that may contain document.write directives?
> * Should scripts re-run if media conditions changed more than once (e.g.
> their `media` intially matched conditions, then stopped, then matched again)
> * Should events handlers that were registered by scripts which media no
> longer matches run?
>
> I believe that mandating `async` (at least as a first step) will enable
> avoiding the running-order problems, with authors being obliged to avoid
> any dependencies between `media` scripts and other (`media` or non-`media`)
> scripts.

On Tue, 21 May 2013, David Bruant wrote:
>
> How bad is the current situation with JS-based loaders? I would expect a
> JS-based loader and the couple of feature-detection tests to be rather small
> as well as heavily cachable, so not that awful for performance.

On Sat, 25 May 2013, Yoav Weiss wrote:
>
> JS based loaders have several drawbacks:
> * JS files are not discovered by the preloader, which means the browsers
> can't prioirtize their download appropriately.
> * They require JS inlining, which will become significantly harder with CSP
> (JS nonces make it possible, but it'd require server side logic)
> * Arguably, attributes make authoring easier, which may mean authors are
> more likely to avoid useless JS downloads.

On Sat, 25 May 2013, Paul Kinlan wrote:
>
> We developed formfactorjs for exactly this type of case (
> github.com/paulkinlan/formfactor) about 2 years ago.
>
> The use case we had was that we had one app that had to respond differently
> based on the form factor type, so a TV would load js that was specific to
> just the TV (ie loading remote controller logic) and a tablet would loads
> js that responded to finger based touch gestures and a phone type media
> query would load js for thumb based gestures.
>
> We got to the point where were talking about trying to have media queries
> on script element to save us from this library we created, however we
> quickly found that things like orientation changes would mean that there is
> a high degree of chance that the developer would have scripts that would
> need to be loaded at some undeterminable time in the future that would
> clash with the scripts that had already been loaded and ruin the state in
> our app (such as scripts sectioned by min-width queries).
>
> We didn't find any reasonable solution for this issue other than force a
> reload of the page :/

On Sun, 26 May 2013, Paul Kinlan wrote:
>
> media queries have no logical OR which means if you want one script
> to match multiple media queries (such as one that would match tablet
> and one that would match tv) you need to declare script blocks
> multiple times.

The thread had other feedback too:
   http://goo.gl/otukz7#msg112
Comment 1 Ian 'Hixie' Hickson 2014-07-21 20:52:51 UTC
One option would be to have the media="" just be a control over when it executes, with nothing special going on when it stops executing.

This could also be integrated into a dependency system: it's just having scripts depend on a media query, which you'd actually be able to do anyway if you can make a script be a dependency for a style sheet.
Comment 2 Anne 2016-03-16 14:38:29 UTC
Once there's a concrete proposal, please open a GitHub issue.