Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)
On 16 October 2014 08:52, Mike West mk...@google.com wrote: * Server stores credentials as `sha512(password + username)`. It might be better to require PBKDF2/bcrypt/scrypt.
Re: [whatwg] apple-touch-icon
On 29 July 2014 12:46, Mathias Bynens mathi...@opera.com wrote: On Mon, Jul 28, 2014 at 4:59 PM, John Mellor joh...@google.com wrote: We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png There’s no need for `shortcut` there as per the standard. Sure, it's just for compatibility with IE11 (IE 9 and 10 allow rel=icon, but only if you also specify type=image/x-icon[1]). [1]: http://blogs.msdn.com/b/ieinternals/archive/2013/09/08/internet-explorer-favicons-png-link-rel-icon-caching.aspx
Re: [whatwg] apple-touch-icon
Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well known URLs, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png (or even good old: link rel=shortcut icon href=/favicon.ico with multiple resolutions in the .ico file for compatibility with IE11). [1]: https://code.google.com/p/chromium/issues/detail?id=259681 [2]: https://bugs.webkit.org/show_bug.cgi?id=104585 [3]: https://code.google.com/p/chromium/issues/detail?id=296962 On 28 July 2014 08:35, Mathias Bynens mathi...@opera.com wrote: On Sun, Jul 27, 2014 at 1:13 PM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 FWIW, Chrome’s intention was to drop support for Apple’s magic file names at some point. https://developer.chrome.com/multidevice/android/installtohomescreen#icon But I agree — it seems that this won’t happen any time soon. In case it helps, here’s some more info on touch icon support on various OS/devices: http://mathiasbynens.be/notes/touch-icons
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On 15 May 2014 17:13, Peter Beverloo bever...@google.com wrote: (snip) For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Actually, it would probably be fine for delayed notifications to fire a notificationshow event on SWs, as long as script run from the notificationshow event is unable to close the notification (but altering/replacing the notification should be allowed). The protection against developers wasting battery with excessively frequent 'alarms' is then that they won't want to spam users with notifications (or will get their notification permission swiftly revoked if they do). Thanks, Peter
Re: [whatwg] AppCache Content-Type Security Considerations
On 13 May 2014 17:38, Ian Hickson i...@hixie.ch wrote: Are the lessons learnt here being reported to the Service Worker team? Yes, I've been discussing this with them in https://github.com/slightlyoff/ServiceWorker/issues/224 and https://github.com/slightlyoff/ServiceWorker/issues/253, which is what led me to spot and report this vulnerability in AppCache to Eduardo et al in the first place. I'll make sure the Service Worker folks stay in sync with this thread.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Sun, Nov 17, 2013 at 11:22 PM, Maciej Stachowiak m...@apple.com wrote: I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows: Thanks for explaining your position Maciej. The src-n proposal with the following changes seems likely reasonable: - In a single attribute (ideally named srcset to avoid gratuitous renaming) with || or some other separator - viewport-urls syntax removed or changed to be more human-understandable Can I focus on the viewport-urls syntax for a moment? Everything else (single attribute with ||s/multiple attributes/multiple elements/split between inline CSS HTML) is mainly just aesthetics. But the viewport-urls syntax provides a crucial bit of functionality, and I'd like to make sure people understand why it's so important. It resolves the fundamental tension between what authors want, chose image source based on layout size, and what browser developers want, don't break the preload scanner, in the very common variable-sized images (viewport-switching) case. Satisfying both conditions requires the author to tell the browser's preload scanner what the layout size of the image will be, in terms of the viewport size (and/or fixed sizes). That's all viewport-urls does: you express your layout image size as a CSS length (whose containing block is the viewport, as if you'd used position:fixed). For example: - 400px - 33% // equivalent to 33vw - calc(50vw - 80px) // flexible width with fixed padding It doesn't need to be exact (it's ok if most authors don't bother with calc), it just needs to approximate the layout image size such that the browser can determine the closest matching source. Finally, in cases where you have a nonlinear relationship between viewport width and image width (primarily in responsive designs where the number of columns changes due to a media query), you can provide a CSS length to either side of the discontinuities, where the discontinuity is expressed as a CSS min-width MQ, hence for a 1-3 column responsive grid you end up with something like the 100% (640px) 50% (960px) 33% examplehttp://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/you've probably seen. But again, while using this correctly will give you the optimal tradeoff between page load performance and image quality, it's generally ok if the long tail of websites don't bother dealing with the discontinuities, and just provide a rough estimate of image size, e.g. they approximate 100% (640px) 50% (960px) 33% as simply 600px. Finally, xanthir.com/b4Su0 explains why without viewport-urls, the markup complexity balloons (as an author still has to figure out the relationship between viewport width and layout image size, but then furthermore has to do a bunch of maths and sprinkle the breakpoints above as subtle variations in densities of the images they provide). Does this all make sense? Hopefully that helped explain why viewport-urls syntax (or something similar) is essential; but I'd definitely welcome suggestions to make it more human-understandable. The CSS lengths seem clear enough, but it's possible there's a better way of expressing the breakpoints... The latest style-based img/content proposal seems reasonable if the following issues could be addressed: - Always loads src per current browser behavior (might be fixable by omitting 'src' attribute). - Not obvious if preload scanning can reasonably be expected to resolve CSS selectors (hopefully parser/preloading experts can weigh in). I personally somewhat prefer the style-based proposal if the issues are addressed, as it has less surface syntax. It would probably also have to be combined with vanilla x-only srcset to do resolution scaling combined with art direction, without forcing sizes to be set explicitly. Regards, Maciej
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Fri, Nov 15, 2013 at 5:12 PM, Shane Hudson m...@shanehudson.net wrote: Could I just please clarify, since its been hard to follow the conversation, that having the style internal means that the prefetcher can still handle the images properly? Yes, *but* only if you use a limited subset of CSS. Adam suggested earlier (quoted below), that the preparser would only be able to match simple selectors (like class and id), but not selectors that need to understand the structure of the DOM tree (e.g. descendant or sibling selectors). Personally, I suspect authors would trip up on this quite a bit. On Tue, Nov 12, 2013 at 6:49 PM, Adam Barth w...@adambarth.com wrote: The hard part is deciding what to put in the optimized subset. We already parse media queries in the preload scanner to find imported stylesheets to load. We probably won't be able to support every media query under the sun, but we could support maybe min-width, min-height, and min-device-pixel-ratio (or whatever you think is best along these lines). For selector matching, we wouldn't be able to support anything that needs to understand the structure of the tree (e.g., descendant selectors or sibling selectors). I'd probably start with just single class and id selectors. In case it wasn't clear from the above, we wouldn't preload the image until we'd encountered the div with the appropriate class name. When scanning that start tag token, we'd simulate CSS selector matching in the preload scanner to see if we've understood any rules that match. None of the above is all that difficult, and it's probably something we should do anyway to improve image preloading across the whole web. Adam
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
One-dimensional solutions like this look pretty but once you combine width
and device-pixel-ratio (resolution) it quickly explodes and you get
num_widths * num_dprs entries. Please read xanthir.com/b4Su0, at least the
example at the bottom showing how srcset quickly gets impractical.
If you want to move the presentational aspects to CSS, you need an approach
closer to my earlier
emailhttp://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-November/041432.html,
preserving the size-viewport-list from src-N.
Combining content:replaced with the attr() function is a neat trick though;
you could tweak my earlier approach to give something like the following
(incorporating size-viewport-list into CSS image-set, which needs to
happen anyway):
style
@media (max-width: 19.99em) {
.artdirected { content: replaced image-set(128px; attr(srcs-smallicon));
}
}
@media (min-width: 20em) {
.artdirected { content: replaced image-set(100% (30em) 50% (50em) 33%;
attr(srcs-flexwidth)); }
}
/style
...
img class=artdirected src=fallback.jpg
srcs-smallicon=i64.jpg 64, i128.jpg 128, i256.jpg 256
srcs-flexwidth=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg 1280,
2560.jpg 2560
(note that the above is a maximally complex example, incorporating art
direction, viewport-switching and dpr-switching; most normal cases would be
simpler than this)
This is a little bit more verbose than the split I'd suggested; but I must
admit it gives nice flexibility (the author can use attr when the images
differ for each member of a CSS class, but can include the urls directly in
the style rule if the images are the same for all members of the CSS class).
On Wed, Nov 13, 2013 at 1:56 AM, Christian Biesinger
cbiesin...@google.comwrote:
On Tue, Nov 12, 2013 at 3:06 PM, Markus Ernst derer...@gmx.ch wrote:
What I don't like about CSS approaches is the fact that changing the
source
of an image is fundamentally different from changing a dimension or
color of
an element. This is not presentational in the same way. Having to
reference content images in the CSS in order to change their sources is
an
authoring nightmare.
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
}
@media (min-width: 600px) {
.artdirected { content: replaced url(attr(src-medium)); }
}
@media (min-width: 800px) {
.artdirected { content: replaced url(attr(src-big)); }
}
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
-christian
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we may
be able to fix that by extending image-set to support src-N's
viewport-urls syntax.
- Requires you to know the intrinsic aspect ratio of the images in advance.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which is
fairly icky. Since we're inlining the presentation into the content anyway,
may as well inline it next to the relevant bit of the content.
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).
Adam
If we did want to split src-N up to separate presentation from content,
you'd probably want to put the size-viewport-list and media-querys into
inline CSS, and leave just the size-based-urls (which are pure content)
in the HTML. Then you'd end up with something like the following.
If you just have viewport-switching (and dpr-switching), it'd be:
style
.photo {
image-width: 100%;
}
/style
img class=photo srcs=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560
(and as in
src-Nhttp://tabatkins.github.io/specs/respimg/Overview.html#viewport,
you could use more complicated size-viewport-list expressions like 100%
(30em) 50% (50em) 33% if the image width is a non-linear function of
viewport width)
If you just have dpr-switching (fixed-width images), it'd be:
style
.photo {
image-width: 128px;
}
/style
img class=photo srcs=64.jpg 64, 128.jpg 128, 256.jpg 256
(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available
image)
If you have art direction and dpr-switching, it'd be:
style
.photo {
image-width: small 128px;
}
@media (min-width: 20em) {
.photo {
image-width: big 400px;
}
}
/style
img class=photo
srcs-small=s64.jpg 64, s128.jpg 128, s256.jpg 256
srcs-big=b200.jpg 200, b400.jpg 400, b800.jpg 800
(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)
This actually looks pretty reasonable (and unlike earlier proposals in this
thread, covers all use cases). One nice benefit over src-N is that
the size-viewport-list -- i.e. 128px or 100% or 100% (30em) 50%
(50em) 33% -- doesn't get repeated for every image, if there are several
images with the same relationship between viewport size and image size.
My main concern is that authors won't realise that the CSS must be inlined;
I'm not sure how to make that foolproof.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Tue, Nov 12, 2013 at 6:54 PM, Adam Barth w...@adambarth.com wrote: On Tue, Nov 12, 2013 at 10:45 AM, John Mellor joh...@google.com wrote: - Doesn't address viewport-switching (variable-sized images), though we may be able to fix that by extending image-set to support src-N's viewport-urls syntax. Why doesn't it support variable-sized images? In example above, one of the cases is 30x30 and the other is 60x60. Maybe I've misunderstood what you mean by variable-sized images? In most responsive designs, there are images whose resolution depends on both the viewport width and the devicePixelRatio. Your approach technically allows handling both, by combining max-width and max-resolution MQs, but if you have 6 widths and 4 dprs, you have to write 24 separate MQs, for every combination. This is the same problem srcset's w unit had; see xanthir.com/b4Su0 for a clear explanation, and compare the extreme verbosity (and incomprehensibility) of the srcset example there, with the much simpler equivalent src-1.
Re: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support
If the user is speeding up playback to improve their productivity (spend less time watching e.g. a lecture), then they may well be willing to wait until enough of the video is buffered, since they can do something else in the meantime. For example by spending 30m buffering the first half of a 1 hour live stream, the user could then watch the whole hour at double speed. Obviously the UI should make it clear what's going on (rather than lengthily buffering without explanation). On 17 Jul 2013 18:41, Peter Carlson (carlsop) carl...@cisco.com wrote: Ian For on-demand movies or VOD, the available playback speeds may be determined by the server of the content. This cannot be overcome by client-side buffering. Peter Carlson
Re: [whatwg] img srcset / css image-set issues
On Wednesday, August 22, 2012, Tab Atkins Jr. wrote: On Tue, Aug 21, 2012 at 4:28 PM, John Mellor joh...@chromium.org wrote: Take the simple example above where you have the same image saved in 4 sizes -- 320.jpg, 640.jpg, 1280.jpg and 2560.jpg, named after their widths -- and you need it to scale across mobile and desktop. With my proposed syntax you just declare each available size once, and the browser does the rest: img srcset=320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x Whereas using only the w/h and x tokens, to properly support devices of various dppx's you have to use the following 16 entry monstrosity (that I had to generate by script): img srcset= 320.jpg 400w 1x, 320.jpg 320w 1.25x, 320.jpg 267w 1.5x, 320.jpg 200w 2x, 320.jpg 160w 2.5x, 640.jpg 800w 1x, 640.jpg 640w 1.25x, 640.jpg 533w 1.5x, 640.jpg 400w 2x, 640.jpg 320w 2.5x, 1280.jpg 1600w 1x, 1280.jpg 1280w 1.25x, 1280.jpg 1067w 1.5x, 1280.jpg 800w 2x, 1280.jpg 640w 2.5x, 2560.jpg 10x (and in the image-set case, doing this with media queries would be even more horrific) No you don't. Just do this: img style=width:100%; srcset=320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x No, that's completely different! See below. I doubt this is actually what you want, though - you're probably not actually trying to cater to devices with an 8:1 pixel ratio! (Those may not ever exist, even if technology does make it possible - I think you drop below human perception about 5x or so.) This is nothing at all to do with 8:1 pixel ratios (though as a happy accident my proposal would also automatically scale to pixel ratios that aren't currently common). If you re-read my original email, you'll see that I defined 320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x to mean that for each alternative image, the browser would multiply the provided intrinsic size (320x120) by that alternative's 'x' token to calculate the number of pixels of image data available in each dimension, then it would pick the one that most appropriately matches the number of device pixels the image is actually taking up in each dimension. So for example 1280.jpg 4x means that this image is 4 times larger than the given intrinsic width of 320px. So sure, it would be suitable for display on a hypothetical 4x display at 320px width; but the browser also knows that it would be suitable for display on a 2x display at 640px width, a 1.5x display at 853px width, and a 1x display at 1280px width. The browser simply doesn't have that kind of information with the current srcset spec, so it is forced to be act more dumbly. Let's assume that, instead, you're trying to serve two versions of the image: one for small screens and one for larger screens, and each version has two resolutions. In that case, you'd do this: img style=width:100% srcset=320.jpg 1x 320w, 640.jpg 2x 320w, 1280.jpg 1x, 2560.jpg 2x But that doesn't work! Let's look at some common devices for which it fails: 360w 2x portrait Galaxy S III = *2560.jpg instead of 640.jpg!* 480w 1x landscape iPhone 3 = 1280.jpg instead of 640.jpg 2560w 1x 30 desktop = 1280.jpg instead of 2560.jpg If even the author of the spec can't write a srcset that doesn't serve wildly inappropriate files to today's popular devices, how can one expect average web authors to write srcsets that properly adapt to future device categories? Indeed, it's not actually possible to fix that srcset just by tweaking the thresholds; you have to add additional redundant declarations (as in my monstrous example above). With my proposed syntax, you just declare the available image sizes, and it just works, across all present and future devices. The fact that the UA is granted some freedom to fiddle with things doesn't change the semantics. HTML's algorithm is just written a little differently than image-set()'s, but the meaning is identical - UAs can choose which resolution version they want based on *any* criteria they choose. As I said, the fact that UAs have freedom doesn't change the semantics in the eyes of the author. The description and algorithm in the spec heavily imply that a typical UA algorithm will be to choose the images with the smallest pixel size descriptors = the pixel size of the display. It would be much clearer if this implication was not made, i.e. remove step 21 completely, change step 24 to read Remove all the entries in candidates except the one whose associated pixel density is the best match for a user-agent-defined value giving the nominal pixel density of the display., and change the phrase maximum pixel density to just pixel density in http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset(and anywhere else). Once again, using image-set() with MQ is *exactly* the same as the w and h descriptors
Re: [whatwg] img srcset / css image-set issues
On Wed, Aug 22, 2012 at 5:19 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Aug 22, 2012 at 4:22 AM, John Mellor joh...@chromium.org wrote: On Wednesday, August 22, 2012, Tab Atkins Jr. wrote: Let's assume that, instead, you're trying to serve two versions of the image: one for small screens and one for larger screens, and each version has two resolutions. In that case, you'd do this: img style=width:100% srcset=320.jpg 1x 320w, 640.jpg 2x 320w, 1280.jpg 1x, 2560.jpg 2x But that doesn't work! Let's look at some common devices for which it fails: 360w 2x portrait Galaxy S III = 2560.jpg instead of 640.jpg! 480w 1x landscape iPhone 3 = 1280.jpg instead of 640.jpg The point of the w/h descriptors is to align with your media queries to solve the art direction use-case, where different layouts may demand images with different sizes/ratios which may be produced differently (possibly generated from the same image, but with different layouts or whatnot). But that's exactly my point! The w/h descriptors are sufficient *only* for art direction, where you want to swap between completely different images (or at least different crops of the same image), based on viewport size, to match other changes occurring in your responsive design as the viewport size changes (and they do a fine job at art direction). They are *not* suitable (even combined with x descriptors) as a general purpose mechanism for dealing with flexibly-sized images, where you need to match the number of device pixels taken up by the image to the number of image pixels in the image you load (while allowing the browser to adjust this based on bandwidth constraints etc), since doing that properly *requires* additional information, i.e. knowing the intrinsic size (or at least intrinsic width or height) of the image before choosing which to download. If one of your breakpoints was predicated on a max-width: 320px MQ, then this is exactly what you want. (This is probably not a great breakpoint, since it's clearly focused on the iPhone and likely not your content's actual breakpoint, but whatever.) 2560w 1x 30 desktop = 1280.jpg instead of 2560.jpg This is adequate. In the olden days before srcset, you'd just get the 1280 version all the time. Now, if you'd like, you can toss in an additional breakpoint with a 2560.jpg 2560w 1x and be fine. It's not *perfectly ideal*, but it's fine. No, it's not fine to just toss in an additional breakpoint. If you do this for all important device categories you go back to the monstrous 16-entry srcset I showed earlier, which is clearly unsustainable. The problem with trying to be smarter is that you have to be very careful to not mess with the art direction use-case. It's *possible* to improve the syntax in the future to handle your last example better, but it needs to be done with care. The art direction use case can be entirely orthogonal. It should be handled with the w/h descriptors as currently specified. What I'm proposing would operate after any w/h descriptors have narrowed down the set of allowable images, and let the browser choose between the remaining images more intelligently in the case of flexible-size images, where currently the browser has no idea which to use. I'm not actively working on anything right now, but my plan is to push for @media to be nestable inside of style blocks, so you can put the declarations right next to each other. Cool :)
[whatwg] Fwd: img srcset / css image-set issues
CSS image-set and HTML img srcset are getting their first implementations
but both APIs have serious shortcomings. We should fix them before it's too
late:
1. Neither is of any use for flexibly-sized images.
2. srcset isn't as smart/intuitive as image-set.
3. image-set is less flexible than srcset.
I'll go through these in turn, in decreasing order of importance (sorry
about the length, but this is a complex topic and I've tried to avoid
ambiguity).
(This email is cross-posted to whatwg and www-style, since this is of equal
relevance to HTML and CSS).
1. Neither is of any use for flexibly-sized images.
These APIs have been designed with fixed-size images in mind, and they work
well for that use case. For example if you have a width:320px image, and
you need to decide whether to load the 2x retina file or the standard
file.
However they stop working when the width (or even just min/max-width) is
flexible, for example width:100%, which makes them almost useless for
responsive web design, and not great even for basic tasks like adapting to
different size mobile devices. I'll explain why:
If you have the same image saved in a variety of scales on the server (e.g.
320.jpg, 640.jpg, 1280.jpg, and 2560.jpg, named after their widths), then
you want the browser to load the one which has the same number of pixels of
image data as the number of device pixels that the image is taking up on
the display (assuming for now that bandwidth isn't a concern, and that you
don't have to worry about the page being displayed at multiple zoom levels
due to pinch zoom). For example if your width:100% image is currently
stretched to 1280 CSS px, then you want to load 1280.jpg on 1x low DPI
devices and 2560.jpg on 2x high DPI devices. But if it has shrunk to 320
CSS px, then you want to load 320.jpg on 1x low DPI devices and 640.jpg on
2x high DPI devices.
Neither image-set nor srcset can cope with this simple fundamental task!
Nor can they, as currently specified: while the browser knows (or can
estimate, if layout hasn't yet happened) the number of device pixels the
image is taking up, it doesn't know how many pixels of image data the
srcset/image-set entries contain until it downloads them, since it knows
their dppx but not their size.
To put it another way, since the browser doesn't know the intrinsic size of
the image until it downloads one of the files (and divides the image data
size by its dppx value), they simply cannot know how much a flexibly-sized
image is being stretched by, and so they can't use that information as
input when deciding which image to download.
[With srcset, it is possible to hack together a srcset definition that will
load approximately the right image file by combining dppx and viewport
width restrictions -- see sample
codehttp://jsbin.com/aganaz/8/edit?javascript,live --
but this is excessively cumbersome for practical use.]
A simple solution to this problem, would be to provide a way for authors to
tell the browser in advance what the intrinsic size of a flexibly-sized
image is, such that the browser can calculate how many pixels of image data
each option contains, and hence which would be most appropriate. For
example, one could add an initial term to the srcset/image-set, providing
the intrinsic size of the image:
img srcset=320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x
selector { background: image-set(320x120, 320.jpg 1x, 640.jpg 2x,
1280.jpg 4x, 2560.jpg 8x); }
This would be equivalent to:
img srcset=2560x960, 320.jpg 0.125x, 640.jpg 0.25x, 1280.jpg 0.5x,
2560.jpg 1x
selector { background: image-set(2560x960, 320.jpg 0.125x, 640.jpg
0.25x, 1280.jpg 0.5x, 2560.jpg 1x); }
For each image, after discarding images that don't satisfy the viewport
width/height criteria in the usual manner if it's a srcset, the browser
would multiply the provided intrinsic size by the image's x value to
calculate the number of pixels of image data available in each dimension,
then it would pick the one that most appropriately matches the number of
device pixels the image is actually taking up in each dimension (see 2.
below for why I recommend most appropriate instead of strictly pick the
smallest image whose image width = device pixel width).
This initial intrinsic width term would be optional, as it is unnecessary
for fixed-size images, but would be strongly recommended for flexible-size
images as without it the x values would select purely on dppx grounds,
which as explained above isn't useful.
In the occasional event that different images have different intrinsic
sizes it would be possible to specify several intrinsic sizes, each of
which would apply to the subsequent images (until the next intrinsic size).
For example:
img id=logo style=width:100% srcset=
320x320, square.jpg 1x 400w, square-hd.jpg 2x 400w,
320x50, flat-s.jpg 1x, flat-m.jpg 2x, flat-l.jpg 4x, flat-xl.jpg 8x
would show a square logo on portrait phones, but a more discreet flat logo
on wider devices (in both
Re: [whatwg] img srcset / css image-set issues
On Tue, Aug 21, 2012 at 8:31 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Aug 21, 2012 at 12:20 PM, John Mellor joh...@google.com wrote: 1. Neither is of any use for flexibly-sized images. This is what Media Queries and the similar 'w' and 'h' tokens in @srcset are for. You can create one pair of 1x/2x images for one size of screen, and another pair for another size of screen. While it is indeed possible to abuse the w/h tokens in this way, it's so impractical as to not be worth using. Take the simple example above where you have the same image saved in 4 sizes -- 320.jpg, 640.jpg, 1280.jpg and 2560.jpg, named after their widths -- and you need it to scale across mobile and desktop. With my proposed syntax you just declare each available size once, and the browser does the rest: img srcset=320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x Whereas using only the w/h and x tokens, to properly support devices of various dppx's you have to use the following 16 entry monstrosity (that I had to generate by script http://jsbin.com/aganaz/8/edit?javascript,live): img srcset= 320.jpg 400w 1x, 320.jpg 320w 1.25x, 320.jpg 267w 1.5x, 320.jpg 200w 2x, 320.jpg 160w 2.5x, 640.jpg 800w 1x, 640.jpg 640w 1.25x, 640.jpg 533w 1.5x, 640.jpg 400w 2x, 640.jpg 320w 2.5x, 1280.jpg 1600w 1x, 1280.jpg 1280w 1.25x, 1280.jpg 1067w 1.5x, 1280.jpg 800w 2x, 1280.jpg 640w 2.5x, 2560.jpg 10x (and in the image-set case, doing this with media queries would be even more horrific) I'll explain why this happens: a) The primary problem with using w/h tokens for this, and the reason the above srcset is so redundant, is that in the current srcset spec the x tokens are totally independent from the w/h tokens. So if you have an image that's 640 image pixels wide, it is suitable for display 640 CSS px wide on a low dpi device, but only 480 CSS px wide on a medium dpi device, and only 320 CSS px wide on a high dpi device, etc. These all need to be encoded separately, since you can't write rules in terms of the product of the 'x' and the 'w'. Clearly it would be better for the browser to do this trivial but repetitive and error-prone maths for you. b) A second difficulty, is that the w/h tokens must be specified in terms of the viewport size, but there may be no trivial relationship between the image size and the viewport size. Even if there is, having to figure it out increases the developer burden, and significantly increases the risk of errors (which can very easily slip through, since it's hard to test on all device types, and most developers will only notice mistakes if the image looks bad, not if it merely consumes an unnecessary amount of bandwidth). c) Finally you'll notice that I put 320.jpg 320w 1.25x instead of 320.jpg 320w 1x. That's because (as pointed out in 2.) srcset is currently specified such that these are strict maximums, yet in practice it's better to upscale an image a little bit (e.g. 1.25x) than to download an image that's twice as big (potentially 4x the file size). Cobbling together w/h and x tokens like this requires the author to manually make value judgements like this and incorporate them into their calculations, when it would be better to let the browser decide. 2. srcset not as smart/intuitive as image-set. The algorithms are meant to be the same. If you read the HTML algorithm carefully, you'll notice that, after you've eliminated the images that violate the 'w' or 'h' constraints, the browser can choose *any* of the remaining images, based on whatever criteria it wants. This happens in two places: step 17 is very explicit in saying UAs can do what they want; step 21 is more implicit, as the nominal pixel density is a UA-defined value and can be literally anything. (There was previously a note in the spec saying this directly, but it appears to have been removed.) Ideally, I'd be able to just refer to the HTML algorithm, but it's far too specialized for @srcset for me to actually use. Instead, I plan to include a note pointing to @srcset and indicating that it should be identical. I'm glad you intend them to be the same. But currently they are very different semantically. With image-set you just provide the intended dppx of each image, and let the UA decide which is most appropriate in a given situation[source http://dev.w3.org/csswg/css4-images/#image-set-notation], i.e. it can be expected to pick the closest match. Whereas with srcset, 2x means maximum pixel density of 2 device pixels per CSS pixel[sourcehttp://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset] (emphasis on the maximum), and step 21 of the algorithmhttp://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates reinforces this by discarding anything whose maximum is too small. The fact that the UA is granted some freedom to fiddle
