Re: Multiple splash screen dimensions

drawing back to earlier conversations I'm tempted to say the spec should call for SVG and the implementations should sort out the device target rendering...  

--  
Brian LeRoux
http://brian.io


On Tuesday, 13 December, 2011 at 8:38 AM, Marcos Caceres wrote:

>  
>  
>  
> On Tuesday, December 13, 2011 at 4:30 PM, 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)?  
> >  
> > 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?  
> >  
> > > 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…
> >  
>  
>  
> Ah, there is also: what happens if the width/height is correct, but he height/width is missing, or "foo" or too big or small (and vice versa).  
>  
> >  
> >  
> > 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).
> >  
> > 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.  
> >  
>  
>  
>