[Webkit-unassigned] [Bug 45443] [GTK] Support for viewport meta tag

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=45443





--- Comment #61 from Gustavo Noronha (kov) <gns at gnome.org>  2010-11-16 04:35:25 PST ---
(In reply to comment #59)
> > * viewport-attributes-recompute-requested is emitted, giving the application the possibility of providing available size, and even override screen size if required
> 
> It seems quite good that adding the viewport-attributes-recompute-requested signal allows the user to override the screenWidth/height and availableWidth/height.
> However, according to the viewport meta-tag spec, the device-width/height keyword is used instead of the screen-width/height. So, I think that using the device-width/height would avoid confusion for the developers.

Sounds good to me =).

> 
> > * Qt uses a hardcoded DPI of 160, why is that?
> I'm not sure, but Nokia device may use the value.
> 
> Is it wrong to call webViewGetDPI() to set the deviceDPI value basically? 

I have no idea =(. I would follow Qt and change it later if required, in this case, I believe.

> > * www.engadget.com seems to work fine, except it has scrolling 100% of the time, probably because our calculation will have to take the space occupied by the scrollbars into account =(
> > * most sites apparently do some crazy stuff, providing very big width and height values, and a very small scale factor - it looks like using full content zoom alone is not enough!
> 
> Your patch related to GtkLauncher doesn't scale web pages if the web pages don't have viewport meta tags. So, do you mean that you tested the web sites, which have viewport meta tags?
> In case of apple.com, it has viewport meta tags, and works well.

Yes, I only tested sites with viewport meta tags. This one, for instance:

http://www.iui-js.org/samples/prefs.html

It doesn't work as I expected it would.

> > * full content zoom fails miserably at resizing text in http://touch.facebook.com/, which is not fun
> 
> Most mobile sites for the iPhone are not zoomed-in/out because user-scalable = 0 as follows,
> 
> <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" /> 

Right, I see, so that means for touch.facebook.com we should not zoom?

> > So, do you guys see any trouble with this API? What use cases are not covered? What was better in the previous approach?
> 
> We need to let the desktopWidth, deviceDPI also be overridden, because there would be some cases for the user to set these values manually.

Sure! Just need to make them properties, and they can be overriden in viewport-attributes-recompute-requested =)

> Thanks kov, your patch improved my patch so much.

\o/ hopefully we'll get this in soon now, feel free to make the changes you suggested (use device instead of screen for the name, and add desktopWidth/deviceDPI as properties), and I'll get it reviewed once more =D

(In reply to comment #60)
> > * Qt uses a hardcoded DPI of 160, why is that?
> 
> It is the dpi of the original iPhone and Android devices, so that it what web authors has been designing for.

I see. So perhaps we should go with it indeed.

> > * most sites apparently do some crazy stuff, providing very big width and height values, and a very small scale factor - it looks like using full content zoom alone is not enough!
> 
> Are you using ; in  the  metatag instead of , ? I had that issue on facebook etc. Google Android used to support ; but they say that they have removed that support.

This is the meta tag in the page I mentioned above:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>

So perhaps what is wrong is we should not use zoom at all because user-scalable is 0 (the viewport computation says we should scale to 0.25 for some reason!).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.