[webkit-dev] Default viewport value on WAP DTDs

Fri May 4 19:47:27 PDT 2012

In that case, please add a feature flag that defaults to false since I
don't think we want to turn this feature on on desktop browsers.

- Ryosuke

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
> Software Engineer
> Google Inc.
>
>
> 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 ﹆﹆﹆
> _______________________________________________
> 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/20120504/099298ab/attachment.html>