[Webkit-unassigned] [Bug 163542] Rename setNeedsStyleRecalc to invalidateStyle

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=163542

--- Comment #5 from Antti Koivisto <koivisto at iki.fi> ---
> I don’t understand why this check is correct. I think this needs a  “why”
> comment.

I don't really know either (for the latter part).

> > Source/WebCore/dom/Node.h:322
> > +    void clearNeedsStyleRecalc() { clearStyleInvalidation(); }
> 
> This function seems to have a peculiar name now that it’s not paired with a
> setNeedsStyleRecalc function. Do we really need to keep it?

Eliminating all NeedsStyleRecalc terminology is bit too much for one patch. This is just where the line is drawn for this one.

> Needs a comma after the word "dynamically". But also, what exactly does
> "used dynamically" mean? Can we say that in a more straightforward way?

I mean "changed after initialization".

> The word "scope" makes sense when telling something to invalidate. But not
> as much sense when it’s indicating how much is invalid. It’s also unclear to
> me that when renderers are "invalidated" that also means the entire subtree
> is invalidated. Maybe all this is more obvious to someone working in this
> area, but I am not so sure.

I'm not entirely happy with the names. Suggestions are welcome. Value 'InvalidationScope::Element' indicates that the style of the element where it is set is invalid. Value 'Subtree' indicates that the element and also all its descendants are invalid. Value 'Renderers' indicates that the renderers for the subtree are invalid and need to be rebuild (also recomputing subtree styles).

> > Source/WebCore/style/StyleTreeResolver.cpp:236
> > +    if (update.change != Detach && (parent().change == Force || element.styleInvalidationScope() == InvalidationScope::Subtree))
> 
> Why is "==" right here? What about the Renderers case?

In Renderers case update.change == Detach. But it could as well be >=.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161017/01c2e376/attachment.html>