> On Feb 26, 2015, at 2:18 AM, Yoav Weiss <yoav@yoav.ws> wrote: > > A standard based note is not likely to have high visibility. A console warning might be more effective. > >> [...] >>>> >> > All in all, I see that there's a valid use case for permitting @viewport rules in external styles other than mere convenience. > So, perhaps limiting @viewport rules to be one of the first rules in an external style (along with @charset and @import) would be enough, Well, let's see: since there could be more than one @media with @viewport inside it, your restriction could theoretically say that @viewport cannot appear outside a dimension-based or zoom-based @media (or similarly restricted linked style sheet in html) unless the @viewport came before that. And that @viewport would be invalidated by any 'image-set()' property (or html with image-set attribute) that came before it in the same level of @media embedding. Or something like that. But I don't think it's worth it to have such a complicated restriction, and too draconian to restrict it even more generally. It's just going to break the author's design in ways the author won't understand or appreciate. And I think the value of such restrictions would be pretty limited anyway. Image loading from image-set should happen after complete style sheet parsing and cascading anyway, and multiple width-based @media rules are already parsed and held in memory anyway on UAs that have resizable windows. At most, an author might defeat some small optimization in a mobile UA with only two default viewport sizes (one for vertical and one for horizontal). That UA might just have to hold onto the other @media blocks during the parsing stage, and at worst might pull in some more style sheets via @import inside @media. But that is no worse than letting an author include dozens of @import calls to the server in existing practice, or having a super large stylesheet full of countless overrides, neither of which is currently restricted by CSS. > if coupled with user agent scanning those files to extract these rules, Sure, but an optimization like that is beyond the authority of this working group. > along with console warnings of possible performance issues. That would be fine with me, or maybe it could be in something like YSlow or in the Audits panel of Chrome's developer tools frame, but I don't think we can mandate it.
Received on Thursday, 26 February 2015 16:10:59 UTC