Re: [csswg-drafts] [css-text] Add new CSS text-transform values for math (#3745)

The CSS Working Group just discussed `(css-text) Add new CSS text-transform values for math`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> Topic:  (css-text) Add new CSS text-transform values for math<br>
&lt;emilio> Github: https://github.com/w3c/csswg-drafts/issues/3745<br>
&lt;emilio> fantasai: I really think this should be done with i18n experts<br>
&lt;emilio> ... probably at tpac<br>
&lt;emilio> Rossen: who added it to the agenda?<br>
&lt;emilio> bkardell_: I did<br>
&lt;emilio> Rossen: are we ready to discuss this?<br>
&lt;emilio> bkardell_: there were very strong objections when I added it to the agenda but it seems that has been solved<br>
&lt;emilio> bkardell_: I'd like to make some progress on that issue<br>
&lt;emilio> astearns: what's the points you're talking about?<br>
&lt;emilio> bkardell_: the philosophy of text-transforms and how it interacts with a11y<br>
&lt;AmeliaBR> q+<br>
&lt;iank_> q+<br>
&lt;emilio> bkardell_: we have a new transform that prob. needs to do something different<br>
&lt;emilio> ... the are at least two answers to the questions<br>
&lt;emilio> florian: I think that's why we need other experts on the discussions<br>
&lt;emilio> ... because whether text-transform affects the semantics is complicated<br>
&lt;emilio> fantasai: I think text-transform, if we're stuck for compat with a11y for capitalization that's unfortunate, but we shouldn't introduce the same for math<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-478206009<br>
&lt;emilio> florian: once we have the markup communicate the semantics, we probably want text-transform to affect some of the presentation but not a11y<br>
&lt;emilio> bkardell_: my understanding is that we'd encourage putting it in the markup, but there's a bunch of legacy content which is what would make this necessary<br>
&lt;emilio> AmeliaBR: I think florian's point is that you could have a presentation transform but the accessibility stuff should be in the markup<br>
&lt;emilio> bkardell_: I'd like to get some kind of checkpoint on this<br>
&lt;emilio> AmeliaBR: the question is: "for math-variant to be exposed and accessible, does it need to be exposed through text-transform transforming the text-content, or via an attribute that gets passed to the a11y tree, which _also_ gets a UA rule to make the presentation change'<br>
&lt;emilio> fantasai: I think that's the right way to go, and gives you the ability to give more accurate info to a11y that doing unicode transformation<br>
&lt;emilio> ... unicode transformation doesn't contain math semantics<br>
&lt;emilio> ... that needs to be in the markup, if that information is in the content it should be given to a11y that way, rather than via text-transform<br>
&lt;emilio> ... a11y doesn't say "Bold", it uses the fact that you're on &lt;strong><br>
&lt;emilio> AmeliaBR: actually that's not true, a11y is trying to introduce roles for &lt;strong> and similar, authors don't distinguish &lt;i> or &lt;em><br>
&lt;emilio> ... if there's an italic &lt;span> in a header it'd be called out depending on the verbosity level<br>
&lt;emilio> Rossen: it calls out format stops<br>
&lt;AmeliaBR> s/a11y/ARIA WG/<br>
&lt;emilio> bkardell_: there's a similarity here with html's kinda-weak semantics, a11y tools get mostly plain text with other hints, for math a11y my understanding is that some tools use the unicode information<br>
&lt;emilio> Rossen: we don't support mathml in Edge<br>
&lt;emilio> bkardell_: well, Edge does parse mathml as XML content<br>
&lt;emilio> ... which is why mathml is a kinda weird place<br>
&lt;emilio> Rossen: [describes how a11y works in Edge and how screen readers can poke at the DOM / render tree in non-Edge (Chromium / Firefox)]<br>
&lt;emilio> Rossen: Edge doesn't allow third-party processes in its process<br>
&lt;emilio> bkardell_: please fact-check me :)<br>
&lt;emilio> florian: I think this is a topic for TPAC, since different a11y experts have diverging oppinions<br>
&lt;emilio> Rossen: are we going to make any progress?<br>
&lt;Rossen_> q?<br>
&lt;emilio> bkardell_: do we have some specific questions/<br>
&lt;emilio> *?<br>
&lt;astearns> ack AmeliaBR<br>
&lt;astearns> ack iank_<br>
&lt;emilio> AmeliaBR: I think my point was previously said, so to wrap up: We're saying that the specific proposal is to take it back to see if we can decouple the style and the markup a11y, and defer for TPAC?<br>
&lt;emilio> bkardell_: yeah<br>
&lt;Rossen_> ack iank_<br>
&lt;emilio> iank_: seems like the people objecting about text-transform is just about a11y, is that correct?<br>
&lt;emilio> AmeliaBR: yeah, it's about whether it sees the characters for a11y before or after transform<br>
&lt;emilio> florian: it's not just about a11y but more generally the semantics, like what would happen in reader mode and such?<br>
&lt;emilio> iank_: another point is that mathml has a lot of legacy content, and mathml does this in a very magic way. We don't want to get in a situation where other math libraries cannot opt-in to this power<br>
&lt;emilio> Rossen_: let's stop here for now<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-499130767 using your GitHub account

Received on Wednesday, 5 June 2019 15:23:23 UTC