12750 - [BLOCK] enlarging small widths not acting like min-width

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DESCRIPTION:
CSS2 says (in 10.4) that:

  The user agent may define a non-negative minimum value for the 'min-width'
  property, which may vary from element to element and even depend on other
  properties. If 'min-width' goes below this limit, either because it was set
  explicitly, or because it was 'auto' and the rules below would make it too
  small, the user agent may use the minimum value as the computed value.

I think it violates the spirit of this passage (although not the letter) that
the value of min-width depends on width.  What you are doing right now is
increasing the width only if it is zero.  I think what you should be doing (by
the spirit of the spec) is increasing the width only if it is too small.

IMO, too small should be defined in terms of inline content but not block-level
content.  That is, I think the first two cases should have the box wrap around
the word "This" (the largest word) and the latter two should really have zero
width.

STEPS TO REPRODUCE:  Load attached test case.

ACTUAL RESULTS:  Side borders of second and fourth test cases are touching each
other (width is zero), but not so for the first and third cases.

EXPECTED RESULTS:  First and second cases should look the same.  Third and
fourth cases should look the same.  (Possibly as I described above.)

(IMO, the correct layouts are those currently in the first and fourth cases.  In
the first case there is one word on a line and the green block wraps tightly
around the words.  In the fourth case, there is a zero-width green block
containing a 400px wide red block.  Currently, the second case (I think
incorrectly) is being shown as a zero-width green block with the four words
alone on each line.  The third case is currently (I think incorrectly) having
the green DIV contain the red P.)

DOES NOT WORK CORRECTLY ON:
 * Linux, viewer, build from source as of 1999-08-28, 12:15 PDT.
(marking All/All anyway)

ADDITIONAL INFORMATION:
The code that's causing this is the following lines in
nsBlockFrame::ComputeFinalSize :

      if ((0 == aReflowState.mComputedWidth) && (aMetrics.width < minWidth)) {
        aMetrics.width = minWidth;
      }

Ian -- any thoughts on the correct way to deal with this?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase described in bug

Comment 2

[Hixie (not reading bugmail)]

David: Your interpretation of the spec seems to me to be spot on.

Presumably one could, in a stylesheet, write:
   * { min-width: 0; }
...which would override the behaviour you describe above. (For the case where
the author really doesn't want the "width:0" property to be ignored with inline
only content, that is.)

Comment 3

[Hixie (not reading bugmail)]

Another test case:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/floatwidth.html
Note that you are not applying an explicit 'min-width' (last section).

(You may need to make sure that the 'initial' value of 'min-width' has an
explicit keyword, like 'auto', otherwise you may not be able to tell the
difference between UA-dependant-value and explicit-value. David: This is the
same as the border-*-color problem; if this is also important for the DOM, you
might want to mention it on www-style...)

Comment 4

[kipp]

*** Bug 17318 has been marked as a duplicate of this bug. ***

Comment 5

[leger]

Updating to default Layout Assignee...kipp no longer with us :-(

Comment 6

[troy]

Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.

Comment 7

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 8

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 9

[buster]

sorry for the spam, marking this one future.  outta time

Comment 10

[Hixie (not reading bugmail)]

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.

Comment 11

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 12

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The patch in bug 159059 changes the behavior described, and might be considered
as a fix for this bug.  (I think it probably should be, since the text-only
approach would require different min-size computation from the standard
min-size, unless we also included the widths of blocks that had specified
width.)  We also shouldn't even need to compute the min-size in many cases.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So do we want to try to do this "right"?  Or just call it fixed?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed.  We're not likely to implement this "optional" min-width business.