Re: [css3-multicol] overflow and paging?

> On Fri, Oct 15, 2010 at 10:30 AM, Shelby Moore <shelby@coolpage.com>
> wrote:
>> [snip]
>>
>>>>  I don't think we need a new keyword - the behavior we want is
>>>> already specifiable with the vh unit, which represent 1% of the
>>>> viewport's height.  So you could have something like
>>>> "column-max-height: 100vh" as the default value.  It would otherwise
>>>> accept any length, with a value of 'auto' meaning "no maximum height".
>>>
>>>
>>> Very nice generalization. Thank you for spending the effort.
>>
>> [snip]
>>
>> On further thought, this won't work correctly.  The column-max-height
>> needs to be constrained to its outer container's block direction
>> dimension
>> constraint (aka height), not to the viewport.
>
> This can be done with a "column-max-height:100%", assuming we define
> percentages to be relative to the height of the multicol element.


IMO, that should be the default, not 100vh, so that we can prevent by
default those visually inconspicious flow order errors that I was
describing.


>  (If
> you have padding/border/etc, you'll have to use a calc() to get the
> value right.)


Hmmm. I am thinking off-top-of-head that should automatically calc? IMO,
we always want the column-height to fit within the outer container's clip
by default, if for no other reason, because it is the only way to make
accessibility work correctly by default.  Also to prevent those visually
inconspicious flow order errors that I was describing.



>> Minor rant: why in CSS do we have to say "width (aka inline direction)"?
>> Why couldn't we reuse the same term?  Is width never in the inline
>> direction?  Then why do we say that "column-width" always applies to the
>> "inline direction"?  Should it be named "column-inline-length" instead?
>>
>> This is making the discussion and teaching of CSS columns very difficult
>> and verbose.  Can we fix this?
>
> "width" is the extent in the horizontal direction.  In vertical text,
> this is not the same as the inline direction.
>
> We could fix this in the same way we fixed the physical dependency of
> top/right/bottom/left, by coming up with a pair of logical-direction
> keywords to use in place of width/height.  No one's come up with a
> good set yet, though.  (I think last time the discussion came up, we
> were happy to use "length" for one of them, probably height, but
> couldn't come up with a good one for width.)

>From my crap ideas, may spring some good ones :D

Seems to me best are "inline-length" and "block-length".  So I would
prefer "column-inline-length" and "column-block-length" instead of
"column-width" and "column-height".  But when are the width and height not
logical any way?  Width on a block element is always the inline length
correct?  If no, then using the "column-block-length" would eliminate the
confusion where people confuse it with the content height and the height
of the multi-column element.


"flowx" and "flowy"

"textx" and "texty"

southern humor:(hang a) "louie" and "reggie"

Received on Friday, 15 October 2010 18:23:06 UTC