23509 2013-10-14 21:25:03 +0000 Media-specific scripts (<script media="">?) 2016-03-16 14:38:29 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX P3 enhancement Needs Impl Interest 1 ian ian annevk ian mike contributor oldest_to_newest 94710 0 ian 2013-10-14 21:25:03 +0000 (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 109145 1 ian 2014-07-21 20:52:51 +0000 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. 125534 2 annevk 2016-03-16 14:38:29 +0000 Once there's a concrete proposal, please open a GitHub issue.