[webkit-dev] EditBug permission
Hi, Could someone please add EditBug permission to my bugs.webkit.org account? I have landed several patches already (mostly for EFL port) and it would be nice if I could assign bugs to me. My account login is: christophe.dumez (at) intel.com Thanks in advance, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EditBug permission
Could someone please add EditBug permission to my bugs.webkit.org (http://bugs.webkit.org/) account? Done. -Adam ___ 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
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
