Re: Multiple splash screen dimensions

On Dec 13, 2011, at 11:30 AM, Marcos Caceres 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]
> 
> 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.   
>> 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)?  

Exactly. Should we require the UA to provide supported aspect ratios as well? If the defined width does not match the current viewport, the developer could also define aspect ratio as a fail-safe attribute. 

> 
> 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?  

I think so, even though we are recommending a naming convention, it doesn't mean people will follow it correctly. Unless we want to graduate the convention from recommended to mandatory.

> 
> The 2 above is hopefully something maybe the Phone Gap guys can answer. What file names are people using? Has a convention naturally emerged?  
> 
>> 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)?  
fallback to aspect ratio somehow?

> 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?  
the UA would never know this occurred if we take this approach. So there's my answer :) Seriously, aspect may be a good fallback if possible.

> 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?   
stretch it

> 4. … there are probably more…  
> 
> The above is why I think it's best to ignore width/height for bitmap files
Do you mean the UA should not detect the image width/height?

> 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).
> 
> What the UA does with the images once its has found a suitable match is an implementation detail, IMO: some will fade in, others may zoom it in… and zoom fade it out when the user agent is ready to go… etc.
+1

>

Received on Tuesday, 13 December 2011 19:49:08 UTC