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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
