Descendants may become or cease to be spanners when an ancestor changes style.

Descendants may become or cease to be spanners when an ancestor changes style.

When building the tree, when inserting something that looks like a
column spanner, we first examine all the parents all the way up to the
multicol container, to make sure that they are all valid spanner
containers. This already works fine.

In our implementation, a valid column spanner container is, roughly, a
"regular" in-flow block. Among other things, it may not establish a
new block formatting context. Nor transforms. And a few other
things.

If the style of a valid column spanner container changes, it may end
up as no longer being a valid spanner container, and vice versa: an
invalid spanner container may become a valid spanner container, all of
a sudden.

Detect this during style change. If a block ceases to be a valid
spanner container, we need to check its subtree for spanners, and turn
them into regular column content. And, vice versa, if a block is
turned into a valid spanner container, we need to check its subtree
for column-span:all objects, which may have to be changed from regular
column content into spanners.

BUG=661761
Committed: https://crrev.com/d97ab241d0580e1a2478e07963faa0b1f0004c9b
Cr-Commit-Position: refs/heads/master@{#430005}

[mstensho (USE GERRIT), 2016-11-04 14:27:07]

The CQ bit was checked by mstensho@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-11-04 14:27:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-04 15:57:58]

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

[commit-bot: I haz the power, 2016-11-04 15:57:59]

Dry run: This issue passed the CQ dry run.

[mstensho (USE GERRIT), 2016-11-04 20:02:30]

Description was changed from

==========
Descendants may become or cease to be spanners when an ancestor changes style.

BUG=661761
==========

to

==========
Descendants may become or cease to be spanners when an ancestor changes style.

When building the tree, when inserting something that looks like a
column spanner, we first examine all the parents all the way up to the
multicol container, to make sure that they are all valid spanner
containers. This already works fine.

In our implementation, a valid column spanner container is, roughly, a
"regular" in-flow block. Among other things, it may not establish a
new block formatting context. Nor transforms. And a few other
things.

If the style of a valid column spanner container changes, it may end
up as no longer being a valid spanner container, and vice versa: an
invalid spanner container may become a valid spanner container, all of
a sudden.

Detect this during style change. If a block ceases to be a valid
spanner container, we need to check its subtree for spanners, and turn
them into regular column content. And, vice versa, if a block is
turned into a valid spanner container, we need to check its subtree
for column-span:all objects, which may have to be changed from regular
column content into spanners.

BUG=661761
==========

[mstensho (USE GERRIT), 2016-11-04 20:09:41]

mstensho@opera.com changed reviewers:
+ eae@chromium.org

[mstensho (USE GERRIT), 2016-11-04 20:09:42]

An inline continuation and a column spanner walk into a bar. Some time later, a
float knocks the spanner off the chair ...

Naaaaaah... this isn't gonna be funny, no matter how I sell it. :(

https://codereview.chromium.org/2479873002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/LayoutMultiColumnFlowThread.cpp
(right):

https://codereview.chromium.org/2479873002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutMultiColumnFlowThread.cpp:40: bool
LayoutMultiColumnFlowThread::s_toggleSpannersIfNeeded;
This is similar to the static bool s_affectsParentBlock mechanism in
LayoutObject. We need to maintain state between styleWillChange() and
styleDidChange() (and hope that the two are called in sequence on the same
layout object).

I don't think is pretty. Rather than this, should I fix LayoutObject, so that it
no longer needs s_affectsParentBlock? We could have styleWillChange() return a
context object that will be passed to the corresponding styleDidChange().

[eae, 2016-11-04 20:31:39]

Not the least bit funny sadly but at least it is well documented!
LGTM

[eae, 2016-11-04 20:32:46]

The CQ bit was checked by eae@chromium.org

[commit-bot: I haz the power, 2016-11-04 20:33:31]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-04 20:39:29]

Description was changed from

==========
Descendants may become or cease to be spanners when an ancestor changes style.

When building the tree, when inserting something that looks like a
column spanner, we first examine all the parents all the way up to the
multicol container, to make sure that they are all valid spanner
containers. This already works fine.

In our implementation, a valid column spanner container is, roughly, a
"regular" in-flow block. Among other things, it may not establish a
new block formatting context. Nor transforms. And a few other
things.

If the style of a valid column spanner container changes, it may end
up as no longer being a valid spanner container, and vice versa: an
invalid spanner container may become a valid spanner container, all of
a sudden.

Detect this during style change. If a block ceases to be a valid
spanner container, we need to check its subtree for spanners, and turn
them into regular column content. And, vice versa, if a block is
turned into a valid spanner container, we need to check its subtree
for column-span:all objects, which may have to be changed from regular
column content into spanners.

BUG=661761
==========

to

==========
Descendants may become or cease to be spanners when an ancestor changes style.

When building the tree, when inserting something that looks like a
column spanner, we first examine all the parents all the way up to the
multicol container, to make sure that they are all valid spanner
containers. This already works fine.

In our implementation, a valid column spanner container is, roughly, a
"regular" in-flow block. Among other things, it may not establish a
new block formatting context. Nor transforms. And a few other
things.

If the style of a valid column spanner container changes, it may end
up as no longer being a valid spanner container, and vice versa: an
invalid spanner container may become a valid spanner container, all of
a sudden.

Detect this during style change. If a block ceases to be a valid
spanner container, we need to check its subtree for spanners, and turn
them into regular column content. And, vice versa, if a block is
turned into a valid spanner container, we need to check its subtree
for column-span:all objects, which may have to be changed from regular
column content into spanners.

BUG=661761
==========

[commit-bot: I haz the power, 2016-11-04 20:39:30]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-04 20:42:34]

Description was changed from

==========
Descendants may become or cease to be spanners when an ancestor changes style.

When building the tree, when inserting something that looks like a
column spanner, we first examine all the parents all the way up to the
multicol container, to make sure that they are all valid spanner
containers. This already works fine.

In our implementation, a valid column spanner container is, roughly, a
"regular" in-flow block. Among other things, it may not establish a
new block formatting context. Nor transforms. And a few other
things.

If the style of a valid column spanner container changes, it may end
up as no longer being a valid spanner container, and vice versa: an
invalid spanner container may become a valid spanner container, all of
a sudden.

Detect this during style change. If a block ceases to be a valid
spanner container, we need to check its subtree for spanners, and turn
them into regular column content. And, vice versa, if a block is
turned into a valid spanner container, we need to check its subtree
for column-span:all objects, which may have to be changed from regular
column content into spanners.

BUG=661761
==========

to

==========
Descendants may become or cease to be spanners when an ancestor changes style.

When building the tree, when inserting something that looks like a
column spanner, we first examine all the parents all the way up to the
multicol container, to make sure that they are all valid spanner
containers. This already works fine.

In our implementation, a valid column spanner container is, roughly, a
"regular" in-flow block. Among other things, it may not establish a
new block formatting context. Nor transforms. And a few other
things.

If the style of a valid column spanner container changes, it may end
up as no longer being a valid spanner container, and vice versa: an
invalid spanner container may become a valid spanner container, all of
a sudden.

Detect this during style change. If a block ceases to be a valid
spanner container, we need to check its subtree for spanners, and turn
them into regular column content. And, vice versa, if a block is
turned into a valid spanner container, we need to check its subtree
for column-span:all objects, which may have to be changed from regular
column content into spanners.

BUG=661761

Committed: https://crrev.com/d97ab241d0580e1a2478e07963faa0b1f0004c9b
Cr-Commit-Position: refs/heads/master@{#430005}
==========

[commit-bot: I haz the power, 2016-11-04 20:42:35]

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