Re: [css-writing-modes-3] Defer auto-muticol behavior in Auto-sizing Block Containers in Orthogonal Flows

On Fri, May 29, 2015 at 9:03 PM, Koji Ishii <kojiishi@gmail.com> wrote:
> This is the point of controversial. When we have too many lines, I
> think we should just let it overflow, and let author decide what to
> do. I think in most cases authors want overflow-x:scroll. Please see
> the first "Demo" section of bibi[1].
>
> Another real example is when iBooks introduced scroll-mode, it
> actually did multi-col for vertical flow so that readers can scroll
> vertically. It was then fixed to scroll horizontally. I don't know why
> Apple made such decision, but as a user, scrolling multi-col pages is
> quite bad user experiences to read the content, unless it's combined
> with scroll-snap or paged behavior.
>
> I understand it varies by tastes. iBooks shipped multi-col indicates
> someone favored that. But some others may want to use regions. Some
> may want to text-overflow:ellipsis. Some may want to hook up an event
> listener and do something fancy.
>
> We already have bunch of options to solve T-shaped documents, so I'm
> suggesting to let authors to choose one. I'm fine to have
> auto-multicol as one of the options authors can pick.
>
> So I see 2 points of discussions:
> 1. Does auto-multicol automatically helps users, or does it force
> single option and take flexibility out?
> 2. If we allow multiple options, which one should be default (or no
> default and overflow by default)?
>
> I prefer multiple options, and default to overflow. But for #2, I'm
> fine to pick an easy one if preferred and we can reach consensus what
> the best UX is.

Ah, gotcha. Yeah, overflowing works too, but it doesn't print.  I
think this was brought up at the meeting.

Having this controllable via a property
('emergency-orthogonal-overflow'?) could help; at least then the UA
stylesheet could default it to overflowing on screen and multicol-ing
in print.

~TJ

Received on Tuesday, 2 June 2015 21:15:54 UTC