Re: Multiple splash screen dimensions

On Tuesday, December 13, 2011 at 7:11 PM, Charles McCathieNevile wrote:

> On Tue, 13 Dec 2011 17:30:09 +0100, Marcos Caceres <w3c@marcosc.com (mailto: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.


Right, this is why it's important to see if the communities that are using splash screens already have worked out some sensible conventions. If not, then it's best to stay silent and maybe let one emerge.   
  
> > > 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
HTML sez:  
  
"When an img element is available, it provides a paint source whose width is the image's intrinsic width, whose height is the image's intrinsic height, and whose appearance is the intrinsic appearance of the image."

Width and height then reflect that, unless explicitly set otherwise.  

> use the  
> preserveAspectRatio attribute from SVG or pick a value of it.

Seems sensible. But that should just be in the SVG document if it has such an 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?
> >  
> > 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  
> IMHO.

Yes… maybe. Depends who you are developing for and who your market is (if I am just targeting Samsung and iPad, and I don't have my head in the "generic tablet device" space, then it might be logical to just prefix my files that… that's not to say that it's right, but sometimes bad things happen). Again, it would be interesting to know what devs are doing. We are not talking about codifying anything bad in the specs, we are just brainstorming.   

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

Good point. The CSS solution is rather elegant, but adds a whole new dimension of complexity.

Received on Tuesday, 13 December 2011 20:39:19 UTC