- From: L. David Baron <dbaron@dbaron.org>
- Date: Sun, 11 Sep 2005 12:22:43 -0700
- To: Staffan Måhlén <staffan.mahlen@comhem.se>
- Cc: www-style@w3.org
- Message-ID: <20050911192243.GA25471@ridley.dbaron.org>
On Friday 2005-09-02 18:06 +0200, Staffan Måhlén wrote:
>
> L. David Baron wrote:
> >On Wednesday 2005-08-31 17:06 +0200, Staffan Måhlén wrote:
> >>I would have expected the above to yield a result very similar to table
> >>column widths;
> >
> >In what examples does it not do so? (Though for tables the available
> >width is per-table, not per-column, so the table as a whole behaves
> >according to that description, but not each column.)
> >
>
> My testing was of course incomplete, i was testing some absolute
> positioning cases and not other shrink-to-fit cases. When digging a bit
> more it turns out there are inconsistencies in how different cases of
> shrink-to-fit is handled. I don't have that many UAs installed, and
> since one of them cannot really be used to test this type of feature i
> only tried with two browsers.
It would be useful if you said which two.
> Essentially, what i (and i think some UAs) may be confused about is what
> the terms: "preferred minimum width" and "preferred width" actually
> refer to. The rec of course states:
> "Roughly: calculate the preferred width by formatting the content
> without breaking lines other than where explicit line breaks occur, and
> also calculate the preferred minimum width, e.g., by trying all possible
> line breaks"
I've written drafts of more detailed definitions, although they're only
partial. A slightly out-of-date version of my draft is
http://groups.google.com/group/netscape.public.mozilla.layout/msg/0455a21b048ffac3
> <?xml version="1.0" encoding="iso-8859-1"?>
> <!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html>
Presumably you meant to include an xmlns attribute here.
> <head>
> <title>Shrink-to-fit</title>
> <style type="text/css">
> pre {background-color: #eee;}
> .main {padding: 1em; font-size: larger}
> b {text-decoration: underline}
>
> .cont_ind {border: solid 1px black;}
> .container {height: 10em; position: relative}
> .abs_ind {background-color: red;}
> .abs {position: absolute; top: 5em}
> .float_ind {background-color: green;}
> .float {float: left;}
>
> .test1 {width: 0}
> .test2 {width: 200px}
> .test3 {width: 500px}
>
> .min_width {width: 400px; border: solid 2px blue}
>
> </style>
> </head>
> <body>
> <h1>Shrink-to-fit</h1>
> <pre class="main">
> min(max(preferred minimum width, available width), preferred width).</pre>
> <h2>preferred minimum width != 0? (container width 0)</h2>
> <p>
> The below is a <span class="cont_ind">relative container</span> of
> width 0,
> causing the absolute <span class="abs_ind">positioned</span>
> and the <span class="float_ind">floating</span> boxes to be forced to
> use preferred min width.
> </p>
> <pre>
> min(max(preferred minimum width, <b>0</b>), preferred width).</pre>
> <p>
> The <span class="abs_ind">absolute positioned</span>
> and <span class="float_ind">floating</span> boxes should be as wide as
> the text they should contain.
> </p>
>
> <div class="container cont_ind test1">
> Container
> <div class="float float_ind">
> A_width_less_float
> </div>
> <div class="abs abs_ind">
> Abs_pos_box
> </div>
> </div>
This test displays as you expect in trunk Firefox (both red and green
boxes the width of their text). I think Firefox 1.0.x had a bug with
absolutely positioned elements that would make them narrower, though.
> <h2>Preferred minimum width != calculated content min width?</h2>
> <p>
> The below is a <span class="cont_ind">relative container</span> of
> width
> 200px, holding <span class="abs_ind">absolute positioned</span>
> and <span class="float_ind">floating</span> boxes that have contents
> forcing their min/max widhts.
> </p>
> <pre>
> min(max(<b>400px?</b>, 200px), preferred width).</pre>
> <p>
> The <span class="abs_ind">absolute positioned</span>
> and <span class="float_ind">floating</span> boxes should be as wide as
> the blue borders.
> </p>
>
> <div class="container cont_ind test2">
> Container
> <div class="float float_ind">
> <div class="min_width">
> Preferred minimum width is this box.
> </div>
> <div class="max_width">
> Preferred width is this box since it wants to be much wider than
> anything else in the parent.
> </div>
> </div>
> <div class="abs abs_ind">
> <div class="min_width">
> Preferred minimum width is this box.
> </div>
> <div class="max_width">
> Preferred width is this box since it wants to be much wider than
> anything else in the parent.
> </div>
> </div>
> </div>
Firefox displays this as you expect (red and green boxes both 400px
wide), although it took me quite a while to figure out what it was you
expected.
> <h2>Preferred width versus actual line-breaks</h2>
> <p>
> The below is a <span class="cont_ind">relative container</span> of
> width
> 500px, causing the absolute <span class="abs_ind">positioned</span>
> and the <span class="float_ind">floating</span> boxes to be forced to
> decide a width that lies between the minimum possible and preferred
> widths.
> </p>
> <pre>
> min(max(<b>width("**opportunity_to_see_how_wide_the_parent_gets.")</b>,
> 500px),
> <b>width("this_text_shall_cause_a_single_line_break**
> **opportunity_to_see_how_wide_the_parent_gets."))</b>.</pre>
> <p>
> If the "preferred width" is equivalent with the table style "maximum"
> cell width, the <span class="abs_ind">positioned</span>
> and the <span class="float_ind">floating</span> boxes should be as wide
> as their parent container. Otherwise, the preferred width
> is a new concept that depends on how the lines were actually flowed
> inside the shrink-to-fit item? In the second case,
> the preferred width seems to be something like the closest possible
> actual line break opportunity:
> </p>
> <p>
> preferred width can be either
> </p>
> <p>
> width("this_text_shall_cause_a_single_line_break**
> **opportunity_to_see_how_wide_the_parent_gets.")
> </p>
> <p>
> or
> </p>
> <p>
> max (width("this_text_shall_cause_a_single_line_break**"),
> width("**opportunity_to_see_how_wide_the_parent_gets."))
> </p>
>
> <div class="container cont_ind test3">
> Container
> <div class="float float_ind">
> <!-- Replace this with two imgs to force specific line-widths
> perhaps-->
> this_text_shall_cause_a_single_line_break**
> **opportunity_to_see_how_wide_the_parent_gets.
> </div>
> <div class="abs abs_ind">
> <!-- Replace this with two imgs to force specific line-widths
> perhaps-->
> this_text_shall_cause_a_single_line_break**
> **opportunity_to_see_how_wide_the_parent_gets.
> </div>
> </div>
I think the question you're asking here is whether there should be a
second pass after the min(max(,),) expression that shrinks things down
to the largest actual line. I believe IE does this and that Mozilla
does this in some cases but not others, but that a bunch of other
browsers (KHTML, at least) do not. Not doing it has the advantages that
it's easier to specify and that it's easier to do across different
implementation designs for shrink-wrapping (in particular, whether or
not to do shrink wrap width calculation by doing something a lot like
layout, which I think is what IE does and what Mozilla currently does
(although hopefully not for long)).
>
> </body>
> </html>
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, The Mozilla Foundation
Received on Sunday, 11 September 2005 19:22:59 UTC