-
Notifications
You must be signed in to change notification settings - Fork 19
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
Align definition of numbers with CSS #23
Comments
I agree that MathML should align it's number parsing with HTML5. Looking at the referenced HTML spec, it appears that attributes can only be pos/neg decimal integers/floating point numbers. They can't be hex or octal except in colors. In looking at the MathML spec itself, it doesn't seem to allow hex digits anywhere except in colors (search for "hexadecimal"), so it seems like they are in alignment in at least intent. The RelaxNG schema might be off. I'm pretty sure that MathML 3 made an attempt to align its basic syntax parsing with HTML5. Of course, it might not have been perfect in doing so. |
The definitions are given here ; I think it corresponds to the RelaxNG schema. In particular for "number":
Not that this does not allow values like I reopened this since we need to update the specs/relaxng schema and write WPT tests for this. cc @bkardell |
See https://lists.w3.org/Archives/Public/public-mathml4/2019May/0006.html Keeping "need resolution" for now. I think we agreed someone should go over the list of number attributes and check carefully. |
"fw: Numbers like "5." is allowed in MathML currently, but not in CSS. Can |
Consensus was to follow CSS. |
Core spec now relies on
But some attributes still refer to MathML3 |
…core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23
…core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23
… some numbers are invalid in …, a=testonly Automatic update from web-platform-tests Update MathML tests for lengths now that some numbers are invalid in core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23 -- wpt-commits: a7bec3cae6324dfadbc93705eb8b119d550e094a wpt-pr: 17908
… some numbers are invalid in …, a=testonly Automatic update from web-platform-tests Update MathML tests for lengths now that some numbers are invalid in core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23 -- wpt-commits: a7bec3cae6324dfadbc93705eb8b119d550e094a wpt-pr: 17908
…. r=emilio See w3c/mathml#23 and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg This commit introduces a new preference option mathml.legacy_number_syntax.disabled to disable legacy MathML numbers (e.g. "1234.") that are not supported by CSS. This feature is now disabled by default. * test_bug553917.html is updated to check that such legacy values now cause an error message to be logged into the console when the feature is disabled. * Legacy MathML features are now disabled for WPT mathml test in a global __dir__.ini file. Removing legacy numbers allow to pass mathml/relations/css-styling/lengths-2.html Differential Revision: https://phabricator.services.mozilla.com/D42907 --HG-- extra : moz-landing-system : lando
…. r=emilio See w3c/mathml#23 and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg This commit introduces a new preference option mathml.legacy_number_syntax.disabled to disable legacy MathML numbers (e.g. "1234.") that are not supported by CSS. This feature is now disabled by default. * test_bug553917.html is updated to check that such legacy values now cause an error message to be logged into the console when the feature is disabled. * Legacy MathML features are now disabled for WPT mathml test in a global __dir__.ini file. Removing legacy numbers allow to pass mathml/relations/css-styling/lengths-2.html Differential Revision: https://phabricator.services.mozilla.com/D42907
…core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23
We have tests for that, so closing. |
… some numbers are invalid in …, a=testonly Automatic update from web-platform-tests Update MathML tests for lengths now that some numbers are invalid in core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23 -- wpt-commits: a7bec3cae6324dfadbc93705eb8b119d550e094a wpt-pr: 17908 UltraBlame original commit: ac0176e866080ef838ca94c26e556216aefcecfa
…. r=emilio See w3c/mathml#23 and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg This commit introduces a new preference option mathml.legacy_number_syntax.disabled to disable legacy MathML numbers (e.g. "1234.") that are not supported by CSS. This feature is now disabled by default. * test_bug553917.html is updated to check that such legacy values now cause an error message to be logged into the console when the feature is disabled. * Legacy MathML features are now disabled for WPT mathml test in a global __dir__.ini file. Removing legacy numbers allow to pass mathml/relations/css-styling/lengths-2.html Differential Revision: https://phabricator.services.mozilla.com/D42907 UltraBlame original commit: 8637163553058a09e835ee6d8e53a09735b1b1ec
… some numbers are invalid in …, a=testonly Automatic update from web-platform-tests Update MathML tests for lengths now that some numbers are invalid in core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23 -- wpt-commits: a7bec3cae6324dfadbc93705eb8b119d550e094a wpt-pr: 17908 UltraBlame original commit: ac0176e866080ef838ca94c26e556216aefcecfa
… some numbers are invalid in …, a=testonly Automatic update from web-platform-tests Update MathML tests for lengths now that some numbers are invalid in core. Basically things like "7.em", "-7.em" or "5" are now invalid. w3c/mathml#24 w3c/mathml#23 -- wpt-commits: a7bec3cae6324dfadbc93705eb8b119d550e094a wpt-pr: 17908 UltraBlame original commit: ac0176e866080ef838ca94c26e556216aefcecfa
…. r=emilio See w3c/mathml#23 and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg This commit introduces a new preference option mathml.legacy_number_syntax.disabled to disable legacy MathML numbers (e.g. "1234.") that are not supported by CSS. This feature is now disabled by default. * test_bug553917.html is updated to check that such legacy values now cause an error message to be logged into the console when the feature is disabled. * Legacy MathML features are now disabled for WPT mathml test in a global __dir__.ini file. Removing legacy numbers allow to pass mathml/relations/css-styling/lengths-2.html Differential Revision: https://phabricator.services.mozilla.com/D42907 UltraBlame original commit: 8637163553058a09e835ee6d8e53a09735b1b1ec
…. r=emilio See w3c/mathml#23 and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg This commit introduces a new preference option mathml.legacy_number_syntax.disabled to disable legacy MathML numbers (e.g. "1234.") that are not supported by CSS. This feature is now disabled by default. * test_bug553917.html is updated to check that such legacy values now cause an error message to be logged into the console when the feature is disabled. * Legacy MathML features are now disabled for WPT mathml test in a global __dir__.ini file. Removing legacy numbers allow to pass mathml/relations/css-styling/lengths-2.html Differential Revision: https://phabricator.services.mozilla.com/D42907 UltraBlame original commit: 8637163553058a09e835ee6d8e53a09735b1b1ec
"The definition of numbers is also not very accurate in the MathML
recommendation compared to HTML5. One has to check the RelaxNG schemas
and the predefined RelaxNG types to know the exact syntax. Again, it
think it would be best to rely on the HTML5 definitions. For example,
<math><mspace width="1E1em" height="10em" mathbackground="red"/></math>
draws a red square in WebKit but Gecko says "1E1em" is invalid.
https://www.w3.org/TR/html5/infrastructure.html#numbers"
original report: https://lists.w3.org/Archives/Public/www-math/2016Aug/0000.html
The text was updated successfully, but these errors were encountered: