On Thu, 17 May 2012 15:13:58 +0100, Matthew Wilcox
wrote:
I'd also point out I'm not claiming this is a replacement for srcset
or . I think it's a useful additional tool for web
developers, but it is aimed at *site wide* generalised uses to make
life a lot easier - I can't see a way to make i
>> That particular solution is, to my mind, the most flexible and useful
>> implementation I've seen, because it's really about breakpoint
>> management and abstraction - which is what all responsive elements
>> need in order to work together well and be future-friendly.
>>
>> It does, no doubt, ha
On Thu, 17 May 2012 14:16:24 +0100, Matthew Wilcox
wrote:
That particular solution is, to my mind, the most flexible and useful
implementation I've seen, because it's really about breakpoint
management and abstraction - which is what all responsive elements
need in order to work together well
On 17 May 2012 11:05, Kornel Lesiński wrote:
> On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox
> wrote:
>
>>> What solution do you have in mind that would let you add a 'tv'
>>> breakpoint site-wide for all images that have been prepared for it, without
>>> need to
>>> update code that embeds
On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox
wrote:
What solution do you have in mind that would let you add a 'tv'
breakpoint site-wide for all images that have been prepared for it,
without need to
update code that embeds those images? And is that really saving much
effort?
Woul
> The solution I've seen proposed[1] only aliases media query content, and
> works only on a per-page basis, so it doesn't allow automatic addition of a
> new image size site-wide, since you have to insert new into every
> anyway.
That is not true. With that particular solution you would never a
On Wed, 16 May 2012 20:09:13 +0100, D. Pitchford
wrote:
What standards does not do in this situation is remove the actual work
effort in having to physically update each and every img's 'srcset'
string with new breakpoints during a redesign, no matter how terse the
'srcset' string is.
Yo
On Wed, May 16, 2012 at 5:42 AM, Odin Hørthe Omdal wrote:
> Tim Kadlec wrote:
>>
>> The lack of em support is a concern though I understand the complications
>> you have brought up.
>>
>> Using ems for media queries (which in turn dictate layout which in turn
>> dictates the image I want to load)
On Wed, 16 May 2012 03:50:21 +0200, Silvia Pfeiffer
wrote:
On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal
wrote:
I'm not sure. What do you think? As far as I've seen, you're highly
knowledgeable about . Why do we have mediaqueries on video
element?
Do we have a use case page?
He
Cheers :)
On 16 May 2012 15:05, Mike Taylor wrote:
> On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox
> wrote:
>
>> What's the actual WHATWG proscribed format for conducting conversations in
>> email
>> format?
>
>
> See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F
>
>
On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox
wrote:
What's the actual WHATWG proscribed format for conducting conversations
in email
format?
See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F
--
Mike Taylor
Opera Software
On 16 May 2012 14:30, Odin Hørthe Omdal wrote:
> Oh, please do quote what you are answering. It's very hard to follow
> such a conversation like this.
>
OK, I am not sure what format to reply to emails with - some people
complain when quotes are left out entirely, other people complain when
repli
Oh, please do quote what you are answering. It's very hard to follow
such a conversation like this.
Matthew Wilcox wrote:
If there was a way to do this in JS, we'd have found it. Every time we
run up against the pre-fetch problem. In fact, it is only the
pre-fetch problem that causes responsive
If there was a way to do this in JS, we'd have found it. Every time we
run up against the pre-fetch problem. In fact, it is only the
pre-fetch problem that causes responsive images to be an issue at all.
It'd be trivial to fix with JS otherwise.
Also, i don't think non-pixel based layouts can be e
Tim Kadlec wrote:
The lack of em support is a concern though I understand the
complications you have brought up.
Using ems for media queries (which in turn dictate layout which in turn
dictates the image I want to load) is increasingly looking like a much
wiser decision than using pixels.
The lack of em support is a concern though I understand the complications you
have brought up.
Using ems for media queries (which in turn dictate layout which in turn
dictates the image I want to load) is increasingly looking like a much wiser
decision than using pixels. A perfect example are d
On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox
wrote:
Am i right in believing that the srcset attribute are limited to
pixels? A unit that's dying out in all responsive designs? Is it
extensible to em, % etc? Because that's what's used.
I'm afraid you are confusing a lot of stuff together
Am i right in believing that the srcset attribute are limited to
pixels? A unit that's dying out in all responsive designs? Is it
extensible to em, % etc? Because that's what's used.
On 16 May 2012 08:39, Chris Heilmann wrote:
> On 16/05/2012 00:23, Kornel Lesiński wrote:
>>
>> On Tue, 15 May 201
On 16/05/2012 00:23, Kornel Lesiński wrote:
On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann
wrote:
The fetish for brevity is something I never understood. More
understandable code is faster to write than cryptic short code.
There is significant difference in verbosity for a *very common
On May 15, 2012, at 3:06 PM, Chris Heilmann wrote:
> I also wonder what we do with videos? Surely they have the same issues and
> there is no proposal for changing the syntax there.
With current codecs, and given human perception of visual images, videos can be
decoded at multiple resolutions
You might remember about my proposal 9 months ago. If not you can see it here:
https://gist.github.com/1158855
http://cdn.url.com/img/myimage_xs.jpg";
media-xs="(min-device-width:320px and max-device-width:640px)"
media-xs-src="http://cdn.url.com/img/myimage_xs.jpg";
m
On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal wrote:
> Silvia Pfeiffer skreiv Wed, 16 May 2012 00:57:48
> +0200
>
>>> Media queries come from the client side. They allow the author of a web
>>> page to tell exactly how she want to lay out her design based on the
>>> different queries. The br
On 2012-05-15, at 7:23 PM, Kornel Lesiński wrote:
> On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann wrote:
>
>> The fetish for brevity is something I never understood. More understandable
>> code is faster to write than cryptic short code.
>
> There is significant difference in verbosity f
On 5/15/12 7:33 PM, Kornel Lesiński wrote:
In fact, I'd keep @media, because it serves some cases very well (I see
dpi/bandwidth optimisation as a problem orthogonal to layout adaptation:
http://geekhood.net/MediaQuery-vs-PerfQuery.png)
@media on video source is terrible for layout adaptation:
On Tue, May 15, 2012 at 4:23 PM, Jeremy Keith wrote:
> Odin wrote:
>> 1. How do we enable authors so that they can display different images under
>> different conditions based on art direction?
>
>> 2. Enabling authors to provide different resolutions of images based on a
>> variety of condition
On Tue, 15 May 2012 23:57:48 +0100, Silvia Pfeiffer
wrote:
Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please
Odin wrote:
> It's heavily optimized for the usecase that will happen most often: for
> "retina" type displays:
>
>
Okay. This is also what Ted said about the srcset proposal and it makes a lot
of sense for that use case.
But it seems far less suited to the use-case of "art-directed" image
On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann
wrote:
The fetish for brevity is something I never understood. More
understandable code is faster to write than cryptic short code.
There is significant difference in verbosity for a *very common case* of
serving images for high-dpi ("Re
Silvia Pfeiffer skreiv Wed, 16 May 2012
00:57:48 +0200
Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please cor
On Wed, May 16, 2012 at 8:37 AM, Odin Hørthe Omdal wrote:
> Andy Davies wrote:
>>
>> Looking at the srcset proposal it appears to be recreating aspects of
>> media-queries in a terse less obvious form...
>>
>> We've already got media queries so surelt we should be using them to
>> determine which
Andy Davies wrote:
Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...
We've already got media queries so surelt we should be using them to
determine which image should be used and if media-queries don't have
features we need then
On Tue, May 15, 2012 at 3:06 PM, Chris Heilmann wrote:
> I also wonder what we do with videos? Surely they have the same issues and
> there is no proposal for changing the syntax there. I do not like the syntax
> of this. Yes it is more terse but it smacks of the horrible syntax of
> window.open p
On 15/05/2012 23:11, Anselm Hannemann Web Development wrote:
Tab, maybe you think this is a good type to write the syntax but the majority
of normal web developers are used to use common HTML syntax. This is why we
proposed the picture element and normal attributes using media queries.
Of cours
Am 16.05.2012 um 00:06 schrieb Chris Heilmann:
> On 15/05/2012 22:46, Bruce Lawson wrote:
>> On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr.
>> wrote:
>>
>>> On Tue, May 15, 2012 at 1:42 PM, Andy Davies wrote:
Looking at the srcset proposal it appears to be recreating aspects of
m
Tab, maybe you think this is a good type to write the syntax but the majority
of normal web developers are used to use common HTML syntax. This is why we
proposed the picture element and normal attributes using media queries.
Of course this means we have lot more to write but at least this is int
On 15/05/2012 22:46, Bruce Lawson wrote:
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr.
wrote:
On Tue, May 15, 2012 at 1:42 PM, Andy Davies
wrote:
Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...
We've already got med
On Tue, May 15, 2012 at 3:01 PM, Anne van Kesteren wrote:
> On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr. wrote:
>> Importantly, I think I'd like to be able to use either min or max, but
>> @srcset's microsyntax only talks about min sizes. (I got it wrong in
>> my previous email.)
>
> Well, it
On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr. wrote:
> Importantly, I think I'd like to be able to use either min or max, but
> @srcset's microsyntax only talks about min sizes. (I got it wrong in
> my previous email.)
Well, it's not a media query. It *describes* the size of the image. A
media
On Tue, May 15, 2012 at 2:46 PM, Bruce Lawson wrote:
> 1) the 600w 200h bit replicates the functionality of the familiar Media
> Queries syntax but in a new unfamiliar microsyntax which many have argued is
> ugly, unintuitive and prone to error
> (http://www.w3.org/community/respimg/2012/05/11/res
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr.
wrote:
On Tue, May 15, 2012 at 1:42 PM, Andy Davies wrote:
Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...
We've already got media queries so surelt we should be using
On Tue, May 15, 2012 at 1:42 PM, Andy Davies wrote:
> Looking at the srcset proposal it appears to be recreating aspects of
> media-queries in a terse less obvious form...
>
> srcset="face-600-200 at 1.jpeg 600w 200h 1x,
> face-600-200 at 2.jpeg 600w 200h 2x,
>
Looking at the srcset proposal it appears to be recreating aspects of
media-queries in a terse less obvious form...
We've already got media queries so surelt we should be using them to
determine which image should be used and if media-queries don't have
features we need then we should be exte
42 matches
Mail list logo