search

w3c / mathml-core

MathML Core draft
https://w3c.github.io/mathml-core
38 stars 14 forks source link

Consider integrating scriptlevel into font-size #62

Closed fred-wang closed 2 years ago

fred-wang commented 4 years ago

cc @fantasai

Instead of having a separate math-level property, we could integrate it into font-size as a function.

NSoiffer commented 4 years ago

Could you be more explicit about what you are proposing. I suspect I know what you are getting at, but I could easily be thinking of something else and in either case, I don't know how you would integrate that into font-size without some sort of math-level value.

fred-wang commented 4 years ago

I think the proposal was to introduce new function values for font-size.

fred-wang commented 4 years ago

@rwlbuis has a first implementation of fantasai's proposal in Chromium. But this still needs to be formalized in the spec.

fred-wang commented 4 years ago

The spec has been updated to use an extension of font-size based on @fantasai 's suggestion and @rwlbuis 's implementation. We still need to review and update the tests.

NSoiffer commented 4 years ago

I don't see the proposed changes are valid CSS in either CSS Fonts Module Level 4 or the editor's draft of that WD. Where in the CSS process is @fantasai 's suggestion? Correct me if I'm wrong, but I think the other proposed extensions to CSS can be mapped to internal CSS properties if they don't get accepted by CSS in the near future. Since this uses an existing CSS property, is that approach feasible? If not, what's the fallback?

fred-wang commented 4 years ago

Some notes on the new approach based on fantasai's suggestion.

First although one cannot arbitrarily set the scriptlevel via CSS, it is still possible to nest two math tag so that the inner one has nonzero scriptlevel. Option (1) of https://github.com/mathml-refresh/mathml/issues/154#issuecomment-607100375 is essentially chosen here.

Second, it is no longer possible to modify the font-size and scriptlevel at the same time on a given element. In particular:

However, in the common use case where font-size is set uniformally for the whole formula (on the math tag, or inherited from an ancestor) then there is no behavior change. It is also fine to set font-size on element without children (e.g. token elements). If you really want to change the font-size of a subformula (which I guess will make your formula look bad anyway), you can always add another mrow level to prevent the font-size and scriptlevel from being modified at the same time.

Last but not least, her approach has big advantages to my opinion:

So I would lean toward that new approach, for these reasons, for consistency with the main goal of MathML Core (better integration with the rest of the Web Platform) and to increase our change to get this accepted by browser reviewers and the CSS WG.

fred-wang commented 4 years ago

I don't see the proposed changes are valid CSS in either CSS Fonts Module Level 4 or the editor's draft of that WD. Where in the CSS process is @fantasai 's suggestion?

This is referring to what she proposed during the breaking out session of the web engines hackfest last October. I'm not sure if we had taken minutes we can share with the group. I have some from Javi Fernandez but they are not very complete (on this point there is only "script-level issues: CSS should control the font's size"). Apparently Brian has notes that I'm mentioning in https://github.com/mathml-refresh/mathml/issues/171#issue-521520255 but not sure what they contain about this particular point.

In any case, I don't remember she said she would write/submit any proposal, she was just giving suggestions to improve ours... Well, I expect this work has to be made by the MathML CG :-) Also I would personally not send any proposal to the CSS WG again, until we have at least addressed all her feedback (basically w3c/mathml#154-#155 w3c/mathml#169-#174). Most of them are easy and I can take of it but her proposal to integrate scriptlevel into font-size was the biggest change which is why things have been stalled so far, until we can experiment this in Chromium.

Correct me if I'm wrong, but I think the other proposed extensions to CSS can be mapped to internal CSS properties if they don't get accepted by CSS in the near future. Since this uses an existing CSS property, is that approach feasible? If not, what's the fallback?

New properties can be defined as internal properties (this is what is done in Gecko) but when Rob tried the same in Chromium we noticed some limitations (e.g. AFAIK they cannot be specified in the UA sheet). I'm not even sure we tried that technique for this complicate thing that affects font-size. That said, new properties or extensions to existing properties can be developed under a runtime flag (which is what we are doing) and the Chromium reviewer for CSS was actually not very strict on approving these experimental things. So I guess that's fine for the short-term while MathML is still under a runtime flag.

For the long term, if the CSS WG does not accept our proposal and since the Chromium reviewers would prefer to avoid "hiding the MathML magic", we basically cannot implement something like scriptlevel that affects font-size. That's why I'd try to be flexible and prefer addressing the feedback over finding perfect compability with MathML3.

fred-wang commented 4 years ago

The spec & tests now follow fantasai's suggestion ; and this has been implemented in Chromium upstream, so closing.

fantasai commented 4 years ago

Wow. So, uh, I think you and I did not understand each other very well here. Definitely, I would not have advocated hiding a counter in the computed value of font-size. My suggestion was more that font-size should have a value that does an appropriate lookup. But not be a depth counter.

(Also if you want to get my attention, I suggest email or IRC or even Twitter. GH notifications get buried in the vast amounts of GH notifications, I basically never see them.)

fantasai commented 4 years ago

Also if you want to change how a core property like font-size works, you should really really get the CSSWG to review what you're doing before you do it.

fred-wang commented 4 years ago

Wow. So, uh, I think you and I did not understand each other very well here. Definitely, I would not have advocated hiding a counter in the computed value of font-size. My suggestion was more that font-size should have a value that does an appropriate lookup. But not be a depth counter.

Sorry for the misunderstanding. Seeing the glass half-full, I think the new proposal is much closer to what you had in mind and contains the necessary simplification that makes integration in font-size possible. Now, I agree it would be straightforward to calculate the new font-size without counter for relative changes scriptlevel(auto) and scriptlevel(add(<integer>))...

But I'm not sure how you mean to do that for the absolute change scriptlevel(<integer>)? This case is not important for the UA sheet but at least some people use scriptlevel(0) and scriptlevel(1) in order to implement TeX's \scriptstyle and \scriptscriptstyle and I'm sure others in the CG will say that all scriptlevel(N) are important since this corresponds to MathML3's scriptlevel="N".

(Also if you want to get my attention, I suggest email or IRC or even Twitter. GH notifications get buried in the vast amounts of GH notifications, I basically never see them.)

I'm commenting here so that the rest of the CG is aware but yes, let's follow-up later on this.

Also if you want to change how a core property like font-size works, you should really really get the CSSWG to review what you're doing before you do it.

Agreed and the plan is definitely to open new issues in the CSS WG tracker and put math items on the agenda for review. Last year my colleagues suggested to write small explainers for new CSS features and submit them to the CSS WG tracker for review, which is what I optimistically did. But the feedback was unfortunately not very constructive, with people basically arguing about the usefulness of MathML rather than on the actual technical problems we were trying to address. However, after a long effort on the MathML Core spec, test and implementation side we believe we are close to be able to give another try. But there are still a few things to refine first before...

fred-wang commented 2 years ago

This is done as agreed in https://github.com/w3c/csswg-drafts/issues/5389 so I think we can close it. We can simplify a bit further after https://github.com/w3c/csswg-drafts/commit/09efeb0f1948f5aec4afc3672c1ab0c264abab36 though.