Percent height border-box content should get correct height in percent height cells

Percent height border-box content should get correct height in percent height cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010
Review-Url: https://codereview.chromium.org/2535173006
Cr-Commit-Position: refs/heads/master@{#438652}
(cherry picked from commit 6c6315ec5c5ca31be742ebbe13cfecb43baae21a)

Committed: https://chromium.googlesource.com/chromium/src/+/58eb404753d8ee142e02b9695a84c2c6c24f88ea

[rhogan, 2016-12-22 13:42:24]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010

Review-Url: https://codereview.chromium.org/2535173006
Cr-Commit-Position: refs/heads/master@{#438652}
(cherry picked from commit 6c6315ec5c5ca31be742ebbe13cfecb43baae21a)
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010

Review-Url: https://codereview.chromium.org/2535173006
Cr-Commit-Position: refs/heads/master@{#438652}
(cherry picked from commit 6c6315ec5c5ca31be742ebbe13cfecb43baae21a)

Committed:
https://chromium.googlesource.com/chromium/src/+/58eb404753d8ee142e02b9695a84...
==========

[rhogan, 2016-12-22 13:42:25]

Committed patchset #1 (id:1) manually as
58eb404753d8ee142e02b9695a84c2c6c24f88ea.