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

Hi there,

On Fri, May 25, 2012 at 3:27 PM, Øyvind Stenhaug <oyvinds@opera.com> wrote:
> 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.

Thanks for doing that.

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

The 980/800 seen in the browsers indicate that they don't support
those tags. So I think the mapping (when supported) is pretty clear.

>
>
>>>> 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 think that makes sense, and we believe we did similar in the N9 browser.

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

Having this in the non-normative section is fine, but at least it
should be clear how to implement this support if the browser intents
to, especially given that it is a de-facto standard.

> 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 think the order is what mostly matters, plus of course the mapping
to the viewport meta tag. Other than that I don't see how much more
detail would be needed.

> I wouldn't expect much legacy
> content using this (and not also using viewport meta) - am I wrong?

Depends on your UA string. We unfortunately saw more than we would
have liked :-)

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

Cheers
Kenneth

>
> On first glance, the priorities look sensible to me, at least.
>
> --
> Øyvind Stenhaug
> Core Norway, Opera Software ASA



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ﹆﹆﹆

Received on Saturday, 26 May 2012 08:38:10 UTC