W3C home > Mailing lists > Public > www-style@w3.org > September 2011

Re: [whatwg] add html-attribute for "responsive images"

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Thu, 01 Sep 2011 16:58:30 +0000
Message-ID: <4E5FB997.2010806@gmail.com>
To: Karl Dubost <karld@opera.com>
CC: "www-style@w3.org Style" <www-style@w3.org>, Anselm Hannemann - Novolo Designagentur <anselm@novolo.de>, Charles Pritchard <chuck@jumis.com>
Þann fim  1.sep 2011 00:04, skrifaði Karl Dubost:
> Le 31 août 2011 à 18:38, Bjartur Thorlacius a écrit :
>> Sending an accept-size (or some such) could solve both the problem of high resolution photography and lengthy documents.
>
> there are at least two use cases
>
I listed two use cases after the "top line" and a quotation.

> 1. sizes
Samples of images are representations of a general resource. The 
resource (e.g. an image) can be represented by multiple message bodies 
(e.g. samples of different resolutions). This can be solved by a HTTP 
header.

> 2. different images
>     The logo icon (50px x 50px) when on a small screen
>     The logo banner type with company name (200px x 50px)
>         on a midle size screen.
>     The logo big image with company name, photo, motto, etc.
>         on a large screen.
>
The solution to this problem is figuring out which resources replace 
each other, and state this semantically in the HTML. You list three 
possible combinations, but do you want discourage rendering both the 
banner and motto to the same viewport?
Ultimately, the document should include the company name and motto, and 
link to a logo and a photo. If the icon is available in multiple sizes, 
the appropriate one should be negotiated using either HTTP content 
negotiation or nested objects. Unless the MIME media subtype 
specification for the image format specifies all necessary parameters, 
HTTP content negotiation is the only practical solution, as object has 
no attributes to describe resources but type. From a theoretical 
standpoint, the application layer protocol is probably the correct place 
to decide on a message body to transfer.

I advise against simply prerendering bitmaps for every device you can 
think of as I figure you're suggesting, because you can't think of 
everything. How is a user to search for a company by its motto, if the 
motto is a bitmap? Click on all colored pixels and use fuzzy searching? 
What if the font used to render the company name and motto is too clear 
and the high contrast incurs one out of thousand (or 10 thousand) 
visitors gets seizure, just by looking at the site? Maybe not a 80% use 
case, but hazard nonetheless.

> The case 2, is the most interesting one. It helps adjusting content depending on the size of the screen.
>
Objects are designed to solve the problem of deciding on a resource to 
render, with fallbacks, but rely on MIME media subtype parameters to 
describe resources. AFAIK there's no resolution parameter for any 
subtype of image.
Received on Monday, 5 September 2011 16:23:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:44 GMT