W3C home > Mailing lists > Public > public-native-web-apps@w3.org > December 2011

Re: Multiple splash screen dimensions

From: Charles McCathieNevile <chaals@opera.com>
Date: Tue, 13 Dec 2011 20:11:19 +0100
To: "Wesley Hales" <whales@redhat.com>, "Marcos Caceres" <w3c@marcosc.com>
Cc: "Filip Maj" <fil@adobe.com>, "public-native-web-apps@w3.org" <public-native-web-apps@w3.org>, "Brian LeRoux" <brian.leroux@nitobi.com>
Message-ID: <op.v6fzk5izwxe0ny@widsith.eng.oslo.osa>
On Tue, 13 Dec 2011 17:30:09 +0100, Marcos Caceres <w3c@marcosc.com> wrote:

> On Tuesday, December 13, 2011 at 2:47 PM, Wesley Hales wrote:
>> From a developer usability/maintenance standpoint, what happens when  
>> I'm trying to target 5, 6, or more resolutions?
>> So the "recommended" filename convention might be something like:
>> [name]_[device]_[type]_[ppi]_[orientation]_[dimensions].[png,jpg,gif]

Please no....

> There is no harm recommending something like this, so long as its a  
> non-normative authoring guideline… however, as you say below, we should  
> gather evidence of current practice before we recommend anything.

And there is harm in recommending something if some implementations follow  
that and it turns out to be a bad idea. This seems like a bad idea,  
because any such naming scheme seems likely to have the same problems as  
the attributes it might try to replace.

>> Of course, they wouldn't be required to follow any convention, so that  
>> seems like a maintenance nightmare once you try to support a lot of  
>> devices. What are you guys seeing from real world apps? At a minimum,  
>> just supporting Apple devices, you have 3+ resolutions x 2 orientations.
>> imo, there are a few good things about having the width/height  
>> attributes:
>> 1) developers know, up front, which screen size they are targeting --  
>> allowing them to keep the config readable.
> So:
> 1. We know people will get these wrong (copy paste error, image adjusted  
> after config.xml is created, etc.). What happens when they are wrong  
> (i.e., what are the semantics of the width and height attributes)?

Either what the HTML spec says (stretch to fit) or use the  
preserveAspectRatio attribute from SVG or pick a value of it.

> 2. If the file name implies the size (e.g., "iPad_big_vertical.png")  
> does it really help to have the w/h values repeated?
> The 2 above is hopefully something maybe the Phone Gap guys can answer.  
> What file names are people using? Has a convention naturally emerged?

If the file name implies the device, you have a bunch of problems already  

>> 2) Allowing the user agent to calculate and parse the image size seems  
>> like needless overhead, since the developer might already be inputing  
>> the image dimensions in the filename.
>> What happens when the device resolution doesn't match the provided  
>> splash images? Do we stretch the closest one or ignore it?
> I we consider width and height attributes, I think your second question  
> is even more complicated:
>  1. what happens if there is no match (image is bigger | smaller)?
>  2. what happens if there is a match in real width and height, but the  
> author declared width and height in the config to something else?
>  3. what happens if there is no match in real width and height, but the  
> author declared width/height and it matches the device resolution?
>  4. … there are probably more…
> The above is why I think it's best to ignore width/height for bitmap  
> files and only respect it for vector graphics (hence, computing the  
> width and height from the images themselves, and allowing the UA find  
> the best fit… and stretching if really needed).

Agreed really. Alternatively, CSS Media queries could provide a model (or  
switch element from SVG, or similar) to let the author decide what to do.

> What the UA does with the images once its has found a suitable match is  
> an implementation detail, IMO



Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Tuesday, 13 December 2011 19:12:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:46:09 UTC