Re: [whatwg] Features for responsive Web design
On 19 May 2012 00:37, Kornel Lesiński kor...@geekhood.net wrote:
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com
wrote:
picture in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
picture only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
Yes indeed, but the problem is not about srcset, picture or anything
else: it's that, as has been pointed out repeatedly to those of us
asking about bandwidth media queries, the browser simply can't do
reliable bandwidth detection. That effects srcset as much as anything
else. So while technically srcset allows for this, the browser itself
does't, so it can never be used in the manner you're describing.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
This would be no better than current JS approaches, in fact making it
worse by adding to the page load size rather than optimising it.
The syntax allows addition of KB descriptor later, which — assuming UAs
will figure out how to measure actual bandwidth well enough — will allow
even more sophisticated selection based on file size (rather than only 1x/2x
scale factors which are only a proxy for the file size).
As above; this seems set not to happen. Besides, how is it going to
know the file size unless you explicitly state it in the srcset
somewhere?
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
Not actually sure what intrinsic sizes of images means.
A default size of the image when you don't specify any size in HTML/CSS.
Ah, OK thanks :) I do not ever set intrinsic sizes, and nor does any
site I have seen that is responsive in nature. Precisely because it
has no meaning or use in a responsive site.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
Or you do what we do now and supply a double resolution image and set
it to a given CSS size. Or just any old size, from my experience of
the iPad3 you don't actually need to be that specific, just get an
oversized image and let it shrink a bit and it holds up well.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
I'd like to see idea's on how this might work.
The current URI template proposal is limited. I've pointed out few cases for
which a single global set of breakpoints is not sufficient. I'd be nice if
you tried to extend the proposal to support those cases as well (e.g. {case}
→ {case:category} and define breakpoints per category such as 'sidebar',
'gravatar', etc.)
All solutions are limited. The more I work on this the more convinced
I am that the nature or HTML and the layout system makes any truly
efficient solution impossible.
I actually prefer the limits of meta than any others simply because
meta does not postpone the issues until a re-design. meta is the
one and only solution I have seen that does not in some way
contaminate the mark-up with values dependent on the current design.
The price for that is less efficient image compression.
I can't see how to extend it as you're suggesting without also falling
to the same presentational properties embeded problem that picture
and srcset fall into. And that to me is a no-go. We already have
srcset if that's the compromise we want to make.
And meta breakpoint has same limitations for DPI adaptation as source
media.
There are two categories of use-cases (art-directed and
dpi/optimization) and picture is suited for only one of them, so
please don't frame the decision as discarding of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
picture
source src=200px media=(min-device-pixel-ratio:2)
source src=100px
/picture
This will only choose between large pixelated image and small pixelated
image, and will not make use of high display density.
On it's own you're right. But no-one actually builds a site like that.
If you're doing a fluid responsive site you've got img {
max-width:100% } in there, and in that case you do actually take
advantage of the high DPI.
I've explained it in more detail previously (using srcset as an example, but
it all applies to
Re: [whatwg] fullscreenchange event should be delayed to after transition is complete
On 18/05/2012 1:02 a.m., Anne van Kesteren wrote: On Thu, May 17, 2012 at 8:06 AM, Chris Pearcecpea...@mozilla.com wrote: I think it would be best to simply make everything from Step 2 onwards of the requestFullscreen() algorithm spec asynchronous. So in the requestFullscreen specification, move Step 5 and Step 6 up to be inserted before Step 2. We should do the same with exitFullscreen(), i.e. move Step 6 and Step 7 of the exitFullscreen algorithm spec up to be inserted before Step 3. We should also specify that those state changes happen in synchronous sections, to keep the world sane. I have done that by putting the state changes on the same task that dispatches the event. http://dvcs.w3.org/hg/fullscreen/rev/73eda102ccb5 Thanks, Looks good, thanks! Chris P.
Re: [whatwg] Features for responsive Web design
On 19 maj 2012, at 10:46, Matthew Wilcox m...@matthewwilcox.com wrote:
On 19 May 2012 00:37, Kornel Lesi��ski kor...@geekhood.net wrote:
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com
wrote:
picture in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
picture only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
Yes indeed, but the problem is not about srcset, picture or anything
else: it's that, as has been pointed out repeatedly to those of us
asking about bandwidth media queries, the browser simply can't do
reliable bandwidth detection. That effects srcset as much as anything
else. So while technically srcset allows for this, the browser itself
does't, so it can never be used in the manner you're describing.
iPhone knows when it's on GPRS/EDGE, so it can implement logic exactly as I've
described it.
What it doesn't know is exact numerical value representing current bandwidth
and latency.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
This would be no better than current JS approaches, in fact making it
worse by adding to the page load size rather than optimising it.
The point is UA can do whatever gives better experience. UAs can innovate in
this area. For example phones know when they're on expensive roaming connection
and always download lowest-res images, without needing authors to add
(bandwidth-cost:expensive) MQ.
The syntax allows addition of KB descriptor later, which ― assuming UAs
will figure out how to measure actual bandwidth well enough ― will allow
even more sophisticated selection based on file size (rather than only 1x/2x
scale factors which are only a proxy for the file size).
As above; this seems set not to happen. Besides, how is it going to
know the file size unless you explicitly state it in the srcset
somewhere?
Setting explicit filesize may be an option. With current spec UA can safely
assume that 1x image is smaller than 2x.
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
Not actually sure what intrinsic sizes of images means.
A default size of the image when you don't specify any size in HTML/CSS.
Ah, OK thanks :) I do not ever set intrinsic sizes, and nor does any
site I have seen that is responsive in nature. Precisely because it
has no meaning or use in a responsive site.
intrinsic size is the one you don't set. Size in img width or CSS width:
overrides intrinsic size.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
Or you do what we do now and supply a double resolution image and set
it to a given CSS size.
That requires relatively large amount of effort ― putting image sizes for all
breakpoints in CSS, with same media queries, and ensuring you have unique
selector for the image.
That's 5-10 lines of code for what you get with mere 2 characters in srcset.
And when intrinsic size is usable you can use it for images with variable size
(e.g. known width, but height dependent on aspect ratio of the image)
Or just any old size, from my experience of
the iPad3 you don't actually need to be that specific, just get an
oversized image and let it shrink a bit and it holds up well.
That is true for devices which use zoom a lot, but may be suboptimal on
desktops.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
I'd like to see idea's on how this might work.
Just throwing an idea here:
img srcset=gravatar?s={grsize}
style
@breakpoint grsize:80;
@media (max-width:320px) {
@breakpoint grsize:40;
}
/style
I'm not sure about using style, as it cannot work in external CSS (we can't
ask UAs to wait).
However declaration may need more syntax than just meta to allow separate
groups of breakpoints.
And meta breakpoint has same limitations for DPI adaptation as source
media.
There are two categories of use-cases (art-directed and
dpi/optimization) and picture is suited for only one of them, so
please don't frame the decision as discarding of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
Re: [whatwg] Features for responsive Web design
On 18 May 2012 22:19, Kornel Lesiński kor...@geekhood.net wrote: On Fri, 18 May 2012 20:24:00 +0100, André Luís andreluis...@gmail.com wrote: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Thank you, that was helpful. I'm trying to steer the overwhelming amount of messages on the topic both here, online and on that mailing-list (recently joined). This will help me think and mature about some possible theories. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. People are already spread too thin on this... I myself am struggling to keep up with the current present status of things. :-\ -- André Luís -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Sat, May 19, 2012 at 2:46 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 19 May 2012 00:37, Kornel Lesiński kor...@geekhood.net wrote: On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: picture in its current form is unable to support bandwidth-based negotiation well By all accounts no solution proposed can do this. This is not a picture only problem. srcset allows UA to pick any image density regardless of actual screen density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download 1x images, instead of 2x. Yes indeed, but the problem is not about srcset, picture or anything else: it's that, as has been pointed out repeatedly to those of us asking about bandwidth media queries, the browser simply can't do reliable bandwidth detection. That effects srcset as much as anything else. So while technically srcset allows for this, the browser itself does't, so it can never be used in the manner you're describing. I'm not sure where you got that idea; no one has said that bandwidth detection is impossible. We've merely said that it's *hard*, and it involves much more than a simple what's the instantaneous bandwidth right now?. Opera Turbo, for example, has high/low bandwidth detection for deciding what behavior to use. It was very difficult to get it right, but I presume they've settled on a decent solution now. *Because* it's hard, we shouldn't put the problem in the hands of devs. It's better to solve it a handful of times in browsers, than to expect ten thousand individual developers to all solve the problem correctly. UAs are also free to download 1x image first, and then 2x image after onload, etc. Declarative nature of descriptors, as opposed to imperative MQs, allows UAs to innovate in this area and come up with new uses that authors didn't predict/express in MQ. This would be no better than current JS approaches, in fact making it worse by adding to the page load size rather than optimising it. No, it's definitely better, because, as already stated, the browser can make these sorts of decisions intelligently. Grabbing the cheapest assets for a fast load then swapping them out when a slow load is less noticeable is a smart decision if the bandwidth supports it. The syntax allows addition of KB descriptor later, which — assuming UAs will figure out how to measure actual bandwidth well enough — will allow even more sophisticated selection based on file size (rather than only 1x/2x scale factors which are only a proxy for the file size). As above; this seems set not to happen. Besides, how is it going to know the file size unless you explicitly state it in the srcset somewhere? I'm not sure I understand the question. He's talking about a descriptor that lets you explicitly state the file size. ~TJ
