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.
Yes, I
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, the
On May 15, 2012, at 7:58 AM, Tab Atkins Jr. wrote:
On Tue, May 15, 2012 at 4:51 PM, Jason Grigsby ja...@cloudfour.com 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 Lumia is show horizontally
On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote:
On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby ja...@cloudfour.com 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 ratio
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 picture, just with a
somewhat more compact microsyntax rather than using MQs directly. (On
the plus side, the slightly-special processing
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 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
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 common
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 srclist why not just create figlist to go
along with the figure element?
When a bunch of us discussed this on an etherpad a while
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’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:
12 matches
Mail list logo
