stylo: Properly support -moz-script-size-multiplier, -moz-script-level, and -moz-script-min-size #16539
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MozReview-Commit-ID: 4jWcugvXR65
|
Heads up! This PR modifies the following files:
|
highfive
added
the
S-awaiting-review
|
|
|
@bors-servo r=heycam |
|
📌 Commit 75dbe9c has been approved by |
highfive
added
S-awaiting-merge
bors-servo
pushed a commit
that referenced
this pull request
Apr 20, 2017
stylo: Properly support -moz-script-size-multiplier, -moz-script-level, and -moz-script-min-size r=heycam https://bugzilla.mozilla.org/show_bug.cgi?id=1355427 (copying over the relevant commit message so that it doesn't get lost in the vcssync) scriptlevel is a property that affects how font-size is inherited. If scriptlevel is +1, for example, it will inherit as the script size multiplier times the parent font. This does not affect cases where the font-size is explicitly set. However, this transformation is not allowed to reduce the size below scriptminsize. If this inheritance will reduce it to below scriptminsize, it will be set to scriptminsize or the parent size, whichever is smaller (the parent size could be smaller than the min size because it was explicitly specified). Now, within a node that has inherited a font-size which was crossing scriptminsize once the scriptlevel was applied, a negative scriptlevel may be used to increase the size again. This should work, however if we have already been capped by the scriptminsize multiple times, this can lead to a jump in the size. For example, if we have text of the form: huge large medium small tiny reallytiny tiny small medium huge which is represented by progressive nesting and scriptlevel values of +1 till the center after which the scriptlevel is -1, the "tiny"s should be the same size, as should be the "small"s and "medium"s, etc. However, if scriptminsize kicked it at around "medium", then medium/tiny/reallytiny will all be the same size (the min size). A -1 scriptlevel change after this will increase the min size by the multiplier, making the second tiny larger than medium. Instead, we wish for the second "tiny" to still be capped by the script level, and when we reach the second "large", it should be the same size as the original one. We do this by cascading two separate font sizes. The font size (mSize) is the actual displayed font size. The unconstrained font size (mScriptUnconstrainedSize) is the font size in the situation where scriptminsize never applied. We calculate the proposed inherited font size based on scriptlevel and the parent unconstrained size, instead of using the parent font size. This is stored in the node's unconstrained size and will also be stored in the font size provided that it is above the min size. All of this only applies when inheriting. When the font size is manually set, scriptminsize does not apply, and both the real and unconstrained size are set to the explicit value. However, if the font size is manually set to an em or percent unit, the unconstrained size will be set to the value of that unit computed against the parent unconstrained size, whereas the font size will be set computing against the parent font size.
|
💔 Test failed - linux-rel-wpt |
highfive
added
S-tests-failed
Manishearth
force-pushed
the
stylo-scriptminsize
branch
from
75dbe9c
to
f7b48eb
Compare
highfive
added
S-awaiting-review
scriptlevel is a property that affects how font-size is inherited. If scriptlevel is +1, for example, it will inherit as the script size multiplier times the parent font. This does not affect cases where the font-size is explicitly set. However, this transformation is not allowed to reduce the size below scriptminsize. If this inheritance will reduce it to below scriptminsize, it will be set to scriptminsize or the parent size, whichever is smaller (the parent size could be smaller than the min size because it was explicitly specified). Now, within a node that has inherited a font-size which was crossing scriptminsize once the scriptlevel was applied, a negative scriptlevel may be used to increase the size again. This should work, however if we have already been capped by the scriptminsize multiple times, this can lead to a jump in the size. For example, if we have text of the form: huge large medium small tiny reallytiny tiny small medium huge which is represented by progressive nesting and scriptlevel values of +1 till the center after which the scriptlevel is -1, the "tiny"s should be the same size, as should be the "small"s and "medium"s, etc. However, if scriptminsize kicked it at around "medium", then medium/tiny/reallytiny will all be the same size (the min size). A -1 scriptlevel change after this will increase the min size by the multiplier, making the second tiny larger than medium. Instead, we wish for the second "tiny" to still be capped by the script level, and when we reach the second "large", it should be the same size as the original one. We do this by cascading two separate font sizes. The font size (mSize) is the actual displayed font size. The unconstrained font size (mScriptUnconstrainedSize) is the font size in the situation where scriptminsize never applied. We calculate the proposed inherited font size based on scriptlevel and the parent unconstrained size, instead of using the parent font size. This is stored in the node's unconstrained size and will also be stored in the font size provided that it is above the min size. All of this only applies when inheriting. When the font size is manually set, scriptminsize does not apply, and both the real and unconstrained size are set to the explicit value. However, if the font size is manually set to an em or percent unit, the unconstrained size will be set to the value of that unit computed against the parent unconstrained size, whereas the font size will be set computing against the parent font size. MozReview-Commit-ID: 820BIWqno3L
Manishearth
force-pushed
the
stylo-scriptminsize
branch
from
f7b48eb
to
3162bab
Compare
|
@bors-servo r=heycam |
|
📌 Commit 3162bab has been approved by |
highfive
added
S-awaiting-merge
bors-servo
pushed a commit
that referenced
this pull request
Apr 20, 2017
stylo: Properly support -moz-script-size-multiplier, -moz-script-level, and -moz-script-min-size r=heycam https://bugzilla.mozilla.org/show_bug.cgi?id=1355427 (copying over the relevant commit message so that it doesn't get lost in the vcssync) scriptlevel is a property that affects how font-size is inherited. If scriptlevel is +1, for example, it will inherit as the script size multiplier times the parent font. This does not affect cases where the font-size is explicitly set. However, this transformation is not allowed to reduce the size below scriptminsize. If this inheritance will reduce it to below scriptminsize, it will be set to scriptminsize or the parent size, whichever is smaller (the parent size could be smaller than the min size because it was explicitly specified). Now, within a node that has inherited a font-size which was crossing scriptminsize once the scriptlevel was applied, a negative scriptlevel may be used to increase the size again. This should work, however if we have already been capped by the scriptminsize multiple times, this can lead to a jump in the size. For example, if we have text of the form: huge large medium small tiny reallytiny tiny small medium huge which is represented by progressive nesting and scriptlevel values of +1 till the center after which the scriptlevel is -1, the "tiny"s should be the same size, as should be the "small"s and "medium"s, etc. However, if scriptminsize kicked it at around "medium", then medium/tiny/reallytiny will all be the same size (the min size). A -1 scriptlevel change after this will increase the min size by the multiplier, making the second tiny larger than medium. Instead, we wish for the second "tiny" to still be capped by the script level, and when we reach the second "large", it should be the same size as the original one. We do this by cascading two separate font sizes. The font size (mSize) is the actual displayed font size. The unconstrained font size (mScriptUnconstrainedSize) is the font size in the situation where scriptminsize never applied. We calculate the proposed inherited font size based on scriptlevel and the parent unconstrained size, instead of using the parent font size. This is stored in the node's unconstrained size and will also be stored in the font size provided that it is above the min size. All of this only applies when inheriting. When the font size is manually set, scriptminsize does not apply, and both the real and unconstrained size are set to the explicit value. However, if the font size is manually set to an em or percent unit, the unconstrained size will be set to the value of that unit computed against the parent unconstrained size, whereas the font size will be set computing against the parent font size. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16539) <!-- Reviewable:end -->
|
☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css, mac-rel-wpt1, mac-rel-wpt2, windows-msvc-dev |
highfive
removed
the
S-awaiting-merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r=heycam https://bugzilla.mozilla.org/show_bug.cgi?id=1355427
(copying over the relevant commit message so that it doesn't get lost in the vcssync)
scriptlevel is a property that affects how font-size is inherited. If scriptlevel is
+1, for example, it will inherit as the script size multiplier times
the parent font. This does not affect cases where the font-size is
explicitly set.
However, this transformation is not allowed to reduce the size below
scriptminsize. If this inheritance will reduce it to below
scriptminsize, it will be set to scriptminsize or the parent size,
whichever is smaller (the parent size could be smaller than the min size
because it was explicitly specified).
Now, within a node that has inherited a font-size which was
crossing scriptminsize once the scriptlevel was applied, a negative
scriptlevel may be used to increase the size again.
This should work, however if we have already been capped by the
scriptminsize multiple times, this can lead to a jump in the size.
For example, if we have text of the form:
huge large medium small tiny reallytiny tiny small medium huge
which is represented by progressive nesting and scriptlevel values of
+1 till the center after which the scriptlevel is -1, the "tiny"s should
be the same size, as should be the "small"s and "medium"s, etc.
However, if scriptminsize kicked it at around "medium", then
medium/tiny/reallytiny will all be the same size (the min size).
A -1 scriptlevel change after this will increase the min size by the
multiplier, making the second tiny larger than medium.
Instead, we wish for the second "tiny" to still be capped by the script
level, and when we reach the second "large", it should be the same size
as the original one.
We do this by cascading two separate font sizes. The font size (mSize)
is the actual displayed font size. The unconstrained font size
(mScriptUnconstrainedSize) is the font size in the situation where
scriptminsize never applied.
We calculate the proposed inherited font size based on scriptlevel and
the parent unconstrained size, instead of using the parent font size.
This is stored in the node's unconstrained size and will also be stored
in the font size provided that it is above the min size.
All of this only applies when inheriting. When the font size is
manually set, scriptminsize does not apply, and both the real and
unconstrained size are set to the explicit value. However, if the font
size is manually set to an em or percent unit, the unconstrained size
will be set to the value of that unit computed against the parent
unconstrained size, whereas the font size will be set computing against
the parent font size.
This change is