spec for intrinsic and min-intrinsic widths
L. David Baron
Here are some proposed definitions of how I think intrinsic and
min-intrinsic widths should be calculated. These are based on testcases
at http://dbaron.org/css/test/2004/intrinsic/ (and testing in
IE/Windows, Mozilla, Opera, and Safari) for the more practical parts and
on theory for some of the less practical parts (e.g., interaction with
'min-width', 'max-width', border collapsing).
The areas of these rules that might lead to undesirable changes in our
behavior are those related to floats and tables.
For floats, these rules would lead to perfect interoperability with
Opera and Safari on my testcases (which we currently have already for
min-intrinsic, but not intrinsic), so I don't think they're too much of
a risk.
For tables these rules might lead to slight changes, but don't seem like
they would lead to significant changes in how interoperable we are with
any of the browsers in question. However, note that no pair within the
4 browsers currently interoperates on the colspan cases.
I'd be interested in reaction to these, and perhaps in more testcases
for tables, especially if anyone knows of any areas where there is
interoperability that we need to preserve. The tables rules could
probably use some work, especially if I can find testcases that show
what browsers *are* doing rather than what they aren't.
-David
In the following definitions, percentages on the following properties are
treated instead as though they were the following:
width, min-width: auto
max-width: none
margin*, padding*: 0
and 'auto' values for 'width' should be treated as 0 when in max() and
infinite when in min().
blocks, inline-blocks, and table cells compute their min-intrinsic by taking
max of all of the following:
* for each child block, including floats,
+ if the child is a table,
m + b + p + max('min-width', min-intrinsic, min('width', 'max-width'))
(or, for 'border-collapse: collapse' tables, only
margin + overhanging border + max...)
+ otherwise, if the child's 'width' is 'auto',
m + b + p + max('min-width', min(min-intrinsic, 'max-width'))
+ otherwise,
m + b + p + max('min-width', min('width', 'max-width'))
* child lines min-intrinsic: break line at every point
don't forget all text-indent, word-spacing, letter-spacing, m/b/p on
inlines, etc. when doing this breaking
blocks, inline-blocks, and table cells compute their intrinsic by taking
max of all of:
* for each child block (excluding floats),
+ if the child is a table,
m + b + p +
max('min-width', min-intrinsic, min('width', 'max-width', intrinsic))
(or, for 'border-collapse: collapse' tables, only
margin + overhanging border + max...)
+ otherwise, if the child's 'width' is 'auto',
m + b + p + max('min-width', min(intrinsic, 'max-width'))
+ otherwise,
m + b + p + max('min-width', min('width', 'max-width'))
* child lines intrinsic: break lines nowhere optional, and add the width
of any floats anchored in the line to the resulting width. This is what
Safari and Opera do: see
http://dbaron.org/css/test/2004/intrinsic/float-intrinsic
Note that the properties 'width', 'min-width', and 'max-width' do not
affect the intrinsic and min-intrinsic widths of the elements on which
they are specified. However, they can affect the intrinsic and
min-intrinsic widths of the parent element in many cases. This allows
declarations like the following to be useful:
width: 5em;
min-width: min-intrinsic;
and also allows some formatting objects (such as flexible boxes) to use
formatting rules in which these properties on children do not effect the
intrinsic and min-intrinsic widths of the parent.
NOTE: The following algorithms (for tables) are quite interoperable in
the absence of colspans and min-*/max-* properties (and perhaps some
other edge cases). In the presence of colspans, there is currently
little interoperability, and the algorithm below is non-optimal,
although simpler than an optimal one.
For a table, determine the min-intrinsic width by adding:
* for 'border-collapse: collapse', (ISSUE: unresolved) amount of the
left and right borders
* 'border-spacing' horizontal value (for 'border-collapse: separate')
* the sum over columns of the sum of:
+ if any cell's column span begins in the column, half the
'border-spacing' horizontal value (for 'border-collapse: separate')
+ if any cell's column span ends in the column, half the
'border-spacing' horizontal value (for 'border-collapse: separate')
+ the maximum of:
- for each cell whose colspan ends in the column,
max('min-width', min-intrinsic, min('max-width', 'width')) +
horizontal padding + horizontal border (or, for 'border-collapse:
collapse', half of the largest of each horizontal border)
- for the column itself (if an element for the column is present),
max('min-width', min('max-width', 'width'))
- for the column-group (if an element for the column-group is present),
max('min-width', min('max-width', 'width'))
For a table, determine the intrinsic width by adding:
* for 'border-collapse: collapse', (ISSUE: unresolved) amount of the
left and right borders
* 'border-spacing' horizontal value (for 'border-collapse: separate')
* the sum over columns of the sum of:
+ if any cell's column span begins in the column, half the
'border-spacing' horizontal value (for 'border-collapse: separate')
+ if any cell's column span ends in the column, half the
'border-spacing' horizontal value (for 'border-collapse: separate')
+ the maximum of:
- for each cell whose colspan ends in the column,
max('min-width', min-intrinsic, min('width', 'max-width', intrinsic))
horizontal padding + horizontal border (or, for 'border-collapse:
collapse', half of the largest of each horizontal border)
- for the column itself (if an element for the column is present),
max('min-width', min('max-width', 'width'))
- for the column-group (if an element for the column-group is present),
max('min-width', min('max-width', 'width'))
NOTE: Absolutely positioned elements never contribute to containing block's
intrinsic or min-intrinsic width.
NOTE: These rules only describe intrinsic and min-intrinsic widths. The
parallel rules for heights are quite complicated. Such rules are
necessary for mixed vertical and horizontal text, for a flexible box
model, and side table captions.
--
L. David Baron <URL: http://dbaron.org/ >
Robert O'Callahan
> I'd be interested in reaction to these, and perhaps in more testcases
> for tables, especially if anyone knows of any areas where there is
> interoperability that we need to preserve. The tables rules could
> probably use some work, especially if I can find testcases that show
> what browsers *are* doing rather than what they aren't.
Impressive.
What about when min-width is a percentage value?
What about overflow:scroll/auto?
Rob
L. David Baron
I think it should be ignored just like other percentages. Why would it
be different?
> What about overflow:scroll/auto?
Hmmm. I guess intrinsic needs to consider the scrollbar width for
'scroll', and perhaps 'auto' as well. min-intrinsic probably just needs
the same, although maybe something else.
-David
Robert O'Callahan
> On Thursday 2004-05-06 21:30 -0400, Robert O'Callahan wrote:
>>What about when min-width is a percentage value?
>
> I think it should be ignored just like other percentages. Why would
> it be different?
OK.
>>What about overflow:scroll/auto?
>
> Hmmm. I guess intrinsic needs to consider the scrollbar width for
> 'scroll', and perhaps 'auto' as well. min-intrinsic probably just
> needs the same, although maybe something else.
Currently (and in the new scrolling code) in the overflow:auto case, we
will figure out if we need a scrollbar due to constrained height, and if
so, add it to the the intrinsic width. But I think we never add it to
the MEW. That won't be possible in the new world, but I'm not sure what
to do instead.
Consider an intrinsically-sized scrollframe with a max-height that
doesn't overflow vertically, and then you insert some content so it does
overflow vertically. We need to reflow to see what the new height is, so
we can see that we need a vertical scrollbar, so we can compute the
correct intrinsic width.
So, in the new world, will the scrollframe have to fire a new
incremental reflow against itself when it wants to change its intrinsic
size during reflow?
Rob
--
Robert O'Callahan <rob...@ocallahan.org> http://ocallahan.org
"If we claim to be without sin, we deceive ourselves and the truth is
not in us. If we confess our sins, he is faithful and just and will
forgive us our sins and purify us from all unrighteousness."
1 Johnn 1:8-9