Implement proposed shadow tree cascade order.

Implement proposed shadow tree cascade order.

This CL implements the shadow tree cascade order proposed in [1].

Previously, in Blink, specificity would win over scope origin, even if the
scopes had an inner/outer scope relationship, and the order-of-appearance
was governed by the CascadeOrder type. Also, !important rules did not
apply in the reverse scope order, as the current spec says for inner/outer
scopes, and the proposal in [1] says apply between all shadow scopes.

What has been done is:

1. CascadeOrder is dropped, as it represented order-of-appearance

2. When collecting rules, sort after each scope instead of just after UA
   and Author since we had:

   UA important
   Author important
   Author
   UA

   and now we have (with A(n) appearing before A(n+1) in the tree-of-trees
   order):

   UA important
   Author scope A(n) important
   ...
   Author scope A(1) important
   Author scope A(1)
   ...
   Author scope A(n)
   UA

   There is bit of convenience functionality added around MatchResult and
   rule ranges to make the code for applying rule ranges in the reverse
   order for !important declarations cleaner.

   The applyProperties code is hot, and I have made performance runs for
   the micro-benchmarks in Layout and CSS without consistent regressions.

3. TreeBoundaryCrossingRules is now reduced to a DocumentOrderedList of
   scoping nodes, so the TreeBoundaryCrossingRules class is removed.

4. Since the cascading order between scopes are just the inner/outer
   relationship in the composed tree (direction decided by !important),
   which is the same as the tree-of-trees order of the shadow trees,
   we can just traverse the DocumentOrderedList of scopes in the reverse
   order instead of doing calculation tricks for CascadeOrder values.

[1] https://lists.w3.org/Archives/Public/www-style/2015Jun/0303.html

BUG=452542, 455148, 487125

[rune, 2015-08-05 08:29:38]

rune@opera.com changed reviewers:
+ hayato@chromium.org, takayoshi.kochi@gmail.com, timloh@chromium.org

[rune, 2015-08-05 08:29:39]

Ready for review.

[rune, 2015-08-05 08:33:35]

rune@opera.com changed reviewers:
+ kochi@chromium.org
- takayoshi.kochi@gmail.com

[kochi, 2015-08-05 09:35:09]

Thanks, I'll take a look.

+tasak FYI

[kochi, 2015-08-10 04:48:19]

On 2015/08/05 09:35:09, Takayoshi Kochi wrote:
> Thanks, I'll take a look.
> 
> +tasak FYI

Hi Rune,
Sorry for taking long to review.
I'm still understanding the CL but will send first round of comments today.

In the meantime, could you break down this CL into pieces unless this CL as a
whole
has to be committed at once so as not to break anything?
E.g. obvious changes first, then split changes into independent ones which can
be
applied in order?

[rune, 2015-08-10 07:07:40]

On 2015/08/10 04:48:19, Takayoshi Kochi wrote:
> On 2015/08/05 09:35:09, Takayoshi Kochi wrote:
> > Thanks, I'll take a look.
> > 
> > +tasak FYI
> 
> Hi Rune,
> Sorry for taking long to review.
> I'm still understanding the CL but will send first round of comments today.
> 
> In the meantime, could you break down this CL into pieces unless this CL as a
> whole
> has to be committed at once so as not to break anything?
> E.g. obvious changes first, then split changes into independent ones which can
> be
> applied in order?

I should at least be able to split out the MatchResult and corresponding
modifications to applyPropertyChanges to prepare for multiple author ranges
without changing behavior. I'll see if I can split the other change further
after that.

[kochi, 2015-08-10 11:42:20]

On 2015/08/10 07:07:40, rune wrote:
> On 2015/08/10 04:48:19, Takayoshi Kochi wrote:
> > On 2015/08/05 09:35:09, Takayoshi Kochi wrote:
> > > Thanks, I'll take a look.
> > > 
> > > +tasak FYI
> > 
> > Hi Rune,
> > Sorry for taking long to review.
> > I'm still understanding the CL but will send first round of comments today.
> > 
> > In the meantime, could you break down this CL into pieces unless this CL as
a
> > whole
> > has to be committed at once so as not to break anything?
> > E.g. obvious changes first, then split changes into independent ones which
can
> > be
> > applied in order?
> 
> I should at least be able to split out the MatchResult and corresponding
> modifications to applyPropertyChanges to prepare for multiple author ranges
> without changing behavior. I'll see if I can split the other change further
> after that.

Thanks, that would be helpful!

[kochi, 2015-08-10 12:15:04]

Sorry for long delay, it would be much appreciated if
you could split this into smaller pieces.

Overall, the change looks good as we agreed on the direction,
clean and clear.

I'll take closer look.

https://codereview.chromium.org/1224673002/diff/40001/Source/core/css/resolve...
File Source/core/css/resolver/MatchResult.cpp (right):

https://codereview.chromium.org/1224673002/diff/40001/Source/core/css/resolve...
Source/core/css/resolver/MatchResult.cpp:60: void
MatchResult::closeOriginOrScope(bool isUAOrigin)
What is this function is expected to do?

I'm still learning, and it may be obvious but I cannot infer
what this is expected to do from the name.

https://codereview.chromium.org/1224673002/diff/40001/Source/core/css/resolve...
File Source/core/css/resolver/StyleResolver.cpp (right):

https://codereview.chromium.org/1224673002/diff/40001/Source/core/css/resolve...
Source/core/css/resolver/StyleResolver.cpp:378: ScopedStyleResolver*
StyleResolver::matchElementScopeRules(const Element& element,
ElementRuleCollector& collector, bool includeEmptyRules)
Can this be a static function, rather than a private member function of
StyleResolver?

[rune, 2015-08-10 13:16:54]

On 2015/08/10 11:42:20, Takayoshi Kochi wrote:
> On 2015/08/10 07:07:40, rune wrote:

> > I should at least be able to split out the MatchResult and corresponding
> > modifications to applyPropertyChanges to prepare for multiple author ranges
> > without changing behavior. I'll see if I can split the other change further
> > after that.
> 
> Thanks, that would be helpful!

I have done that in https://codereview.chromium.org/1282243002/ now, but I'm not
quite happy with it yet. I'll re-iterate on that before publishing.

[rune, 2015-08-18 13:34:15]

On 2015/08/10 13:16:54, rune wrote:
> On 2015/08/10 11:42:20, Takayoshi Kochi wrote:
> > On 2015/08/10 07:07:40, rune wrote:
> 
> > > I should at least be able to split out the MatchResult and corresponding
> > > modifications to applyPropertyChanges to prepare for multiple author
ranges
> > > without changing behavior. I'll see if I can split the other change
further
> > > after that.
> > 
> > Thanks, that would be helpful!
> 
> I have done that in https://codereview.chromium.org/1282243002/ now, but I'm
not
> quite happy with it yet. I'll re-iterate on that before publishing.

[1] has now landed. I've split the rest of this CL into [2] and [3]. Closing
this CL now.

[1] https://codereview.chromium.org/1282243002/
[2] https://codereview.chromium.org/1298173004/
[3] https://codereview.chromium.org/1291873005/