Text Autosizing: Treat position:absolute/fixed as constrained height.

Text Autosizing: Treat position:absolute/fixed as constrained height.

This patch changes Text Autosizing to consider out of flow positioned
elements (position:absolute and position:fixed) as having constrained height
(like e.g. max-height:50px). Hence Text Autosizing will no longer autosize
them nor their descendents, unless they are themselves explicitly
unconstrained (e.g. with overflow:auto).

This fixes a bunch of known cases (see bugs below) where web designers
overuse position:absolute (often trying to exactly recreate something they
were given in Photoshop), and when Text Autosizing subsequently autosizes
the absolutely positioned text, the various bits of text overlap each other.

The patch had very few negative impacts on the Alexa 2000 homepages, so this
seems a reasonable change to make.

Added test positioned-out-of-flow.html covering this new behavior.

Deleted tests constrained-then-position-absolute-ancestors.html and
constrained-then-position-fixed-ancestors.html which inherently relied upon
the old behavior.

Coalesced tests constrained-then-float-ancestors.html and
constrained-out-of-flow.html into a single constrained-floats.html test that
just covers float behavior, removing parts that relied on the old behavior.

Modified the following tests which used the old behavior, but for which an
equivalent is still possible, to use position:absolute;overflow:auto instead
of just position:absolute, hence they continue to get the old behavior:
- cluster-list-item.html
- clusters-insufficient-text.html
- clusters-insufficient-width.html
- clusters-sufficient-text-except-in-root.html
- clusters-sufficient-width.html
- oscillation-javascript-fontsize-change.html

BUG=162006, 162009, 178123, 181174
R=jchaffraix@chromium.org, kenneth.r.christiansen@intel.com

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=151558

[kenneth.r.christiansen, 2013-05-28 13:30:55]

lgtm, but what about sticky positioned elements?

I mean, many sites try to accomplish sticky positioned elements using JavaScript
and we need to make sure that when the element is becoming absolutely
positioned, it doesn't suddenly loose any potential text enlargement.

[Julien - ping for review, 2013-05-29 21:53:39]

lgtm.

> lgtm, but what about sticky positioned elements?

I don't think we should be concerned about that yet. It was already broken and
currently there is no specification for the new position, which will slow down
adoption.

[johnme, 2013-05-30 10:35:31]

On 2013/05/28 13:30:55, kenneth.r.christiansen wrote:
> many sites try to accomplish sticky positioned elements using JavaScript
> and we need to make sure that when the element is becoming absolutely
> positioned, it doesn't suddenly loose any potential text enlargement.

I tested JS-emulated sticky positioning: http://jsbin.com/arumit/1
The "sticky" paragraph remains autosized even after it is set to
position:absolute.

I believe this is due to http://webkit.org/b/108205 locking the
textAutosizingMultiplier, so even though the text is no longer eligble
for autosizing, we don't make it smaller again. This seems reasonable.

In the reverse case, where a block starts off position:absolute then
stops being position:absolute, then it would presumably go from
not autosized to autosized, and then remain autosized even if it once
again becomes position:absolute. Not perfect, but not disastrous either.

The latter of these could probably be avoided by a smarter multiplier
locking algorithm, that not only locks autosized text, but also
locks non-autosized text after some delay (sufficient to allow styles
to resolve and layouts to occur). That would cause text that is
initially position:absolute to never get autosized...

As for true position:sticky, unlike absolute and fixed it should not
be considered as constraining the height of its contents, since unlike
absolute and fixed, sticky elements continue to reserve space in the
flow of their parent, hence unless they explicitly have a height or
max-height applied, it's relatively safe to assume they can grow
vertically.

[johnme, 2013-05-31 15:48:40]

Committed patchset #1 manually as r151558 (presubmit successful).