[webkit-dev] Default viewport value on WAP DTDs

Tue May 8 11:22:17 PDT 2012

Both Chrome for Android and the legacy Android Browser do what Hugo
described, i.e. we default to a width=device-width viewport* when an
XHTML-MP doctype is provided.

And as suggested in wkbug.com/55874, we similarly default to a
width=device-width viewport if a legacy HandheldFriendly meta tag is
present, e.g.:

<meta name="HandheldFriendly" content="true">

and if a legacy MobileOptimized meta tag is present then we will use a
viewport with the width provided, e.g. if the following tag is present:

<meta name="MobileOptimized" content="240">

we will treat that the same as a "width=240" viewport tag (though IIRC the
legacy Android Browser ignored the provided width and just treated it as
device-width).

However note that we give these implicit viewport declarations lower
priority than actual viewport meta tags, so irrespective of the order they
appear in the document, a viewport meta tag will override any behaviour we
infer from the doctype or those legacy meta tags.

We do all this because some number of legacy sites depend on this
behaviour. I'm afraid we don't know how common these sites still are; but
these heuristics have never seemed to cause us any problems.

It makes sense to propose standardizing the XHTML-MP behaviour on www-style
since I agree with Kenneth that this is something that should be covered by
the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a
good place to try and standardize how we deal with legacy mobile meta tags.
And we'd be happy to see any of these heuristics incorporated into
WebKit (either before or after they get standardized) so we don't need to
fork them.

Cheers,
John

*: (unlike Hugo's current patch, we don't add "initial-scale=1.0,
user-scalable=no", just "width=device-width", since there doesn't seem to
be any reason to assume that XHTML-MP sites want to disable zooming, and it
may actually lead to a worse user experience).

On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen <
kenneth.christiansen at gmail.com> wrote:

> Hi there,
>
> On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai <ojan at chromium.org> wrote:
> > I see. That's unfortunate. I don't really know the best path forward
> here.
> > I'm inclined to agree with Alexey that we should at least try to
> standardize
> > this before committing code. It's not clear to me where this should be
> > specced. Easiest path forward is to make this proposal to both
> > whatwg at whatwg.org for the HTML spec and www-style at w3.org for the CSS
> Device
> > Adaptation spec.
>
> I will pass it by the CSS Device Adaptation spec first as I really
> think it fits there.
>
> > We'll see what the response there is and can decide what to do next based
> > off that response. Does that sound OK?
>
> I think we will add a feature flag for now, together with layout tests
> for a document with XHTML-MP doctype using and not using fixed
> layouting.
>
> > I'm reluctant to make a change like this, but it sounds like there might
> not
> > be a better choice. One concern I have is how many sites would break due
> to
> > this behavior? For example, will this fix sites on N9, but break them on
> > Android/iOS or are these wapforum doctypes never sent to Android/iOS
> because
> > of UA-sniffing?
>
> It can only break browsers respecting the viewport meta and using
> fixed layouting in some way, those currently mobile browsers. As far
> as I heard Android and iOS are using similar tricks but they seldom
> get the pages due to UA sniffing. I already tried contacting the
> Android team.
>
> Cheers,
> Kenneth
> > On Fri, May 4, 2012 at 3:39 PM, Kenneth Rohde Christiansen
> > <kenneth.christiansen at gmail.com> wrote:
> >>
> >> Nokia actually looked into this about a year ago and we homogenized
> >> our UA strings across our different devices, so that we could start to
> >> tell contents providers to give us the best content supported by our
> >> browsers. Part of this work was actually simplifying our UA string so
> >> much as possible and it is actually quite similar to what you are
> >> using today.
> >>
> >> The user agent for the N9 browser, for instance, is:
> >>
> >> Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko)
> >> NokiaBrowser/8.5.0 Mobile Safari/534.13
> >>
> >> The problem is not just the user agent. For instance the user agent is
> >> known by your Google, and we did pass validation for Tier 1 YouTube
> >> content, but the Google search team, as far as I heard, decided that
> >> we didn't have enough market penetration for them to turn on Tier 1
> >> content for us, and serves us the XHTML-MP (Tier 3?) content instead.
> >>
> >> As far as I understand, the decision comes from that team not wanting
> >> to dedicate resources to make sure the Tier 1 content keeps working on
> >> our device. I totally understand their reasoning and decision, but it
> >> is a saddens me given the promise of the open web and HTML5. It is
> >> even more sad that this is not a unique case and it will only be
> >> solved the day content providers stop looking at the user agent
> >> strings.
> >>
> >> Kenneth
> >>
> >> On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai <ojan at chromium.org> wrote:
> >> > Instead of UA faking, is it possible for you to pick an actual UA
> string
> >> > that is more compatible with the web at large? For Chromium we
> >> > experimented
> >> > with making the most minimal UA string possible without a big loss in
> >> > web
> >> > compatibility. To our disappointment, we found we had to match the
> >> > Safari UA
> >> > string almost exactly. Our current UA string is "Mozilla/5.0 (X11;
> Linux
> >> > x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1096.1
> >> > Safari/536.6". The parts that we found to be safe to change are the
> >> > platform
> >> > names in the first sent of parenthesis. The version number after
> >> > AppleWebKit. And the Chrome/versionNumber section. Even getting rid of
> >> > the
> >> > Safari/versionNumber caused us significant web compatibility problems.
> >> >
> >> > That said, we did all this testing in 2008. The web may have changed
> >> > considerably since then. In either case, if your UA string diverges
> too
> >> > much, I expect this problem will just be the tip of the iceberg of
> >> > compatibility problems you'll encounter. So it might be worth
> >> > considering
> >> > changing your UA string before trying to add new DocType switching
> >> > behavior.
> >> >
> >> > Ojan
> >> >
> >> > On Fri, May 4, 2012 at 10:53 AM, Hugo Parente Lima
> >> > <hugo.lima at openbossa.org>
> >> > wrote:
> >> >>
> >> >> On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote:
> >> >> > On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen <
> >> >> >
> >> >> > kenneth.christiansen at gmail.com> wrote:
> >> >> > > This is not supporting XHTML-MP, as we are not implementing
> >> >> > > anything
> >> >> > > special to support it. We are basically showing the content as it
> >> >> > > was
> >> >> > > HTML5 and that solves most real use-cases. Injecting a proper
> >> >> > > viewport
> >> >> > > configuration makes it also layout properly.
> >> >> >
> >> >> > Okay. Is this change observable by the page? Or more specifically,
> >> >> > can a
> >> >> > web page currently feature-detect whether a given browser support
> >> >> > XHTML-MP
> >> >> > by checking the size of the viewport?
> >> >>
> >> >> The page knows nothing, just as it knows nothing about the ~980
> pixels
> >> >> used
> >> >> for the canvas width, it's a matter of change a magic value to the
> >> >> device-
> >> >> width to get websites better looking.
> >> >>
> >> >> I attached screenshots of MiniBrowser runnin with and without the
> patch
> >> >> using:
> >> >>
> >> >> MiniBrowser --window-size 480x720 http://m.yahoo.com
> >> >>
> >> >> Without patch (viewport of 980 pixels):
> >> >> https://bug-85425-attachments.webkit.org/attachment.cgi?id=140272
> >> >> Patched (viewport of 880 pixels)
> >> >> https://bug-85425-attachments.webkit.org/attachment.cgi?id=140273
> >> >>
> >> >>
> >> >> > If the answer is yes, then we'll be breaking the feature detection.
> >> >> >
> >> >> > Unfortunately most unknown mobile browsers tend to get lots of
> >> >> >
> >> >> > > XHTML-MP. Heck, we even get that for google.com on the Nokia N9
> :-(
> >> >> > > as
> >> >> > > well as other high profile sites.
> >> >> >
> >> >> > Yeah, it's very unfortunate.
> >> >> >
> >> >> > This makes the sites render acceptable, until we can advocate the
> >> >> >
> >> >> > > sites to accept our user agent, something which we haven't always
> >> >> > > had
> >> >> > > luck with. Google for one didn't want to provide us the Tier 1
> site
> >> >> > > of
> >> >> > > google.com on the N9, even though it works a lot better than the
> >> >> > > XHTML-MP version we are being served. I don't see this situation
> >> >> > > change any time soon.
> >> >> >
> >> >> > Can we work-around this issue by faking the user agent string?
> >> >>
> >> >> If you are working on your own browser you wont be telling every
> >> >> website
> >> >> that
> >> >> you are a iPhone forever, at least you will not be happy doing that.
> >> >>
> >> >> Regards.
> >> >> Hugo Parente Lima
> >> >>
> >> >> _______________________________________________
> >> >> webkit-dev mailing list
> >> >> webkit-dev at lists.webkit.org
> >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > webkit-dev mailing list
> >> > webkit-dev at lists.webkit.org
> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> >
> >>
> >>
> >>
> >> --
> >> 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 ﹆﹆﹆
> >
> >
>
>
>
> --
> 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 ﹆﹆﹆
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120508/75c25213/attachment.html>