Re: [whatwg] Features for responsive Web design
On 8 sie 2012, at 12:57, Florian Rivoal flori...@opera.com wrote: Is there a good reason to believe that * will be something other than a power of two? That is, could we just optimize the *x syntax away and specify that the first option is 1x, the second is 2x, the third is 4x, etc.? If you look at mobile phones, there are a bunch of existing devices with 1.5 device pixel per css pixel, and also some with 2.25, so I don't think we can assume only powers of 2 will be used. Pixel-perfect design for non-integer scaling ratios is very hard. To have evenly thin lines (1 device pixel wide) on such screens you have to use fractional CSS pixel sizes, and fractions need to be different for different scaling ratios. I don't think anybody will take advantage of that. IMHO non-integer ratios are a mistake that can/will be corrected. Fractional ratios have proven to be unnecessary: on desktops 1x CSS pixel changed from 72dpi (CRT) to 130dpi on notebook screens, but we haven't got fractional scaling ratios along the way. Variability in screen sizes and actual DPI has been accepted. The same can happen with 1.5x-2.5x screens: pretend they all are 2x, vary CSS pixel width/height, accept physical size of CSS pixel will be slightly different. For example the 2.25 ratio doesn't make sense to me. 12.5% increase in screen density is going to be imperceptible. A better solution would be to use the crisp 2x ratio and have bigger screen area (in CSS pixels). For mobile browsers which have zoom it's easy as they can pretend to have 2x scaling ratio on a virtual viewport and resize it to screen of any other density. That's what Retina MacBook Pro does with whole screen when user requests screen resolution that isn't 1:1 with screen pixels. You can see from previous OS X releases that Apple has struggled with implementation of fractional scaling ratios for years and has given up on them. It's going to be easier to stick to 2x screens (like most desktop monitors settled on ~100dpi) or use fake 2x (scaled viewport) than expect authors to make pixel-perfect designs for 1.25, 1.5, 1.75, 2.25, etc. -- regards, Kornel
Re: [whatwg] Features for responsive Web design
On 9 sie 2012, at 11:06, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I don't think anybody will take advantage of that. IMHO non-integer ratios are a mistake that can/will be corrected. Limiting to powers of two because it can/will be “simpler” in this case not only makes the attribute harder to read – it also locks vendors in. I'm not talking just about difficulty of specifying image scaling factor, but overall difficulty of developing complete page layout with all box, border and margin sizes in fractional CSS pixels. I assume that if a designer cares enough to create several pixel-perfect versions of images, they will also want same pixel perfection from all other page features, e.g. will hate that on 1.5dppx screen a 1px border is rendered with 1dpx in one place, but 2dpx in another (or differently blurry 2dpx in both places) and will want to specify 0.px or 1.px border instead. One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). Btw, I am not aware of any other attribute that has a logarithmic scale baked in – are you? Best scaling ratios are linear, rounded to nearest integer (i.e. 3x is OK too). That's quite common in computer science, and not surprising when dealing with discrete unit like device pixel. -- regards, Kornel
Re: [whatwg] The pic element
On 1 cze 2012, at 00:58, Anselm Hannemann Web Development i...@anselm-hannemann.com wrote: • Improved alternative text — allows structured fallback, avoids duplication. This is where I do not agree. If you use MQ style with source you have a messy markup when writing alternative text inside the pic-element. Since source is not read nor displayed, it doesn't matter. You can simply treat entire content as fallback. Alt-text should always be in an attribute and this would also be easier for screenreaders etc. Structure is there to aid screen readers. See http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0216.html pic src=portrait.jpg (orientation:portrait), landscape.jpgalt text/pic Selects image based on orientation of the device. Why won't you do this with separate attributes? Of course this is much shorter to write but it confuses the masses of developers because this is not a familiar HTML/CSS-pattern. I would like to see it this style which is much more common: pic src-xs=small.jpg media-xs=(max-width:15em) src-xl=large.jpg alt=alt text title=title text/pic I don't mind either way, but this seems a bit more noisier and less compact. source can be an option for authors who prefer separate attributes. Embeds image at 192dpi (default scaling is 2x, possible to override with CSS). Same as `pic src=image.jpg 2xalt text/pic` or `img src=100x100px width=50 height=50 alt=alt text`. Why is default scaling 2x? A default image should always be @1x, right? We already have element for 1x images – img In the future 1x displays will be low-end minority and 2x will be the norm. It'll be annoying for designers that the default looks terribly and every page always needs the bad default overridden. I'm trying to avoid need for yet another opt-out from the past like doctype and meta charset. It'd be great if in 10-20 years all you had to do is type pic src instead of img src to get first-class support for hires images. To address Tab's concern the default is connected to image-resolution in CSS, so you can change it if you need to: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html (I'm not sure if `source` should allow microsyntax in `src` `source src=b 3x` instead of `resolution=3x`) I don't think so. It is much easier to have separate attributes. But what about extending the media-attr so we can write: source src=b media=3x Resolution descriptor is not a media query. I'd like to make that clear — it's not merely an abbreviation of min-device-pixel-ratio, it's a property of the image — more similar to width/height attributes. An `img` element can be used in place of any `source`. `width`/`height` defines size to display selected image at, but does not take part in selection of alternatives. If you could take the alt-text into pic and source I fully'll agree. You should be able to specify an alt-tag for every source if needed (in most use cases it isn't but in some it is if you have another crop with same meaning but different contents) Alt is not supposed to be description of the image. It's supposed to be alternative content to be used instead. e.g. not red triangle with exclamation mark but warning! So different alternative for each source would imply that purpose/meaning of the content changes with viewport size, and that'd be weird — content read to the user would change based on size of the window that a screen reader user may not even see? The common syntax for use with JS polyfills is expected to be: pic src=…noscriptimg src=… alt=…/noscript/pic ##In formal terms The `pic` element requires closing tag. The content is interpreted as a fallback for UAs that don't support `pic` or don't display the image (fallback includes text in img alt inside pic). I wouldn't necessary require a closing tag if you use the short syntax because the alt-text should be in attribute. Void element is not an option due to backwards compatibility. If there are commas or backslashes in the URL they must be escaped with `\`. This is another problem why I would separate the diff. srces. Escaping an URL is not something that should be necessary in HTML I think. I agree, it's ugly, but otherwise you get ambiguous syntax for entries without descriptor or media query. I thought about specifying some magic, like ignoring trailing comma in URL, but all such magical solutions have surprising edge cases. Explicit escaping is at least easy to comprehend. * `media` — same as `media` part in `pic src` * `resolution` — same as `resolution` part in `pic src` * `src` — single URL without escaping or microsyntax * `width` and `height` — analogous to `img width/height` for each alternative image * alt * title are missing IMO. title is global, so available for pic too. Might be worthwhile to specify how title on source behaves. As I've mentioned earlier I think it's not
Re: [whatwg] responsive images
On 22 maj 2012, at 05:53, Paul Court p...@pmcnetworks.co.uk wrote:
As a HTML author and programmer, I just cannot see myself implementing the
current srcset proposal on sites. As a programmer, it has very much got what
we would call a bad code smell.
img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h
1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h
Not to mention, what happens when a 3x device is released?
2x image will be used, upscaled.
I think that 3x device is very very unlikely to ever happen, since 2x screens
are may be dense enough to have pixels smaller than human eye can see.
1x and 2x are. Is it 2x 72 or 2x 96?
and isn't 600-200@2 just the same as 1200-400@1?
'x' is not a media query, but property of the image.
600@2 is a higher quality version of 300@1.
Perhaps something like this:-
picture
src=some.img?{width}-{height}@{dpi}
img src=some-fallback.img
/picture
You could then define a list of parameters that the browser supports as
replacements. Eg. viewport-width/height, dpi, density. This could also be
carried over to other tags.
If width/height is a virwport size then it will generate lots of unique URLs
(requires server to generate many images and proxies to cache them separately),
and may generate lots of requests when window is resized.
It doesn't work with static file servers, and may be costly/problematic for
CDNs.
Another risk is that authors will create files only for size/DPI of iPhone and
iPad and never supply images for 3000 other resolutions of various Android
devices.
--
regards, Kornel
Re: [whatwg] Features for responsive Web design
Sorry, I forgot to clarify this ― I had in mind adding width/height on each source element, not on picture. -- regards, Kornel On 22 maj 2012, at 16:01, Maciej Stachowiak m...@apple.com wrote: On May 21, 2012, at 9:37 PM, Kornel Lesi��ski kor...@geekhood.net wrote: There’s no prior precedent this sort of thing―there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. If 'width' and 'height' attributes on the picture element would do the same thing as they do on img, then they would be setting the size via style, rather than setting intrinsic size. Even if setting the size explicitly affected intrinsic size rather than size computed via style, it would miss the point of intrinsic size, which is that images get automatically the right amount of space based on the image itself. Auto-sizing may not be the right choice for all designs, but it is for some designs. - Maciej
Re: [whatwg] responsive images
On 22 maj 2012, at 15:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 22, 2012 at 7:26 AM, Kornel Lesi��ski kor...@geekhood.net wrote: I think that 3x device is very very unlikely to ever happen, since 2x screens are may be dense enough to have pixels smaller than human eye can see. Tell that to printers, which can easily hit 400+dpi. You need more than 2x before you make anti-aliasing fully unnecessary. Is making AA unnecessary a goal though? It seems to me that antialiasing isn't a complex or computationally expensive problem any more. -- regards, Kornel
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] Bandwidth media queries
I think we may be talking past each other, as I don't see how your answers address the problems I'm trying to highlight. It's not enough to say it's a hard problem. It's not going to solve itself. If you say media queries can be useful for bandwidth/quality use-cases, you need to actually specify how can they work. I'm trying to show here that MQ model is very problematic, and won't work well *even if UA has perfectly accurate bandwidth information at all times*! MQs are stateless and expected to match the same way globally, and that clashes with stateful and non-uniform nature of caches that should be taken into account. So please specifically address cases I've listed in my previous email. -- regards, Kornel On 18 maj 2012, at 10:52, Matthew Wilcox m...@matthewwilcox.com wrote: Thanks for all the feedback everyone. I don't think it's going to stop people trying to do this though; there are already write-ups for doing bandwidth detection in JS to manipulate img assets: http://www.csskarma.com/blog/detecting-for-bandwidth/ Tricky problem. I'm not sure if that was intended to be an answer to my message: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036005.html I don't think that's at decision stage, because nobody has defined what options are there to decide. The options I see are not compelling: 1. let it match actual bandwidth and apply rules according to standard media query logic. This will suck, as the page design will flip and reload whenever wind blows, and cache will be wasted. 2. let it match some average or sticky value of bandwidth according to standard MQ logic. This will suck less, but still it won't make optimal use of cache OR bandwidth, and page may get stuck in suboptimal bandwidth (e.g. you catch WiFi only momentarily and get 3G browser stuck with peak value or vice versa). 3. Violate MQ logic and allow mixed queries on the page (e.g. if browser has cached image while it had high bandwidth, use the image, even if bandwidth has dropped since). That will allow UAs to use best quality images it can and eliminate redundant requests, but will create unpredictable, inconsistent nightmare for designers. That's why I think there needs to be alternative solution parallel to MQs. It's a shame that Respimg mailinglist is dead: http://lists.w3.org/Archives/Public/public-respimg/2012May/0003.html -- regards, Kornel Lesi��ski
