433621 - Add a CSS property for web authors to override intrinsic widths (and/or request that minimum width isn't passed through scrollframes)

Status: NEW

(Core :: Layout, enhancement)

Description

[Daniel Holbert [:dholbert]]

The patch for bug 402567 made Trunk pass min-width through scrollframes, rather than just giving them a min-width of zero as we did in Firefox 2.

However, the old behavior was useful in some cases.  And it's hard for a web author to emulate the old behavior when you have tables that contain scrollframes. (This caused some issues with gmail old-version -- see bug 407257)

In bug 407257 comment 35, dbaron said:
> I think both behaviors make
> sense -- for different cases.  We really ought to be giving authors a way to
> choose between them, since there are important use cases for both.

This bug is to give authors a way to choose which behavior they want.

Comment 1

[Martijn Wargers (dead)]

That would be great!
I think I then also could remove the ugly workaround for marquees that was used in bug 407016.

Comment 3

[crisp]

https://bugzilla.mozilla.org/show_bug.cgi?id=402567 seemed to deal only with automatic-layout tables containing another fixed-layout table that has a percentage width, but the fix for that affects all table-layouts and is focussing on 'scrollframes'. I'm all for better compatibility with other browsers except when other browsers' implementations are actually less than optimal from an author perspective. I do expect a browser to try to match any width-directives on table or table-cells and to clip/scroll any descendants that have overflow specified other than 'visible' as needed.

I explained before that the current behaviour will f.i. make it virtually impossible to ever implement text-overflow in a sane way using tables with automatic table-layout. The fact that IE and WebKit suffer from the same problem (and those browsers actually do support some form of text-overflow, but it's useless in automatic-layout tables) should at least be some incentive to try to do better in Firefox instead of blindly following their behaviour.

So imo 'scrollframes' (I guess that's what you call an element that has the overflow property set to something different than 'visible') *should* return a min-width of 0 unless they have explicitly defined a min-width.

I think the main problem in Gecko is this (from https://bugzilla.mozilla.org/show_bug.cgi?id=402567#c20 ):

1. Compute column intrinsic widths:
  a) First cell:  min = 0, pref = nscoord_MAX
    ** The prefCoord is nscoord_MAX because
FixedTableLayoutStrategy::GetPrefWidth always returns that.

In that testcase, where the inner table has a width specified of 10% and the outer table a width of 100px I'd say that 'pref' should be 10% of 100px = 10px and not nscoord_MAX...

Even when the inner table would have width=100% there shouldn't be a problem applying an heuristic that satisfies both the accumulated min-values and the width-directive on the outer table. The sum of prefs would be 600 + 11 = 611, so you could size the first column to (600 / 611) * 600 = 589px which still leaves 11px for the second column.

This might become more complex wrt colspan, but imo would be a big improvement over the current situation and matches more closely authors expectations, and is still inline with the non-normative section in 17.5.2.2 of the CSS2.1 spec that says:

"If W is greater than MIN, the extra width should be distributed over the columns."

It's just a matter of how you distribute the extra width...

Comment 4

[Johnny Stenback (:jst)]

Not a DOM bug.

Comment 5

[spaceghost]

Some more details on this, and a request to submit the -moz-XXX setting fix sooner rather than later.

If this is indeed a 'pass-through' style width ie: min-width of the 'scrollpane' contents is passed to it by the min-width of the contents of the scrollpane... then it follows that this would be over-rideable setting using explicit style setting of min-width for the 'scrollpane' div.

Turns out not to be the case... the 'scrollpane' min-width cannot be set to a percentage width explicitly in any way.

We have a web spreadsheet with resizable columns, and the table cells contain a div that should always be slightly smaller than the TD size, allowing the TD to be resized dynamically regardless of the TD contents.  So a min-width of 99% for the inner 'scrollpane' div worked flawlessly in FF2.x.

In FF3.x this no longer works as the inner DIV 'scrollpane' does not resize because the content of the cell is too big.

FWIW: this works fine in IE7 and Chrome as the explicit setting of the inner div to a percentage will properly size the 'scrollpane'.

Please provide authors with the -moz-XXX setting to go back to the FF2.x behavior as it is impossible to emulate.

Comment 6

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

minimum width as described in this bug is different from the CSS min-width property.  That said, one possible way to fix it is to add CSS properties to specify the minimum and preferred intrinsic widths.

Comment 7

[spaceghost]

Thanks David for the rapid response!

But, unfortunately, that is exactly what we're trying to do (add CSS properties to allow for min-width smaller than content width in the div.)

easy way to see this bug in action is to look here:
http://web-1.extentech.com/grid/grid.jsp?meme_id=2124

in FF2.x you can resize the colum A small as you like... but in FF3, the width of the contents does not allow the column to be resized smaller.

As you can see using Firebug or whatnot, the TD of the grid contains a DIV with size of "90%" which in all the other browsers (FF2, IE6+7, chrome) logically resizes the inner DIV to 90% of the container TD -- and because we set 'overflow:hidden;' on the inner DIV, the contents nicely hide away as you would want in a spreadsheet cell.

FF3.x simply will not allow us to set the inner DIV to a % width... thus the broken resizing.

Seems like a patch to fix the *explicit* setting of the inner DIV widths to a percentage would put this one to rest.

Thanks!

Comment 8

[Karl Dubost💡 :karlcow]

is it still an issue?

Comment 9

[Daniel Holbert [:dholbert]]

This bug is for a feature-request, so yes -- it is still an issue, in the sense that we don't have the feature yet.

It seems like this feature (via the strategy in comment 6) is still something that would be useful, though obviously not high-priority, given the lack of activity here.

Comment 10

[Daniel Holbert [:dholbert]]

(removing "-moz" from summary, since we're not using prefixes for new properties anymore. If we do work on this, it'll need to be in conjunction with a w3c csswg spec / proposal of some sort.)