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

Thanks for the detailed and kind reply. Please see inline:

On Sat, May 30, 2015 at 6:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, May 29, 2015 at 9:47 AM, Koji Ishii <kojiishi@gmail.com> wrote:
>> What I'm suggesting here is for UA not to handle the overflow in block
>> direction automatically and forcibly.
>>
>> Was this point clear?
>
> I'm not sure what you mean by this, so no. ^_^  Let me restate what
> the behavior in question is:
>
> When you have orthogonal flows, such as vertical Japanese text in an
> English document, if you're not careful with sizing you can easily get
> horrible behavior.

Agreed. This happens Japanese vertical within Japanese horizontal too.

> Without an explicit height, the line-length of the
> Japanese is unconstrained, and will lay out similar to max-content,
> requiring people to scroll down to read each line and then back up to
> read the next.

Agreed. When logical width is indefinite, there should be some constrain.

> As well, if the text is long enough, the lines will
> stack off the screen horizontally, creating a "T-shaped" document.
> Horizontal scrolling in a primarily-vertical page is very frustrating.

Agreed.

> Automatically applying multicol with some constraints fixes both of
> these problems.  By setting a column-width of the screen height, lines
> won't span longer than the screen, so you can read more comfortably.
> (Screen height might not be the ideal line length, but at least you
> don't have to scroll back and forth to read; it's a minimum viable
> fix-up.)  By using multicol, when there are enough lines to overflow
> the width of the element they instead create a new column downward, so
> the document stays vertically-scrollable only.
>
> This behavior causes orthogonal content to conform to the document's
> overall flow-direction preferences, avoiding user-hostile behavior,
> particularly when an author tests only with short spans of content but
> in production the content is sometimes long.

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.

[1] http://bibi.epub.link/

/koji

Received on Saturday, 30 May 2015 04:03:42 UTC