Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
I wasn't aware of the { content: replaced url(attr(src-big)); }
syntax. This looks indeed better when you want to keep the sources in
the img tag.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
content: replaced url(attr(data-mobile-retina))
}
}
@media (min-width: 640px) {
.artdirection {
content: replaced url(attr(data-tablet))
}
(...)
}
img src=low.png class=artdirection data-mobile-retina=high.png
data-tablet=wide.png data-4ktv=toobigforyourbandwitdh.png
alt=smth/
One minor problem is that content: replaced, just like
background-image, prevents the user from right click / save as the
image.
But how do I tell content: to replace the src attribute ? I can't
find the syntax spec. Because the same CSS could also be applied to
the image in video poster attribute if I could tell content to
replace the poster attribute.
When CSS or MQ aren't available, you still get low.png. It's still an
image and not a div so the alt attribute can keep the accessibility
(granted, you could apply aria roles on a div).
Of course there is always the possibility of .artdirection being
overriden later in the CSS. Maybe shadow dom could shield the original
art direction.
laurent
--
http://laurentperez.fr
J2EE tips and best practices
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Sun, Nov 17, 2013 at 11:22 PM, Maciej Stachowiak m...@apple.com wrote: I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows: Thanks for explaining your position Maciej. The src-n proposal with the following changes seems likely reasonable: - In a single attribute (ideally named srcset to avoid gratuitous renaming) with || or some other separator - viewport-urls syntax removed or changed to be more human-understandable Can I focus on the viewport-urls syntax for a moment? Everything else (single attribute with ||s/multiple attributes/multiple elements/split between inline CSS HTML) is mainly just aesthetics. But the viewport-urls syntax provides a crucial bit of functionality, and I'd like to make sure people understand why it's so important. It resolves the fundamental tension between what authors want, chose image source based on layout size, and what browser developers want, don't break the preload scanner, in the very common variable-sized images (viewport-switching) case. Satisfying both conditions requires the author to tell the browser's preload scanner what the layout size of the image will be, in terms of the viewport size (and/or fixed sizes). That's all viewport-urls does: you express your layout image size as a CSS length (whose containing block is the viewport, as if you'd used position:fixed). For example: - 400px - 33% // equivalent to 33vw - calc(50vw - 80px) // flexible width with fixed padding It doesn't need to be exact (it's ok if most authors don't bother with calc), it just needs to approximate the layout image size such that the browser can determine the closest matching source. Finally, in cases where you have a nonlinear relationship between viewport width and image width (primarily in responsive designs where the number of columns changes due to a media query), you can provide a CSS length to either side of the discontinuities, where the discontinuity is expressed as a CSS min-width MQ, hence for a 1-3 column responsive grid you end up with something like the 100% (640px) 50% (960px) 33% examplehttp://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/you've probably seen. But again, while using this correctly will give you the optimal tradeoff between page load performance and image quality, it's generally ok if the long tail of websites don't bother dealing with the discontinuities, and just provide a rough estimate of image size, e.g. they approximate 100% (640px) 50% (960px) 33% as simply 600px. Finally, xanthir.com/b4Su0 explains why without viewport-urls, the markup complexity balloons (as an author still has to figure out the relationship between viewport width and layout image size, but then furthermore has to do a bunch of maths and sprinkle the breakpoints above as subtle variations in densities of the images they provide). Does this all make sense? Hopefully that helped explain why viewport-urls syntax (or something similar) is essential; but I'd definitely welcome suggestions to make it more human-understandable. The CSS lengths seem clear enough, but it's possible there's a better way of expressing the breakpoints... The latest style-based img/content proposal seems reasonable if the following issues could be addressed: - Always loads src per current browser behavior (might be fixable by omitting 'src' attribute). - Not obvious if preload scanning can reasonably be expected to resolve CSS selectors (hopefully parser/preloading experts can weigh in). I personally somewhat prefer the style-based proposal if the issues are addressed, as it has less surface syntax. It would probably also have to be combined with vanilla x-only srcset to do resolution scaling combined with art direction, without forcing sizes to be set explicitly. Regards, Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Hi
I was at the Paris RICG meetup in Paris, I understand the complexity of the
responsive requirements.
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
img src= class=artdirection/
What do you think ?
laurent
On Tue, Nov 19, 2013 at 2:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
I see. It seems like it would be simpler to just define content on a
real element to have the existing WK/Blink behavior without saying
replaced. It is not obvious why ignoring the element size is a useful
default behavior. But I suppose that discussion is out of scope here and
would better be discussed in a CSS-relevant forum.
Yeah, feel free to raise it in www-style if you're interested.
Otherwise, fantasai and/or I will take care of it in due time, when we
have time for it.
For the sake of curiosity: is there any reasonably accurate current
draft that describes what 'content' is supposed to do on a non-pseudo
element?
Nope.
The most recent reference I could find is
http://www.w3.org/TR/css3-content/ but that hasn't been updated in a
while. It says If the computed value of the part of the 'content' property
that ends up being used is a single URI, then the element or pseudo-element
is a replaced element. The box model defines different rules for the layout
of replaced elements than normal elements. Replaced elements do not have
'::before' and '::after' pseudo-elements; the 'content' property in the
case of replaced content replaces the entire contents of the element's
box. But I can't tell if that matches what you say or is the opposite.
Right, Content is out-of-date and hasn't been sanity checked. Don't
let the recent-ish date fool you; it's just a stripped-down version of
the older 2003 draft, and the remaining parts haven't been seriously
gone over yet.
~TJ
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 19, 2013, at 4:17 PM, Laurent Perez l.lauren...@gmail.com wrote:
Hi
I was at the Paris RICG meetup in Paris, I understand the complexity of the
responsive requirements.
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
img src= class=artdirection/
What do you think ?
We've been discussing these kinds of CSS-based proposals. Is there a reason you
picked 'background-image' instead of 'content'? As discussed earlier in the
thread 'content is likely to work better in a variety of ways.
Also, what do you think about the attr(src-medium url) trick, which would let
the image URLs be in the markup but the media queries in un-repeated CSS?
Regards,
Maciej
laurent
On Tue, Nov 19, 2013 at 2:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
I see. It seems like it would be simpler to just define content on a
real element to have the existing WK/Blink behavior without saying
replaced. It is not obvious why ignoring the element size is a useful
default behavior. But I suppose that discussion is out of scope here and
would better be discussed in a CSS-relevant forum.
Yeah, feel free to raise it in www-style if you're interested.
Otherwise, fantasai and/or I will take care of it in due time, when we
have time for it.
For the sake of curiosity: is there any reasonably accurate current
draft that describes what 'content' is supposed to do on a non-pseudo
element?
Nope.
The most recent reference I could find is
http://www.w3.org/TR/css3-content/ but that hasn't been updated in a
while. It says If the computed value of the part of the 'content' property
that ends up being used is a single URI, then the element or pseudo-element
is a replaced element. The box model defines different rules for the layout
of replaced elements than normal elements. Replaced elements do not have
'::before' and '::after' pseudo-elements; the 'content' property in the
case of replaced content replaces the entire contents of the element's
box. But I can't tell if that matches what you say or is the opposite.
Right, Content is out-of-date and hasn't been sanity checked. Don't
let the recent-ish date fool you; it's just a stripped-down version of
the older 2003 draft, and the remaining parts haven't been seriously
gone over yet.
~TJ
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/19/13 4:17 PM, Laurent Perez l.lauren...@gmail.com wrote:
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
There are talks on and syntax at the www-style mailing list:
http://lists.w3.org/Archives/Public/www-style/
Also combined with calc() notation.
Search for:
[mediaqueries] Add and syntax?
for the thread
You may also join that list to discuss such CSS related features directly.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: It seems like the blockers to this syntax working as-is are: - For Safari and Chrome, url(attr()) doesn't work. This will never work; for legacy compat reasons, url() is not a function, but a syntax construct specially recognized and handled by the parser. (Don't nest incompatible microsyntaxes, kids!) url(attr()) is compatibly a bad-url token right now. However, attr(foo url) does work, at least per spec. I don't think it's been implemented yet. - For Safari and Chrome, content: replaced url() doesn't work. I couldn't find a spec for the 'content' property that includes the 'replaced' token so I am not sure what it is even supposed to do. Yes, this has been a longstanding suggestion to make a 'content' image actually make the image replaced, as opposed to its current behavior which inserts an anonymous replaced-element child into it. As fantasai and I haven't significantly picked up the Content spec lately, we haven't added it yet. - For Firefox, the 'content' property doesn't work on an element (as opposed to :before and :after).. This is just a lack of implementation. I was able to get Safari and Chrome to work by getting rid of 'replaced' and specifying the images in CSS instead of using url(attr). With those changes, I noted the following possibly undesirable effects: It didn't actually work - if you try to size the element, you'll note that the images don't care. (1) Saving the image from the context menu (or opening in a new tab or window, or other context menu operations like copy) always uses the src image instead of the selected image. Dragging it uses the correct image. Sounds like something that could potentially be fixed. (2) Preloading will always preload the src (and I suspect the normal loader would do it to so that both the image src and the content: replaced source will be loaded). This is because the preloader doesn't understand CSS yet. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 18, 2013, at 9:05 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote:
It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
This will never work; for legacy compat reasons, url() is not a
function, but a syntax construct specially recognized and handled by
the parser. (Don't nest incompatible microsyntaxes, kids!)
url(attr()) is compatibly a bad-url token right now.
However, attr(foo url) does work, at least per spec. I don't think
it's been implemented yet.
Thanks for the clarification. Modulo the syntax change, it still seems like
something eminently implementable.
- For Safari and Chrome, content: replaced url() doesn't work. I couldn't
find a spec for the 'content' property that includes the 'replaced' token so
I am not sure what it is even supposed to do.
Yes, this has been a longstanding suggestion to make a 'content' image
actually make the image replaced, as opposed to its current behavior
which inserts an anonymous replaced-element child into it. As
fantasai and I haven't significantly picked up the Content spec
lately, we haven't added it yet.
I'm not enough of a CSS expert to understand the implications of that change.
What would be the observable behavior changes that 'content: replaced' would
produce?
- For Firefox, the 'content' property doesn't work on an element (as opposed
to :before and :after)..
This is just a lack of implementation.
I was able to get Safari and Chrome to work by getting rid of 'replaced' and
specifying the images in CSS instead of using url(attr). With those changes,
I noted the following possibly undesirable effects:
It didn't actually work - if you try to size the element, you'll note
that the images don't care.
Not sure what you mean by this. Do you mean that explicitly sizing the img
will be ignored by the replaced 'content' image? Because that does not seem to
be Safari or Chrome's current behavior. In particular, this markup always gives
me a 10x10 image but the contents change with the window size:
style
.artdirected {
width: 10px;
height: 10px;
}
@media (min-width: 480px) {
.artdirected { content: url(foo-small.jpg); }
}
@media (min-width: 600px) {
.artdirected { content: url(foo-medium.jpg); }
}
@media (min-width: 800px) {
.artdirected { content: url(foo-big.jpg); }
}
/style
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
(1) Saving the image from the context menu (or opening in a new tab or
window, or other context menu operations like copy) always uses the src
image instead of the selected image. Dragging it uses the correct image.
Sounds like something that could potentially be fixed.
(2) Preloading will always preload the src (and I suspect the normal loader
would do it to so that both the image src and the content: replaced source
will be loaded).
This is because the preloader doesn't understand CSS yet.
Yes, but this affects (a) polyfill deployability and (b) the level of
cleverness required in the preloader's CSS parsing (it has to not only start
preloads from CSS but inhibit natural image preloads).
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak m...@apple.com wrote:
I'm not enough of a CSS expert to understand the implications of that change.
What would be the observable behavior changes that 'content: replaced' would
produce?
- For Firefox, the 'content' property doesn't work on an element (as
opposed to :before and :after)..
This is just a lack of implementation.
I was able to get Safari and Chrome to work by getting rid of 'replaced'
and specifying the images in CSS instead of using url(attr). With those
changes, I noted the following possibly undesirable effects:
It didn't actually work - if you try to size the element, you'll note
that the images don't care.
Not sure what you mean by this. Do you mean that explicitly sizing the img
will be ignored by the replaced 'content' image? Because that does not seem
to be Safari or Chrome's current behavior. In particular, this markup always
gives me a 10x10 image but the contents change with the window size:
Ah, right, WK/Blink violate the spec wrt 'content' on real elements.
They don't support the normal value set, but do support a single
url(), which makes the element replaced.
Try it on a ::before pseudo, which implements the actual spec for 'content':
!DOCTYPE html
div/div
style
div::before {
display: block;
width: 400px;
height: 100px;
border: thin solid;
content: foo url(http://xanthir.com/pony);
}
/style
Even if you remove the foo string, so it's just a single image, it
still just sits there in the pseudo-element at its normal size,
ignoring the div::before's size entirely.
The replaced keyword will be a new branch in the 'content' grammar,
which allows a single url() after it, and does what WK/Blink currently
do.
(1) Saving the image from the context menu (or opening in a new tab or
window, or other context menu operations like copy) always uses the src
image instead of the selected image. Dragging it uses the correct image.
Sounds like something that could potentially be fixed.
(2) Preloading will always preload the src (and I suspect the normal loader
would do it to so that both the image src and the content: replaced source
will be loaded).
This is because the preloader doesn't understand CSS yet.
Yes, but this affects (a) polyfill deployability and
Right, there's always a tension between preload the most
important/fallback version and preload nothing until I'm ready for
polyfills.
(b) the level of cleverness required in the preloader's CSS parsing (it has
to not only start preloads from CSS but inhibit natural image preloads).
Correct.
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 18, 2013, at 2:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak m...@apple.com wrote:
I'm not enough of a CSS expert to understand the implications of that
change. What would be the observable behavior changes that 'content:
replaced' would produce?
- For Firefox, the 'content' property doesn't work on an element (as
opposed to :before and :after)..
This is just a lack of implementation.
I was able to get Safari and Chrome to work by getting rid of 'replaced'
and specifying the images in CSS instead of using url(attr). With those
changes, I noted the following possibly undesirable effects:
It didn't actually work - if you try to size the element, you'll note
that the images don't care.
Not sure what you mean by this. Do you mean that explicitly sizing the img
will be ignored by the replaced 'content' image? Because that does not seem
to be Safari or Chrome's current behavior. In particular, this markup always
gives me a 10x10 image but the contents change with the window size:
Ah, right, WK/Blink violate the spec wrt 'content' on real elements.
They don't support the normal value set, but do support a single
url(), which makes the element replaced.
Try it on a ::before pseudo, which implements the actual spec for 'content':
!DOCTYPE html
div/div
style
div::before {
display: block;
width: 400px;
height: 100px;
border: thin solid;
content: foo url(http://xanthir.com/pony);
}
/style
Even if you remove the foo string, so it's just a single image, it
still just sits there in the pseudo-element at its normal size,
ignoring the div::before's size entirely.
The replaced keyword will be a new branch in the 'content' grammar,
which allows a single url() after it, and does what WK/Blink currently
do.
I see. It seems like it would be simpler to just define content on a real
element to have the existing WK/Blink behavior without saying replaced. It is
not obvious why ignoring the element size is a useful default behavior. But I
suppose that discussion is out of scope here and would better be discussed in a
CSS-relevant forum.
For the sake of curiosity: is there any reasonably accurate current draft that
describes what 'content' is supposed to do on a non-pseudo element?
The most recent reference I could find is http://www.w3.org/TR/css3-content/
but that hasn't been updated in a while. It says If the computed value of the
part of the 'content' property that ends up being used is a single URI, then
the element or pseudo-element is a replaced element. The box model defines
different rules for the layout of replaced elements than normal elements.
Replaced elements do not have '::before' and '::after' pseudo-elements; the
'content' property in the case of replaced content replaces the entire contents
of the element's box. But I can't tell if that matches what you say or is the
opposite.
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote: I see. It seems like it would be simpler to just define content on a real element to have the existing WK/Blink behavior without saying replaced. It is not obvious why ignoring the element size is a useful default behavior. But I suppose that discussion is out of scope here and would better be discussed in a CSS-relevant forum. Yeah, feel free to raise it in www-style if you're interested. Otherwise, fantasai and/or I will take care of it in due time, when we have time for it. For the sake of curiosity: is there any reasonably accurate current draft that describes what 'content' is supposed to do on a non-pseudo element? Nope. The most recent reference I could find is http://www.w3.org/TR/css3-content/ but that hasn't been updated in a while. It says If the computed value of the part of the 'content' property that ends up being used is a single URI, then the element or pseudo-element is a replaced element. The box model defines different rules for the layout of replaced elements than normal elements. Replaced elements do not have '::before' and '::after' pseudo-elements; the 'content' property in the case of replaced content replaces the entire contents of the element's box. But I can't tell if that matches what you say or is the opposite. Right, Content is out-of-date and hasn't been sanity checked. Don't let the recent-ish date fool you; it's just a stripped-down version of the older 2003 draft, and the remaining parts haven't been seriously gone over yet. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, 2013, at 9:00 AM, Yoav Weiss y...@yoav.ws wrote:
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com 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)); }
}
@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
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
You're right, Maciej's concerns were addressed by Christian's proposal (and
John's followup proposal).
Any thoughts on my concerns with making inline CSS mandatory (especially
from the CSP angle)?
To be clear, I really like the idea of a style-based responsive image solution,
as it involves significantly less additional syntax and may avoid some
repetition. I just want to make sure whatever we come up with does not have any
undesirable side effects.
I can't get this particular example to work in Safari, Chrome or Firefox. Is it
meant to? It seems to always show foo.jpg. Here's a worked version with
distinct images for each filename:
The reason I tried is because I want to see what side effects this approach
might have without having to guess that from the specs.
It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
- For Safari and Chrome, content: replaced url() doesn't work. I couldn't find
a spec for the 'content' property that includes the 'replaced' token so I am
not sure what it is even supposed to do.
- For Firefox, the 'content' property doesn't work on an element (as opposed to
:before and :after)..
I did not get a chance to test IE.
I was able to get Safari and Chrome to work by getting rid of 'replaced' and
specifying the images in CSS instead of using url(attr). With those changes, I
noted the following possibly undesirable effects:
(1) Saving the image from the context menu (or opening in a new tab or window,
or other context menu operations like copy) always uses the src image instead
of the selected image. Dragging it uses the correct image.
(2) Preloading will always preload the src (and I suspect the normal loader
would do it to so that both the image src and the content: replaced source will
be loaded).
#1 would likely be fixed by a more thorough 'content' implementation. #2 could
presumably be fixed by a CSS-aware preload scanner and by tweaking the img
implementation, but the scanner would have to know how to apply CSS selectors
as it scans, since resolution of a CSS selector is what determines the right
attribute to load. The problem though is when attempting to implement a
polyfill of some kind. The polyfill would not be able to prevent 'src' from
loading as an additional resource. This could possibly be addressed by not
specifying a regular 'src' at all when using a polyfill.
Other than these two details, it seems like a good solution to the problem.
Implementing url(attr()) and these quality-of-implementation improvements would
possibly be simpler than src-n as currently specified, and it exposes a lot
less new syntax.
Regards,
Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, 2013, at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth w...@adambarth.com wrote: Do you have an alternative proposal aside from src-N? Recall that src-N has been rejected by WebKit and therefore is no longer viable. Hey, WebKit, what's your answer if we just take src-N and use a || separator to cram them all into a single attribute? Otherwise identical proposal; none of this gradually expand srcset thing. I think this is a terrible idea, and plenty of actual authors agree with me, but if multiple attributes is the one thing that's acting as a deal-killer for implementors, then screw it, we can mitigate the pain with an OM later. May god have mercy on our souls, etc. I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows: The src-n proposal with the following changes seems likely reasonable: - In a single attribute (ideally named srcset to avoid gratuitous renaming) with || or some other separator - viewport-urls syntax removed or changed to be more human-understandable The latest style-based img/content proposal seems reasonable if the following issues could be addressed: - Always loads src per current browser behavior (might be fixable by omitting 'src' attribute). - Not obvious if preload scanning can reasonably be expected to resolve CSS selectors (hopefully parser/preloading experts can weigh in). I personally somewhat prefer the style-based proposal if the issues are addressed, as it has less surface syntax. It would probably also have to be combined with vanilla x-only srcset to do resolution scaling combined with art direction, without forcing sizes to be set explicitly. Regards, Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Saturday, November 16, 2013 12:11 AM, Bruno Racineux
On 11/15/13 2:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
There is no compaction
scheme that helps here. (Unless you're trying for one of the
url-template ones, and we don't want to go there.)
Why not? I'd like to hear the argument against what I am proposing.
Either a regex or a template approach.
I would like to hear that as well. I think it's still the simplest and most
concise solution. Using Tab's examples to illustrate it and a variation of
the URL template solution I proposed a little while ago:
On Friday, November 15, 2013 9:31 PM, Tab Atkins Jr. wrote:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
I'm using different image names to not confuse anyone with too many numbers
meta var=thumb-size content=size-set(small .5x, orig 1x, large 2x, xxl
3x)
img src=thumb-fallback.jpg src-t=thumb-{thumb-size}.jpg
I used size-set in lack of a better name. The idea is to allow a number of
functions to set the value of a variable.
Use-case 2: Art-direction (slightly different images based on layout
breakpoints)
src-N
img src-1=(width 30em) foo.5 .5x, foo1 1x, foo2 2x, foo3 3x
src-2=bar.5 .5x, bar1 1x, bar2 2x, bar3 3x
src=foo1
PreloaderCSS
img src=foo1 id=foo
style
@media (width 30em) { #foo { content: replaced image-set(foo.5
.5x, foo1 1x, foo2 2x, foo3 3x); } }
@media (width = 30em) { #foo { content: replaced image-set(bar.5
.5x, bar1 1x, bar2 2x, bar3 3x); } }
/style
meta var=thumb-size content=size-set(mob-s .5x, mob-o 1x, mob-l 2x,
mob-xxl 3x)
meta var=thumb-size content=size-set(def-s .5x, def-o 1x, def-l 2x,
def-xxl 3x) media=min-width: 30em
img src=thumb-fallback.jpg src-t=thumb-{thumb-size}.jpg
Use-case 3: Variable-sized images
src-N
img src-1=100% (30em) 50% (50em) 33%; foo200 200, foo400 400, foo800
800, foo1200 1200, foo1600 1600 src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo200 200, foo400 400,
foo800 800, foo1200 1200, foo1600 1600); }
@media (width 30em) { #foo { width: 100vw; }}
@media (30em = width 50em) { #foo { width: 50vw; }}
@media (width = 50em) { #foo { width: 33vw; }}
/style
meta var=thumb-size content=size-set(100% (30em) 50% (50em) 33%;
xs 200, s 400, def 800, xl 1200, xxl 1600)
img src=thumb-fallback.jpg src-t=thumb-{thumb-size}.jpg
I think this is by far the most elegant solution and combines the elegance
of src-n by offloading the burden of the calculations to the browser with
the conciseness a templating approach is able to achieve. I expect that only
very few authors are going to create all the image variations by hand. In
the vast majority of the cases this will be done automatically by the
server. It's simple enough to rewrite the image tags to include a src-t
following some convention and adding those meta tags to the header.
I would really like to hear some arguments as to why URL templates are no
viable (or at least not a preferable) solution.
Cheers,
Markus
--
Markus Lanthaler
@markuslanthaler
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/15/13 9:48 PM, matmarquis.com m...@matmarquis.com wrote: I¹d say the likelihood of a project not using a content image directory a step or two from root is roughly the same as the likelihood that I¹m hot-linking to images on someone else¹s website땧hich is to say ³very slim.² The ³real world with clouds² case is a lot more apt to land somewhere between two exaggerations, with a more common representation of usage being something like: There is no exaggeration, I write here based on knowledge, research, and facts. I'd say you are either misunderstanding the broad based usage of RespImg or not well aware of current practices. There are no imgurl base element here, and RespImg is not limited to your 2-5 local theme or ui images. 'Very-slim' would be speaking of small sites which serve images locally for a theme and have a well designed short path structure which very few people practice or even care for. And by: /img/path/pic100.png, for content images, you realistically mean: /images/2013/11/15/my-seo-optimized-name-web-400x300.jpg I just showed you a medium range 'flickr' case which is an image gallery website serving thousand of widgets. The cases applies to Facebook album images and everything else in that category. With Wordpress accounting for 20% of all websites, here is your wordpress default average theme path: //s.ma.tt/blog-content/themes/twentythirteen/images/headers/circle.png Sitepoint (wordpress based): Local theme: //www.sitepoint.com/wp-content/themes/sitepoint/assets/svg/sitepoint.svg Content: //dab1nmslvvntp.cloudfront.net/wp-content/uploads/2013/11/azurefig1.png Cloud: //dab1nmslvvntp.cloudfront.net/wp-content/uploads/2013/09/jump-start-php_35 5.png Here are two random ones from a Drupal site: //www.eurocentres.com/sites/default/files/styles/ec_header_image/public/cou rse_ss_panorama.jpg?itok=czf1epUh //www.eurocentres.com/sites/default/files/styles/ec_teaser_image_side_wide/ public/brochure.jpg?itok=-SndaYVk With just the Drupal default 'path' being: sites/all/mytemplate/files/category/etc Mashable Rack CDN: //rack.3.mshcdn.com/media/ZgkyMDEzLzExLzE1LzhhL2JiMS5hN2I3Ny5qcGcKcAl0 aHVtYgkxNzV4MTc1IwplCWpwZw/1303c958/d02/bb1.jpg NYTimes CDN: //i1.nyt.com/images/2013/11/16/us/SNAKES-1/SNAKES-1-hpMedium-v2.jpg Techcrunch CDN: //tctechcrunch2011.files.wordpress.com/2013/11/football-blank2.jpg The chances of a path as short as '/img/path/pic100.png' in bytes size is the one that's very slim I am afraid. In fact, I dare you to find me a platform that stores its uploaded images with an average path that short by design. img src=/img/path/pic100.png src-1=100% (30em) 50% (50em) calc(33% - 100px); /img/path/pic100.png 100, /img/path/pic200.png 200, /img/path/pic400.png 400, /img/path/pic800.png 800, /img/path/pic1600.png 1600, /img/path/pic3200.png 3200 alt=[�] I don¹t find this terribly difficult to parse, as an author. Even with a path that short this the way it reads as a real world source: img src=/img/path/pic100.png src-1=100% (30em) 50% (50em) calc(33% - 100px); /img/path/pic100.png 100, /img/path/pic200.png 200, /img/path/pic400.png 400, /img/path/pic800.png 800,/img/path/pic1600.png 1600, /img/path/pic3200.png 3200 You can barely tell how many src(s) there are, right away.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 16, at 4:25 PM, Bruno Racineux wrote:
On 11/15/13 9:48 PM, matmarquis.com m...@matmarquis.com wrote:
I©öd say the likelihood of a project not using a content image directory a
step or two from root is roughly the same as the likelihood that I©öm
hot-linking to images on someone else©ös website—which is to say ©øvery
slim.©÷ The ©øreal world with clouds©÷ case is a lot more apt to land
somewhere between two exaggerations, with a more common representation of
usage being something like:
There is no exaggeration, I write here based on knowledge, research, and
facts.
I'd say you are either misunderstanding the broad based usage of RespImg
or not well aware of current practices. There are no imgurl base element
here, and RespImg is not limited to your 2-5 local theme or ui images.
I started and have been running the Responsive Images Community Group for
nearly three years now. I helped build BostonGlobe.com and the original
“prototype” script for responsive images, I’m a maintainer on the Picturefill
project, and I wrote large parts of the `picture` proposal. I have a pretty
fair idea of the current “best practices” for responsive sites.
'Very-slim' would be speaking of small sites which serve images locally
for a theme and have a well designed short path structure which very few
people practice or even care for.
And by: /img/path/pic100.png, for content images, you realistically mean:
/images/2013/11/15/my-seo-optimized-name-web-400x300.jpg
I just showed you a medium range 'flickr' case which is an image gallery
website serving thousand of widgets. The cases applies to Facebook album
images and everything else in that category.
With Wordpress accounting for 20% of all websites,
here is your wordpress default average theme path:
//s.ma.tt/blog-content/themes/twentythirteen/images/headers/circle.png
Sitepoint (wordpress based):
Local theme:
//www.sitepoint.com/wp-content/themes/sitepoint/assets/svg/sitepoint.svg
Content:
//dab1nmslvvntp.cloudfront.net/wp-content/uploads/2013/11/azurefig1.png
Cloud:
//dab1nmslvvntp.cloudfront.net/wp-content/uploads/2013/09/jump-start-php_35
5.png
Here are two random ones from a Drupal site:
//www.eurocentres.com/sites/default/files/styles/ec_header_image/public/cou
rse_ss_panorama.jpg?itok=czf1epUh
//www.eurocentres.com/sites/default/files/styles/ec_teaser_image_side_wide/
public/brochure.jpg?itok=-SndaYVk
With just the Drupal default 'path' being:
sites/all/mytemplate/files/category/etc
Mashable Rack CDN:
//rack.3.mshcdn.com/media/ZgkyMDEzLzExLzE1LzhhL2JiMS5hN2I3Ny5qcGcKcAl0
aHVtYgkxNzV4MTc1IwplCWpwZw/1303c958/d02/bb1.jpg
NYTimes CDN:
//i1.nyt.com/images/2013/11/16/us/SNAKES-1/SNAKES-1-hpMedium-v2.jpg
Techcrunch CDN:
//tctechcrunch2011.files.wordpress.com/2013/11/football-blank2.jpg
The chances of a path as short as '/img/path/pic100.png' in bytes size is
the one that's very slim I am afraid. In fact, I dare you to find me a
platform that stores its uploaded images with an average path that short
by design.
The examples above are entirely examples of sites that use templates for their
output, at which point things have effectively left “hand-authoring” territory.
In authoring a page, we’re building and handing off those templates for
integration with a CMS, at which point those sources are output on the backend.
I can’t think of many instances where I’ll be forced to hand-edit the *output*
of a Drupal site.
A more accurate example in terms of actual authoring with any of things you’ve
cited above—specific variable syntax notwithstanding—would be something like:
img
src={img1}
src-1=100% (30em) 50% (50em) calc(33% - 100px);
{img1} 100,
{img2} 200,
{img3} 400,
{img4} 800,
{img5} 1600,
{img6} 3200
alt=[…]
But for the sake of discussion, I’m fine with inflating any syntax pattern up
for discussion equally with hotlinked Flickr URLs, since there’s really no
point in arguing either way. “Six of one, sixty characters of another,” as they
say.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/16/13 3:24 PM, matmarquis.com m...@matmarquis.com wrote:
I started and have been running the Responsive Images Community Group for
nearly three years now.I helped build BostonGlobe.com and the original
³prototype² script for responsive images, I¹m a maintainer on the
Picturefill project, and I wrote large parts of the `picture` proposal. I
have a pretty fair idea of the current ³best practices² for responsive
sites.
You are taking it personally on a misread, and my admittedly exaggerated
verbose to criticize your counter-argument. By 'current practices', I was
solely referring to the average length of image paths, which you gave me
no factual argument other than I¹d say the likelihood is ³very slim.²
with non practical examples.
I was partly aware of your background, but that's besides the point of
this argument.
Please just don't qualify my example as 'exaggeration' with a fictitious
'more common representation of usage' in term of average char length.
The average src path of an img on the web is between 50 to 70 chars.
That's the sole point of my argument here, as per my examples.
And I don't know why you seem to talk about 'hotlinked' images as a
special category... I just hope that your argument is not that
Hotlinked/Cloud/CDN images don't apply to src-N or srcset, which is what I
first read.
On 11/16/13 3:15 PM, Yoav Weiss y...@yoav.ws wrote:
Claims of research and facts are usually more credible when linked to an
actual research and/or facts.
Yoav, I didn't feel the need to point to non-existing studies to prove
a fairly obvious point, other that citing something a dozen examples
mentioning with wordpress + drupal which roughly cover 50% of cms usage
stats, or over 30% of the web.
But if you must have those particular facts, here they are:
http://w3techs.com/technologies/details/cm-wordpress/all/all
http://trends.builtwith.com/cms
On 11/16/13 3:24 PM, matmarquis.com m...@matmarquis.com wrote:
The examples above are entirely examples of sites that use templates for
their output, at which point things have effectively left
³hand-authoring² territory. In authoring a page, we¹re building and
handing off those templates for integration with a CMS, at which point
those sources are output on the backend. I can¹t think of many instances
where I¹ll be forced to hand-edit the *output* of a Drupal site.
Neither do I. I am talking about the resulting size of an HTML page, and
readability of src-N code in the broad context of debugging.
Not code editing per say. I don't recall saying that the code had to be
editing friendly.
A more accurate example in terms of actual authoring with any of things
you¹ve cited abovespecific variable syntax notwithstandingwould be
something like:
img
src={img1}
src-1=100% (30em) 50% (50em) calc(33% - 100px);
{img1} 100,
{img2} 200,
{img3} 400,
{img4} 800,
{img5} 1600,
{img6} 3200
alt=[]
I am not concerned about the authoring of it. Not sure why you are
referring to authoring with that example? I am actually not sure you are
getting my point about 'bloat' and whether your couter-argument actually
talk about the same thing...
But for the sake of discussion, I¹m fine with inflating any syntax
pattern up for discussion equally with hotlinked Flickr URLs, since
there¹s really no point in arguing either way. ³Six of one, sixty
characters of another,² as they say.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak m...@apple.com wrote: 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. Can any proponent of the inline-style based methods address the concerns Maciej and myself have raised?
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 1:55 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak m...@apple.com wrote:
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.
Can any proponent of the inline-style based methods address the concerns
Maciej and myself have raised?
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com 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)); }
}
@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
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com 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)); }
}
@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
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
You're right, Maciej's concerns were addressed by Christian's proposal (and
John's followup proposal).
Any thoughts on my concerns with making inline CSS mandatory (especially
from the CSP angle)?
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 9:00 AM, Yoav Weiss y...@yoav.ws wrote:
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com 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)); }
}
@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
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
You're right, Maciej's concerns were addressed by Christian's proposal (and
John's followup proposal).
Any thoughts on my concerns with making inline CSS mandatory (especially
from the CSP angle)?
CSP 1.1 supports securing inline style and script with nonces and/or hashes.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Could I just please clarify, since its been hard to follow the
conversation, that having the style internal means that the prefetcher can
still handle the images properly?
Thanks,
Shane
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
On Fri, Nov 15, 2013 at 1:55 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak m...@apple.com
wrote:
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.
Can any proponent of the inline-style based methods address the concerns
Maciej and myself have raised?
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com 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)); }
}
@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
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 5:12 PM, Shane Hudson m...@shanehudson.net wrote: Could I just please clarify, since its been hard to follow the conversation, that having the style internal means that the prefetcher can still handle the images properly? Yes, *but* only if you use a limited subset of CSS. Adam suggested earlier (quoted below), that the preparser would only be able to match simple selectors (like class and id), but not selectors that need to understand the structure of the DOM tree (e.g. descendant or sibling selectors). Personally, I suspect authors would trip up on this quite a bit. On Tue, Nov 12, 2013 at 6:49 PM, Adam Barth w...@adambarth.com wrote: 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 Nov 15, at 12:12 PM, Shane Hudson wrote:
Could I just please clarify, since its been hard to follow the
conversation, that having the style internal means that the prefetcher can
still handle the images properly?
Also, we seem to be operating under the assumption that requiring in-page CSS
is going to fly with implementors and/or authors. I can only speak to the
latter being false, in my own case, but the former seems a little hard to
believe.
Thanks,
Shane
On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth w...@adambarth.com wrote:
On Fri, Nov 15, 2013 at 1:55 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak m...@apple.com
wrote:
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.
Can any proponent of the inline-style based methods address the concerns
Maciej and myself have raised?
My apologies. I thought Christian Biesinger addressed all these
concerns with his proposal:
On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
cbiesin...@google.com 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)); }
}
@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
Specifically, his approach uses an img element, which addresses all
four of Maciej's concerns.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 10:25 AM, matmarquis.com m...@matmarquis.com wrote: On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table. The primary benefit of this proposal over src-N is that implementors are willing to implement it (or at least haven't refused to implement it yet). Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
To my knowledge the only implementor who flat-out refused to implement src-N was WebKit. There is interest from Mozilla and Blink, though it did sound like Blink was considering playing follow the leader. Take care, Tim Kadlec On Fri, Nov 15, 2013 at 12:25 PM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 15, 2013 at 10:25 AM, matmarquis.com m...@matmarquis.com wrote: On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table. The primary benefit of this proposal over src-N is that implementors are willing to implement it (or at least haven't refused to implement it yet). Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 10:32 AM, Tim Kadlec t...@timkadlec.com wrote: To my knowledge the only implementor who flat-out refused to implement src-N was WebKit. There is interest from Mozilla and Blink, though it did sound like Blink was considering playing follow the leader. That's right. Blink isn't likely to implement a responsive image proposal that WebKit refuses to implement. Adam On Fri, Nov 15, 2013 at 12:25 PM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 15, 2013 at 10:25 AM, matmarquis.com m...@matmarquis.com wrote: On Nov 15, at 12:27 PM, Yoav Weiss wrote: Any thoughts on my concerns with making inline CSS mandatory (especially from the CSP angle)? CSP 1.1 supports securing inline style and script with nonces and/or hashes. OK, since the latest proposals keep the URLs outside the style, modifying the content image can keep the same style, assuming layout is identical. So these inline-style are not more likely to change than any other inline-styles and the authoring complexity is identical to other inline styles. Still - I'm not sure such a solution is author friendly. I’m just not sure what this proposal claims to handle or support that `src-n` doesn’t, apart from handling it with a slightly different syntax that’s subjectively preferred by a few people? Seems like it depends on a number of fairly large assumptions, but doesn’t really bring anything new to the table. The primary benefit of this proposal over src-N is that implementors are willing to implement it (or at least haven't refused to implement it yet). Adam
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.
Okay, here are some examples done up in as reasonable and compact a
manner as I can do, assuming certain syntaxes when they haven't yet
been created:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
Use-case 2: Art-direction (slightly different images based on layout
breakpoints)
src-N
img src-1=(width 30em) foo.5 .5x, foo1 1x, foo2 2x, foo3 3x
src-2=bar.5 .5x, bar1 1x, bar2 2x, bar3 3x
src=foo1
PreloaderCSS
img src=foo1 id=foo
style
@media (width 30em) { #foo { content: replaced image-set(foo.5
.5x, foo1 1x, foo2 2x, foo3 3x); } }
@media (width = 30em) { #foo { content: replaced image-set(bar.5
.5x, bar1 1x, bar2 2x, bar3 3x); } }
/style
Use-case 3: Variable-sized images
src-N
img src-1=100% (30em) 50% (50em) 33%; foo200 200, foo400 400, foo800
800, foo1200 1200, foo1600 1600 src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo200 200, foo400 400,
foo800 800, foo1200 1200, foo1600 1600); }
@media (width 30em) { #foo { width: 100vw; }}
@media (30em = width 50em) { #foo { width: 50vw; }}
@media (width = 50em) { #foo { width: 33vw; }}
/style
These examples... do not look good.
The simplest one isn't much worse, granted. It suffers from the put
an id on it that makes working with label/input a minor chore,
but otherwise is mostly just shifting things around.
The second one is a bit more annoying. The additional syntax weight
of the CSS trappings add up a bit, even with only two options.
The third one is just more or less ridiculous. The added syntax
weight really shows itself here, with three largish lines to express
what src-N does in 5 tokens. The fact that the sizes are separated
from the sources is weird. The fact that you can only use a few units
(because you're no longer able to say evaluate these sizes in an MQ
context, so em units and the like are useless because they depend
on style resolution) is very confusing.
This is a subset of CSS, yes, but the line dividing what you can use
from what you can't is rather windy, rather than being clear-cut and
simple. People will regularly get this wrong.
Any argument that this is simpler to author, or easier for CMSes to
deal with, is rather laughable. It's just as hard, if not more so.
A further, and kinda killer, problem with this is that it *can't be
reasonably polyfilled*. I know as much as anyone that designing
around polyfills is often too limiting, but seriously, polyfilling
this requires a full CSS parser. What this actually means is that
people will be using custom attributes and PictureFill or whatever for
a long time. They'll be polyfilling for a long time regardless, but
the problem here is that they wont' be using a syntax compatible with
the real solution.
The one benefit of this proposal is that it potentially lets us
preload unrelated CSS images, if they happen to match the patterns we
specify (inline, id or class selector, etc.). That sounds like
something that would be good to do regardless, but doesn't by itself
buy us enough benefit to justify the rest of the pain of this
solution.
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
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.
Okay, here are some examples done up in as reasonable and compact a
manner as I can do, assuming certain syntaxes when they haven't yet
been created:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
Use-case 2: Art-direction (slightly different images based on layout
breakpoints)
src-N
img src-1=(width 30em) foo.5 .5x, foo1 1x, foo2 2x, foo3 3x
src-2=bar.5 .5x, bar1 1x, bar2 2x, bar3 3x
src=foo1
PreloaderCSS
img src=foo1 id=foo
style
@media (width 30em) { #foo { content: replaced image-set(foo.5
.5x, foo1 1x, foo2 2x, foo3 3x); } }
@media (width = 30em) { #foo { content: replaced image-set(bar.5
.5x, bar1 1x, bar2 2x, bar3 3x); } }
/style
Use-case 3: Variable-sized images
src-N
img src-1=100% (30em) 50% (50em) 33%; foo200 200, foo400 400, foo800
800, foo1200 1200, foo1600 1600 src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo200 200, foo400 400,
foo800 800, foo1200 1200, foo1600 1600); }
@media (width 30em) { #foo { width: 100vw; }}
@media (30em = width 50em) { #foo { width: 50vw; }}
@media (width = 50em) { #foo { width: 33vw; }}
/style
These examples... do not look good.
The simplest one isn't much worse, granted. It suffers from the put
an id on it that makes working with label/input a minor chore,
but otherwise is mostly just shifting things around.
The second one is a bit more annoying. The additional syntax weight
of the CSS trappings add up a bit, even with only two options.
The third one is just more or less ridiculous. The added syntax
weight really shows itself here, with three largish lines to express
what src-N does in 5 tokens. The fact that the sizes are separated
from the sources is weird. The fact that you can only use a few units
(because you're no longer able to say evaluate these sizes in an MQ
context, so em units and the like are useless because they depend
on style resolution) is very confusing.
This is a subset of CSS, yes, but the line dividing what you can use
from what you can't is rather windy, rather than being clear-cut and
simple. People will regularly get this wrong.
Any argument that this is simpler to author, or easier for CMSes to
deal with, is rather laughable. It's just as hard, if not more so.
A further, and kinda killer, problem with this is that it *can't be
reasonably polyfilled*. I know as much as anyone that designing
around polyfills is often too limiting, but seriously, polyfilling
this requires a full CSS parser. What this actually means is that
people will be using custom attributes and PictureFill or whatever for
a long time. They'll be polyfilling for a long time regardless, but
the problem here is that they wont' be using a syntax compatible with
the real solution.
The one benefit of this proposal is that it potentially lets us
preload unrelated CSS images, if they happen to match the patterns we
specify (inline, id or class selector, etc.). That sounds like
something that would be good to do regardless, but doesn't by itself
buy us enough benefit to justify the rest of the pain of this
solution.
Do you have an alternative proposal aside from src-N? Recall that
src-N has been rejected by WebKit and therefore is no longer viable.
Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, 2013, at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
The simple case is a case srcset (the DPR parts) solves and I'd argue should be
used here instead.
The simplest one isn't much worse, granted. It suffers from the put
an id on it that makes working with label/input a minor chore,
but otherwise is mostly just shifting things around.
Sure you can use ids. But the idea behind the CSS proposal was to allow better
sharing of the breakpoint media queries. Using ids doesn't share, using a class
would. Src-N you have no choice but to repeat everything everywhere.
These examples... do not look good.
They look better in an editor. CSS is syntax highlighted. Src-N's format isn't
and likely would never be — as most HTML attributes aren't.
— Timothy Hatcher
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth w...@adambarth.com wrote: Do you have an alternative proposal aside from src-N? Recall that src-N has been rejected by WebKit and therefore is no longer viable. As far as I've been able to divine, Apple's position is do nothing, because srcset is good enough for the iPad. There were vague hints of technical problems that, despite repeated questions about it, were never elaborated on. The only objection is aesthetic. Aesthetic concerns don't, by themselves, suffice to shoot down an idea that other vendors like. By that same token, srcset is dead, because FF dropped support for it. I'm not even sure Apple doesn't object to PreloaderCSS, except that by virtue of it being roughly do nothing, they might not feel like it's a grotesque perversion of the HTML language or [making] the web my science project. The only feedback from Apple in this thread has been Ryosuke saying that he thinks art direction is presentational, and thus better suited to being placed in CSS (it's no more presentational than the src attribute itself), and Maciej saying that using 'content' rather than 'background-image' seems better (valid). ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 1:05 PM, Timothy Hatcher timo...@apple.com wrote:
On Nov 15, 2013, at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
The simple case is a case srcset (the DPR parts) solves and I'd argue should
be used here instead.
You can s/src-1/srcset/ this example; the two are identical for this use-case.
The simplest one isn't much worse, granted. It suffers from the put
an id on it that makes working with label/input a minor chore,
but otherwise is mostly just shifting things around.
Sure you can use ids. But the idea behind the CSS proposal was to allow
better sharing of the breakpoint media queries.
Not really. PreloaderCSS gives you two choices, both bad:
1. Put the image sources in a style next to each img, thus
repeating your layout breakpoints in the MQs multiple times. (This
weakness is shared by src-N.)
2. Or put all your image sources in a single style block somewhere
in the page, requiring people to look in two places for image sources
and virtually guaranteeing that the fallback url in img src will be
ignored and fall out of sync. You still have your breakpoints in at
least *two* places though - once in your in-page style block, and
once in your external CSS.
I think #1 is better, as we can solve it with Custom MQs/MQ
Variables/whatever, which the CSSWG is already kosher with (and I'll
be writing up soon). Once that's solved, much of the problems of this
approach disappear for both src-N and PreloaderCSS.
Using ids doesn't share,
using a class would. Src-N you have no choice but to repeat everything
everywhere.
Why would you be using classes? Most images that you need to make
responsive are one-off content images, like the big picture in
http://www.bostonglobe.com/magazine/2013/11/10 (and maybe the
picture in the sidebar).
The only reason to use a class is if:
1. You're displaying the exact same image multiple times on the same page.
2. *And* it's for some reason appropriate/important as a content
image, rather than just using a standard (and totally okay) CSS
image-replacement method.
3. *And* it's large enough that you actually care about the increased
weight from higher densities. (Gimme an 8x retweet arrow; who cares?)
I respectfully submit that images matching all three of these criteria
are so low-occurrence as to be mistaken for noise.
Even on a site that uses a *lot* of images that could benefit from
responsiveness, like Vogue http://www.vogue.com/, all of them are
one-offs.
So, let's be honest here - using classes in PreloaderCSS was *never*
something people were actually going to do. It's all about IDs and
just shifting all the src-N stuff from attributes to an adjacent style
block.
These examples... do not look good.
They look better in an editor. CSS is syntax highlighted. Src-N's format
isn't and likely would never be — as most HTML attributes aren't.
While the tools will save us is not generally a useful argument,
syntax highlighting is easy peasy. I could add this to Sublime's HTML
highlighter in half an hour max, and it would only take that long
because I'm still not super-comfortable with the authoring format.
There's no syntax highlighting *yet*. isn't a very useful argument
here.
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, 15 Nov 2013, Tab Atkins Jr. wrote: These examples... do not look good. I presume you mean that they don't look good in the style case, but actually, I don't know if that's accurate. Don't forget that in many cases the page will have multiple such images. You have to duplicated the img-* markup in each case. You only have to give the style block once. This is a subset of CSS, yes, but the line dividing what you can use from what you can't is rather windy, rather than being clear-cut and simple. People will regularly get this wrong. That's a valid concern, I think. FWIW, my original thought in this direction (which I unsuccessfully tried to peddle in #whatwg) was to use a dedicated language rather than something backwards-compatible with CSS. A further, and kinda killer, problem with this is that it *can't be reasonably polyfilled*. The main idea of Adam's idea is it doesn't have to be, no? -- 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)
On Nov 15, 2013, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Nov 15, 2013 at 1:05 PM, Timothy Hatcher timo...@apple.com wrote:
On Nov 15, 2013, at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Use-case 1: Variable density.
src-N
img src-1=foo.5 .5x, foo1 1x, foo2 2x, foo3 3x src=foo1
PreloaderCSS
img src=foo1 id=foo
style
#foo { content: replaced image-set(foo.5 .5x, foo1 1x, foo2 2x,
foo3 3x); }
/style
The simple case is a case srcset (the DPR parts) solves and I'd argue should
be used here instead.
You can s/src-1/srcset/ this example; the two are identical for this use-case.
I was saying srcset would naturally better here instead of style in a world
where src-N does not exist.
The simplest one isn't much worse, granted. It suffers from the put
an id on it that makes working with label/input a minor chore,
but otherwise is mostly just shifting things around.
Sure you can use ids. But the idea behind the CSS proposal was to allow
better sharing of the breakpoint media queries.
Not really. PreloaderCSS gives you two choices, both bad:
1. Put the image sources in a style next to each img, thus
repeating your layout breakpoints in the MQs multiple times. (This
weakness is shared by src-N.)
2. Or put all your image sources in a single style block somewhere
in the page, requiring people to look in two places for image sources
and virtually guaranteeing that the fallback url in img src will be
ignored and fall out of sync. You still have your breakpoints in at
least *two* places though - once in your in-page style block, and
once in your external CSS.
I think #1 is better, as we can solve it with Custom MQs/MQ
Variables/whatever, which the CSSWG is already kosher with (and I'll
be writing up soon). Once that's solved, much of the problems of this
approach disappear for both src-N and PreloaderCSS.
Using ids doesn't share,
using a class would. Src-N you have no choice but to repeat everything
everywhere.
Why would you be using classes? Most images that you need to make
responsive are one-off content images, like the big picture in
http://www.bostonglobe.com/magazine/2013/11/10 (and maybe the
picture in the sidebar).
The only reason to use a class is if:
1. You're displaying the exact same image multiple times on the same page.
2. *And* it's for some reason appropriate/important as a content
image, rather than just using a standard (and totally okay) CSS
image-replacement method.
3. *And* it's large enough that you actually care about the increased
weight from higher densities. (Gimme an 8x retweet arrow; who cares?)
I respectfully submit that images matching all three of these criteria
are so low-occurrence as to be mistaken for noise.
Even on a site that uses a *lot* of images that could benefit from
responsiveness, like Vogue http://www.vogue.com/, all of them are
one-offs.
So, let's be honest here - using classes in PreloaderCSS was *never*
something people were actually going to do. It's all about IDs and
just shifting all the src-N stuff from attributes to an adjacent style
block.
You conveniently left out the nice part of Christian's proposal, or didn't
notice it. Using attr() allows the style rules to be written generically by
only defining the breakpoint media queries in the style. The image URLs and
sizes are not in the style they are in the meaningfully named HTML attrs. So
classes can be used instead of ids and used for all or groups of similar
images. Yes writing the examples like you did does require a style per image
and is not a win. Nothing stopes one-off images though.
These examples... do not look good.
They look better in an editor. CSS is syntax highlighted. Src-N's format
isn't and likely would never be — as most HTML attributes aren't.
While the tools will save us is not generally a useful argument,
syntax highlighting is easy peasy. I could add this to Sublime's HTML
highlighter in half an hour max, and it would only take that long
because I'm still not super-comfortable with the authoring format.
There's no syntax highlighting *yet*. isn't a very useful argument
here.
If an attribute requires syntax highlighting to be understood, you failed. No
other HTML attributes really require attribute level syntax highlighting,
except maybe style or onclick and friends. But even those are not syntax
highlighted.
I was merely saying: you get better looking code for free with style. CSS
syntax highlighters already understand CSS and media queries. No tool changes
required.
— Timothy Hatcher
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 2:39 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Nov 2013, Tab Atkins Jr. wrote: These examples... do not look good. I presume you mean that they don't look good in the style case, but actually, I don't know if that's accurate. Don't forget that in many cases the page will have multiple such images. You have to duplicated the img-* markup in each case. You only have to give the style block once. Nope, you'll be duplicating per-image in both cases. As I told Timothy, you *might* condense some things so that you don't duplicate the @media declaration, but then you've separated the sources from the imgs, which has its own problems. This is a subset of CSS, yes, but the line dividing what you can use from what you can't is rather windy, rather than being clear-cut and simple. People will regularly get this wrong. That's a valid concern, I think. FWIW, my original thought in this direction (which I unsuccessfully tried to peddle in #whatwg) was to use a dedicated language rather than something backwards-compatible with CSS. A further, and kinda killer, problem with this is that it *can't be reasonably polyfilled*. The main idea of Adam's idea is it doesn't have to be, no? Adam's idea (at least, the variant that uses img/content rather than div/background-image) relies on abilities that older (and current) browsers don't have, so it does need to be polyfilled. Even if you use div/background-image, you lose the ability to auto-size images (background images don't affect the size of the element), and you still don't have a reasonable syntax for variable-sized images, as those require additions to image-set(). ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
* Tab Atkins Jr. wrote: On Fri, Nov 15, 2013 at 2:39 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Nov 2013, Tab Atkins Jr. wrote: These examples... do not look good. I presume you mean that they don't look good in the style case, but actually, I don't know if that's accurate. Don't forget that in many cases the page will have multiple such images. You have to duplicated the img-* markup in each case. You only have to give the style block once. Nope, you'll be duplicating per-image in both cases. (There is always an option to introduce one of the many macro proposals, or to make a dedicated at-rule or similar feature to avoid duplication.) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 2:49 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tab Atkins Jr. wrote: On Fri, Nov 15, 2013 at 2:39 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Nov 2013, Tab Atkins Jr. wrote: These examples... do not look good. I presume you mean that they don't look good in the style case, but actually, I don't know if that's accurate. Don't forget that in many cases the page will have multiple such images. You have to duplicated the img-* markup in each case. You only have to give the style block once. Nope, you'll be duplicating per-image in both cases. (There is always an option to introduce one of the many macro proposals, or to make a dedicated at-rule or similar feature to avoid duplication.) No. My point is that almost all of the syntax weight is the urls and their descriptors, regardless of the approach. There is no compaction scheme that helps here. (Unless you're trying for one of the url-template ones, and we don't want to go there.) ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 2:39 PM, Timothy Hatcher timo...@apple.com wrote:
On Nov 15, 2013, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You can s/src-1/srcset/ this example; the two are identical for this
use-case.
I was saying srcset would naturally better here instead of style in a
world where src-N does not exist.
Right; I'm saying it doesn't matter. Just mentally substitute the two
if you want. I was specifically comparing a reasonable solution to
the provided use-cases (src-N) to PreloaderCSS, not srcset.
So, let's be honest here - using classes in PreloaderCSS was *never*
something people were actually going to do. It's all about IDs and
just shifting all the src-N stuff from attributes to an adjacent style
block.
You conveniently left out the nice part of Christian's proposal, or didn't
notice it. Using attr() allows the style rules to be written generically by
only defining the breakpoint media queries in the style. The image URLs
and sizes are not in the style they are in the meaningfully named HTML
attrs. So classes can be used instead of ids and used for all or groups of
similar images.
Here's Christian's example (adjusted to use proper syntax):
style
@media (min-width: 480px) {
.artdirected { content: replaced attr(src-small url); }
}
@media (min-width: 600px) {
.artdirected { content: replaced attr(src-medium url); }
}
@media (min-width: 800px) {
.artdirected { content: replaced attr(src-big url); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
Yeah, that's a bit of win on verbosity, but it still suffers from the
invalid in every current browser, and hard to polyfill problem, and
the the line that separates usable CSS from unusable is hard to see.
(And note that this doesn't do density negotiation. To make *that*
work, we'd have to add an image-set type to attr().)
The problem is wanting to spread breakpoint information around in
several parts of the page, but wanting to edit it in only one place.
We can solve this directly, and the CSSWG is fairly supportive of the
generic approach for doing so. We can hack around the issue by trying
to make it less painful to put into everything MQ-dependent into one
place, but we're just skirting the issue. We added Custom
Properties/Variables for a reason, and that reasoning applies
identically to MQs, so we should just embrace it and stop pretending
that MQ maintenance is a problem.
If an attribute requires syntax highlighting to be understood, you failed.
No other HTML attributes really require attribute level syntax highlighting,
except maybe style or onclick and friends. But even those are not syntax
highlighted.
I was merely saying: you get better looking code for free with style.
CSS syntax highlighters already understand CSS and media queries. No tool
changes required.
It doesn't require syntax highlighting. While the most complex
possible case needs a little getting used to before it's easily
readable, it's not so complex that syntax highlighting is necessary;
it's still pretty short and simple.
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth w...@adambarth.com wrote: Do you have an alternative proposal aside from src-N? Recall that src-N has been rejected by WebKit and therefore is no longer viable. Hey, WebKit, what's your answer if we just take src-N and use a || separator to cram them all into a single attribute? Otherwise identical proposal; none of this gradually expand srcset thing. I think this is a terrible idea, and plenty of actual authors agree with me, but if multiple attributes is the one thing that's acting as a deal-killer for implementors, then screw it, we can mitigate the pain with an OM later. May god have mercy on our souls, etc. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/13/13 5:52 AM, John Mellor joh...@google.com wrote:
style
@media (max-width: 19.99em) {
.artdirected { content: replaced image-set(128px;
attr(srcs-smallicon));
}
}
@media (min-width: 20em) {
.artdirected { content: replaced image-set(100% (30em) 50% (50em) 33%;
attr(srcs-flexwidth)); }
}
You have a repeat of MQs here.
/style
...
img class=artdirected src=fallback.jpg
srcs-smallicon=i64.jpg 64, i128.jpg 128, i256.jpg 256
srcs-flexwidth=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg 1280,
2560.jpg 2560
Just to make it clear. My notion of 'imgset' here was in part an image
set, much more that it is yet-another set image with multiple sources.
The above doesn't really solve the bloat. Whether it's srcset or src-N the
page's source length of heavy image sites will be insane... Especially if
not gzipped.
The new syntax has got to be DRY. It maybe doesn't have the ONLY way, but
we surely need an non-repeat approach as part of the solution.
On 11/15/13 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Why would you be using classes? Most images that you need to make
responsive are one-off content images, like the big picture in
http://www.bostonglobe.com/magazine/2013/11/10 (and maybe the
picture in the sidebar).
Tab, you are seriously worrying me with that argument. What about a full
gallery of images sharing the same pattern. If you guys think that
responsive images are only small single isolated unique sets of images. I
don't think we are looking at the same sets of use cases...
Imagine a gallery page with 20+ images using the exact same breakpoint
model. Do you really want to repeat the srcs for every single of those
images. I don't know about perversion of the web. But it looks to me like
no one is picturing the impending bloat for these use cases...
This isn't 1998 writing static pages anymore. Website are built on
frameworks. Most of the time, Frameworks build ALL their images in sets of
sizes with a simple common pattern. Those cases should apply to a
comprehensive RespImg solution. This is what I am trying to solve here.
Here is an update along my initial model with John's example, and
custom media-vars (with the syntax we discussed on the w3cstyle list):
head
style
@media-var 'smallicon' (max-width: 19.99em);
@media-var 'flexwidth' (min-width: 20em);
@imgset 'set-1' (64 64 1x, 128 128 1x, 256 256 1x 128 2x 64 3x), regexp();
@imgset 'set-2' (160 160, 320 320, 640 640, 1280 1280), regexp();
/style
/head
img src=fallback.jpg
imgset=set-1@media('smallicon') 128px;
set-2@media('flexwidth') 100% (30em) 50% (50em) 33%
It does not require the preloader to have full css parser. It only has to
parse @media and the new @imgset CSS subset language, using a similar
syntax to @media. And I believe if offer an easy way to polyfill this.
This is really as big as the DOM ought to get AFAIAC.
-BR
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/15/13 2:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: There is no compaction scheme that helps here. (Unless you're trying for one of the url-template ones, and we don't want to go there.) Why not? I'd like to hear the argument against what I am proposing. Either a regex or a template approach. You keep agreeing that neither srcset nor src-N address that. So why leave it unsolved and induce more verbose to pages. I don't get it.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 3:02 PM, Bruno Racineux br...@hexanet.net wrote:
On 11/15/13 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Why would you be using classes? Most images that you need to make
responsive are one-off content images, like the big picture in
http://www.bostonglobe.com/magazine/2013/11/10 (and maybe the
picture in the sidebar).
Tab, you are seriously worrying me with that argument. What about a full
gallery of images sharing the same pattern. If you guys think that
responsive images are only small single isolated unique sets of images. I
don't think we are looking at the same sets of use cases...
Imagine a gallery page with 20+ images using the exact same breakpoint
model. Do you really want to repeat the srcs for every single of those
images. I don't know about perversion of the web. But it looks to me like
no one is picturing the impending bloat for these use cases...
I don't understand. You don't repeat any sources, you specify them
once. There's just a batch of sources per image. Can't make this
more compact.
The repetition is in the MQs, and that's solveable quite directly and
generically with custom MQs.
Here is an update along my initial model with John's example, and
custom media-vars (with the syntax we discussed on the w3cstyle list):
head
style
@media-var 'smallicon' (max-width: 19.99em);
@media-var 'flexwidth' (min-width: 20em);
@imgset 'set-1' (64 64 1x, 128 128 1x, 256 256 1x 128 2x 64 3x), regexp();
@imgset 'set-2' (160 160, 320 320, 640 640, 1280 1280), regexp();
/style
/head
img src=fallback.jpg
imgset=set-1@media('smallicon') 128px;
set-2@media('flexwidth') 100% (30em) 50% (50em) 33%
Where are the source urls? Are they supposed to be those numbers in
@imgset? What does regexp() mean? I don't understand your use of
commas in @imgset.
It does not require the preloader to have full css parser. It only has to
parse @media and the new @imgset CSS subset language, using a similar
syntax to @media. And I believe if offer an easy way to polyfill this.
This isn't as terrible for polyfilling, since it's easier to spot
things and extract them with a regex. I find it less understandable,
though this might be because you haven't explained most of your syntax
and possibly have some syntax errors.
~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 15, 2013, at 3:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The simplest one isn't much worse, granted. It suffers from the put an id on it that makes working with label/input a minor chore, but otherwise is mostly just shifting things around. Sure you can use ids. But the idea behind the CSS proposal was to allow better sharing of the breakpoint media queries. Not really. PreloaderCSS gives you two choices, both bad: 1. Put the image sources in a style next to each img, thus repeating your layout breakpoints in the MQs multiple times. (This weakness is shared by src-N.) Addressed by attr() as mentioned in other replies already. 2. Or put all your image sources in a single style block somewhere in the page, requiring people to look in two places for image sources and virtually guaranteeing that the fallback url in img src will be ignored and fall out of sync. You still have your breakpoints in at least *two* places though - once in your in-page style block, and once in your external CSS. I think #1 is better, as we can solve it with Custom MQs/MQ Variables/whatever, which the CSSWG is already kosher with (and I'll be writing up soon). Once that's solved, much of the problems of this approach disappear for both src-N and PreloaderCSS. The repetition is in the MQs, and that's solveable quite directly and generically with custom MQs. And those custom MQs would need to be declared in a style inline to be useable by the preloader. So they will need to be declared inline and used in external CSS already. So why not take a more CSS approach instead of src-N if you already need to use a style to reduce repetition of MQs? — Timothy Hatcher
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
[whatever mail program you're using is doing quoting terribly, so I have to correct it afterwards] On Fri, Nov 15, 2013 at 3:42 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 15, 2013, at 3:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Not really. PreloaderCSS gives you two choices, both bad: 1. Put the image sources in a style next to each img, thus repeating your layout breakpoints in the MQs multiple times. (This weakness is shared by src-N.) Addressed by attr() as mentioned in other replies already. Not quite, as I addressed in those replies. It helps, but it's hacking around the issue by inverting it - rather than pushing the definition of an MQ out to everywhere that needs it, it's pulling everything that needs an MQ into the one definition of it. The repetition is in the MQs, and that's solveable quite directly and generically with custom MQs. And those custom MQs would need to be declared in a style inline to be useable by the preloader. So they will need to be declared inline and used in external CSS already. So why not take a more CSS approach instead of src-N if you already need to use a style to reduce repetition of MQs? The two concepts aren't directly connected. The fact that you're using MQs for something doesn't intrinsically imply that the thing should be CSS as well. MQs are useful for plenty of things! That's not an argument *for* src-N, of course. It's just not an argument against, either; it's a non sequitur for the current discussion. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/15/13 3:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I don't understand. You don't repeat any sources, you specify them
once. There's just a batch of sources per image. Can't make this
more compact.
What I mean is that with src-N you will have to repeat the paths AND the
full batch for every image that share the same source+breakpoint pattern
unless you use a template or regex model.
Assuming your RespImg EXAMPLE 5 (from the draft):
img src-1=100% (30em) 50% (50em) calc(33% - 100px);
pic100.png 100, pic200.png 200, pic400.png 400,
pic800.png 800, pic1600.png 1600, pic3200.png 3200
In the real world with clouds, this is your average prospect size of it
with just 4 imgs:
img src=http://farm8.staticflickr.com/7325/10858537575_e6af698601_m.jpg;
src-1=100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698601_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_xxl.jpg 3200
img src=http://farm8.staticflickr.com/7325/10858537575_e6af698602_m.jpg;
src-1=100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698602_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_xxl.jpg 3200
img src=http://farm8.staticflickr.com/7325/10858537575_e6af698603_m.jpg;
src-1=100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698603_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_xxl.jpg 3200
img src=http://farm8.staticflickr.com/7325/10858537575_e6af698604_m.jpg;
src-1=100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698604_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_xxl.jpg 3200
Now imagine 20 images... Or an additional src-N to each of them...
While gzip size will generally compact those fairly well, that affects the
overall size of your page (especially if images sizes are identified by
folder instead of img suffix, where the compression will not be as good)
It is also making the source difficult to read for debugging purpose
because of the length. This what I mean by bloat.
While that doesn't seem to be of everyone's concern, the raw byte size of
pages will quadruple instantly with image galleries. That's not DRY,
and more memory consumption for mobiles.
The repetition is in the MQs, and that's solveable quite directly and
generically with custom MQs.
It's in the src-path(s) too as explained above.
My imgset template model only gives you this per image instead:
img src=http://farm8.staticflickr.com/7325/10858537575_e6af698606_t.jpg;
imgset=flick 100% (30em) 50% (50em) calc(33% - 100px);
Or even less if that 'variable sized' MQ language is also tokenized at the
head level (which you currently seem to working on):
img src=http://farm8.staticflickr.com/7325/10858537575_e6af698606_t.jpg;
imgset=flick@('flexsize');
Here is an update along my initial model with John's example, and
custom media-vars (with the syntax we discussed on the w3cstyle list):
head
style
@media-var 'smallicon' (max-width: 19.99em);
@media-var 'flexwidth' (min-width: 20em);
@imgset 'set-1' (64 64 1x, 128 128 1x, 256 256 1x 128 2x 64 3x),
regexp();
@imgset 'set-2' (160 160, 320 320, 640 640, 1280 1280), regexp();
/style
/head
img src=fallback.jpg
imgset=set-1@media('smallicon') 128px;
set-2@media('flexwidth') 100% (30em) 50% (50em) 33%
Where are the source urls? Are they supposed to be those numbers in
@imgset? What does regexp() mean? I don't understand your use of
commas in @imgset.
There is no need for other src urls other than the base src template.
All you have to do is replace the suffix, folder, or other pattern from
that path (as defined by the framework which resizes your images), using
either the regex pattern or
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
It does not require the preloader to have full css parser. It only has
to
parse @media and the new @imgset CSS subset language, using a similar
syntax to @media. And I believe if offer an easy way to polyfill this.
This isn't as terrible for polyfilling, since it's easier to spot
things and extract them with a regex. I find it less understandable,
though this might be because you haven't explained most of your syntax
and possibly have some syntax errors.
And just to be complete, when it come to Adam's '.artdirected' background
case. Here a more compact way I'd consider do it along the new @imgset,
without the need for the preloader to parse any classes or presentational
css at all.
Let's take the premise that one can currently preload all or many css
backgrounds, without having to declare any css classes at all. The way you
this, is at the head level, using multiple-background support.
Example:
style
head{ background: url(bg.png), url(header.png), url(logo.png),
url(nav.png); }
/style
And as long as your images are cached, it's a simple and efficient compact
way of preloading backgrounds before your external css is parsed. I don't
know if one would call this a hack or not, AFAIK doing it is not
against any specs. And the head element is style-able without any issues
across browsers. I have been using it conveniently as a simple viewport
dimmer for modal windows without any issues nor side effects.
So how about just using the same approach, and as very similar syntax as
The inline imgset= attribute for the css background-image property, such
as a short and simple:
style
head{
background-image: imgset(set-1@media('small') 128px; icon-128.png),
imgset(set-2@media('flexwidth') 30px; bg.png);
}
/style
The preloader has enough imgset() info it can parse without having to look
at the rest of the css syntax. It just cares about imgset() which it can
handle with @imgset grammar with the previous @img definition ahead of it.
No inline styling here is required, which by definition makes it a no
brainer for 'stoopid', since the head element is hidden by default.
Note that technically, if you provide this in the head before external
styles, the css would actually render and start loading the images even
before the preloader kicks-in...
Or does the preloader look at the head first (once received), and then
the body? Adam?I think it works either way regardless...
Again Tab, please revamp the syntax as you deem more appropriate and more
css spec compliant. I do not claim that my syntax is perfect or ideal.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 13 Nov 2013 11:33, Jirka Kosek ji...@kosek.cz wrote:
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.
No different to data-* .
Silvia.
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] imgset responsive imgs proposition (Re: The src-N proposal)
One-dimensional solutions like this look pretty but once you combine width
and device-pixel-ratio (resolution) it quickly explodes and you get
num_widths * num_dprs entries. Please read xanthir.com/b4Su0, at least the
example at the bottom showing how srcset quickly gets impractical.
If you want to move the presentational aspects to CSS, you need an approach
closer to my earlier
emailhttp://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-November/041432.html,
preserving the size-viewport-list from src-N.
Combining content:replaced with the attr() function is a neat trick though;
you could tweak my earlier approach to give something like the following
(incorporating size-viewport-list into CSS image-set, which needs to
happen anyway):
style
@media (max-width: 19.99em) {
.artdirected { content: replaced image-set(128px; attr(srcs-smallicon));
}
}
@media (min-width: 20em) {
.artdirected { content: replaced image-set(100% (30em) 50% (50em) 33%;
attr(srcs-flexwidth)); }
}
/style
...
img class=artdirected src=fallback.jpg
srcs-smallicon=i64.jpg 64, i128.jpg 128, i256.jpg 256
srcs-flexwidth=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg 1280,
2560.jpg 2560
(note that the above is a maximally complex example, incorporating art
direction, viewport-switching and dpr-switching; most normal cases would be
simpler than this)
This is a little bit more verbose than the split I'd suggested; but I must
admit it gives nice flexibility (the author can use attr when the images
differ for each member of a CSS class, but can include the urls directly in
the style rule if the images are the same for all members of the CSS class).
On Wed, Nov 13, 2013 at 1:56 AM, Christian Biesinger
cbiesin...@google.comwrote:
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 Tue, Nov 12, 2013 at 12:50 PM, 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
Based on the above, the Feature image of say an article or recipe would
be added as a background image?
From an Authors point of view.. yikes that's ugly, but more importantly
could be a large maintenance nightmare.
Real world use case #1:
- I have a large scale corporate website that serves Articles and Recipes
through the same template(s), including the head.
- In order to have an Article and Recipe feature image responsive with
this solution I would need to now put this in the head:
style type=text/css
@media (min-width: 480px) {
.artdirected-article {
width: 30px;
height: 30px;
background-image: image-set(url(article-small.png) 1x,
url(article-small-hires.png) 2x);
}
.artdirected-recipe {
width: 30px;
height: 30px;
background-image: image-set(url(recipe-small.png) 1x,
url(recipe-small-hires.png) 2x);
}
}
@media (min-width: 600px) {
.artdirected-article {
width: 60px;
height: 60px;
background-image: image-set(url(article-large.png) 1x,
url(article-large-hires.png) 2x);
}
.artdirected-recipe {
width: 60px;
height: 60px;
background-image: image-set(url(recipe-large.png) 1x,
url(recipe-large-hires.png) 2x);
}
}
/style
Then, modify templates in order to render these separately:
div class=artdirected-article/div
div class=artdirected-recipe/div
Now what if my templates are also used for TV Show details, Host details...
- Add 2 more entries into the head
- abstract the templates for more logic and/or just create separate
templates (which seems as though it may be easier to now do that, yikes)
It also seems as though we'd be adding a boatload of code to the head that
may or may not even be used, so now I would need new MasterPages to render
different head's for different templates you get where I'm going with
this?
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.
Real world use case #2 (based on Compatibility is solid):
Based on the Content from Use Case #1 (Articles and Recipes):
- There is an overall corporate requirement to have Article and Recipe
Feature images print along with the Content (Directions, Ingredients
etc.)
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Am 13.11.2013 14:52 schrieb John Mellor:
style
@media (max-width: 19.99em) {
.artdirected { content: replaced image-set(128px; attr(srcs-smallicon));
}
}
@media (min-width: 20em) {
.artdirected { content: replaced image-set(100% (30em) 50% (50em) 33%;
attr(srcs-flexwidth)); }
}
/style
...
img class=artdirected src=fallback.jpg
srcs-smallicon=i64.jpg 64, i128.jpg 128, i256.jpg 256
srcs-flexwidth=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg 1280,
2560.jpg 2560
(note that the above is a maximally complex example, incorporating art
direction, viewport-switching and dpr-switching; most normal cases would be
simpler than this)
Looks great to me. Just verbose enough to be understood by average
authors (as I am one), perfectly maintainable, and as powerful as src-N.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 13.11.2013 13:48, Silvia Pfeiffer wrote: 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. No different to data-* . Not completely. In practice you don't use completely arbitrary data-* attributes just few of them needed by JS library you use on the page. So you know which JS libraries are imported you can know which data-* attributes could be there. 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] 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)
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] 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
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] 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
--
[whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Here is a complementary approach to the src-N syntax, I'd like to present for discussion. The goal is: 1. Address all use cases in a similar way as src-N does without the 'N' part. 2. Cut the verbose to a 'strict' minimum with reusable OO definitions. 3. Provide a vocabulary that is easy to parse and easily interpretable by javascript. It's not src-N or srcset, because the new inline semantic refers to 'sizes' instead, and require only the one original 'src' for all images. First we provide the image set definitions in the head for the preloader as: imgset 1: 1080, 1024, 960, 900, 854, 840, 800, 720, 640, 600, 540, 500, 420, 300, 240; 2: 200, 150, 100, 75, 50; logo: small 150 1x 300 2x, medium 200 1x, large 250 1x; custom: /(?=\-)(.*)(?=\.)/s; //-- regex pattern value /imgset Set 1 and 2 define all widths available for those particular sets. It assumes the 'image-WxH.ext' format by default. (I omitted a regex for those, we'll consider this a default pattern for now) The third set (logo), is one that defines a keyword relationship with img sizes. (note: 'logo:small' is both 150px at 1x resolution and 300px at 2x resolution) Then 'custom', is the regex pattern used at the platform level for naming the different sizes. Here is the first img example using the 'image-WxH.ext' image name syntax. img width=600 height=300 src=image-600x300.jpg res=1x imgset=1 sizing=ratio sizes=100% (360px) 66% (800px) 33% The new 'res' attribute would define the pixel density the author chooses to provide. The 'imgset' attribute refers to the imgset target definition list by ID or keyword. The 'sizing' attributes provides the custom matching pattern for how images are stored, and for the browser to replace the original src with its current width+resolution match. Finally the 'sizes' attribute is similar to src-N as far as handling variable size imgs. The browser can figure out the width/height ratio given by the 'width' and 'height' attributes. Here is another example which use the imgset '2' with a pixel size, and indicated resolution at 1x and 2x: img width=100 height=100 src=gravatar-100x100.jpg res=1x,2x imgset=2 sizing=ratio sizes=50px (360px) 75px (800px) 100px Even though the breakpoint sizes are in pixel, the browser can do the math using the 'ratio' sizing and the given 'res' values. No need to specify multiple pixel densities in the imgset(s) when a pixel ratio is involved. Finally the 'custom' case which uses the 'logo' imgset as reference. img width=250 height=100 src=logo-large.jpg res=1x,2x sizing=custom imgset=logo sizes=small (360px) medium (800px) large The 'custom' regex pattern is used to determine what image name correspond to the appropriate breakpoint sizes. With the above applied to an iPhone 3, logo-large.jpg becomes logo-small.jpg, and stays logo-large.jpg for the iPhone 4. Overall this solution cuts off the fat by a very large margin. And the introduction of a regex way seem like a good approach (and probably the only one) to also remove the 'src' verbose, with the advantage of reusable definitions by multiple images. Also the head's imgset can be converted to (or even given as) json for javascript interpretation readiness. Anyhow, this is the complementary and optimized approach I am suggesting. -BR On 11/10/13 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
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. Adam On Mon, Nov 11, 2013 at 7:43 PM, Bruno Racineux br...@hexanet.net wrote: Here is a complementary approach to the src-N syntax, I'd like to present for discussion. The goal is: 1. Address all use cases in a similar way as src-N does without the 'N' part. 2. Cut the verbose to a 'strict' minimum with reusable OO definitions. 3. Provide a vocabulary that is easy to parse and easily interpretable by javascript. It's not src-N or srcset, because the new inline semantic refers to 'sizes' instead, and require only the one original 'src' for all images. First we provide the image set definitions in the head for the preloader as: imgset 1: 1080, 1024, 960, 900, 854, 840, 800, 720, 640, 600, 540, 500, 420, 300, 240; 2: 200, 150, 100, 75, 50; logo: small 150 1x 300 2x, medium 200 1x, large 250 1x; custom: /(?=\-)(.*)(?=\.)/s; //-- regex pattern value /imgset Set 1 and 2 define all widths available for those particular sets. It assumes the 'image-WxH.ext' format by default. (I omitted a regex for those, we'll consider this a default pattern for now) The third set (logo), is one that defines a keyword relationship with img sizes. (note: 'logo:small' is both 150px at 1x resolution and 300px at 2x resolution) Then 'custom', is the regex pattern used at the platform level for naming the different sizes. Here is the first img example using the 'image-WxH.ext' image name syntax. img width=600 height=300 src=image-600x300.jpg res=1x imgset=1 sizing=ratio sizes=100% (360px) 66% (800px) 33% The new 'res' attribute would define the pixel density the author chooses to provide. The 'imgset' attribute refers to the imgset target definition list by ID or keyword. The 'sizing' attributes provides the custom matching pattern for how images are stored, and for the browser to replace the original src with its current width+resolution match. Finally the 'sizes' attribute is similar to src-N as far as handling variable size imgs. The browser can figure out the width/height ratio given by the 'width' and 'height' attributes. Here is another example which use the imgset '2' with a pixel size, and indicated resolution at 1x and 2x: img width=100 height=100 src=gravatar-100x100.jpg res=1x,2x imgset=2 sizing=ratio sizes=50px (360px) 75px (800px) 100px Even though the breakpoint sizes are in pixel, the browser can do the math using the 'ratio' sizing and the given 'res' values. No need to specify multiple pixel densities in the imgset(s) when a pixel ratio is involved. Finally the 'custom' case which uses the 'logo' imgset as reference. img width=250 height=100 src=logo-large.jpg res=1x,2x sizing=custom imgset=logo sizes=small (360px) medium (800px) large The 'custom' regex pattern is used to determine what image name correspond to the appropriate breakpoint sizes. With the above applied to an iPhone 3, logo-large.jpg becomes logo-small.jpg, and stays logo-large.jpg for the iPhone 4. Overall this solution cuts off the fat by a very large margin. And the introduction of a regex way seem like a good approach (and probably the only one) to also remove the 'src' verbose, with the advantage of reusable definitions by multiple images. Also the head's imgset can be converted to (or even given as) json for javascript interpretation readiness. Anyhow, this is the complementary and optimized approach I am suggesting. -BR On 11/10/13 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy.
