[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 #35 from Gustavo Noronha (kov) <gns at gnome.org>  2010-10-19 07:30:33 PST ---
(In reply to comment #22)
> > As Kenneth said, when the size of the viewport is changed, we need to compute the optimal viewport configuration again. Therefore, there should be a way of accessing the viewportConfig via the view like getting the WindowFeatures.
> 
> Be careful what you call the viewport. There is the actual visible viewport (which might grow, like when the address bar scrolls out on the iphone) and there is the layout viewport.
> 
> When calculating the "viewport features", as you are calling it, we need the minimum actual visible viewport as input and it will output the actual layout viewport, plus min, max, initial scale etc.

OK, let me try to describe this process so my thinking is clearer:

Say you load a page that has a viewport tag. ChromeClient::dispatchViewportDataDidChange will eventually be called. At this point you will want to know the following:

The size of the screen (deviceHeigh/deviceWidth), the size of the are visible to the user (availableWidth/availableHeight), the screen DPI, the "desktop width", so that you can provide WebCore::computeViewportAttributes with them.

Screen size and DPI should be obtainable automatically. I don't see a point in only providing available width and height when you call compute manually and using the contents size in the automatic computation, and I'm really lost on the meaning of desktop width to be honest.

So what I'm thinking is this:

1. We provide a viewport-attributes-changed signal in the view; while handling that signal you have to feed the ViewportAttributes with the data it requires for the computation by setting properties on it - after handling this you just need to get the ViewportAttributes object that is owned by the view and make use of the computed values as needed; we can have a viewport-attributes-available signal in the ViewportAttributes object, or a state tracking enum that we can monitor for notify signals
2. We throw away webkit_web_view_set_viewport_attributes and webkit_viewport_attributes_computation entirely

Are there any use cases that would not be covered by this that you can see? I think it makes the API more elegant and simple.

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