Re: [css3-multicol] accessibility and UX

> On 10/20/2010 02:30 PM, Håkon Wium Lie wrote:
>> Shelby Moore wrote:
>>
>>   >  >  But the WG has decided, after discussions, to not address the
>> issue in
>>   >  >  the CSS3 multicol draft, which is now in CR.
>>   >
>>   >  Who decided that?  Where can I read their logic?
>>
>> The Working Group (WG) made a decision. The minutes are here:
>>
>>    http://www.w3.org/2008/10/20-css-irc.html
>
> http://lists.w3.org/Archives/Public/www-style/2008Nov/0023.html

Thanks.

A few comments, but note my comments will assume the "viewport" is the
multi-col element which has overflow:auto, since that is the priority case
I am concerned about most:


(1) "Fantasai: also it's really awkward to scroll through that, you need to
             position your scrollbars so that the entire block of columsn
             fits within the viewport, then scroll precisely to the next set"

Good point, but that is why you need some gap between column rows, and gap
needs to fit within the height of the multi-col element (so that user can
position a portion of the gap on the top and bottom so as to have some
allowance).

Also UAs can support Page Up and Down when the multi-col element has focus
(was the last thing clicked or scrolled). I would suggest they should
snap-to column row boundaries on Page Up and Down.


(2) "Steve: If I scroll a column at a time, I keep the context. If I jump
to a
          page, you don't see the context anymore. Cf. turning the page and
          no longer remembering the last line at the bottom."

That is a non-issue. One can scroll partially if they want content. The
column row gap is crucial.


(3) "Alex: Scrolling is really bad for that kind of reading experience"

Yeah but in this case, we are at least improving the scrolling so that we
are not scrolling from bottom to top of the entire document just to read
left-to-right.  That is hardly a argument against what I proposed, but
rather an argument for it.


(4) "Peter: Our conclusion was that all modes were valid in some cases, if
          the designers wants it."

Correct. If I want a vertically scrolling multi-col element with
constrained height, then I know what I want for my users and why.  What
you have now prevents me from doing the right thing for my users.


(5) "Alex: There is no natural way to overflow columns. Traditional is to
         make a new page.
   Håkon: That's why I think pagination solution is the right thing to do.
          More work, though..."

Yup. We have a new metaphor, and we still need rows of columns, we just
break then on the height of the visible area that can be scrolled.


(6) "Håkon: Meta-solution is to have overflow mode pagination as general
feature.
   Håkon Set overflow-mode: paginate and you will get new pages for all
         overflow."

Okay I understand. WG wants to optionally allow the page breaks to occur
on any vertically (block direction) scrolled overflow. That is more
ambitious. Sometimes we need to do important cases first.

But it needs to the be _default_ for multi-col element when both width and
height constrained. So there is no need to give it a name yet and
generalize it.  We can simply do the correct thing for the default case
for multi-col element overflow.  No need to add any new setting for now.
We can come back to the setting and generalization later.


(7) "Steve: But user probably can't tell whether I'm using pagination or
not in a page."

The column row gap is very important.


(8) "Fantasai: Better a new module.
   Fantasai: Leave multicol as it is, add new module later.
ScribeNick: fantasai
   Howcome: it seems the conclusion is we don't make a changeto the
multicol spec now"

Ditto what I wrote in #6.  IMO, we need the improvement now for multi-col.
Generalize to overflow:paginate later.


(9) "åkon: Can use 'column-gap' also between the pages.
   Steve: No, they are diff. gaps.
   <fantasai> or column-row-gap"

+1


(10) "Hakon: spec doesn't specify where page break occurs"

And still doesn't:

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

Received on Thursday, 21 October 2010 03:41:36 UTC