Use available width for replaced element with intrinsic ratio but no dimensions

Use available width for replaced element with intrinsic ratio but no dimensions

Prior to this patch, we walked up the ancestor chain to find a
specified width for replaced content with intrinsic ratio but no
intrinsic size nor any specified dimensions.

This is clearly wrong when the containing block has no specified width
but an implicitly set width through the constraint equation. In that
case we would walk past the containing block and possible find an
ancestor with specified width to size against.

An other illustration of why it's wrong in the context of a stf
container where we would possibly go outside the stf container to
fetch a width.

Both scenarios illustrated by tests.

After this patch, we instead always use the available width of the
container, to properly size inside a container with no specified size.

http://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width

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

[davve, 2014-06-23 14:44:04]

Philip, one more SVG sizing CSS thingy. I'm not sure why the code was so complex
as it was (and this worries me a bit), but I can't come up with a case where
using the available width of the container is the wrong thing to do. Also, I
find plenty of cases where firstContainingBlockWithLogicalWidth does the wrong
thing.

So this feels like the obvious thing to do now.

[pdr., 2014-06-24 20:53:47]

On 2014/06/23 14:44:04, David Vest wrote:
> Philip, one more SVG sizing CSS thingy. I'm not sure why the code was so
complex
> as it was (and this worries me a bit), but I can't come up with a case where
> using the available width of the container is the wrong thing to do. Also, I
> find plenty of cases where firstContainingBlockWithLogicalWidth does the wrong
> thing.
> 
> So this feels like the obvious thing to do now.

LGTM. This is old and crufty code :/ I agree with your points here.

[pdr., 2014-06-24 20:53:51]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2014-06-24 20:54:49]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/davve@opera.com/341773004/60001

[commit-bot: I haz the power, 2014-06-24 22:34:54]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_blink_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_dbg/builds/1...)
  linux_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/1...)
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/12641)
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/13419)

[commit-bot: I haz the power, 2014-06-24 23:00:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-06-24 23:00:35]

Try jobs failed on following builders:
  linux_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/1...)

[davve, 2014-06-25 14:00:31]

The CQ bit was checked by davve@opera.com

[commit-bot: I haz the power, 2014-06-25 14:00:56]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/davve@opera.com/341773004/80001

[commit-bot: I haz the power, 2014-06-25 15:06:12]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_blink_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_dbg/builds/1...)

[commit-bot: I haz the power, 2014-06-25 16:08:55]

Change committed as 176929