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
