On Wed, 20 Nov 2013 05:24:21 -0000, Bruno Racineux <br...@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
