[webkit-dev] Default viewport value on WAP DTDs

Wed May 9 03:54:31 PDT 2012

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.christiansen at 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 <ojan at chromium.org> wrote:
>> On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima <hugo.lima at openbossa.org>
>> wrote:
>>>
>>> On Tuesday, May 08, 2012 07:22:17 PM John Mellor wrote:
>>> > Both Chrome for Android and the legacy Android Browser do what Hugo
>>> > described, i.e. we default to a widthÞvice-width viewport* when an
>>>
>>> > XHTML-MP doctype is provided.
>>> >
>>> > And as suggested in wkbug.com/55874, we similarly default to a
>>> > widthÞvice-width viewport if a legacy HandheldFriendly meta tag is
>>> > present, e.g.:
>>> >
>>> > <meta name"HandheldFriendly" content"true">
>>>
>>> >
>>> > and if a legacy MobileOptimized meta tag is present then we will use a
>>> > viewport with the width provided, e.g. if the following tag is present:
>>> >
>>> > <meta name"MobileOptimized" content"240">
>>> >
>>> > we will treat that the same as a "width$0" viewport tag (though IIRC the
>>>
>>> > legacy Android Browser ignored the provided width and just treated it as
>>> > device-width).
>>> >
>>> > However note that we give these implicit viewport declarations lower
>>> > priority than actual viewport meta tags, so irrespective of the order
>>> > they
>>> > appear in the document, a viewport meta tag will override any behaviour
>>> > we
>>> > infer from the doctype or those legacy meta tags.
>>> >
>>> > We do all this because some number of legacy sites depend on this
>>> > behaviour. I'm afraid we don't know how common these sites still are;
>>> > but
>>> > these heuristics have never seemed to cause us any problems.
>>> >
>>> > It makes sense to propose standardizing the XHTML-MP behaviour on
>>> > www-style
>>> > since I agree with Kenneth that this is something that should be covered
>>> > by
>>> > the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a
>>> > good place to try and standardize how we deal with legacy mobile meta
>>> > tags.
>>> > And we'd be happy to see any of these heuristics incorporated into
>>> > WebKit (either before or after they get standardized) so we don't need
>>> > to
>>> > fork them.
>>>
>>> Kenneth pointed that the XHTML-MP behavior is already on the spec, but on
>>> a
>>> non normative section, the introduction:
>>>
>>> "Certain DOCTYPEs (for instance XHTML Mobile Profile) are used to
>>> recognize
>>> mobile documents which are assumed to be designed for handheld devices,
>>> hence
>>> using the viewport size as the initial containing block size."
>>>
>>> on http://www.w3.org/TR/css-device-adapt/
>>
>>
>> I see. Given this and the fact that Android already does this, I think this
>> change is fine. Do any Apple/iOS folk object?
>>
>> The Android behavior seems a little more conservative to me, so I'd prefer
>> if we did that (e.g. don't mess with zooming). We should make the most
>> minimal change we can to optimize compatibility.
>>
>> Before making this change, I'd still like to see discussion on www-style for
>> this. Specifically, it would be good for this to move to a normative section
>> and to be more concretely specified. This open-ended language is not useful
>> for actually achieving interoperability across mobile browser vendors. It
>> should say specifically which doctypes and how it relates to the viewport
>> meta tag. Again, I prefer the Android behavior here of always having the
>> viewport meta tag win.
>>
>> Speaking of which, given the note in the spec, has there already been
>> discussion on www-style about this?
>>
>> Ojan
>>
>>>
>>>
>>>
>>> > Cheers,
>>> > John
>>> >
>>> > *: (unlike Hugo's current patch, we don't add "initial-scale1.0,
>>> > user-scalableno", just "widthÞvice-width", since there doesn't seem to
>>>
>>> > be any reason to assume that XHTML-MP sites want to disable zooming, and
>>> > it
>>> > may actually lead to a worse user experience).
>>>
>>> You are right, setting just the width should be enough.
>>>
>>> > On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen <
>>> >
>>> > kenneth.christiansen at gmail.com> wrote:
>>> > > Hi there,
>>> > >
>>> > > On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai <ojan at 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
>>> > > > whatwg at whatwg.org for the HTML spec and www-style at 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.christiansen at gmail.com> wrote:
>>> > > >> Nokia actually looked into this about a year ago and we homogenized
>>> > > >> our UA strings across our different devices, so that we could start
>>> > > >> to
>>> > > >> tell contents providers to give us the best content supported by
>>> > > >> our
>>> > > >> browsers. Part of this work was actually simplifying our UA string
>>> > > >> so
>>> > > >> much as possible and it is actually quite similar to what you are
>>> > > >> using today.
>>> > > >>
>>> > > >> The user agent for the N9 browser, for inst
>>> nce, is:
>>> > > >>
>>> > > >> Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko)
>>> > > >> NokiaBrowser/8.5.0 Mobile Safari/534.13
>>> > > >>
>>> > > >> The problem is not just the user agent. For instance the user agent
>>> > > >> is
>>> > > >> known by your Google, and we did pass validation for Tier 1 YouTube
>>> > > >> content, but the Google search team, as far as I heard, decided
>>> > > >> that
>>> > > >> we didn't have enough market penetration for them to turn on Tier 1
>>> > > >> content for us, and serves us the XHTML-MP (Tier 3?) content
>>> > > >> instead.
>>> > > >>
>>> > > >> As far as I understand, the decision comes from that team not
>>> > > >> wanting
>>> > > >> to dedicate resources to make sure the Tier 1 content keeps working
>>> > > >> on
>>> > > >> our device. I totally understand their reasoning and decision, but
>>> > > >> it
>>> > > >> is a saddens me given the promise of the open web and HTML5. It is
>>> > > >> even more sad that this is not a unique case and it will only be
>>> > > >> solved the day content providers stop looking at the user agent
>>> > > >> strings.
>>> > >
>>> >>
>>> > > >> Kenneth
>>> > > >>
>>> > > >> On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai <ojan at 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.lima at 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.christiansen at gmail.com> wrote:
>>> > > >> >> > > This is not supporting XHTML-MP, as we are not implementing
>>> > > >> >> > > anything
>>> > > >> >> > > special to support it. We are basically showing the content
>>> > > >> >> > > as
>>> > >
>>> >> >> > > it
>>> > > >> >> > > was
>>> > > >> >> > > HTML5 and that solves most real use-cases. Injecting a
>>> > > >> >> > > proper
>>> > > >> >> > > viewport
>>> > > >> >> > > configuration makes it also layout properly.
>>> > > >> >> >
>>> > > >> >> > Okay. Is this change observable by the page? Or more
>>> > > >> >> > specifically,
>>> > > >> >> > can a
>>> > > >> >> > web page currently feature-detect whether a given browser
>>> > > >> >> > support
>>> > > >> >> > XHTML-MP
>>> > > >> >> > by checking the size of the viewport?
>>> > > >> >>
>>> > > >> >> The page knows nothing, just as it knows nothing about the ~980
>>> > >
>>> > > pixels
>>> > >
>>> > > >> >> used
>>> > > >> >> for the canvas width, it's a matter of change a magic value to
>>> > > >> >> the
>>> > > >> >> device-
>>> > > >> >> width to get websites better looking.
>>> > > >> >>
>>> > > >> >> I attached screenshots of MiniBrowser runnin with and without
>>> > > >> >> the
>>> > >
>>> > > patch
>>> > >
>>> > > >> >> using:
>>> > > >> >>
>>> > > >> >> MiniBrowser --window-size 480x720 http://m.yahoo.com
>>> > > >> >>
>>> > > >> >> Without patch (viewport of 980 pixels):
>>> > > >> >> https://bug
>>> 85425-attachments.webkit.org/attachment.cgi?id 0272
>>>
>>> > > >> >> Patched (viewport of 880 pixels)
>>> > > >> >> https://bug-85425-attachments.webkit.org/attachment.cgi?id 0273
>>>
>>> > > >> >>
>>> > > >> >> > If the answer is yes, then we'll be breaking the feature
>>> > > >> >> > detection.
>>> > > >> >> >
>>> > > >> >> > Unfortunately most unknown mobile browsers tend to get lots of
>>> > > >> >> >
>>> > > >> >> > > XHTML-MP. Heck, we even get that for google.com on the Nokia
>>> > > >> >> > > N9
>>> > > :
>>> > > :-(
>>> > > :
>>> > > >> >> > > as
>>> > > >> >> > > well as other high profile sites.
>>> > > >> >> >
>>> > > >> >> > Yeah, it's very unfortunate.
>>> > > >> >> >
>>> > > >> >> > This makes the sites render acceptable, until we can advocate
>>> > > >> >> > the
>>> > > >> >> >
>>> > > >> >> > > sites to accept our user agent, something which we haven't
>>> > > >> >> > > always
>>> > > >> >> > > had
>>> > > >> >> > > luck with. Google for one didn't want to provide us the Tier
>>> > > >> >> > > 1
>>> > >
>>> > > site
>>> > >
>>> > > >> >> > > of
>>> > > >> >> > > google.com on the N9, even though it works a lot better t
>>> an the
>>> > > >> >> > > XHTML-MP version we are being served. I don't see this
>>> > > >> >> > > situation
>>> > > >> >> > > change any time soon.
>>> > > >> >> >
>>> > > >> >> > Can we work-around this issue by faking the user agent string?
>>> > > >> >>
>>> > > >> >> If you are working on your own browser you wont be telling every
>>> > > >> >> website
>>> > > >> >> that
>>> > > >> >> you are a iPhone forever, at least you will not be happy doing
>>> > > >> >> that.
>>> > > >> >>
>>> > > >> >> Regards.
>>> > > >> >> Hugo Parente Lima
>>> > > >> >>
>>> > > >> >> _______________________________________________
>>> > > >> >> webkit-dev mailing list
>>> > > >> >> webkit-dev at lists.webkit.org
>>> > > >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> > > >> >
>>> > > >> > _______________________________________________
>>> > > >> > webkit-dev mailing list
>>> > > >> > webkit-dev at lists.webkit.org
>>> > > >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> > > >>
>>> > > >> --
>>> > > >> Kenneth Rohde Christiansen
>>> > > >> Senior Engineer
>>> > > >> Nokia Mobile Phones, Browser / WebKit
>>> eam
>>> > > >> Phone  +45 4093 0598 / E-mail kenneth at webkit.org
>>> > > >>
>>> > > >> http://codeposts.blogspot.com ﹆﹆﹆
>>> > >
>>> > > --
>>> > > Kenneth Rohde Christiansen
>>> > > Senior Engineer
>>> > > Nokia Mobile Phones, Browser / WebKit team
>>> > > Phone  +45 4093 0598 / E-mail kenneth at webkit.org
>>> > >
>>> > > http://codeposts.blogspot.com ﹆﹆﹆
>>> > > _______________________________________________
>>> > > webkit-dev mailing list
>>> > > webkit-dev at lists.webkit.org
>>> > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
> --
> Kenneth Rohde Christiansen
> Senior Engineer
> Nokia Mobile Phones, Browser / WebKit team
> Phone  +45 4093 0598 / E-mail kenneth at webkit.org
>
> http://codeposts.blogspot.com ﹆﹆﹆

-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ﹆﹆﹆