Separate specified and effective writing-mode [chromium/src : master]
Xianzhu Wang (Gerrit)
Xianzhu Wang posted comments on this change.
Patch set 2:Commit-Queue +1
To view, visit change 547368. To unsubscribe, visit settings.
Xianzhu Wang (Gerrit)
Xianzhu Wang posted comments on this change.
Patch set 3:Commit-Queue +1
Xianzhu Wang (Gerrit)
Xianzhu Wang uploaded patch set #4 to this change.
Separate specified and effective writing-mode
Some table components need to use the table's writing-mode, while
still need the specified writing-mode for getComputedStyle() API and
inheritance.
BUG=736093
Change-Id: I878de77af4ff201475a3158a9877b99c9ce44eac
---
A third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-writing-mode-table.html
M third_party/WebKit/Source/core/css/CSSProperties.json5
M third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp
M third_party/WebKit/Source/core/css/ComputedStyleExtraFields.json5
M third_party/WebKit/Source/core/css/resolver/MatchedPropertiesCache.cpp
M third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
M third_party/WebKit/Source/core/css/resolver/StyleResolverState.h
M third_party/WebKit/Source/core/style/ComputedStyle.h
8 files changed, 96 insertions(+), 6 deletions(-)
To view, visit change 547368. To unsubscribe, visit settings.
Xianzhu Wang (Gerrit)
Xianzhu Wang would like nainar to review this change.
Separate specified and effective writing-mode
Some table components need to use the table's writing-mode, while
still need the specified writing-mode for getComputedStyle() API and
inheritance.
BUG=736093
Change-Id: I878de77af4ff201475a3158a9877b99c9ce44eac
---
A third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-writing-mode-table.html
M third_party/WebKit/Source/core/css/CSSProperties.json5
M third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp
M third_party/WebKit/Source/core/css/ComputedStyleExtraFields.json5
M third_party/WebKit/Source/core/css/resolver/MatchedPropertiesCache.cpp
M third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
M third_party/WebKit/Source/core/css/resolver/StyleResolverState.h
M third_party/WebKit/Source/core/style/ComputedStyle.h
8 files changed, 96 insertions(+), 6 deletions(-)
To view, visit change 547368. To unsubscribe, visit settings.
Rune Lillesveen (Gerrit)
Rune Lillesveen posted comments on this change.
Patch set 4:
To what extent do we need to store the used value for table display elements in ComputedStyle?
Since you're hiding the used (effective) value in GetWritingMode(), it's not obvious from this patch where this matters, but could this be handled by logic in the table layout code instead? Would that be expensive/much code?
I think I would've used the CSS terms computed/used instead of specified/effective.
Xianzhu Wang (Gerrit)
Xianzhu Wang posted comments on this change.
Patch set 4:
+kojii
Patch Set 4:
To what extent do we need to store the used value for table display elements in ComputedStyle?
Since you're hiding the used (effective) value in GetWritingMode(), it's not obvious from this patch where this matters, but could this be handled by logic in the table layout code instead? Would that be expensive/much code?
I think I would've used the CSS terms computed/used instead of specified/effective.
Your questions let me think of how we should categorize the "effective" values of 'direction' and 'writing-mode' of the table components. It seems that they may be something between computed values and used values, depending on how we define their effects on computed values of other properties depending on them.
For example,
<table>
<tr id="tr" style="writing-mode: vertical-rl">
...
</tr>
</table>
What should "getComputedStyle(tr).inlineSize" evaluate?
I'm not sure what the best definition of the above behavior is, but it seems most convenient to let these properties depend on the "effective"[1] values of 'direction' and 'writing-mode' instead of their specified/computed values, otherwise we would need another whole set of functions (besides the many current direction-aware ComputedStyle methods) to convert the results from specified/computed direction/writing-mode to used direction/writing-mode.
[1] I still use "effective" because under this definition, it affects computed values of other properties so it's not just "used". It's also not "computed" because according to the definition of computed style, the computed value should be the specified value. Perhaps we should define a special computed value rule for writing-mode/direction of the table components to use the "effective" values as their computed values?
Xianzhu Wang (Gerrit)
Please hold off on reviewing this CL.
This implementation may cause trouble of future implementation of logical properties (https://drafts.csswg.org/css-logical). I've sent an email to www-style (https://lists.w3.org/Archives/Public/www-style/2017Jun/0030.html) for clarification.
nainar (Gerrit)
nainar posted comments on this change.
Patch set 4:
Taking myself off so it doesnt show in my incoming stack. Please add me back when ready for review
Xianzhu Wang (Gerrit)
Xianzhu Wang abandoned this change.
To view, visit change 547368. To unsubscribe, visit settings.