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.christian...@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 <o...@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.l...@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.christian...@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@lists.webkit.org > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > > > > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
