From: fantasai via GitHub <sysbot+gh@w3.org>

Date: Thu, 10 Sep 2020 04:03:47 +0000

To: public-css-archive@w3.org

Message-ID: <issue_comment.created-689965166-1599710626-sysbot+gh@w3.org>

Date: Thu, 10 Sep 2020 04:03:47 +0000

To: public-css-archive@w3.org

Message-ID: <issue_comment.created-689965166-1599710626-sysbot+gh@w3.org>

Fwiw, I think my original concern was that the previous iteration of this feature--which used a separate property as the counter--depended on concepts that don't exist in CSS, like whether `font-size` has a specified value. (It always has a specified value.) Integration with font-size has to be defined in a way that can actually work; however, doesn't mean necessarily that the entire feature needs to be encapsulated into the font-size property itself. We could keep the depth counter as its own property, something like ``` math-depth: auto | add || <integer> inherited: yes computed value: integer ``` Then for > If the specified value font-size is of the form scriptlevel(...) then the computed value of font-size is obtained by multiplying the inherited value of font-size by a nonzero scale factor calculated by the following procedure ... you could instead have something like - Option A: The used value of `font-size` is obtained by multiplying the computed `font-size` by a nonzero scale factor calculated by the following procedure [ insert MathML algorithm, with A=0 ] ... - Option B: If [ `math-depth` is nonzero | the specified `font-size` is `math` ] , the computed value of `font-size` is obtained by multiplying the inherited `font-size` by a nonzero scale factor calculated by the following procedure ... - Option C: If `math-depth` is nonzero, the computed value of `font-size` is obtained by multiplying what would have been the computed `font-size` by a nonzero scale factor calculated by the following procedure ... Here's the side-effects of various options: - Option A: Here, the scale factor is inherited independently of the inherited font size, and they're combined at used-value time. This means that setting `font-size` to a value doesn't necessarily give you that value: it gives you that value multiplied by the effective scale factor tracked by `math-depth`. It means that font-relative length units are relative to the base `font-size` rather than to the effective one; you may or may not want this effect. - Option B: The `math-depth` calculation overrides the specified `font-size`. In the first sub-option (“if `math-depth` is nonzero”) this override is implied, and whatever the author specified on `font-size` is ignored. In the second (“if `font-size` is `math`”), this interaction is explicit; the author can't specify a conflicting value on `font-size`, since they have to specify the `math` keyword to explicitly defer the font-size calculation to `math-depth`. - Option C: In this case, the math scaling operates on the “raw” computed font-size: in most cases, this will be the inherited `font-size` (as in the previous option), but if the author specifies a `font-size` on the element, then that value will be used as the basis for scaling instead of the inherited value. Option D: If you really want a declaration like `font-size: <length>` to reset the math-depth counter so that you get that absolute size, though, then `font-size` is essentially a shorthand for a depth counter property and a length tracker property -- your current spec is effectively doing this, but without real longhands for this `font-size` “shorthand”. I think it's a bit weird to have `font-size` (which is such a basic property) incorporate this separate concept of a depth counter into its computed value, but maybe it's okay... would definitely want to get the rest of the CSSWG's opinion on that, though. I'll note that we're running into a similar need for a font-size scaling factor for drop caps, see https://github.com/w3c/csswg-drafts/issues/4988 ; it would be interesting to note what the similarities and differences are wrt expected behavior. (For example, in the drop caps case, we suspect that font-relative lengths should be unaffected by `initial-letter`’s scaling effects.) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689965166 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-configReceived on Thursday, 10 September 2020 04:05:03 UTC

*
This archive was generated by hypermail 2.4.0
: Tuesday, 5 July 2022 06:42:16 UTC
*