[webkit-dev] Default viewport value on WAP DTDs

Ojan Vafai ojan at chromium.org
Fri May 4 22:12:35 PDT 2012


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.

We'll see what the response there is and can decide what to do next based
off that response. Does that sound OK?

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?

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 ﹆﹆﹆
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120504/7d5fce6c/attachment.html>


More information about the webkit-dev mailing list