Re: [csswg-drafts] [css-device-adapt] @viewport is preloader-hostile

The fact that the design is preloader-hostile is indeed an issue we 
need to solve. But there's another tension in the other direction: 
regardles of the actual mechanism, this really is style, not content, 
and belongs on that side of the divide.

This is not just true philosophically (although it is as well), but 
also practically: whether you should have an `@viewport` / `<meta 
viewport>` / whatever-alternative-we-come-up-with and what parameters 
it should have depends on what's in your stylesheet. If the same 
document / app is styled differently, you may need different viewport 
settings. Even if you're not switching stylesheets, content and styles
 may be handled by different teams, and the style teams has access to 
the css but not to the markup, yet they're the one who know what needs
 to go in to the viewport settings.

But this requirement is at odds with being pre-loader friendly, since 
it implies (at least naïvely) to store this in the form of a css rule 
in the stylesheet, as the current iteration does it.

I am not entirely sure how to solve both problems at the same time. 
I'd be tempted to experiment with something along the lines of what 
@bradkemper said: keep it in css, but only accept it from inline 
styles in `<head>` or from a stylesheet directly linked from `<head>` 
(no `@import`), and only if there's not synchronous js before it, 
and... That feels a bit clucky, and I'd certainly welcome something 
simpler, but I am very reluctant to have this somewhere else than in 
CSS, regardless of what the final incarnation turns out to be.


-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/258#issuecomment-230154804 
using your GitHub account

Received on Sunday, 3 July 2016 13:58:37 UTC