Re: [webkit-dev] Default viewport value on WAP DTDs
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 nameHandheldFriendly contenttrue 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 nameMobileOptimized content240 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
Re: [webkit-dev] Default viewport value on WAP DTDs
On Fri, 2012-05-04 at 23:18 -0700, Martin Robinson wrote: We chose between faking Chromium or faking OS X on all operating systems. We are now a port of Chromium called WebKitGTK+. I don't see any easy way out of this mess. Me neither. Also 'Safari on Linux' was being seen as Android, it seems, by some sites. Even with all of that work some sites still refuse to work or hand us dumbed down content, Google properties included. The only solution to the mess seems to be to fake U-A indeed. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
Both Chrome for Android and the legacy Android Browser do what Hugo described, i.e. we default to a width=device-width viewport* when an XHTML-MP doctype is provided. And as suggested in wkbug.com/55874, we similarly default to a width=device-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=240 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. Cheers, John *: (unlike Hugo's current patch, we don't add initial-scale=1.0, user-scalable=no, just width=device-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). 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 standardize 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 wapforum 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 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:
Re: [webkit-dev] Default viewport value on WAP DTDs
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/ Cheers, John *: (unlike Hugo's current patch, we don't add initial-scale=1.0, user-scalable=no, 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
Re: [webkit-dev] Default viewport value on WAP DTDs
On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima hugo.l...@openbossa.orgwrote: 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 nameHandheldFriendly contenttrue 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 nameMobileOptimized content240 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
Re: [webkit-dev] Default viewport value on WAP DTDs
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 nameHandheldFriendly contenttrue 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 nameMobileOptimized content240 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
Re: [webkit-dev] Default viewport value on WAP DTDs
On Fri, May 4, 2012 at 2:32 PM, Ojan Vafai o...@chromium.org wrote: 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. It seems that the web has changed since then. Recently we found that constructing a version string similar to the Chromium user agent (except replacing Chromium with Epiphany or WebKitGTK+) triggered the you are Safari, but not Safari desktop path in Typekit, thus breaking custom fonts on many sites. Experimentation suggested that Typekit had three separate paths: 1. Safari with the OS X in the first parenthesis - Safari desktop - fonts on 2. Safari with something else in the first parenthesis - Safari mobile - fonts off 3. Safari with something else in the first parenthesis, but also including the string Chrome/Chromium - Chromium - fonts on We chose between faking Chromium or faking OS X on all operating systems. We are now a port of Chromium called WebKitGTK+. I don't see any easy way out of this mess. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
That won't make a difference, but sure, let's do that. :-) The reason why it doesn't matter is that the desktop browser are not using fixed layout and are thus laying our given the actual viewport dimensions. Even with the flag we should make tests to ensure these two cases. Cheers, Kenneth On Sat, May 5, 2012 at 4:47 AM, Ryosuke Niwa rn...@webkit.org wrote: 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
Re: [webkit-dev] Default viewport value on WAP DTDs
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 standardize 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 wapforum 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 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 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
Re: [webkit-dev] Default viewport value on WAP DTDs
03.05.2012, в 13:46, Hugo Parente Lima написал(а): !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN http://www.wapforum.org/DTD/xhtml-mobile10.dtd; The proposed patch changes the magic value of 980 pixels to device-width when this doctype is found causing the website to render nicely if the device screen is small, i.e. don't show the website in a 980 pixels canvas zoomed out to fit the 980 pixels screen. Some webkit browsers already use this hack, like the N9 browser and if I understood correctly by the Zalan comments on the bug, the iOS Safari too. I think that introduction of new doctype based modes should go through HTML5 first - if WebKit needs this, then other browsers need it, too. Also, it's not clear what the distinction between mobile and non-mobile is. Is Safari on an 11 MacBook Air a mobile browser? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
I think this relates more to the CSS Device Adaptation spec. Desktop browser so far ignores the viewport meta tag, where as mobile browsers do not. The thing is that a default viewport information is inserted when the viewport meta tag is missing, which most current mobile browsers then layouts using a width of around 980 (can differ from browser to browser). This is done as it handles desktop pages quite well. Most XHTML-MP pages on the other hand assume that they are being laid out using the width of the mobile device, which is often far lower then 980 (especially as high resolution mobile devices adjust the device-pixel-ratio). Kenneth On Fri, May 4, 2012 at 6:01 PM, Alexey Proskuryakov a...@webkit.org wrote: 03.05.2012, в 13:46, Hugo Parente Lima написал(а): !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN http://www.wapforum.org/DTD/xhtml-mobile10.dtd; The proposed patch changes the magic value of 980 pixels to device-width when this doctype is found causing the website to render nicely if the device screen is small, i.e. don't show the website in a 980 pixels canvas zoomed out to fit the 980 pixels screen. Some webkit browsers already use this hack, like the N9 browser and if I understood correctly by the Zalan comments on the bug, the iOS Safari too. I think that introduction of new doctype based modes should go through HTML5 first - if WebKit needs this, then other browsers need it, too. Also, it's not clear what the distinction between mobile and non-mobile is. Is Safari on an 11 MacBook Air a mobile browser? - WBR, Alexey Proskuryakov ___ 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
Re: [webkit-dev] Default viewport value on WAP DTDs
I don't think we want to support XHTML-MP. We finally got rid of WML after years of discussions and attempts. If we were to accept this patch, I'd like to see a broader discussion about whether we want to support XHTML-MP or not first. - Ryosuke On Thu, May 3, 2012 at 1:46 PM, Hugo Parente Lima hugo.l...@openbossa.orgwrote: Hi, I was pointed to trigger a discussion here about the patch: https://bugs.webkit.org/show_bug.cgi?id=85425 I'll try to resume to issue: If no viewport is specified webkit uses the magic and well know value of 980 pixels for the canvas width, this value is very good for most websites developed for desktop usage, on the other side there are the websites[1] developed for small screen mobile devices. Those websites will look pretty ugly on a 980 pixels canvas, many of those websites uses a different DTD like: !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN http://www.wapforum.org/DTD/xhtml-mobile10.dtd; The proposed patch changes the magic value of 980 pixels to device-width when this doctype is found causing the website to render nicely if the device screen is small, i.e. don't show the website in a 980 pixels canvas zoomed out to fit the 980 pixels screen. Some webkit browsers already use this hack, like the N9 browser and if I understood correctly by the Zalan comments on the bug, the iOS Safari too. Comments about why the viewport width should or shouldn't be changed by the doc type is appreciated. Thanks! Regards Hugo Parente Lima [1] http://m.yahoo.com; http://www.google.com (using a user agent like: Nokia 7110/1.0) ___ 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
Re: [webkit-dev] Default viewport value on WAP DTDs
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. 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. 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. Cheers, Kenneth On Fri, May 4, 2012 at 6:31 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't think we want to support XHTML-MP. We finally got rid of WML after years of discussions and attempts. If we were to accept this patch, I'd like to see a broader discussion about whether we want to support XHTML-MP or not first. - Ryosuke On Thu, May 3, 2012 at 1:46 PM, Hugo Parente Lima hugo.l...@openbossa.org wrote: Hi, I was pointed to trigger a discussion here about the patch: https://bugs.webkit.org/show_bug.cgi?id=85425 I'll try to resume to issue: If no viewport is specified webkit uses the magic and well know value of 980 pixels for the canvas width, this value is very good for most websites developed for desktop usage, on the other side there are the websites[1] developed for small screen mobile devices. Those websites will look pretty ugly on a 980 pixels canvas, many of those websites uses a different DTD like: !DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN http://www.wapforum.org/DTD/xhtml-mobile10.dtd; The proposed patch changes the magic value of 980 pixels to device-width when this doctype is found causing the website to render nicely if the device screen is small, i.e. don't show the website in a 980 pixels canvas zoomed out to fit the 980 pixels screen. Some webkit browsers already use this hack, like the N9 browser and if I understood correctly by the Zalan comments on the bug, the iOS Safari too. Comments about why the viewport width should or shouldn't be changed by the doc type is appreciated. Thanks! Regards Hugo Parente Lima [1] http://m.yahoo.com; http://www.google.com (using a user agent like: Nokia 7110/1.0) ___ 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
Re: [webkit-dev] Default viewport value on WAP DTDs
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? 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? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
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=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 signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
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.orgwrote: 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=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
Re: [webkit-dev] Default viewport value on WAP DTDs
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 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
Re: [webkit-dev] Default viewport value on WAP DTDs
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.
Re: [webkit-dev] Default viewport value on WAP DTDs
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 standardize 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. We'll see what the response there is and can decide what to do next based off that response. Does that sound OK? 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 wapforum doctypes never sent to Android/iOS because of UA-sniffing? 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 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
