Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

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