Re: [css3-multicol] overflow and paging?

Very important, please read one more time...

> On Thu, Oct 14, 2010 at 11:33 AM, Shelby Moore <shelby@coolpage.com>
> wrote:
>>> On Thu, Oct 14, 2010 at 10:54 AM, Shelby Moore <shelby@coolpage.com>
>>> wrote:
>>>> Thus isn't the spec is wrong then? Should it ever allow the column
>>>> height
>>>> to be greater than constrained height of any outer container, because
>>>> afaics the result is typographically erroneous. Note I am not
>>>> referring
>>>> to
>>>> the non-paging media viewport container (including <iframe> and
>>>> <frame>).
>>>> Can anyone think of a valid need for that?
>>>
>>> Simplicity and predictability, mainly.  We could make CSS attempt to
>>> be smarter about how it reacts to ancestor heights, but that would
>>> make it harder to predict how it works.  It's fairly simple to fix the
>>> issue manually with a few "height:100%" rules scattered around.
>>
>> I am usually the one to argue for orthogonality, so I agree with you on
>> that principle.
>>
>> But the trade-off is that CSS is used by naive developers (like me
>> sometimes, hehe), who even after we add the "column-overflow:block"
>> option, are going to forget to put the "height:100%" and are going to
>> probably not even notice or care that the columns are too tall for the
>> container. I didn't notice that because of this, effectively the sort
>> order of the user profiles which is the flowed multi-col content (see
>> prior diagrams) was wrong until after weeks of working with my site
>> every
>> day. It is deceptive thing that people won't really notice, the
>> usability
>> error will accumulate somewhat silently.
>>
>> Thus usability of the www could suffer. There is the amatuer programmer
>> requirement I think on CSS?
>>
>> In this case, wouldn't it be much more predictable if multi-col
>> containers
>> always limit their column height to any blocking constraint of their
>> outer
>> containers, up to but not including the viewport or frame? And then have
>> an explicit setting to turn that off, e.g. "column-height:auto".  So the
>> default would be "column-height:constrain".
>>
>> Any opinion?
>
> I don't really think it would make things any more predictable.


I will present a proof now, because I thought it was obvious, but I guess
not.

I am not going to fight too hard for it, because I already know what I
need to do once you add "column-height:constrain" (which btw, I appreciate
very much, thank you for understanding).

But I thought I should try to be unselfish and think about the other people.

And I don't think I did a good job of explaining why it will be less
predictable if we don't by default, prevent the case I encountered.

In the interests of showing I care about the www (not just myself), let me
expend the effort to try one last time to convince you a little bit more
carefully.

===========

If we by default allow the "column height" to exceed the height of an
outer container, then it is very likely that the web programmer will not
realize there is an error, and just continue on with the error for a very
long time (possible long after they left the project and no one else is
around to fix it), thus littering the www with many insideous column
formatting errors that no one really notices but which wreck havor on
usability.

The reason is because the difference between the correct and incorrect
results is very subtle and insideous visually, although the error is very
great.

Imagine the following capital letters are user images sorted on some
important criteria, e.g. last login date:

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

>>> -------------
>>> |           |
>>> -------------
>>> |A D|       |
>>> |B E|   2   |
>>> |C F|       |
>>> -------------
>>>  G J
>>>  H K
>>>  I L
>>>
>>>  M P
>>>  N Q
>>>  O R
>>>
>>> But instead now I erroneously see:
>>>
>>> -------------
>>> |           |
>>> -------------
>>> |A J|       |
>>> |B K|   2   |
>>> |C L|       |
>>> -------------
>>>  D M
>>>  E N
>>>  F O
>>>  G P
>>>  H Q
>>>  I R


So if the "column height" is NOT correctly limited to any constrained
height of the outer containers by default, then instead of seeing ABC DEF
(the first 6 in the sort order), the user sees ABC JKL.  Since they are
only seeing photos in this example, they think they are looking at the
first 6 items in the sort order, even the web developer programming the
site thinks so too, but in reality JKL are the 11th, 12th, and 13th items
in the sort order.

That is a bug.  But it is a silent bug.  Nobody notices.  The www becomes
erroneous.

Whereas if by default we prevent that bug, then the www will be much more
predictable.

How can you say it is not more predictable?


> I'll note that, had you used somewhat cleaner HTML without a container
> element, the issue wouldn't have arisen at all, as the height of the
> element would have been specified rather than 'auto'.

Two orthogonal rebuttals:

1. Irrelevant because if the user can do it, it can happen.  The key is
can the developer (and his viewers) reasonably see that they made an
error? And I think I showed above that there are many cases where they
will not be able to readily.

2. The html I used was optimally "clean", because of orthogonality which
is a concept you argued for.  I needed the container <div> to be
orthogonal to the mult-col div, because the container <div> gets many
different things flowed into it, depending on which menu tab is selected
inside the social network.  But more over, I can give you many examples
where the problem will occur where there isn't a duplicate <div> inside of
a <div>.  For example, the <tr> could be contained, then you might have a
column element contained within it, but that might not be the only element
contained within it.  Even in my <div> case that could be true, e.g.:

<div style='height:600px; width:250px'>
   The brown fox jumped over the lazy dog.
   <div style='column-width:125px'>
      ...same content as I had before
   </div>
</div>


>  This is, of
> course, not always an option with current CSS layout techniques; you
> often need to augment the DOM with additional elements to make the
> page act as expected.  My goal in this group right now is to fix this
> in the majority of cases by providing more powerful layout models such
> as Flexbox, Template, and others.

I would love to see Flexbox, but that still won't stop the above insideous
multi-column typography error.  The multi-column case is unique in the way
it can cause insideous sorting error that goes unnoticed.

Is that more convincing?

All the best Tad.  Thank you.

Received on Thursday, 14 October 2010 20:32:56 UTC