- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Thu, 21 Nov 2013 02:09:21 -0000
- To: "Ian Hickson" <ian@hixie.ch>, "Markus Ernst" <derernst@gmx.ch>, "Bruno Racineux" <bruno@hexanet.net>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Wed, 20 Nov 2013 05:24:21 -0000, Bruno Racineux <bruno@hexanet.net> wrote: > If your sources and breakpoints are hard-coded in your articles (stored > DB), and you suddenly have to change your site's theme, or add a new > image at the platform level or a new resolution? What if one breakpoint > is no > longer relevant? Or what if you change designs with a complete new > responsive approach? How does an inline syntax help me with that case? > > You can be stuck. That forces you to regenerate all the img src(s) of > your articles with your new layout and new inline breakpoints. I sympathize with the problem. Unfortunately we have a hard requirement of supporting the preload scanner, which means we absolutely cannot wait for any external file. And since we can't wait for any external file, we can't wait for stylesheets or any reusable centralized definition of breakpoints. When HTTP/2 Push becomes a standard feature preload scanner won't be so important any more and we'll be able to revisit this. > A centralized css-subset approach do not have such difficult problems. > Verbose aside, to me this all screams: RespIMGs has to be a CSS related > feature with centralization of custom MQs and srcset(s) at the <head>. With preload scanner limitation definitions in <head> is the best we could possibly do. I have proposed Media Query Variables intended to be used in <style> in <head> for responsive images. I've also wanted MQ variables to be usable in external stylesheets to reduce repetition in regular @media CSS, but even mere possibility of authors misusing external CSS definitions for responsive images (which would achieve centralization you want, but also get in the way of preload scanner) made browser vendors feel uneasy about this proposal. I hope to convince them otherwise, but until then your best bet is to use server-side templating language (or project-wide find and replace) to define your breakpoints once. -- regards, Kornel
Received on Thursday, 21 November 2013 02:10:02 UTC