Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
2013-11-12 9:58, Adam Barth wrote: Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. But you could use style type=text/foobar.../style, with a suitable value for foobar, like x-imgset. This could even be handled with a polyfill in old browsers (JavaScript code that reads such elements and interprets their content). Yucca (who would still prefer text/css)
[whatwg] Mailing List Archive Link
Hi, I don’t know if this is the right place to ask for but I couldn’t find any information stored in the received emails from this list about the online archived version. In the mails from w3c there is a header tag with the reference to the archived version but I couldn’t find one here. If you ask me I would like to have a link on bottom of every message to the archived version but at w3c they said it wouldn’t be possible because this needs massive changes in the software. Still a link in the headers would be very useful. If it’s the wrong place here, could you forward it to the right persons or tell me where to ask for such feature-requests? Thanks, -Anselm - Anselm Hannemann @helloanselm
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 9:58, Adam Barth wrote: Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. But you could use style type=text/foobar.../style, with a suitable value for foobar, like x-imgset. This could even be handled with a polyfill in old browsers (JavaScript code that reads such elements and interprets their content). Maybe there's a CSS solution to this problem? Do we just need to make the preload scanner smarter about interpreting CSS? Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 12.11.2013, at 09:11, Adam Barth w...@adambarth.com wrote: On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 9:58, Adam Barth wrote: Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. But you could use style type=text/foobar.../style, with a suitable value for foobar, like x-imgset. This could even be handled with a polyfill in old browsers (JavaScript code that reads such elements and interprets their content). Maybe there's a CSS solution to this problem? Do we just need to make the preload scanner smarter about interpreting CSS? Adam Dear Adam, no, a preload scanner will never (okay, never say never) interpret CSS. This is against the rule of it to improve performance before interpreting layout. This also has been answered more in detail several times now so if you need more evidence, please look up in the archives. Thanks :) -Anselm
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 12.11.2013, at 09:08, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 9:58, Adam Barth wrote: Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. But you could use style type=text/foobar.../style, with a suitable value for foobar, like x-imgset. This could even be handled with a polyfill in old browsers (JavaScript code that reads such elements and interprets their content). Yucca (who would still prefer text/css) Hi, while one could do that, we want to introduce a new web-standard. What you describe is a hacky solution which might work but is far away from a standard-syntax (it’s only misusing an existing header element) and from what it looks like and what I know from old quirky browsers this might not be bullet-proof. -Anselm
Re: [whatwg] Mailing List Archive Link
On Tue, Nov 12, 2013 at 4:10 PM, Anselm Hannemann i...@anselm-hannemann.com wrote: If it’s the wrong place here, could you forward it to the right persons or tell me where to ask for such feature-requests? This is hard to solve giving the software we use last I checked. I recommend bookmarking http://lists.w3.org/Archives/Public/public-whatwg-archive/latest and using that to find the relevant URL. -- http://annevankesteren.nl/
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 12:29 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 10:14, Anselm Hannemann wrote: no, a preload scanner will never (okay, never say never) interpret CSS. This is against the rule of it to improve performance before interpreting layout. This whole thing is about scanning *something* in early phase, so if some rules prevent from using style sheets for something that is really a stylesheet matter (unless we regard it as a client/server negotiation issue), change the rules. The rule that Anselm refers to does not exist. We can make the preload scanner smarter if we want to. It's just a matter of understanding the engineering constraints under which it operates. Given that I wrote the preload scanner that's used in WebKit and Blink, I have a pretty good grasp of those constraints. :) Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 5:33 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 12, 2013, at 4:11 PM, Adam Barth w...@adambarth.com wrote: On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-11-12 9:58, Adam Barth wrote: Unfortunately, we can't add new tags to head. If the parser sees a tag it doesn't recognize in the head, it creates a fake body tag and pushes the tag down into the body. But you could use style type=text/foobar.../style, with a suitable value for foobar, like x-imgset. This could even be handled with a polyfill in old browsers (JavaScript code that reads such elements and interprets their content). Maybe there's a CSS solution to this problem? Do we just need to make the preload scanner smarter about interpreting CSS? In fact, I’d argue that CSS will be a better fit to address art direction use case since it’s purely presentational. Only insofar as literally this entire feature is presentational. We could define some ways to list set of images that could be replaced for a given img element in HTML and then let CSS pick which one to use for example. No, we can't gate any of the major use-cases behind a time barrier (waiting for external CSS to come in) like that. That defeats the entire point; at that point, you might as well just solve it in script. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 12.11.2013 14:33 schrieb Ryosuke Niwa:
On Nov 12, 2013, at 4:11 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
2013-11-12 9:58, Adam Barth wrote:
Unfortunately, we can't add new tags to head. If the parser sees a
tag it doesn't recognize in the head, it creates a fake body tag and
pushes the tag down into the body.
But you could use style type=text/foobar.../style, with a suitable value
for foobar, like x-imgset. This could even be handled with a polyfill in old
browsers (JavaScript code that reads such elements and interprets their
content).
Maybe there's a CSS solution to this problem? Do we just need to make
the preload scanner smarter about interpreting CSS?
In fact, I’d argue that CSS will be a better fit to address art direction use
case since it’s purely presentational.
We could define some ways to list set of images that could be replaced for a
given img element in HTML and then let CSS pick which one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
I assume that in order to allow preloading, some mechanism would have to
be added to tell the UA that this part of the CSS has to be evaluated
before downloading starts.
(I personnally would prefer author-defined keywords instead of numbers
for the identification of sources.)
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
2013-11-12 17:52, Tab Atkins Jr. wrote: No, we can't gate any of the major use-cases behind a time barrier (waiting for external CSS to come in) like that. Why does it need to be *external* CSS? Surely external style sheets are generally preferred, but if you want inline code, what is the problem with a style element? It’s less inline than img tag attributes, and it appears in the head, so you can process it even before you start parsing img tags. Yucca
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can be
used to fill the URL templates of the images in the document's body.
--
Markus Lanthaler
@markuslanthaler
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of
approach is not part of the discussion?
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst derer...@gmx.ch wrote:
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a
simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can
be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of approach
is not part of the discussion?
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tuesday, November 12, 2013 6:50 PM, Adam Barth wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
All the information is there.
Except if there are other, external stylesheets that might overwrite these
definitions
We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
I see a number of other problems with this approach as well. E.g., how would
this work for videos? What about browsers not supporting media queries (or
CSS for that matter)? With this solution you need to replace all img tags
with meaningless divs. Right clicking to save an image would break as well.
--
Markus Lanthaler
@markuslanthaler
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
This is possible using a set of proposals already underway, last I checked in
on them: http://nicolasgallagher.com/responsive-images-using-css3/ Considering
the delay involved in skipping the preparser and waiting for CSS to download
(as well as the fact that the `src` *will* be prefetched, resulting in a
double-request), this really leaves us in the same position as any number of
script-based solutions—we’re just creating a responsive images “engine” in CSS,
rather than in JavaScript or inside an SVG.
This subject has come up a number of times on the respimg list, and it always
plays out largely the same way: an optimization like this would be beneficial
for sure (and I’m in favor of one myself), but in this context we’re looking at
creating an entire variable syntax specific to images. Obviously there’s a huge
amount of implementation overhead involved in something like this, and making
it a requirement in any proposal would create a *huge* barrier to
implementation vs. getting a simple *extendable* markup pattern in place and
building on that. Once we have a solution in place for responsive images, it
makes sense that it would become a consideration in larger discussions such as
http://lists.w3.org/Archives/Public/www-style/2013May/0638.html
We don’t want the search for the all-time-perfect responsive image solution to
stand in the way of setting up the foundation for one, and we definitely don’t
want to create a set of solutions to larger problems that can only ever apply
to image sources.
-M
On Nov 12, at 12:50 PM, Adam Barth wrote:
On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst derer...@gmx.ch wrote:
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a
simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can
be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of approach
is not part of the discussion?
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
If you legitimately think this will work, I'm for it. If you just
think it's a vague maybe, I'd like to continue pursuing new syntax.
(If we do this, we just need to port the variable-sized-image stuff
into image-set(). It wouldn't be hard.)
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:17 AM, Markus Lanthaler
markus.lantha...@gmx.net wrote:
On Tuesday, November 12, 2013 6:50 PM, Adam Barth wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
All the information is there.
Except if there are other, external stylesheets that might overwrite these
definitions
The preloader is just heuristic. There are many cases where it loads
resources that aren't needed by the page.
We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
I see a number of other problems with this approach as well. E.g., how would
this work for videos?
That sounds like a separate problem that we can solve separately.
Neither srcset nor src-N nor picture address videos.
What about browsers not supporting media queries (or
CSS for that matter)?
The web site will likely need to do something different to support
those browsers. That's likely the case already if the web site wants
to support browsers that don't implement CSS.
With this solution you need to replace all img tags
with meaningless divs. Right clicking to save an image would break as well.
It's extremely common practice to use background-image to supply
images today. Perhaps we should solve the
right-click-to-save-a-CSS-background-image problem in a way that works
for all these uses.
On Tue, Nov 12, 2013 at 10:23 AM, matmarquis.com m...@matmarquis.com wrote:
This is possible using a set of proposals already underway, last I checked in
on them: http://nicolasgallagher.com/responsive-images-using-css3/
Considering the delay involved in skipping the preparser and waiting for CSS
to download (as well as the fact that the `src` *will* be prefetched,
resulting in a double-request), this really leaves us in the same position as
any number of script-based solutions—we’re just creating a responsive images
“engine” in CSS, rather than in JavaScript or inside an SVG.
Please read my proposal. I'm suggesting that we teach the preload
scanner how to understand a subset of CSS large enough to cover these
use cases. It doesn't involve any futuristic CSS technology. It just
requires adding smarts to existing implementations of existing
standards. You point about prefetching the src attribute is also
incorrect because there is no src attribute in my proposal. Fallback
isn't handled by src. It's handled by CSS.
This subject has come up a number of times on the respimg list, and it always
plays out largely the same way: an optimization like this would be beneficial
for sure (and I’m in favor of one myself), but in this context we’re looking
at creating an entire variable syntax specific to images.
My proposal did not include any new syntax. Please read my proposal
before trying to shoot it down. :)
Obviously there’s a huge amount of implementation overhead involved in
something like this, and making it a requirement in any proposal would create
a *huge* barrier to implementation vs. getting a simple *extendable* markup
pattern in place and building on that. Once we have a solution in place for
responsive images, it makes sense that it would become a consideration in
larger discussions such as
http://lists.w3.org/Archives/Public/www-style/2013May/0638.html
Given that I'm an implementor and you don't appear to be an
implementor, I'd like to ask you to believe me when I say that my
proposal is a smaller implementation burden than picture or src-N.
We don’t want the search for the all-time-perfect responsive image solution
to stand in the way of setting up the foundation for one, and we definitely
don’t want to create a set of solutions to larger problems that can only ever
apply to image sources.
My proposal doesn't involve inventing anything. It's just a proposal
to optimize a subset of CSS. These optimizations will benefit folks
interested in responsive images. They will also benefit existing
content that happens to fall into the subset without caring about
responsive images.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Really? An empty div element? What about accessibility or When CSS cannot be
loaded? What if only html is grabbed by another page? It doesn't seem to be a
really solid solution in my opinion.
Anselm
On 12 Nov 2013, at 19:40, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
If you legitimately think this will work, I'm for it. If you just
think it's a vague maybe, I'd like to continue pursuing new syntax.
(If we do this, we just need to port the variable-sized-image stuff
into image-set(). It wouldn't be hard.)
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we may
be able to fix that by extending image-set to support src-N's
viewport-urls syntax.
- Requires you to know the intrinsic aspect ratio of the images in advance.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which is
fairly icky. Since we're inlining the presentation into the content anyway,
may as well inline it next to the relevant bit of the content.
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).
Adam
If we did want to split src-N up to separate presentation from content,
you'd probably want to put the size-viewport-list and media-querys into
inline CSS, and leave just the size-based-urls (which are pure content)
in the HTML. Then you'd end up with something like the following.
If you just have viewport-switching (and dpr-switching), it'd be:
style
.photo {
image-width: 100%;
}
/style
img class=photo srcs=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560
(and as in
src-Nhttp://tabatkins.github.io/specs/respimg/Overview.html#viewport,
you could use more complicated size-viewport-list expressions like 100%
(30em) 50% (50em) 33% if the image width is a non-linear function of
viewport width)
If you just have dpr-switching (fixed-width images), it'd be:
style
.photo {
image-width: 128px;
}
/style
img class=photo srcs=64.jpg 64, 128.jpg 128, 256.jpg 256
(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available
image)
If you have art direction and dpr-switching, it'd be:
style
.photo {
image-width: small 128px;
}
@media (min-width: 20em) {
.photo {
image-width: big 400px;
}
}
/style
img class=photo
srcs-small=s64.jpg 64, s128.jpg 128, s256.jpg 256
srcs-big=b200.jpg 200, b400.jpg 400, b800.jpg 800
(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)
This actually looks pretty reasonable (and unlike earlier proposals in this
thread, covers all use cases). One nice benefit over src-N is that
the size-viewport-list -- i.e. 128px or 100% or 100% (30em) 50%
(50em) 33% -- doesn't get repeated for every image, if there are several
images with the same relationship between viewport size and image size.
My main concern is that authors won't realise that the CSS must be inlined;
I'm not sure how to make that foolproof.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
[Please don't top-post. Quote the relevant parts of the message
you're responding to.]
On Tue, Nov 12, 2013 at 10:44 AM, Anselm Hannemann
i...@anselm-hannemann.com wrote:
On 12 Nov 2013, at 19:40, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
Really? An empty div element? What about accessibility or When CSS cannot be
loaded? What if only html is grabbed by another page? It doesn't seem to be a
really solid solution in my opinion.
Right, that's not great, but once we finally define the replaced
keyword for the 'content' property, you should be able to set it
directly on imgs, like:
style
.foo {
content: replaced image-set(...);
}
/style
img class='foo' src=fallback
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:40 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
If you legitimately think this will work, I'm for it. If you just
think it's a vague maybe, I'd like to continue pursuing new syntax.
The hard part is deciding what to put in the optimized subset. We
already parse media queries in the preload scanner to find imported
stylesheets to load. We probably won't be able to support every media
query under the sun, but we could support maybe min-width, min-height,
and min-device-pixel-ratio (or whatever you think is best along these
lines).
For selector matching, we wouldn't be able to support anything that
needs to understand the structure of the tree (e.g., descendant
selectors or sibling selectors). I'd probably start with just single
class and id selectors.
In case it wasn't clear from the above, we wouldn't preload the image
until we'd encountered the div with the appropriate class name. When
scanning that start tag token, we'd simulate CSS selector matching in
the preload scanner to see if we've understood any rules that match.
None of the above is all that difficult, and it's probably something
we should do anyway to improve image preloading across the whole web.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:45 AM, John Mellor joh...@google.com wrote:
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we may
be able to fix that by extending image-set to support src-N's
viewport-urls syntax.
Why doesn't it support variable-sized images? In example above, one
of the cases is 30x30 and the other is 60x60. Maybe I've
misunderstood what you mean by variable-sized images?
- Requires you to know the intrinsic aspect ratio of the images in advance.
That seems like something we should improve about CSS more generally.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which is
fairly icky. Since we're inlining the presentation into the content anyway,
may as well inline it next to the relevant bit of the content.
These seem like minor concerns compared to the cost of inventing new
HTML elements, attribute, and semantics.
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).
No user agents support src-N or picture, so we're already ahead of
the game. :)
If we did want to split src-N up to separate presentation from content,
you'd probably want to put the size-viewport-list and media-querys into
inline CSS, and leave just the size-based-urls (which are pure content) in
the HTML. Then you'd end up with something like the following.
If you just have viewport-switching (and dpr-switching), it'd be:
style
.photo {
image-width: 100%;
}
/style
img class=photo srcs=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560
(and as in src-N, you could use more complicated size-viewport-list
expressions like 100% (30em) 50% (50em) 33% if the image width is a
non-linear function of viewport width)
If you just have dpr-switching (fixed-width images), it'd be:
style
.photo {
image-width: 128px;
}
/style
img class=photo srcs=64.jpg 64, 128.jpg 128, 256.jpg 256
(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available
image)
If you have art direction and dpr-switching, it'd be:
style
.photo {
image-width: small 128px;
}
@media (min-width: 20em) {
.photo {
image-width: big 400px;
}
}
/style
img class=photo
srcs-small=s64.jpg 64, s128.jpg 128, s256.jpg 256
srcs-big=b200.jpg 200, b400.jpg 400, b800.jpg 800
(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)
This actually looks pretty reasonable (and unlike earlier proposals in this
thread, covers all use cases). One nice benefit over src-N is that the
size-viewport-list -- i.e. 128px or 100% or 100% (30em) 50% (50em)
33% -- doesn't get repeated for every image, if there are several images
with the same relationship between viewport size and image size.
These proposals all invent new syntax and semantics. I'd much rather
start with an approach that doesn't introduce new syntax or semantics
and just makes the web faster by optimizing existing content.
My main concern is that authors won't realise that the CSS must be inlined;
I'm not sure how to make that foolproof.
We'll have to write tutorials and the like. All these proposals have
a developer education component. Developers won't magically know how
to use src-N either.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 6:54 PM, Adam Barth w...@adambarth.com wrote: On Tue, Nov 12, 2013 at 10:45 AM, John Mellor joh...@google.com wrote: - Doesn't address viewport-switching (variable-sized images), though we may be able to fix that by extending image-set to support src-N's viewport-urls syntax. Why doesn't it support variable-sized images? In example above, one of the cases is 30x30 and the other is 60x60. Maybe I've misunderstood what you mean by variable-sized images? In most responsive designs, there are images whose resolution depends on both the viewport width and the devicePixelRatio. Your approach technically allows handling both, by combining max-width and max-resolution MQs, but if you have 6 widths and 4 dprs, you have to write 24 separate MQs, for every combination. This is the same problem srcset's w unit had; see xanthir.com/b4Su0 for a clear explanation, and compare the extreme verbosity (and incomprehensibility) of the srcset example there, with the much simpler equivalent src-1.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 10:54 AM, Adam Barth w...@adambarth.com wrote: Why doesn't it support variable-sized images? In example above, one of the cases is 30x30 and the other is 60x60. Maybe I've misunderstood what you mean by variable-sized images? It doesn't support a *compact syntax for providing multiple densities for variable-sized images*. This topic has been brought up over and over again when discussing why srcset isn't sufficient. Please see http://www.xanthir.com/b4Su0 - just look at the examples if you're in a hurry. The point is obvious. - Requires you to know the intrinsic aspect ratio of the images in advance. That seems like something we should improve about CSS more generally. Yes, this is fixable through the 'content' property and proper indication that you're creating a replaced element, rather than just filling the element with an anonymous piece of content. Then height: auto; will work as intended. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Message: 9
Date: Tue, 12 Nov 2013 10:54:54 -0800
From: Adam Barth w...@adambarth.com
To: John Mellor joh...@google.com
Cc: Jukka K. Korpela jkorp...@cs.tut.fi, Markus Ernst
derer...@gmx.ch, whatwg whatwg@lists.whatwg.org,
Markus Lanthaler
markus.lantha...@gmx.net, Ryosuke Niwa rn...@apple.com
Subject: Re: [whatwg] imgset responsive imgs proposition (Re: The
src-N proposal)
Message-ID:
caje5ia_pzceu9prvaxfy--pqbqjh1t7+kfcaw9fuvmk7mfr...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 12, 2013 at 10:45 AM, John Mellor joh...@google.com wrote:
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we
may
be able to fix that by extending image-set to support src-N's
viewport-urls syntax.
Why doesn't it support variable-sized images? In example above, one
of the cases is 30x30 and the other is 60x60. Maybe I've
misunderstood what you mean by variable-sized images?
- Requires you to know the intrinsic aspect ratio of the images in
advance.
That seems like something we should improve about CSS more generally.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which
is
fairly icky. Since we're inlining the presentation into the content
anyway,
may as well inline it next to the relevant bit of the content.
These seem like minor concerns compared to the cost of inventing new
HTML elements, attribute, and semantics.
I suggest that not being able to provide an associated text alternative for
an image via a simple method is not a 'minor concern' for some.
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).
No user agents support src-N or picture, so we're already ahead of
the game. :)
If we did want to split src-N up to separate presentation from content,
you'd probably want to put the size-viewport-list and media-querys
into
inline CSS, and leave just the size-based-urls (which are pure
content) in
the HTML. Then you'd end up with something like the following.
If you just have viewport-switching (and dpr-switching), it'd be:
style
.photo {
image-width: 100%;
}
/style
img class=photo srcs=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560
(and as in src-N, you could use more complicated size-viewport-list
expressions like 100% (30em) 50% (50em) 33% if the image width is a
non-linear function of viewport width)
If you just have dpr-switching (fixed-width images), it'd be:
style
.photo {
image-width: 128px;
}
/style
img class=photo srcs=64.jpg 64, 128.jpg 128, 256.jpg 256
(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available
image)
If you have art direction and dpr-switching, it'd be:
style
.photo {
image-width: small 128px;
}
@media (min-width: 20em) {
.photo {
image-width: big 400px;
}
}
/style
img class=photo
srcs-small=s64.jpg 64, s128.jpg 128, s256.jpg 256
srcs-big=b200.jpg 200, b400.jpg 400, b800.jpg 800
(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)
This actually looks pretty reasonable (and unlike earlier proposals in
this
thread, covers all use cases). One nice benefit over src-N is that the
size-viewport-list -- i.e. 128px or 100% or 100% (30em) 50% (50em)
33% -- doesn't get repeated for every image, if there are several images
with the same relationship between viewport size and image size.
These proposals all invent new syntax and semantics. I'd much rather
start with an approach that doesn't introduce new syntax or semantics
and just makes the web faster by optimizing existing content.
My main concern is that authors won't realise that the CSS must be
inlined;
I'm not sure how to make that
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 12, 2013, at 9:50 AM, Adam Barth w...@adambarth.com wrote:
On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst derer...@gmx.ch wrote:
Am 12.11.2013 17:48 schrieb Markus Lanthaler:
On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
We could define some ways to list set of images that could be
replaced for a given img element in HTML and then let CSS pick which
one to use for example.
style type=text/css
@media (min-width: 480px) {
img.artdirected {
use-src: 1;
}
}
@media (min-width: 600px) {
img.artdirected {
use-src: 2;
}
}
/style
img class=artdirected
src=small.jpg
src-1=medium.jpg
src-2=large.jpg
alt=Alternative text
[...]
This may be technically incorrect or incomplete; it's just a sketch of
the idea, based on my conviction that sources belong into the img
element, while MQs should be kept centralised.
Using URL templates this could be simplified even further. For example by
extending the meta element to allow it to set some form of global
configuration variables it would be possible to define images using a
simple
naming convention:
head
meta var=img-size content=small
meta var=img-size content=medium media=min-width: 480px
meta var=img-size content=large media=min-width: 900px
/head
body
img src=teaser-fallback.jpg src-t=teaser-{img-size}.jpg
img src=profile-fallback.jpg src-t=profile-{img-size}.jpg
/body
If a variable is set multiple times as in the case above, the latest
assignment wins. As soon as the closing head tag is encountered, the value
of all variables is known and they effectively become constants that can
be
used to fill the URL templates of the images in the document's body.
That looks really cool to me. Is there any reason why this kind of approach
is not part of the discussion?
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Content authors can already do what is described above, and in fact often do.
However, a div with a background-image property set is not the same as an
img in practice. Here are a few differences:
(1) There's no ready way to have an element size automatically to its
background-image (the way an img will to its src by default).
(2) In general, browsers will not provide the same user interaction operations
for a background image as for a content image in an img element (e.g. ability
to drag it elsewhere, context menu items to save it, etc).
(3) Assistive technologies will ignore background image holding divs for which
no textual equivalent has been provided (as opposed to img, where they do
something like reading the filename, or just indicate the presence of an image
without labeling it).
(4) Software that processes content to look for images may treat content images
in img differently from images specified as backgrounds, for instance by
assuming background images are decorative and therefore less meaningful and/or
less related to search terms in text on the page.
Some of the above may be addressable by using the 'content' property instead of
the 'background-image' property, though using 'content' on an element as
opposed to a :before or :after pseudo does not work reliably cross-browser.
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com
(mailto:w...@adambarth.com) wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
Would the style element have to reside inline, to reap the performance
benefits?
On Tuesday, November 12, 2013 at 11:47 AM, Tab Atkins Jr. wrote:
On Tue, Nov 12, 2013 at 10:44 AM, Anselm Hannemann
i...@anselm-hannemann.com (mailto:i...@anselm-hannemann.com) wrote:
Really? An empty div element? What about accessibility or When CSS cannot
be loaded? What if only html is grabbed by another page? It doesn't seem to
be a really solid solution in my opinion.
Right, that's not great, but once we finally define the replaced
keyword for the 'content' property, you should be able to set it
directly on imgs, like:
style
.foo {
content: replaced image-set(...);
}
/style
img class='foo' src=fallback”
In the meantime, this might be a little more fallback-friendly, when combined
with some styles to hide the a in capable browsers:
div class=“foo”a href=“fallback.jpg”Alt text/a/div
But regarding both this and Adam’s original proposal… losing the ability to
mark up a content image seems like a huge sacrifice. I imagine services like
Google Images and Pinterest rely on images being first-class content citizens,
in-markup right alongside paragraphs, videos, audio, etc…
Thus, Tab’s suggestion seems far superior in the long term, as long as we can
be sure (?) that no one is incurring a double-load of the fallback + the
replaced image.
—eric
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 11:38 AM, li...@ericportis.com
li...@ericportis.com wrote:
On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth w...@adambarth.com
(mailto:w...@adambarth.com) wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
Would the style element have to reside inline, to reap the performance
benefits?
If you want the preload scanner to be able to load the images, you'll
need to put the URLs in a place where the preload scanner can see
them, which means inline.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 12.11.2013 18:50 schrieb Adam Barth:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
What I don't like about CSS approaches is the fact that changing the
source of an image is fundamentally different from changing a dimension
or color of an element. This is not presentational in the same way.
Having to reference content images in the CSS in order to change their
sources is an authoring nightmare.
If inventing new elements or attributes is bad, I assume the whole
discussion on responsive images is actually obsolete, as what you
suggest can be done already in principle.
Re: [whatwg] Questions regarding Path object
On Mon, 11 Nov 2013, Elliott Sprehn wrote: Then I object to us shipping this in Chrome. Bleeding on the global scope with such a generic name ignoring all the other reasonable uses of the word Path is not good for the platform. It's not forward thinking, and it's confusing for developers. The name issue was raised before (the name clashes with the paper.js library, IIRC), but no vendor had objected (the feature was added over a year ago now - March 2012), the suggested alternative names weren't great, the compatibility issue wasn't huge, and so I left it as is, and Apple shipped it. Changing it now seems like a poor time to change it. ...but, if you won't ship it, maybe we need to change it after all? Would Apple ship a different name? What are Mozilla's opinions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
The hard part is deciding what to put in the optimized subset. We
already parse media queries in the preload scanner to find imported
stylesheets to load. We probably won't be able to support every media
query under the sun, but we could support maybe min-width, min-height,
and min-device-pixel-ratio (or whatever you think is best along these
lines).
I'm pretty sure we could support every MQ here, either on the main thread
(as it's implemented now in Blink WebKit) or inside the preloadScanner
itself, assuming a thread-safe CSS parser is available, which is something
we'd need anyway if we want the PreloadScanner to parse CSS.
For selector matching, we wouldn't be able to support anything that
needs to understand the structure of the tree (e.g., descendant
selectors or sibling selectors). I'd probably start with just single
class and id selectors.
In case it wasn't clear from the above, we wouldn't preload the image
until we'd encountered the div with the appropriate class name. When
scanning that start tag token, we'd simulate CSS selector matching in
the preload scanner to see if we've understood any rules that match.
None of the above is all that difficult, and it's probably something
we should do anyway to improve image preloading across the whole web.
I agree that such an optimization can improve loading of inline CSS
background images anyway.
OTOH, I'm not sure this is the right solution for content images.
On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 12, 2013, at 9:50 AM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
All the information is there. We just need to teach the preload
scanner to parse a subset of CSS and match a subset of selectors. If
you stay within the preloadable subset, then your images will be
loaded by the preload scanner. Otherwise, they'll just be loaded
normally.
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Content authors can already do what is described above, and in fact often
do. However, a div with a background-image property set is not the same
as an img in practice. Here are a few differences:
(1) There's no ready way to have an element size automatically to its
background-image (the way an img will to its src by default).
(2) In general, browsers will not provide the same user interaction
operations for a background image as for a content image in an img
element (e.g. ability to drag it elsewhere, context menu items to save it,
etc).
(3) Assistive technologies will ignore background image holding divs for
which no textual equivalent has been provided (as opposed to img, where
they do something like reading the filename, or just indicate the presence
of an image without labeling it).
(4) Software that processes content to look for images may treat content
images in img differently from images specified as backgrounds, for
instance by assuming background images are decorative and therefore less
meaningful and/or less related to search terms in text on the page.
Some of the above may be addressable by using the 'content' property
instead of the 'background-image' property, though using 'content' on an
element as opposed to a :before or :after pseudo does not work reliably
cross-browser.
I agree with Maceij's concerns here.
I also think that writing inline CSS will be cumbersome in a CSP world.
Hashes will make it easier for static inline CSS, but if we're going to
write down frequently-changing, content images' resources in inline CSS,
that'd be a lot of hash calculations. A build step can help, but it's a
downside of this approach.
John's approach of splitting content presentation seems better to me. It
enables to keep img semantic and maintain the variable resources in HTML.
I'm not sure it's better than src-N+custom MQs though.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/12/13 12:11 AM, Adam Barth w...@adambarth.com wrote:
On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
2013-11-12 9:58, Adam Barth wrote:
Unfortunately, we can't add new tags to head. If the parser sees a
tag it doesn't recognize in the head, it creates a fake body tag and
pushes the tag down into the body.
But you could use style type=text/foobar.../style, with a suitable
value
for foobar, like x-imgset. This could even be handled with a polyfill
in old
browsers (JavaScript code that reads such elements and interprets their
content).
Maybe there's a CSS solution to this problem? Do we just need to make
the preload scanner smarter about interpreting CSS?
The style element can do. How about the following css like approach then:
style type=text/x-imgset
.set-1 {
imgset: small 150 1x, medium 200 1x, large 300 1x 150 2x;
pattern: /(?=\-)(.*)(?=\.)/s; --- that or a template model
sizes: 1x,2x;
}
:tablet{
media: (min-width: 568px) and (max-width: 768px);
}
:phone{
media: (min-width: 320px) and (max-width: 568px);
}
/style
It requires the pre-loader to parse some inline css subset, but only a
limited semantic and fairly small, not a css presentational one. The MQ
syntax remains the same as CSS, and they are tokenized by imgset which put
them away from the DOM.
The image becomes:
img width=300 height=100 src=logo-large.jpg imgset=set-1: small
(phone) medium (tablet) large
Or perhaps combine this new language as css4 classes and pseudo selectors
if feasible, where you can refer to MQs with pseudo classes for the
presentational aspect like:
header:tablet{
/*new style*/
}
That would be a very flexible way to deal with media queries too...
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 3:06 PM, Markus Ernst derer...@gmx.ch wrote:
What I don't like about CSS approaches is the fact that changing the source
of an image is fundamentally different from changing a dimension or color of
an element. This is not presentational in the same way. Having to
reference content images in the CSS in order to change their sources is an
authoring nightmare.
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
-christian
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Wed, Nov 13, 2013 at 9:56 AM, Christian Biesinger
cbiesin...@google.com wrote:
On Tue, Nov 12, 2013 at 3:06 PM, Markus Ernst derer...@gmx.ch wrote:
What I don't like about CSS approaches is the fact that changing the source
of an image is fundamentally different from changing a dimension or color of
an element. This is not presentational in the same way. Having to
reference content images in the CSS in order to change their sources is an
authoring nightmare.
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
I quite like this if we can make it work. It keeps the references to
the images in the img tag, but makes use of media queries for the
different constraints. It looks clean and is easy to understand.
Silvia.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 12, 2013, at 6:09 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote:
On Wed, Nov 13, 2013 at 9:56 AM, Christian Biesinger
cbiesin...@google.com wrote:
On Tue, Nov 12, 2013 at 3:06 PM, Markus Ernst derer...@gmx.ch wrote:
What I don't like about CSS approaches is the fact that changing the source
of an image is fundamentally different from changing a dimension or color of
an element. This is not presentational in the same way. Having to
reference content images in the CSS in order to change their sources is an
authoring nightmare.
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
I quite like this if we can make it work. It keeps the references to
the images in the img tag, but makes use of media queries for the
different constraints. It looks clean and is easy to understand.
Silvia.
This is indeed the cleanest proposal so far. It should work well with CMSs that
would predefine the viewport breakpoints, leaving the user to specify only a
set of images. It is also human friendly by minimizing repetition and not using
arbitrary numbers.
DPR switching with viewport breakpoints might still be too complex to define.
(At least you only need to do it once in the header.) An example that involves
DPR would help illustrate that for everyone.
— Timothy Hatcher
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 13.11.2013 2:56, Christian Biesinger wrote:
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
...
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
Do you expect that there will be just predefined set of src-* attributes
or user can define as many of them as he/she wants and use arbitrary
identifier after src-?
If the later is one, then validation and content completion in HTML
source editors will be nightmare.
Jirka
--
--
Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz
--
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
--
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
--
Bringing you XML Prague conferencehttp://xmlprague.cz
--
Re: [whatwg] Questions regarding Path object
[resending because of a bounced message] DrawingPath is saying the same thing twice. Maybe DOMDrawing is better? (with drawing the definition of http://dictionary.cambridge.org/dictionary/british/drawing?q=drawing) On Tue, Nov 12, 2013 at 6:39 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I bikeshed-+1 Elliott's earlier suggestion of DrawingPath. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
