Prioritize first-lines over orphans when deciding whether to propagate a strut.

Prioritize first-lines over orphans when deciding whether to propagate a strut.

The orphans code piece simply blindly propagates the strut to the block if the
orphans requirement isn't satisfied. It's incapable of inserting a break at a
class C break point [1] (i.e. before the first line in the block), while the
first-line code piece handles this just fine (since this is easy to do when at
the first line, but not when at a later line).

If we're at a non-first line at the time of breaking, there's no support for
going back to insert a break before the first line. That has to be done when
processing the first line, not later on. Flip the priority, so that orphans
requirements aren't even checked if we're at the first line. There's no need
then. We always try to avoid breaking before the first line anyway.

[1] https://drafts.csswg.org/css-break/#possible-breaks

Committed: https://crrev.com/26d004ea56c7db51b1dc19ba21670587604612d8
Cr-Commit-Position: refs/heads/master@{#388838}

[mstensho (USE GERRIT), 2016-04-21 18:39:53]

Description was changed from

==========
Being the first line is more relevant than being an orphan.
==========

to

==========
Prioritize first-lines over orphans when deciding whether to propagate a strut.

The orphans code piece simply blindly propagates the strut to the block if the
orphans requirement isn't satisfied. It's incapable of inserting a break at a
class C break point [1] (i.e. before the first line in the block), while the
first-line code piece handles this just fine (since this is easy to do when at
the first line, but not when at a later line).

If we're at a non-first line at the time of breaking, there's no support for
going back to insert a break before the first line. That has to be done when
processing the first line, not later on. Flip the priority, so that orphans
requirements aren't even checked if we're at the first line. There's no need
then. We always try to avoid breaking before the first line anyway.

[1] https://drafts.csswg.org/css-break/#possible-breaks
==========

[mstensho (USE GERRIT), 2016-04-21 18:43:12]

mstensho@opera.com changed reviewers:
+ eae@chromium.org, leviw@chromium.org, szager@chromium.org,
wkorman@chromium.org

[mstensho (USE GERRIT), 2016-04-21 18:43:13]

This doesn't really fix anything super-important, but I'm trying to fix bug
473509 (spec-compliant parsing of 'orphans' and 'widows'), and there are some
existing layout tests that would fail without this change then.

[eae, 2016-04-21 19:02:03]

LGTM

[eae, 2016-04-21 19:02:16]

The CQ bit was checked by eae@chromium.org

[commit-bot: I haz the power, 2016-04-21 19:03:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1908643003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1908643003/1

[commit-bot: I haz the power, 2016-04-21 19:09:32]

Description was changed from

==========
Prioritize first-lines over orphans when deciding whether to propagate a strut.

The orphans code piece simply blindly propagates the strut to the block if the
orphans requirement isn't satisfied. It's incapable of inserting a break at a
class C break point [1] (i.e. before the first line in the block), while the
first-line code piece handles this just fine (since this is easy to do when at
the first line, but not when at a later line).

If we're at a non-first line at the time of breaking, there's no support for
going back to insert a break before the first line. That has to be done when
processing the first line, not later on. Flip the priority, so that orphans
requirements aren't even checked if we're at the first line. There's no need
then. We always try to avoid breaking before the first line anyway.

[1] https://drafts.csswg.org/css-break/#possible-breaks
==========

to

==========
Prioritize first-lines over orphans when deciding whether to propagate a strut.

The orphans code piece simply blindly propagates the strut to the block if the
orphans requirement isn't satisfied. It's incapable of inserting a break at a
class C break point [1] (i.e. before the first line in the block), while the
first-line code piece handles this just fine (since this is easy to do when at
the first line, but not when at a later line).

If we're at a non-first line at the time of breaking, there's no support for
going back to insert a break before the first line. That has to be done when
processing the first line, not later on. Flip the priority, so that orphans
requirements aren't even checked if we're at the first line. There's no need
then. We always try to avoid breaking before the first line anyway.

[1] https://drafts.csswg.org/css-break/#possible-breaks
==========

[commit-bot: I haz the power, 2016-04-21 19:09:33]

Committed patchset #1 (id:1)

[wkorman, 2016-04-21 19:27:35]

lgtm

[commit-bot: I haz the power, 2016-04-22 19:37:10]

Description was changed from

==========
Prioritize first-lines over orphans when deciding whether to propagate a strut.

The orphans code piece simply blindly propagates the strut to the block if the
orphans requirement isn't satisfied. It's incapable of inserting a break at a
class C break point [1] (i.e. before the first line in the block), while the
first-line code piece handles this just fine (since this is easy to do when at
the first line, but not when at a later line).

If we're at a non-first line at the time of breaking, there's no support for
going back to insert a break before the first line. That has to be done when
processing the first line, not later on. Flip the priority, so that orphans
requirements aren't even checked if we're at the first line. There's no need
then. We always try to avoid breaking before the first line anyway.

[1] https://drafts.csswg.org/css-break/#possible-breaks
==========

to

==========
Prioritize first-lines over orphans when deciding whether to propagate a strut.

The orphans code piece simply blindly propagates the strut to the block if the
orphans requirement isn't satisfied. It's incapable of inserting a break at a
class C break point [1] (i.e. before the first line in the block), while the
first-line code piece handles this just fine (since this is easy to do when at
the first line, but not when at a later line).

If we're at a non-first line at the time of breaking, there's no support for
going back to insert a break before the first line. That has to be done when
processing the first line, not later on. Flip the priority, so that orphans
requirements aren't even checked if we're at the first line. There's no need
then. We always try to avoid breaking before the first line anyway.

[1] https://drafts.csswg.org/css-break/#possible-breaks

Committed: https://crrev.com/26d004ea56c7db51b1dc19ba21670587604612d8
Cr-Commit-Position: refs/heads/master@{#388838}
==========

[commit-bot: I haz the power, 2016-04-22 19:37:11]

Patchset 1 (id:??) landed as
https://crrev.com/26d004ea56c7db51b1dc19ba21670587604612d8
Cr-Commit-Position: refs/heads/master@{#388838}