On May 16, 2012, at 6:45 AM, Jeremy Keith wrote:
> Simon wrote:
>> The width/height descriptors in srcset seem to be difficult for people to
>> get right, even people who read the spec.
>>
>> * It's not clear from the syntax that it refers to the viewport size rather
>> than the image size.
>
On May 15, 2012, at 4:51 PM, Tab Atkins Jr. wrote:
> I suspect this is simply confusion about the proposal - @srcset
> handles the "art-directed" case same as , just with a
> somewhat more compact microsyntax rather than using MQs directly. (On
> the plus side, the slightly-special processing of
On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote:
> On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby wrote:
>> Are you saying that all of the image source listed in srcset would have the
>> same aspect ratio? In the example Hixie provided, face-icon.png is a
>> different
On May 15, 2012, at 7:58 AM, Tab Atkins Jr. wrote:
> On Tue, May 15, 2012 at 4:51 PM, Jason Grigsby wrote:
>> On May 15, 2012, at 12:28 AM, Ian Hickson wrote:
>>>> * Example 2: On the Nokia Browser site where it describes the Meego
>>>> browser, the Nokia L
On May 15, 2012, at 12:28 AM, Ian Hickson wrote:
>> * Example 2: On the Nokia Browser site where it describes the Meego
>> browser, the Nokia Lumia is show horizontally on wide screens. As the
>> screen narrows, the Nokia Lumia is then shown vertically and cropped.
>> Bryan and Stephanie Rieger
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 could b
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
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 importa
On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote:
> I'm late to this discussion so pardon me if this has already been discussed,
> by using the same logic as the why not just create to go
> along with the element?
When a bunch of us discussed this on an etherpad a while back, we ruled
out
On Feb 8, 2012, at 8:04 AM, Ronjec Viktor wrote:
> People, this is really getting out of hand...
>
> 1. WHATWG is a standards body, meaning it _standardizes_ solutions.
> Everyone who followed the discussion up until now can easily tell that
> currently there is no unified, or even close to comm
I’ve read that comment three times and still don’t grok it. :-)
It seems the comment mixes lookahead pre-parsing behavior with pre-fetching and
pre-rendering behavior. Compare the definitions of pre-fetching and
pre-rendering in the Google Chrome documentation that the comment points to:
http://
Then yes, I can get behind the idea of that such a communication method would
be very useful.
On Feb 7, 2012, at 4:55 AM, Matthew Wilcox wrote:
> Absolutely agree that we should not be concentrating on one specific thing.
> What I want is the ability to have the server ask for whatever info it
I agree that this is a problem. I’ve spent far too much time trying to find
solutions for images in responsive designs and none that I reviewed work.
(research at http://cloudfour.com/responsive-imgs-part-2).
But I find the arguments that Henri Sivonen made against putting the
information in th
13 matches
Mail list logo
