Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider support for the box-sizing property #257

Open
fred-wang opened this issue Sep 5, 2024 · 0 comments
Open

Consider support for the box-sizing property #257

fred-wang opened this issue Sep 5, 2024 · 0 comments

Comments

@fred-wang
Copy link
Contributor

box-sizing property was mentioned on #75

I think spec and chrome ignores it for MathML, but we might want to support it.

Just opening this issue not to forget about it.

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
Projects
None yet
Development

No branches or pull requests

1 participant