[webkit-dev] Default viewport value on WAP DTDs

Ojan Vafai ojan at chromium.org
Fri May 4 14:32:14 PDT 2012

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.


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

More information about the webkit-dev mailing list