Hi there, Just wanted to say that I sent an email to www-style: http://lists.w3.org/Archives/Public/www-style/2012May/0371.html
Cheers, Kenneth On Tue, May 8, 2012 at 10:07 PM, Kenneth Rohde Christiansen <kenneth.christian...@gmail.com> wrote: > Hi there, > > Now that I have all this info, I will write an email to www-style this > week (hopefully tomorrow). Thanks John Mellor for clarifying what > Android does. > > Here is some info about WP7 Internet Explorer which does very similar things: > http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx > > Cheers, > Kenneth > > On Tue, May 8, 2012 at 8:58 PM, Ojan Vafai <o...@chromium.org> wrote: >> On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima <hugo.l...@openbossa.org> >> wrote: >>> >>> On Tuesday, May 08, 2012 07:22:17 PM John Mellor wrote: >>> > Both Chrome for Android and the legacy Android Browser do what Hugo >>> > described, i.e. we default to a widthÞvice-width viewport* when an >>> >>> > XHTML-MP doctype is provided. >>> > >>> > And as suggested in wkbug.com/55874, we similarly default to a >>> > widthÞvice-width viewport if a legacy HandheldFriendly meta tag is >>> > present, e.g.: >>> > >>> > <meta name"HandheldFriendly" content"true"> >>> >>> > >>> > and if a legacy MobileOptimized meta tag is present then we will use a >>> > viewport with the width provided, e.g. if the following tag is present: >>> > >>> > <meta name"MobileOptimized" content"240"> >>> > >>> > we will treat that the same as a "width$0" viewport tag (though IIRC the >>> >>> > legacy Android Browser ignored the provided width and just treated it as >>> > device-width). >>> > >>> > However note that we give these implicit viewport declarations lower >>> > priority than actual viewport meta tags, so irrespective of the order >>> > they >>> > appear in the document, a viewport meta tag will override any behaviour >>> > we >>> > infer from the doctype or those legacy meta tags. >>> > >>> > We do all this because some number of legacy sites depend on this >>> > behaviour. I'm afraid we don't know how common these sites still are; >>> > but >>> > these heuristics have never seemed to cause us any problems. >>> > >>> > It makes sense to propose standardizing the XHTML-MP behaviour on >>> > www-style >>> > since I agree with Kenneth that this is something that should be covered >>> > by >>> > the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a >>> > good place to try and standardize how we deal with legacy mobile meta >>> > tags. >>> > And we'd be happy to see any of these heuristics incorporated into >>> > WebKit (either before or after they get standardized) so we don't need >>> > to >>> > fork them. >>> >>> Kenneth pointed that the XHTML-MP behavior is already on the spec, but on >>> a >>> non normative section, the introduction: >>> >>> "Certain DOCTYPEs (for instance XHTML Mobile Profile) are used to >>> recognize >>> mobile documents which are assumed to be designed for handheld devices, >>> hence >>> using the viewport size as the initial containing block size." >>> >>> on http://www.w3.org/TR/css-device-adapt/ >> >> >> I see. Given this and the fact that Android already does this, I think this >> change is fine. Do any Apple/iOS folk object? >> >> The Android behavior seems a little more conservative to me, so I'd prefer >> if we did that (e.g. don't mess with zooming). We should make the most >> minimal change we can to optimize compatibility. >> >> Before making this change, I'd still like to see discussion on www-style for >> this. Specifically, it would be good for this to move to a normative section >> and to be more concretely specified. This open-ended language is not useful >> for actually achieving interoperability across mobile browser vendors. It >> should say specifically which doctypes and how it relates to the viewport >> meta tag. Again, I prefer the Android behavior here of always having the >> viewport meta tag win. >> >> Speaking of which, given the note in the spec, has there already been >> discussion on www-style about this? >> >> Ojan >> >>> >>> >>> >>> > Cheers, >>> > John >>> > >>> > *: (unlike Hugo's current patch, we don't add "initial-scale1.0, >>> > user-scalableno", just "widthÞvice-width", since there doesn't seem to >>> >>> > be any reason to assume that XHTML-MP sites want to disable zooming, and >>> > it >>> > may actually lead to a worse user experience). >>> >>> You are right, setting just the width should be enough. >>> >>> > On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen < >>> > >>> > kenneth.christian...@gmail.com> wrote: >>> > > Hi there, >>> > > >>> > > On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai <o...@chromium.org> wrote: >>> > > > 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 >>> > > >>> > > st >>> ndardize >>> > > >>> > > > 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 >>> > > > wha...@whatwg.org for the HTML spec and www-st...@w3.org for the CSS >>> > > >>> > > Device >>> > > >>> > > > Adaptation spec. >>> > > >>> > > I will pass it by the CSS Device Adaptation spec first as I really >>> > > think it fits there. >>> > > >>> > > > We'll see what the response there is and can decide what to do next >>> > > > based >>> > > > off that response. Does that sound OK? >>> > > >>> > > I think we will add a feature flag for now, together with layout tests >>> > > for a document with XHTML-MP doctype using and not using fixed >>> > > layouting. >>> > > >>> > > > 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 wapfor >>> m doctypes never sent to Android/iOS >>> > > >>> > > because >>> > > >>> > > > of UA-sniffing? >>> > > >>> > > It can only break browsers respecting the viewport meta and using >>> > > fixed layouting in some way, those currently mobile browsers. As far >>> > > as I heard Android and iOS are using similar tricks but they seldom >>> > > get the pages due to UA sniffing. I already tried contacting the >>> > > Android team. >>> > > >>> > > Cheers, >>> > > Kenneth >>> > > >>> > > > 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 inst >>> nce, 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 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 0272 >>> >>> > > >> >> Patched (viewport of 880 pixels) >>> > > >> >> https://bug-85425-attachments.webkit.org/attachment.cgi?id 0273 >>> >>> > > >> >> >>> > > >> >> > 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 t >>> an 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 >>> eam >>> > > >> Phone +45 4093 0598 / E-mail kenneth at webkit.org >>> > > >> >>> > > >> http://codeposts.blogspot.com ﹆﹆﹆ >>> > > >>> > > -- >>> > > 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 >>> >> >> >> _______________________________________________ >> 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 ﹆﹆﹆ -- 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