- From: Shelby Moore <shelby@coolpage.com>
- Date: Fri, 15 Oct 2010 12:11:30 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style@w3.org
> On Fri, Oct 15, 2010 at 3:26 AM, Shelby Moore <shelby@coolpage.com> wrote: >> Another thread raised the issue of whether the CSS column layout model >> is >> sufficiently generalized: >> >> http://lists.w3.org/Archives/Public/www-style/2010Oct/0280.html >> >> Afaics (so far) it is, because the model does not preclude later >> specifying how to to do variable column widths per column, and perhaps >> even overflow into other elements via the proposed "overflow:" at the >> above link (thanks to Brad Kemper for the idea on extending and re-using >> overflow setting, suppose that is what Tab Aktins had in mind). >> >> In addition to the proposed "column-height:constrain" default at the >> above >> link, there is one more setting lacking in the current model which I >> think >> is going to build bad inertia, and thus I think we should correct it >> asap. >> >> Imagine the case where the content of the multi-column element contain >> block elements (which may be intermixed with inline), e.g.: >> >> <div style='column-width:250px'> >> Unwrapped Snicker bar at bottom of the swimming pool. >> <div>Something there</div> >> <span style='display:inline-block'><img src='person.jpg'/>Name</span> >> ...etc... >> </div> >> >> That will be common when columinating a large set of logically similar >> items (e.g. in my case user profile summaries with a thumbnail photo). >> >> The problem is that in that case, the page designer may be striving for >> "give me as many columns, for which my content will fit, within the >> 250px >> space I have allocated". So in current spec the column-width as >> hard-coded to specific length, is not what the designer needs. And >> column-count isn't appropriate either. What the designer needs is for >> the >> browser layout engine to analyze the block elements in the content and >> determine the "minimum" column-width that won't clip the content. This >> is >> a complex calculation which includes the text wrapping settings, etc.. >> >> Thus I propose "column-width:minimum". >> >> Please let me know if that description of the problem is unclear, >> insufficient, or incorrect. > > You don't actually want "as many columns for which my content will > fit". You want "as many columns as will look good with my content". Agreed. > The former is doable (it's just the 'min-content' keyword, currently > supported only by Firefox under a prefix), Thanks. I didn't know that. Will CSS3 adopt it? > but it'll be ugly, because > the minimum content size is just the width of the longest word or > replaced element. Agreed ugly in generalized ("set it and don't look") case, but in specific cases it depends, because one may have large enough images that restrict the minimum width to something reasonable. The designer will get visual feedback on this if they turn on the setting, and may adjust accordingly. They can resort to min-width... > The latter is not doable, because it involves aesthetic judgements of > balance and personal taste. You can probably fake it, though, with a > combination of a sensible min-width (to prevent things from shrinking > *too* small), Yeah now that you mention it, I think min-width:???em is what designers want in this case. This is not the same as setting column-width:???em, because column-width can not: 1. expand or contract the column width (constrained to minimum or min-midth) so as to maximize total width while minimizing height. Note we might need a column-max-width then too? 2. the min-width is overriden by the content itself. Btw, this is why is very important to be able to wrap long text sans spaces (e.g. urls). Tangentially, I wish there was some CSS support for automatically displaying long unwrappable text shortened with ellipsis (that expand on hover or something like that) depending on the need to avoid overflow in the dynamic layout? > plus a "width:min-content" rule to ensure that the > column doesn't get smaller than the largest word / replaced element. I thought that was always the case? Or is that just the default? I wasn't aware of and haven't yet studied that setting. Will do later.
Received on Friday, 15 October 2010 16:11:59 UTC