[webkit-dev] Default viewport value on WAP DTDs

Hugo Parente Lima hugo.lima at openbossa.org
Fri May 4 14:55:46 PDT 2012


On Friday, May 04, 2012 02:32:14 PM Ojan Vafai 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.

IMO this is almost the same of UA faking and doesn't fix the problem for 
websites that doesn't serves different contents based on UA string.

Regards.
Hugo Parente Lima
 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120504/66452405/attachment.bin>


More information about the webkit-dev mailing list