- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 30 Sep 2011 03:43:21 +0000 (UTC)
- To: Dimitri Glazkov <dglazkov@chromium.org>
- cc: Roland Steiner <rolandsteiner@chromium.org>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>
On Thu, 29 Sep 2011, Dimitri Glazkov wrote: > > c) an API to manipulate the layout programmatically (turn page, advance > to next panel, etc.) [...] > > Once you're operating on the layout programmatically, you need logical > primitives that explain and expose the functionality of a layout manager > to DOM scripting. You need DOM objects that are Panes, Containers, > Splitters, etc. In this case, you have to go with element behavior > attachment. I strongly disagree that we should support this specific use case as described. It is bringing media-specific concerns into the logic layer, which is a layering violation and would lead to authors writing inaccessible applications, e.g. "magazines" that are only readable on a visual medium and that either completely break down in non-visual mediums, or force users of non-visual mediums to interact with the content in a physical manner more constrained by the physical metaphor in the visual presentation than the logical structure of the content. We should never be in a world where it's considered ok for a Web page to ask a user using a speech browser to hit "next page" half way through a sentence, for example. A speech browser simply has no use for pagination. I think it would make plenty of sense for such a binding to be an entirely self-contained (no API) presentational binding which included *as part of the binding* the next page / previous page buttons. But those buttons have no place in the content itself, and therefore there would be no need for an API in such a binding. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 30 September 2011 03:46:34 UTC