Re: [css-device-adapt] CSS Device Adaptation and legacy meta tags and doctypes

On Fri, 25 May 2012 01:02:57 +0200, Kenneth Rohde Christiansen  
<kenneth.christiansen@gmail.com> wrote:

> Hi there,
>
> TabAtkins told me that the CSS Device Adaption spec changed hands, so
> I am adding the new editors to this thread.

I've seen it, just haven't gotten around to investigate yet, sorry about  
that.

I filed the issue as <http://www.w3.org/Style/CSS/Tracker/issues/253> now.

>>> Test: \ Browser:|Android|Chrome |Firefox|  IE   | Nokia | Opera  
>>> |Safari |
>>> ----------------+-------+-------+-------+-------+-------+-------+-------+
>>> Default         |  980  |  980  |  800? | 1024  |  980  |  980? |  980  
>>>  |
>>> XHTML-MP        |  320  |  320  |  320  |  320  |  320  |  320  |  320  
>>>  |
>>> HandheldFriendly|  320  |  320  |  800? |  320  |  320  |  980? |  980  
>>>  |
>>> MobileOptimized |  320  |  320  |  800? |  320  |  320  |  980? |  980  
>>>  |

>>> It seems that all browsers already treat the XHTML-MP doctype as  
>>> equivalent
>>> to a width=device-width viewport, so I agree with Kenneth that it  
>>> would make
>>> sense for the Device Adaptation spec to explicitly formalize this  
>>> defacto
>>> standard in a normative section.

Maybe it should set "zoom: 1" by default instead, in case the browser  
doesn't fill the entire width of the screen? I guess the only the highest  
priority "hint" has an effect, and that the individual parts (width,  
zoom/scale...) don't cascade separately.

Given that this is markup stuff, I'm unsure if it is appropriate as  
normative text in a CSS spec. The existing <meta name="viewport"> mapping  
is currently in a non-normative section. All these <meta>/doctype variants  
could be viewed as factors influencing the UA stylesheet, which has never  
been normative in CSS. (But maybe it should have been.)

>>> Handling of legacy HandheldFriendly and MobileOptimized viewport tags  
>>> is
>>> less consistent, but adding these to the specification could also be  
>>> useful,
>>> to improve interoperability.

I suppose a suggested order of priority could be added, but I'm not sure  
if it's worth going into more detail than that. I wouldn't expect much  
legacy content using this (and not also using viewport meta) - am I wrong?

>>> In both cases the order of precedence Kenneth suggested (whereby modern
>>> standards override legacy ones, irrespective of document order) seems  
>>> wise,
>>> as it reduces the risk of supporting the legacy methods.

On first glance, the priorities look sensible to me, at least.

-- 
Øyvind Stenhaug
Core Norway, Opera Software ASA

Received on Friday, 25 May 2012 13:28:42 UTC