[cascade] Simplify initial, inherited and invalid variables.
The current approach is quite confusing and inconsistent. The value nullptr means too many different things, depending on the situation. This CL introduces a new, hopefully clearer model, where nullptr always means invalid at computed-value-time, and base::nullopt means "no entry found". This means that, if a ComputedStyle has a present entry of 'nullptr' for a given custom property, we do not e.g. fall back to values from StyleInitialData. However, if there is no entry (base::nullopt), we look up values from the root-bucket (see StyleInheritedVariables), and/or StyleInitialData. A consequence of this approach, is that explicitly applied initial and inherited values must actually be present on the ComputedStyle; we can not return to a state of base::nullopt. This is because of the root-bucket optimization of StyleInheritedVariables, which makes it impossible to actually erase a value in all cases. (We actually don't have the same restriction for StyleNonInheritedVariables, but the behavior is the same, for simplicity). Another change in this CL, is that StyleInitialData now has the initial "data" as well as the initial "values". This is again to avoid that nullptr has different meanings. If we didn't store the initial data, we could end up with a nullptr for registered properties with an implicitly initial value. This is incompatible with the "nullptr means nullptr" idea. Note that CSSInvalidVariableValue isn't technically needed anymore after this CL, but since it's going to be useful for the Cascade project (during the application phase only, not as a persistently stored object), I'd like to keep it. It has a unit tests, so it's not completely unused. BUG=947004 R=futhark@chromium.org Change-Id: I4922f0d36f3d3d4fde6a25e56ef5c14c0c9890f5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1601135Reviewed-by:Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#657681}
Showing
Please register or sign in to comment