Re: overflowing content handling - was (Re: Positioned Layout proposal)

> Shelby Moore wrote:
>>>> Perhaps I can allocate more time thinking about this at some point,
>>>> because CSS as it is now really frustrates me. The tsuris seems mostly
>>>> to
>>>> revolve around the fact that CSS is not designed to support the new
>>>> Web
>>>> applications which want to keep all their content inside the viewport
>>>> and
>>>> create overflowed scrolled sub-areas instead of overflowing the
>>>> viewport.
>>>
>>> Perhaps this is due to the fact that someone using a keyboard can not
>>> easy scroll the page and the overflowed scrolled sub-areas (which are
>>> really boxes with overflow:auto) and switch between them. The focus
>>> either has to be on the viewport or the overflowed scrolled sub-areas
>>> and this focus has to be changed to scroll either one.
>>>
>>> This is an accessibility issue.
>>
>> Afaics, that is an orthogonal concern, which can be handled by the UA.
>
>
> Firstly can you clarify orthogonal?
>
>    Wikipedia - In mathematics, two vectors are orthogonal if they
>    are perpendicular, i.e., they form a right angle.

In short, "separation of concerns". Here follows the mathematical definition.

Orthogonal functions:

http://en.wikipedia.org/w/index.php?title=Orthogonality&oldid=381268031#Orthogonal_functions

Meaning that the domains (variables) of some set of concerns are
independent, e.g. in the example the two functions are orthogonal over the
unit interval:

http://en.wikipedia.org/w/index.php?title=Orthogonality&oldid=381268031#Examples

So when I use the term orthogonal, I mean that we try our best to define
each attribute setting (variable), 'width:?', whose state machines are
fully generalized with respect to any other possible setting in CSS.

As Tab Atkins pointed out by example, we run into problems when we define
settings that do not have orthogonal relative properties:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0357.html

In my private research I am claiming that the lack of orthogonality, which
in computer science is I think equivalent to lack of referential
transparency (a deeper consideration that I am working on in my private
research on my Copute language), leads to spaghetti, gridlock, politics
and the Dunbar number:

http://goldwetrust.up-with.com/knowledge-f9/book-ultimate-truth-chapter-6-math-proves-go-forth-multiply-t159-15.htm#3640

(readers who closed-minded, irrational, unscientific, or otherwise
offended by existential philosophical debate, should skip the above link)

Tangetially, I have been just recently tying this into an attempt to unify
general relativity and quantum mechanics (quantum information):

http://goldwetrust.up-with.com/technology-f8/theory-of-everthing-t124.htm#3681


>> For example, the UA may provide Page Up and Page Down keys, and may use
>> the the Tab key and/or shortcut keys to move the focus around.  Also the
>> UA should give some indication of focus-- afaik they do not now.
>
>
> This is not just what is handled by the UA. This also includes OS, PC
> and user devices like a mouse or keyboard.

What is the distinction you are making?

My point was that the CSS should express the semantics, and the rendering
system should map those semantics into accessibility solutions.  We should
not move the accessibility layer into the semantic layer (which is what
CSS design is erroneously forcing), because by definition, that is the
antithesis of accessibility.

What I mean by that last sentence, is that something can not be accessible
in all cases if it requires the application to consider accessibility in
its semantics.  Rather the rendering agent should insure it only exposes
semantics for which it knows how to always map into accessibility. This
mapping should be invisible to the semantic layer (the actual CSS
properties).

Note I am not referring to the Semantic Web (Tim Berners-Lee), but rather
to the semantics of the CSS itself.  When I design a page that says "these
are multi-columns", I don't want to present them to CSS using tables and
pre-computed columns breaks.  When I design a web application page that
has a left scrolling page that fills the viewport, I don't want to have to
use a generic construct and then use JavaScript in real-time to resize
that on viewport size changes, because that obscures the semantics of what
I am doing from the CSS layer.

>> It is really a failed assumption that all web apps need to scroll
>> contiguously in the viewport. Imo, that was a design error.
>
>
> I would rather suggest that it is a failed assumption by a CSS author
> that overflowing content doesn't have to be scrolled to occasionally,
> especially considering the range we have in display devices.


IMO, that reminds me of the Steve Jobs attitude:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0537.html

Rather if CSS provides the setting so that I can tell CSS that I want my
left pane's height to always extend to the bottom of the viewport, and if
the rendering agent (UA) is on a device that makes this constraint insane,
then the UA will just override my constraint. But at least my CSS
semantics were not obscured.

> On the CSS discuss list, I have often seen pages like this.
>
>
> <!DOCTYPE html>
> <html>
> <body style="margin:0;">
> <div style="overflow: scroll; height: 1000px;">
> <div style="height: 1200px; background: white;">content</div>
> </div>
> </body>
> </html>
>
>
> Even I get lost in there.

Agreed that is very poor UI design. But that is not what I was asking for.
I was asking to be able to set 'height:vbottom', so that the
"sub-viewport" (aka the overflowed element) is not scrolled within the
parent viewport.

The point was that I have more content than can fit within the parent
viewport, so I separate the concerns of my content.  In the left pane, I
put a long srolling list of choices. When one of those is clicked, I
display the full content FOR THAT CHOICE ONLY in the right pane, and thus
the right pane is then more manageable from a screen real estate cost
analysis (as compared to putting full content for all choices in the
document simultaneously, which is what CSS semantics FORCE me to do).  But
that design isn't possible in current CSS.  I can not express these
semantics in CSS.  I have to resort to JavaScript.

>> If you are
>> really concerned about accessibility and usability, then just ponder the
>> how unusable an application is if you are only looking at one tile of it
>> and have to scroll the whole app around.
>
>
> I have a desktop with a mouse and keyboard. Can I ask you what types
> of display devices you using a referring too?

All possible ones you can envision.

> I myself while surfing have been using the scrolling mechanism on the
> mouse and realized that I have to move the mouse outside some
> particular element of the page with overflow with values of auto or
> scroll (example, YouTube). I only know this since I am a CSS author
> that has experimented with overflow. I can imagine some other web user
> with the use of both a mouse and a keyboard not knowing what to do.

I am not entirely visualizing your example? Could you re-explain?

In any case, if you are referring to the user not being given a visual (or
audio), indication of what they can do with the their user input devices
with respect to a particular set of CSS semantics, then is the fault of
the UA. The UA must given sufficient rendering such that the user is not
lost. There is probably much science that could be done on UA design. We
should strive to make that concern orthogonal to generalizing the CSS
semantics to what designers want to express.

Received on Saturday, 23 October 2010 12:45:20 UTC