-
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
mpadded and resolution of percentage values #227
Comments
Discussed at the Core CG meeting today. Looking at usage stats, no one is reporting usage of %'s. @rwlbuis reported Google only has an issue with 'width', but it seems weird to support depth/height and not width. We didn't discuss The meeting resolved that '%' should be removed completely from mpadded in core. They should remain in full and the polyfill should handle them (it already handles cross width - height/depth values).. |
@rwlbuis We can't "remove %" since they are defined for CSS lengths. Instead, we need a way to interpret these values. I assume the suggestion is to handle them the same as what is done for "absent or invalid" in the spec so I'll do this. How did you implement this in chromium? Do you have WPT tests? |
I updated the spec to treat % as invalid/unspecified. This seems to match rob's tests. @rwlbuis voffset/lspace attributes are not tested by web-platform-tests/wpt#24664 ; what's the decision here? |
I think it is best to treat voffset/lspace attributes same as the width attribute regarding percentages. I updated the test for that: |
Removing all references to % in mpadded attrs for core is what the group decided. It is weird to allow them in only some cases. The polyfill was updated to convert all %s to pixels. |
I think you will have to use some Javascript to do this, which potentially is done by including the mpadded polyfill. Your other alternative, which I don't recommend, is to use the polyfill, convert the position it comes up for your specific cases to a font relative unit such as 'ex's, and then use those in your code. I think it will get it close to right, but I doubt it will be exactly right in all situations. If you have lots of expression, that probably doesn't work for you. |
@NSoiffer Thank you for the link to the polyfill. It contains some interesting techniques. After a polyfill-mpadded has set the vertical alignment of the fraction, I believe a reflow would then be necessary to properly set the height and depth of the parentheses around the fraction shown above. (Correct me if that is wrong.) Of course, we all want to avoid a reflow. It is very late to introduce a new attribute for the ongoing effort, but I hope that some kind |
Unfortunately, without support for percentages, reflow is required. I'm a little dubious that a From a usage point of view, it seems hard to imagine it crosses the bar to get into core. Getting it into MathML 4 (and hence having a polyfill pre-built) is possibly more doable. I suggest you file a separate issue for that and provide use cases (from a TeX macro?) and maybe usage statistics if you can find them. Those could make a compelling case if there is significant usage. |
Since support of % in mpadded attrs is no longer part of core, I removed the needs tests, etc labels. The spec seems up to date. The polyfill implments %s, so I am closing this issue. |
cc @bfgeek @rwlbuis
This came up during chrome review.
Currently the spec follows MathML3 i.e. relative width/height/depth refer to the default size i.e. the size of its content.
In CSS, percentage refers to the size of the block container.
If we map MathML attributes to CSS this does not work.
So it looks like core level 1 should restrict more mpadded or things rewritten.
See also #103 #50 #45 #185
The text was updated successfully, but these errors were encountered: