On Sun, 13 May 2012 00:43:48 +0200, Jason Grigsby ja...@cloudfour.com
wrote:
On May 11, 2012, at 8:52 PM, Simon Pieters wrote:
There seem to be two proposals for what syntax to use for the
responsive images use case: several elements vs. an attribute.
There are two proposals because they
On Fri, 11 May 2012 20:52:43 +0200, Simon Pieters sim...@opera.com wrote:
There seem to be two proposals for what syntax to use for the responsive
images use case: several elements vs. an attribute.
I think an attribute is simpler to implement and thus likely to result
in fewer bugs in
On Mon, 14 May 2012 01:30:20 +0100, Odin Hørthe Omdal odi...@opera.com
wrote:
All optional replacements of the src will have to be fitted in the same
box as the original src. That might actually require you to specify both
width and height upfront. Of course, people won't really do that, so I
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
- img srcset for serving different resolutions of a content image
(for bandwidth and dpi)
- picture for serving different versions of a content image (for art
direction)
...and
On Sun, 13 May 2012, David Goss wrote:
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
- img srcset for serving different resolutions of a content image
(for bandwidth and dpi)
- picture for serving different versions of a
On May 13, 2012, at 9:51 AM, David Goss wrote:
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
After skyping with Mat (@wilto) last night, I think I may be the only one who
didn’t fully grok that the mediaqueries in picture
On Sun, May 13, 2012 at 10:36 AM, Jason Grigsby ja...@cloudfour.com wrote:
It may be that the proposal is written in language that implementors
understand and that it needs to be rewritten to make it clearer for authors
how it would work. Or it could be an indication that the syntax is too
On 13 May 2012 10:14, James Graham jgra...@opera.com wrote:
On Sun, 13 May 2012, David Goss wrote:
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
- img srcset for serving different resolutions of a content image
(for
Also note that there is a great difference in implementation complexity
between various properties above. For example, viewport width/height is
rather easy to work with because one can assume it won't change between
prefetching and layout, so one can prefetch the right asset. On the
On Sun, May 13, 2012 at 12:26 PM, David Goss dvdg...@gmail.com wrote:
As I understand it, the img srcset syntax would
have to keep getting extended every time we wanted to test a different
property.
It doesn't test anything. It tells the UA metadata about the image
set it would otherwise have
On 13 May 2012, at 13:19, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com
wrote:
On Sun, May 13, 2012 at 12:26 PM, David Goss dvdg...@gmail.com wrote:
As I understand it, the img srcset syntax would
have to keep getting extended every time we wanted to test a different
property.
It
On 5/13/12 7:26 AM, David Goss wrote:
but it'd be irresponsible to just serve an
img with the high res source to all users, making them wait longer
for the download even though they can't see the extra quality on their
screen.
Except when they can, e.g. by printing or moving the display to
Jason Grigsby wrote:
David Goss wrote:
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
After skyping with Mat (@wilto) last night, I think I may be the only
one who didn’t fully grok that the mediaqueries in picture could
On May 13, 2012, at 9:42 AM, Odin Hørthe Omdal wrote:
Connection speed
As an extension of the iPad example above, it would also be
irresponsible to serve the high res image to users that do have a high
pixel density display but are not on a fast internet connection for
whatever reason. So
On Sun, May 13, 2012 at 5:21 PM, Mathew Marquis m...@matmarquis.com wrote:
AND they have to update their sites and mediaqueries when we get
something new to optimize for. I don't think they will do that, based on
how extremely big the problem with -webkit-prefixes are.
I've seen enough of the
On Sun, 13 May 2012 18:01:12 +0100, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com wrote:
What authors _can_ do and user agents _cannot_ do is describe their
images. Such metadata never needs to be misinterpreted and allows user
agents to iterate and improve the end-user experience even
On Sun, 13 May 2012 10:36:37 +0100, Jason Grigsby ja...@cloudfour.com
wrote:
On May 13, 2012, at 9:51 AM, David Goss wrote:
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
After skyping with Mat (@wilto) last night, I
On May 13, 2012, at 1:01 PM, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com wrote:
On Sun, May 13, 2012 at 5:21 PM, Mathew Marquis m...@matmarquis.com wrote:
AND they have to update their sites and mediaqueries when we get
something new to optimize for. I don't think they will do that,
On Sun, 13 May 2012 01:33:25 +0100, Mathew Marquis m...@matmarquis.com
wrote:
I worry that, when faced with this markup, developers will simply opt to
serve the largest possible image in a src. In fairness, that approach
works with far less headache.
In the long term that may be a very
On Sun, 13 May 2012 20:20:54 +0100, Mathew Marquis m...@matmarquis.com
wrote:
The key problem about designing a responsive images solution around
user agent characteristics not image characteristics is that authors
will inevitably make more false assumptions about what images match
what user
On Sun, May 13, 2012 at 6:01 PM, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com wrote:
On Sun, May 13, 2012 at 5:21 PM, Mathew Marquis m...@matmarquis.com wrote:
When we get ?something new to optimize for,? we start adding that thing
going forward. The evolution of media queries?or, say,
On 5/13/12, Kornel Lesiński kor...@geekhood.net wrote:
I think layout (media queries) and optimisation cases are orthogonal and
it would be a mistake to do both with the same mechanism.
My knee-jerk reaction to the above thought is that layout should be
done using CSS and any optimizations left
On Sun, May 13, 2012 at 8:55 PM, Bjartur Thorlacius
svartma...@gmail.com wrote:
But the chosen image resolution might be a factor for choosing layout.
Maybe we should think of a way to expose _that_ information to CSS,
rather than going in the other direction.
section
img src=a.jpg alt=
Kornel Lesiński wrote:
Selection of 1x/2x images is relevant only as long as we have 100dpi
screens and slow connections, and both will disappear over time.
Well, the web is a huge place. I'm quite sure that'll take ages and
ages if it ever happens at all (I don't think it'll ever disappear).
On Sun, 13 May 2012 20:55:08 +0100, Bjartur Thorlacius
svartma...@gmail.com wrote:
The problem with that, though, is that then bandwidth constraints
can't affect layout. Users should be able to configure UAs to use
downsized images even given a large viewport, if only to save
bandwidth and
On Sun, 13 May 2012 21:23:58 +0100, Odin Hørthe Omdal odi...@opera.com
wrote:
picture
source src=narrow_low-quality srcset=narrow_hi-quality 2x
media=max-width:4in
source src=wide_low-quality srcset=wide_hi-quality 2x
img src=fallback alt=alt
/picture
Instead of srcset
On 5/13/12, Kornel Lesiński kor...@geekhood.net wrote:
By resolution I mean pixel density (regular vs Retina display), so this
doesn't affect layout.
Ah, I must have misunderstood you.
I can imagine layout complexity being tied to bandwidth (an image-rich
design vs minimalistic text-only
On Sun, 13 May 2012 23:00:10 +0100, Bjartur Thorlacius
svartma...@gmail.com wrote:
I've got a hunch I'm over-thinking this, but might
bandwidth-constrained users not prefer miniatures instead of huge
pixelated images?
Perhaps sometimes, but support for this would tie layout and bandwidth
Kornel Lesiński said:
Odin said:
Actually, for this to work, the user agent needs to know the size of the
standard image. So:
img src=dog.jpg width=960
srcset=d...@2.jpg 2x, dog-lo.jpg 500w
So if you've got the smartphone held in portrait, it's 250 css pixels
wide, and so 500 real
On May 12, 2012, at 5:33 PM, Mathew Marquis m...@matmarquis.com wrote:
I worry that, when faced with this markup, developers will simply opt to
serve the largest possible image in a src. In fairness, that approach works
with far less headache.
For the resolution-adaptation use case, that
On 5/13/12 12:21 PM, Mathew Marquis wrote:
The amount of “developers can never be trusted with this” sentiment I’ve heard
from the members of this group is incredibly depressing.
For the record, developing a web browser and in the process realizing
how much web content is fundamentally
On 5/13/12 3:20 PM, Mathew Marquis wrote:
I doubt any UAs will be forced to misinterpret common media queries because
they haven’t been accounted for.
Opera has already been forced to do this. For example, in its
projection mode it matches both the projection and screen media
queries
On May 13, 2012, at 7:03 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/13/12 3:20 PM, Mathew Marquis wrote:
I doubt any UAs will be forced to misinterpret common media queries because
they haven’t been accounted for.
Opera has already been forced to do this. For example, in its
While that information may be available at the time the img tag is parsed, I
don’t believe it will be available at the time of prefetching — I’m happy to
research this further and report back with citations. I’m sure I don’t have to
tell you that “disable prefetching on img tags just in case
On Sat, 12 May 2012, Boris Zbarsky wrote:
On 5/12/12 9:28 AM, Mathew Marquis wrote:
While that information may be available at the time the img tag is parsed,
I don’t believe it will be available at the time of prefetching
Which information?
At least in Gecko, prefetching happens when the
On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote:
While that information may be available at the time the img tag is parsed, I
don’t believe it will be available at the time of prefetching — I’m happy to
research this further and report back with citations. I’m sure I
On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote:
On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote:
While that information may be available at the time the img tag is parsed, I
don’t believe it will be available at the time of prefetching — I’m
On May 12, 2012, at 12:35 PM, Adam Barth w...@adambarth.com wrote:
On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote:
On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote:
While that information may be available at the time the img tag is parsed,
On May 11, 2012, at 8:52 PM, Simon Pieters wrote:
There seem to be two proposals for what syntax to use for the responsive
images use case: several elements vs. an attribute.
There are two proposals because they solve two different use cases. Both use
cases are becoming increasingly
I didn’t want to cloud my previous email with my opinions on various solutions,
but as you may expect, I have some thoughts on the solutions to these two use
cases.
On May 13, 2012, at 12:43 AM, Jason Grigsby wrote:
Use case #1
---
Document author needs to display different versions
I’ve put together a summary of potential use cases addressed by the picture
markup and posted them to the WHATWG wiki, along with a few key implementation
details: http://wiki.whatwg.org/wiki/Adaptive_images
I don’t mind saying that the `img set` markup is inscrutable to the point where
I may
On 5/12/12 9:28 AM, Mathew Marquis wrote:
While that information may be available at the time the img tag is parsed, I
don’t believe it will be available at the time of prefetching
Which information?
At least in Gecko, prefetching happens when the tag is parsed.
So in fact in Gecko the
There seem to be two proposals for what syntax to use for the responsive
images use case: several elements vs. an attribute.
I think an attribute is simpler to implement and thus likely to result in
fewer bugs in browsers, which in turn benefits Web developers.
With img src=... srcset=...,
43 matches
Mail list logo
