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 Sun, May 13, 2012 at 1:47 AM, Brett Zamir bret...@yahoo.com wrote:
With Server-Side JavaScript taking off, could we reserve runat (or maybe
an even simpler and more concise server boolean attribute) for a standard
and (via CommonJS) potentially portable way for server-side files to be
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 5/13/2012 5:23 PM, Benjamin Hawkes-Lewis wrote:
On Sun, May 13, 2012 at 1:47 AM, Brett Zamirbret...@yahoo.com wrote:
With Server-Side JavaScript taking off, could we reserve runat (or maybe
an even simpler and more concise server boolean attribute) for a standard
and (via CommonJS)
Just use type=text/server-js...
--
Anne van Kesteren
http://annevankesteren.nl/
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, 2012-05-13 at 17:16 +0200, Anne van Kesteren wrote:
Just use type=text/server-js...
Is that really a good idea? It seems odd to use a mime type for such a
reason.
--
Anne van Kesteren
http://annevankesteren.nl/
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
Just use type=text/server-js...
Is that really a good idea? It seems odd to use a mime type for such a
reason.
I thought it was quite a nice idea.
Why would it not be? It's describing what's in the script tag, just like it's
supposed to do. It's even a quite much used pattern for doing
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=
Syntax used on the wiki:
http://wiki.whatwg.org/wiki/Adaptive_images
places alt on the new element:
picture alt=alt
source …
img
/picture
I think it can be improved in two ways:
- Instead of having alt on picture, it could be on the fallback img.
This will give better
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 May 13, 2012, at 4:20 PM, Kornel Lesiński kor...@geekhood.net wrote:
Syntax used on the wiki:
http://wiki.whatwg.org/wiki/Adaptive_images
places alt on the new element:
picture alt=alt
source …
img
/picture
I think it can be improved in two ways:
- Instead of having
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
37 matches
Mail list logo
