- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Sep 2020 16:54:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `text-transform values for MathML`, and agreed to the following:
* `RESOLVED: Add math-auto to text-transform`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: text-transform values for MathML<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5386<br>
<fantasai> bkardell_: MathML created and exists with lots of tools/systems that don't have full access to Unicode<br>
<fantasai> bkardell_: So legacy documents and even things written before that available<br>
<fantasai> bkardell_: so number of case where the markup itself contains the information that you need in order to understand that this character that we want to render isn't the literal text value of the element<br>
<fantasai> bkardell_: text-transforms were the solutions that we used<br>
<fantasai> bkardell_: because that's what needs to happen<br>
<fantasai> bkardell_: didn't see any reason to make that specifically hidden or unavailable to users<br>
<fantasai> bkardell_: I know fantasai and Florian had raised some concerns last time<br>
<fantasai> bkardell_: we've talked a bunch since then<br>
<fantasai> bkardell_: fantasai has updated the meta-advice in css-text-3 to provide some nuance<br>
<fantasai> bkardell_: the meaning *is* in the document<br>
<fantasai> bkardell_: I don't know if ppl still object to these or what<br>
<fantasai> fredw: 2 separate cases<br>
<fantasai> fredw: case of math-auto, which is automatic italic<br>
<fantasai> fredw: and this is the most important one<br>
<fantasai> fredw: Not adding any semantics<br>
<fantasai> fredw: default var rendered as italic<br>
<fantasai> fredw: the other was strings for tools/documents not using Unicode<br>
<fantasai> fredw: we are using text-transform to do the transformation even if MathML says to preserve the semantic<br>
<fantasai> fredw: maybe a bit controversial<br>
<fantasai> fredw: Florian was saying it's OK as long as we have the mathvariant attribute in the markup<br>
<fantasai> fredw: if ppl really don't like, can only add math-auto one<br>
<fantasai> fredw: might break some back compat, might need a polyfill, but...<br>
<fantasai> NeilS: could be done internally and not break anything<br>
<fantasai> NeilS: My concern is a11y, will changed character be in the a11y tree<br>
<fantasai> bkardell_: had several ppl who implement screenreaders saying that the transform value is exposed on existing ones, and that was a sticking point because we don't always want that<br>
<fantasai> bkardell_: certainly we can go either way here<br>
<fantasai> bkardell_: either it will be, or it won't be, exposed to screenreaders<br>
<fantasai> NeilS: As long as exposed to screenreaders, then no a11y issue<br>
<faceless2> +1 to Neils comment<br>
<fantasai> bkardell_: There's a specific example in the issue itself<br>
<fantasai> bkardell_: to non-Math ppl like myself, not intuitive<br>
<fantasai> emilio: Proposal of math-auto<br>
<fantasai> emilio: is it like user-select, like auto behaves as inherit or something?<br>
<fantasai> emilio: it's not clear to me<br>
<fantasai> emilio: seems like pseudo-code that Rob posted would be computed value time which is a bit odd<br>
<fantasai> fredw: basically transformation, whether italic or not [...]<br>
<fantasai> fredw: it doesn't copute to italic<br>
<fantasai> s/copute/compute/<br>
<fantasai> iank_: would it be fair to say that you'd apply to ...<br>
<fantasai> fredw: only to mi element<br>
<fantasai> fredw: mi { text-transform: math-auto }<br>
<fantasai> fredw: Takes effect when only one letter<br>
<fantasai> fredw: don't think it can be computed<br>
<fantasai> iank_: the specific variant is based on the attribute on the mi element?<br>
<fantasai> bkardell_: in the example or in general?<br>
<fantasai> bkardell_: mi is special, because it has this idea of a single-letter identifier<br>
<fantasai> bkardell_: those are treated stylistically a certain way<br>
<fantasai> bkardell_: but that's only stylistic, no meaning<br>
<fantasai> bkardell_: but math-variant is where you provide additional semantics missing from your lack of character support<br>
<fantasai> iank_: so if you have mathvariant specified, it turns off that auto text-transform behavior?<br>
<fantasai> faceless2: mathvariant is acting as a preshint<br>
<fantasai> faceless2: but math-auto, if no other math-transform is set<br>
<fantasai> faceless2: it would be italicized if it was one letter<br>
<fantasai> iank_: so also have all the other math transform values<br>
<fantasai> fredw: can override the default behavior<br>
<fantasai> iank_: so it's for this leaf to do this slight magical behavior<br>
<fantasai> NeilS: I think math-auto is really presentation<br>
<fantasai> NeilS: Others are there for legacy issue, and not presentation, should actually map to a different character<br>
<fantasai> NeilS: that's why may not be appropriate for CSS<br>
<bkardell_> fantasai: I guess I have 1 question and 1 concern...<br>
<bkardell_> fantasai: does the auto italic thing be a text transform really, or does it really just want font styling?<br>
<bkardell_> fredw: the way math fonts are designed, you do<br>
<bkardell_> fantasai: the other ones you do want to be a semantic effect. I am a little uncomfortable with this.<br>
<bkardell_> fantasai: whatever screen readers do it's intention was clear and I don't love changing that<br>
<fantasai> astearns: if this is only way to get semantics for legacy stuff, do we really want to expose it to CSS so that it can be used on new things?<br>
<fantasai> bkardell_: MathML Core 1 is a pretty minimal subset, there are lots of things that use more elements than we're including<br>
<fantasai> bkardell_: and the intent is for mathml to have a healthy future with additional levels<br>
<fantasai> bkardell_: so will be unknown elements<br>
<fantasai> bkardell_: so weird to say you don't have access to the magic to make other elements work like L1<br>
<fantasai> iank_: broadly agree with that<br>
<fantasai> iank_: also from what we've heard from screenreader developers<br>
<fantasai> iank_: this sort of text-transform is only presentation<br>
<fantasai> iank_: that ship sailed a long time ago<br>
<fantasai> bkardell_: it's not that they couldn't be that<br>
<fantasai> bkardell_: the new one has to be<br>
<fantasai> iank_: text-transform: uppercase is definitely exposed to screenreaders<br>
<fantasai> NeilS: Another case we haven't resolved yet<br>
<fantasai> NeilS: is hyphen-minus<br>
<fantasai> NeilS: vs minus<br>
<fantasai> NeilS: They're defined to be equivalents<br>
<fantasai> NeilS: it should map hyphen-minus to U+2122 MINUS<br>
<fantasai> NeilS: Could imagine that text-transform would be the way to do this as well<br>
<bkardell_> fantasai: you could go either way with that one<br>
<fantasai> faceless2: You'd also struggle to do that with text-transform<br>
<fantasai> faceless2: apply to whole document, then declaration for e.g. fraktur would override and disable<br>
<fantasai> bkardell_: I suggest we either resolve or move on<br>
<fantasai> fredw: maybe just resolve on math-auto, and unsure for rest<br>
<fantasai> astearns: I think I heard you say that math-auto is the only one you have implemented so far?<br>
<fantasai> bkardell_: upstream chromium<br>
<fantasai> fredw: we have the others implemented in a separate branch<br>
<fantasai> astearns: so let's resolve on math-auto<br>
<fantasai> astearns: any objections to adding math-auto to text-transform?<br>
<fantasai> emilio: Not quite objection, but want to clarify how it behaves exactly<br>
<fantasai> astearns: resolve to add, then work on details<br>
<fantasai> RESOLVED: Add math-auto to text-transform<br>
<fantasai> astearns: still seems like there's concerns around the rest of math-values<br>
<fantasai> faceless2: The only concerns are wrt exposing to screenreaders?<br>
<fantasai> astearns: there seem to be a lot of them, also, that's my concern<br>
<fantasai> fantasai: I don't like adding things that are supposed to alter semantics to CSS.<br>
<fantasai> astearns: let's hold off on these for now<br>
<fantasai> fantasai: ...<br>
<fantasai> iank_: would it be possible to add a new HTML-level attribute with mathvariant and then, if you set `text-transform` to auto that'll read the attribute and apply it?<br>
<fantasai> iank_: Semantics would still be in the document, just whether you apply it would be in CSS<br>
<fantasai> NeilS: I don't think it makes sense to add something new<br>
<fantasai> NeilS: this is all for legacy support<br>
<fantasai> bkardell_: maybe talk about that, maybe at HTML layer we can do something<br>
<fantasai> NeilS: I have to drop off for another MathML meeting<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5386#issuecomment-690502711 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 September 2020 16:54:45 UTC