Interaction between height and baseline alignment #259
Labels
Comments
moz-wptsync-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 30, 2024
This patch implements support for the width/height properties on MathML elements [1]. The general algorithm from the spec is as follows: (1) The outcome of the math layout is a "math content box". (2) The content box sets its size from computed width/height values. If auto, it's the one of the "math content box". This patch ignores percentage values for now [2] [3]. (3) math content box is shifted so that its inline-start and top edges aligns with the ones of the content box. There are exceptions elements like mfrac and munder/mover/munderover which instead horizontally center the math content box within the content box. For baseline adjustment, we follow what Chromium does, see [4]. (4) Padding+border are added around the content box. Note that we ignore the box-sizing property for now [5]. The patch essentially tweaks the various MathML layout algorithms to perform steps (3) and (4) before the calls to GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics. [1] https://w3c.github.io/mathml-core/#layout-algorithms [2] w3c/mathml-core#76 [3] w3c/mathml-core#77 [4] w3c/mathml-core#259 [5] w3c/mathml-core#257 Below is more information about test coverage: - width-height-001: Verify that width, height, inline-size and block-size properties sets the size of the content box. This test used to verify they are ignored, this patch fixes the `<meta name="assert">` tag. It also adds a test for the case the specified size is smaller than the content (we force non empty descendants to make sure this content is large enough) and to verify the width is used for the preferred width. - width-height-002, width-height-003: These are reftests visually checking offsets of the math content box within a larger content box (specified by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot, in LTR/RTL modes. In particular they allow to verify some painted elements like fraction bar and radical symbols. - width-height-004: This test more directly checks that the math content box is horizontally centered within a larger content box for munder, mover, munderover and mfrac. This patch extends the test to cover the case when the math content box is wider (i.e. overflowing outside the content box) and removes unnecessary specified height. - width-height-005: New test for other layout algorithm that don't center the math content box, checking inline-start edges of children when a width is specified. We check both LTR/RTL modes and wider/narrower content boxes. - width-height-006: Same but checking the top edges for larger/smaller height and verifying that baseline is perserved. Differential Revision: https://phabricator.services.mozilla.com/D221436 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1916988 gecko-commit: dc848382811227e2f040f438794da638b8792f5b gecko-reviewers: emilio
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Sep 30, 2024
… r=emilio This patch implements support for the width/height properties on MathML elements [1]. The general algorithm from the spec is as follows: (1) The outcome of the math layout is a "math content box". (2) The content box sets its size from computed width/height values. If auto, it's the one of the "math content box". This patch ignores percentage values for now [2] [3]. (3) math content box is shifted so that its inline-start and top edges aligns with the ones of the content box. There are exceptions elements like mfrac and munder/mover/munderover which instead horizontally center the math content box within the content box. For baseline adjustment, we follow what Chromium does, see [4]. (4) Padding+border are added around the content box. Note that we ignore the box-sizing property for now [5]. The patch essentially tweaks the various MathML layout algorithms to perform steps (3) and (4) before the calls to GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics. [1] https://w3c.github.io/mathml-core/#layout-algorithms [2] w3c/mathml-core#76 [3] w3c/mathml-core#77 [4] w3c/mathml-core#259 [5] w3c/mathml-core#257 Below is more information about test coverage: - width-height-001: Verify that width, height, inline-size and block-size properties sets the size of the content box. This test used to verify they are ignored, this patch fixes the `<meta name="assert">` tag. It also adds a test for the case the specified size is smaller than the content (we force non empty descendants to make sure this content is large enough) and to verify the width is used for the preferred width. - width-height-002, width-height-003: These are reftests visually checking offsets of the math content box within a larger content box (specified by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot, in LTR/RTL modes. In particular they allow to verify some painted elements like fraction bar and radical symbols. - width-height-004: This test more directly checks that the math content box is horizontally centered within a larger content box for munder, mover, munderover and mfrac. This patch extends the test to cover the case when the math content box is wider (i.e. overflowing outside the content box) and removes unnecessary specified height. - width-height-005: New test for other layout algorithm that don't center the math content box, checking inline-start edges of children when a width is specified. We check both LTR/RTL modes and wider/narrower content boxes. - width-height-006: Same but checking the top edges for larger/smaller height and verifying that baseline is perserved. Differential Revision: https://phabricator.services.mozilla.com/D221436
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Oct 1, 2024
… r=emilio This patch implements support for the width/height properties on MathML elements [1]. The general algorithm from the spec is as follows: (1) The outcome of the math layout is a "math content box". (2) The content box sets its size from computed width/height values. If auto, it's the one of the "math content box". This patch ignores percentage values for now [2] [3]. (3) math content box is shifted so that its inline-start and top edges aligns with the ones of the content box. There are exceptions elements like mfrac and munder/mover/munderover which instead horizontally center the math content box within the content box. For baseline adjustment, we follow what Chromium does, see [4]. (4) Padding+border are added around the content box. Note that we ignore the box-sizing property for now [5]. The patch essentially tweaks the various MathML layout algorithms to perform steps (3) and (4) before the calls to GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics. [1] https://w3c.github.io/mathml-core/#layout-algorithms [2] w3c/mathml-core#76 [3] w3c/mathml-core#77 [4] w3c/mathml-core#259 [5] w3c/mathml-core#257 Below is more information about test coverage: - width-height-001: Verify that width, height, inline-size and block-size properties sets the size of the content box. This test used to verify they are ignored, this patch fixes the `<meta name="assert">` tag. It also adds a test for the case the specified size is smaller than the content (we force non empty descendants to make sure this content is large enough) and to verify the width is used for the preferred width. - width-height-002, width-height-003: These are reftests visually checking offsets of the math content box within a larger content box (specified by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot, in LTR/RTL modes. In particular they allow to verify some painted elements like fraction bar and radical symbols. - width-height-004: This test more directly checks that the math content box is horizontally centered within a larger content box for munder, mover, munderover and mfrac. This patch extends the test to cover the case when the math content box is wider (i.e. overflowing outside the content box) and removes unnecessary specified height. - width-height-005: New test for other layout algorithm that don't center the math content box, checking inline-start edges of children when a width is specified. We check both LTR/RTL modes and wider/narrower content boxes. - width-height-006: Same but checking the top edges for larger/smaller height and verifying that baseline is perserved. Differential Revision: https://phabricator.services.mozilla.com/D221436 UltraBlame original commit: dc848382811227e2f040f438794da638b8792f5b
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Oct 1, 2024
… r=emilio This patch implements support for the width/height properties on MathML elements [1]. The general algorithm from the spec is as follows: (1) The outcome of the math layout is a "math content box". (2) The content box sets its size from computed width/height values. If auto, it's the one of the "math content box". This patch ignores percentage values for now [2] [3]. (3) math content box is shifted so that its inline-start and top edges aligns with the ones of the content box. There are exceptions elements like mfrac and munder/mover/munderover which instead horizontally center the math content box within the content box. For baseline adjustment, we follow what Chromium does, see [4]. (4) Padding+border are added around the content box. Note that we ignore the box-sizing property for now [5]. The patch essentially tweaks the various MathML layout algorithms to perform steps (3) and (4) before the calls to GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics. [1] https://w3c.github.io/mathml-core/#layout-algorithms [2] w3c/mathml-core#76 [3] w3c/mathml-core#77 [4] w3c/mathml-core#259 [5] w3c/mathml-core#257 Below is more information about test coverage: - width-height-001: Verify that width, height, inline-size and block-size properties sets the size of the content box. This test used to verify they are ignored, this patch fixes the `<meta name="assert">` tag. It also adds a test for the case the specified size is smaller than the content (we force non empty descendants to make sure this content is large enough) and to verify the width is used for the preferred width. - width-height-002, width-height-003: These are reftests visually checking offsets of the math content box within a larger content box (specified by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot, in LTR/RTL modes. In particular they allow to verify some painted elements like fraction bar and radical symbols. - width-height-004: This test more directly checks that the math content box is horizontally centered within a larger content box for munder, mover, munderover and mfrac. This patch extends the test to cover the case when the math content box is wider (i.e. overflowing outside the content box) and removes unnecessary specified height. - width-height-005: New test for other layout algorithm that don't center the math content box, checking inline-start edges of children when a width is specified. We check both LTR/RTL modes and wider/narrower content boxes. - width-height-006: Same but checking the top edges for larger/smaller height and verifying that baseline is perserved. Differential Revision: https://phabricator.services.mozilla.com/D221436 UltraBlame original commit: dc848382811227e2f040f438794da638b8792f5b
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Oct 1, 2024
… r=emilio This patch implements support for the width/height properties on MathML elements [1]. The general algorithm from the spec is as follows: (1) The outcome of the math layout is a "math content box". (2) The content box sets its size from computed width/height values. If auto, it's the one of the "math content box". This patch ignores percentage values for now [2] [3]. (3) math content box is shifted so that its inline-start and top edges aligns with the ones of the content box. There are exceptions elements like mfrac and munder/mover/munderover which instead horizontally center the math content box within the content box. For baseline adjustment, we follow what Chromium does, see [4]. (4) Padding+border are added around the content box. Note that we ignore the box-sizing property for now [5]. The patch essentially tweaks the various MathML layout algorithms to perform steps (3) and (4) before the calls to GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics. [1] https://w3c.github.io/mathml-core/#layout-algorithms [2] w3c/mathml-core#76 [3] w3c/mathml-core#77 [4] w3c/mathml-core#259 [5] w3c/mathml-core#257 Below is more information about test coverage: - width-height-001: Verify that width, height, inline-size and block-size properties sets the size of the content box. This test used to verify they are ignored, this patch fixes the `<meta name="assert">` tag. It also adds a test for the case the specified size is smaller than the content (we force non empty descendants to make sure this content is large enough) and to verify the width is used for the preferred width. - width-height-002, width-height-003: These are reftests visually checking offsets of the math content box within a larger content box (specified by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot, in LTR/RTL modes. In particular they allow to verify some painted elements like fraction bar and radical symbols. - width-height-004: This test more directly checks that the math content box is horizontally centered within a larger content box for munder, mover, munderover and mfrac. This patch extends the test to cover the case when the math content box is wider (i.e. overflowing outside the content box) and removes unnecessary specified height. - width-height-005: New test for other layout algorithm that don't center the math content box, checking inline-start edges of children when a width is specified. We check both LTR/RTL modes and wider/narrower content boxes. - width-height-006: Same but checking the top edges for larger/smaller height and verifying that baseline is perserved. Differential Revision: https://phabricator.services.mozilla.com/D221436 UltraBlame original commit: dc848382811227e2f040f438794da638b8792f5b
fred-wang
added a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 1, 2024
This patch implements support for the width/height properties on MathML elements [1]. The general algorithm from the spec is as follows: (1) The outcome of the math layout is a "math content box". (2) The content box sets its size from computed width/height values. If auto, it's the one of the "math content box". This patch ignores percentage values for now [2] [3]. (3) math content box is shifted so that its inline-start and top edges aligns with the ones of the content box. There are exceptions elements like mfrac and munder/mover/munderover which instead horizontally center the math content box within the content box. For baseline adjustment, we follow what Chromium does, see [4]. (4) Padding+border are added around the content box. Note that we ignore the box-sizing property for now [5]. The patch essentially tweaks the various MathML layout algorithms to perform steps (3) and (4) before the calls to GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics. [1] https://w3c.github.io/mathml-core/#layout-algorithms [2] w3c/mathml-core#76 [3] w3c/mathml-core#77 [4] w3c/mathml-core#259 [5] w3c/mathml-core#257 Below is more information about test coverage: - width-height-001: Verify that width, height, inline-size and block-size properties sets the size of the content box. This test used to verify they are ignored, this patch fixes the `<meta name="assert">` tag. It also adds a test for the case the specified size is smaller than the content (we force non empty descendants to make sure this content is large enough) and to verify the width is used for the preferred width. - width-height-002, width-height-003: These are reftests visually checking offsets of the math content box within a larger content box (specified by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot, in LTR/RTL modes. In particular they allow to verify some painted elements like fraction bar and radical symbols. - width-height-004: This test more directly checks that the math content box is horizontally centered within a larger content box for munder, mover, munderover and mfrac. This patch extends the test to cover the case when the math content box is wider (i.e. overflowing outside the content box) and removes unnecessary specified height. - width-height-005: New test for other layout algorithm that don't center the math content box, checking inline-start edges of children when a width is specified. We check both LTR/RTL modes and wider/narrower content boxes. - width-height-006: Same but checking the top edges for larger/smaller height and verifying that baseline is perserved. Differential Revision: https://phabricator.services.mozilla.com/D221436 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1916988 gecko-commit: dc848382811227e2f040f438794da638b8792f5b gecko-reviewers: emilio Co-authored-by: Frédéric Wang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follow-up of #75
I've worked on the Firefox implementation of width/height, tried to follow what MathML Core / Chromium do and I'm adding missing test coverage.
I just uploaded a testcase for various situations: https://bug1916988.bmoattachments.org/attachment.cgi?id=9425482
One behavior I'm not sure is what happens when we specify a CSS height that is smaller than the line-ascent. It seems Chrome sets the corresponding height and does not clamp the line-ascent, so baseline alignment with other siblings stay the same. I think that makes sense to me and that's what I'm implementing in Firefox, but we might need some extra text is the spec to clarify.
Related to that, when we specify a height for the "content box" that is different from the one of the "math content box", then MathML Core (and Chromium, in what I'm implementing in Firefox and in WPT tests I'm adding) says to align the top edges of these boxes. But maybe what is more natural is to tweak the line-ascent/line-descent evenly so that the baseline is unchanged.
The text was updated successfully, but these errors were encountered: