On Thursday 2004-05-06 16:21 -0700, L. David Baron wrote: > 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.
I'd like to emphasize this point again, since nobody responded. :-)
I've actually gone back and forth a few times on this point for the past
few weeks, but I think I do want to do what I propose in this message.
The key change here is that we would use a rough approximation for
intrinsic width of blocks that contain floats rather than doing layout
to figure it out exactly.
The disadvantage is that it would become impossible to achive close
compatibility with IE/Windows and IE/Mac on some of the more obscure
layout cases.
The advantage is that we could get rid of doing layout to compute
intrinsic widths, which would allow us to simplify layout code a good
bit, which would allow:
* fixing the root causes of all the incremental reflow problems rather
than fixing lots of tiny (and hard to fix) bugs one at a time
* making XUL and HTML code more similar and working out quirks in their
interaction
* making a larger percentage of minority browsers interoperable on the
same behavior -- which would both:
+ encourage web authors to write pages compatible with that behavior
(and not *too* many pages are incompatible with Safari and Opera)
+ move the behavior to something that's more likely to integrate with
future web standards, allowing better standardization of future
layout concepts
That said, this does mean breaking some web pages, but I think I still
want to do it.
-David
Also, for reference, my testcases are at
http://dbaron.org/css/test/2004/intrinsic/
> 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.
> 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/ >
pgpI6MXWSYiVr.pgp
Description: PGP signature
