Support tag names as invalidation set features.

Support tag names as invalidation set features.

We collected the tag names into the invalidation sets, but we never used them
for anything. This makes selectors like this use invalidation sets:

.class span {}

R=esprehn@chromium.org,chrishtr@chromium.org
BUG=335247
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=170807

[chrishtr, 2014-04-02 18:42:54]

Was thinking about this yesterday, in the context of my id patch. I'd feel
better if we first implement matching only all descendant invalidation set
values match. This will make matching more efficient in terms of elements
invalidated, and incidentally make this patch (or my patch from yesterday that
is not yet committed for ids) simpler, or actually I think not necessary at all
since it subsumes it I believe..

The change would be to refactor StyleResolver to use a vector of pending
DescendantInvalidationSets rather than vectors of class, attribute, etc.
individually. Then add a matches() method to DescendantInvalidation set that
checks against the whole set. (Elliot had this latter piece in his original
patch from January.)

[chrishtr, 2014-04-02 23:08:34]

Just talked with Elliot. His view is that my patch & this patch are steps
forward and avoid a weird performance cliff in style, so let's get them in
and then pursue the refactoring I mentioned. That reasoning sounds fine to
me.


On Wed, Apr 2, 2014 at 11:42 AM, <chrishtr@chromium.org> wrote:

> Was thinking about this yesterday, in the context of my id patch. I'd feel
> better if we first implement matching only all descendant invalidation set
> values match. This will make matching more efficient in terms of elements
> invalidated, and incidentally make this patch (or my patch from yesterday
> that
> is not yet committed for ids) simpler, or actually I think not necessary
> at all
> since it subsumes it I believe..
>
> The change would be to refactor StyleResolver to use a vector of pending
> DescendantInvalidationSets rather than vectors of class, attribute, etc.
> individually. Then add a matches() method to DescendantInvalidation set
> that
> checks against the whole set. (Elliot had this latter piece in his original
> patch from January.)
>
> https://codereview.chromium.org/222643002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[rune, 2014-04-03 06:52:52]

On 2014/04/02 23:08:34, chrishtr wrote:
> Just talked with Elliot. His view is that my patch & this patch are steps
> forward and avoid a weird performance cliff in style, so let's get them in
> and then pursue the refactoring I mentioned. That reasoning sounds fine to
> me.

Great!

[esprehn, 2014-04-03 09:58:04]

This needs to be updated following chrishtr's patch. It can't hurt to keep both
tests though.

[rune, 2014-04-03 10:45:46]

On 2014/04/03 09:58:04, esprehn wrote:
> This needs to be updated following chrishtr's patch. It can't hurt to keep
both
> tests though.

Rebased, kept the tests, and modified the CL description.

[esprehn, 2014-04-03 22:19:45]

lgtm

[commit-bot: I haz the power, 2014-04-03 22:19:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rune@opera.com/222643002/20001

[commit-bot: I haz the power, 2014-04-04 00:01:35]

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

[commit-bot: I haz the power, 2014-04-04 00:01:35]

Commit queue rejected this change because the description was changed
between the time the change entered the commit queue and the time it
was ready to commit. You can safely check the commit box again.

[esprehn, 2014-04-04 00:07:37]

The CQ bit was checked by esprehn@chromium.org

[commit-bot: I haz the power, 2014-04-04 00:07:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rune@opera.com/222643002/20001

[commit-bot: I haz the power, 2014-04-04 00:08:33]

Change committed as 170807