W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-figures][css-multicol][css-overflow] Ten CSS One-Liners to Replace Native Apps

From: Rafał Pietrak <rafal@ztk-rp.eu>
Date: Tue, 29 Jul 2014 19:19:42 +0200
Message-ID: <53D7D7AE.7040806@ztk-rp.eu>
To: www-style@w3.org
Hi,

Sorry I fell silent, apparently current proposals 
(http://www.w3.org/TR/css-overflow-3) is more then I'm aquainted 
with.... so I tried to catch up a little reading rhrough it.

W dniu 28.07.2014 09:40, Håkon Wium Lie pisze:
> Rafał Pietrak wrote:
>
>   > Speaking as an ocassional web-pages author: I would apreaciate if I
>   > could css-declare: "body {column-count:1}", and as a consequence get an
>   > "e-book reader" like page behavior, meaning:
>   >
>   > 1. vertical scroller *disapear*, and column height hard-equal to the
>   > current viewport height.
>
> This is what 'overflow: paged-*' do [1]
>
> I'd like it to be easy to switch into paged mode, but I'm not sure
> 'column-count' is a good switch (even if we could turn back time).
> There are cases when you want multi-column layouts, even in scrolled
> environment. E.g., Wikipedia uses it for references. A few more
> keywords on the 'overflow' property seems like a reasonable solution,
> no?

Yes. I agree. "column-count" is not a good trigger. I dind't see that 
before.

But:

1. a moment ago I wanted to say: I don't think "overflow: paged-*" is 
good either .... but haveing a critical look at myself I must admit, 
that this statement is strongly based on my "internal semantics of 
overflow", which roots back to TeX, and I tend to understand "overflow" 
as a box (usually a letter-box), which *cannot* be moved over because 
available glue does not allow for that. For me 
"line/paragtaph/column/page breaks" does not constitute a "proper 
overflow", but is just an ordinary context "boxing". So I'd rather say: 
"i personally dont apreciate overflow atribute as a trigger to alter 
pageing/scrolling behavior".

2. I do think, that "column-height" is actually a good trigger, since: 
a) that attribute does not exist yet, and b) the currently available 
"tools", like explicit "max-height", that could be applied to 
encapsulating DIV, although standarized ... it didn't work for me in 
chrom and iceweasle, and c) the goal is not to set "max-height" of 
"something", but to actually set "exact-height" ... thus "column-height" 
sounds quite right.


>
>   > 2. horizontal scroller show up (if content overflows the one visible column)
>
> Yes, or some other UI. This is what 'overflow: paged-*-controls' does.

I'd say, that my initial comment was triggered by the examples of 
getting "multicolumn newspaper" look and feel (like here: 
http://figures.spec.whatwg.org/) - which looks impresive. Yet, I think, 
that having a trigger like "column-height" would get css styling the 
ability to mimic e-books easily (and e-newspaper-multicolumn, too), 
while not being as elaborated as the "overflow: paged-*" attribute 
definition.

Also, I've noticed that Tab mentioned, that "column-height" was 
discussed before. May be someone could point me to messages with 
conclusions from those discussion?

-R
Received on Tuesday, 29 July 2014 17:20:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC