- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Apr 2019 00:03:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `text-transform's design, intent and reality resolution`.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: text-transform's design, intent and reality resolution<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/3775<br>
<dael> astearns: Wanted to have this introduced so can make a bit of progress before bringing in more people<br>
<dael> birtles: I don't see where this was spec originally in the design, but at some point it became a stated thing we have talked about about the intent fo text-transform and what it exposes to screen readers and why<br>
<astearns> s/birtles/bkardell_/<br>
<dael> birtles: Feel like I dropped the ball a bit on kana discussions because I know it wasn't reality and assumed other people did too. Some of the text stuff I don't feel I cam comment so wasn't paying close attention<br>
<florian> q+<br>
<dael> bkardell_: Opened a different issue requesting something that is inline with how screenreaders work. That changes to how we have designed to not expose text to screenreaders. It's come up that it does not match reality<br>
<astearns> ack bkardell_<br>
<dael> bkardell_: AT and browsers have chosen universally to expose transform text. I'd like to consider that so that we can properly discuss the other issue<br>
<dael> bkardell_: My position is that the ones that exist and in wide use are stated design principle is out of touch with reality. It's a concious choice that's what users want. At a min our principle needs some finesse<br>
<IanPouncey> q+<br>
<astearns> ack florian<br>
<dael> florian: The discussion is a bit long winded, I'll jump to where we are. I don't see the same contridiction of bkardell_ if we look a little deeper. DOn't think ti's interesting to debate what screen reader users what, the exprests have said. Screen readers do not give access to raw doc, they present it. It's easier to include the transform. I don't think that makes semantics change<br>
<Rossen> q+<br>
<dael> florian: I don't think we could do that. There are places where we don't present CSS so we can't say that text-transforms are an intrinsic part of doc that can't be removed. If screenreaders as one UA think best way to present is to apply the text-transform, great. But I don't think we can go from there to never not allow them to be applied. If you introduce a new text-transform old browsers won't know<br>
<AmeliaBR> q+<br>
<iank_> q+<br>
<dael> florian: I thinkw e have to rec that the doc is the doc and the text transforms need to be allowed to apply. I think the claim that case transforms are desirable is credible, but I don't want to generalize to say all transforms always must be preserved. I think cjk and i18n transforms you want the other way.<br>
<dael> florian: I think we need to discuss transform by transforms, but can't say all must be preserved<br>
<astearns> ack fantasai<br>
<dael> fantasai: I agree with florian that text-transform can't be intrinsic part of doc semantics. They were designed as a way to have this distinction partly. If we don't have them to diff doc and visual rendering we'll have to find a way to do it.<br>
<dael> fantasai: Someone suggested creating a custom font, I don't want to get intot hat arms race<br>
<dael> fantasai: I'm not sure how deeply this investigated in the past. I don't see anything in bugzilla. Chrome issues had people arguing on both sides. I don't know if this has been inestigated deeply enough. We need to talk to the people we need to talk to and figure out what to fall out. If no discussion on Gecko it's prob what's convenient<br>
<astearns> ack IanPouncey<br>
<dael> IanPouncey: Few points, to reiterat bkardell_ it seemed to those of us who work with screen readers that this was common knowledge, that's on us. For what florian said I think misconception about where problem lies. I'ts not screen readers doing transform, it's the browser and a11y tree exposing it<br>
<florian> q+ to respond to IanPouncey<br>
<dael> IanPouncey: It's not screen reader doing anything in most modern browser. Any of the ideas of a screen reader making a decision about what to present is problematic b/c you cannot reverse a transform to uppercase b/c you don't know what char were uppercase<br>
<dael> IanPouncey: Speculating on this, I wonder if similar issue for content is on teh radar. I think there was an assumption when prop introduced that it's not exposed to screen readers and it is now. I wonder if there's a similar problem there<br>
<astearns> ack Rossen<br>
<fantasai> s/figure out what to fall out/figure out what to do. It's possible the current situation is what fell out of original implementations, and screenreaders just dealt with it but it's not ideal/<br>
<dael> Rossen: Way screen readers work is a long discussion. How text is represented also heavily depends on current platoform support and AT consuming that ingo. nvbia on windows will have different characteristics to express richness of text comparred to narrator using ui automation<br>
<fantasai> Point about delivering transformed text through AT meaning screenreaders can't access original text even if they want to is imho important<br>
<dael> Rossen: One thing I know from interacting with the community and a11y wgs and immpl a11y the thing I can tell you is a lot of people think of screen readers for the blind. It's part of the users but not all. Most people are those with low vision. They can see parts of the screen. So when you start producing disparity between rendered results and what screen reader represents it becomes confusing<br>
<dael> Rossen: Consider editing scenarios- most people will navigate text by character to check spelling. If at that itme you have text transform that caps for example for them to not know it's upper case will be confusing. Same reason why we map ital to em, lots of font features that map to a11y prop I don't see why this should be unique<br>
<dael> Rossen: Other thing I want to give a big shout out, CSSAOM would be ideal place to continue this discussion<br>
<astearns> ack AmeliaBR<br>
<dael> AmeliaBR: There's 2 aspects to the discussion. What should happen, how is best way to expose full information. THen specific practical issue in that we have recently added values ot text transform with some impl and this new prop for math variants<br>
<fantasai> wrt checking spelling in editing environment... ideally you want to know what text you're actually typing, for when the text transform goes away -- source text should be following standard capitalization rules, would be problematic if ::first-line { text-transform: uppercase; } led someone to type in all-caps when replacing one word with another in the first phrase of a para<br>
<dael> AmeliaBR: By putting it all in text-transform it forcecs us to treat them the same for exposing before or after transform values<br>
<dael> AmeliaBR: Even if not complete agree on optimal for exposing case changes I'm trusing florian that exposing CJK typgraphical is a problematic situation from a11y.<br>
<dael> AmeliaBR: If mathML comes through it's very important to expose transformation.<br>
<fantasai> generally, editing text with text-transform turned on is going to be very confusing regardless...<br>
<iank_> q-<br>
<dael> AmeliaBR: With these different semantic impacts it might be worth discussing if these should be split up, even if it's transform to long hands that could all reset by a shorthand but there is a text-transform case that's different then CJK text-transform. If we sep to different prop we can start talking semantics and what stange transformations happen<br>
<astearns> q+<br>
<dael> AmeliaBR: Esp in terms of what's exposed to a11y, copy/paste APIs, lots of places where people use text-transform and if they're not all equal maybe use different properties<br>
<astearns> ack florian<br>
<Zakim> florian, you wanted to respond to IanPouncey<br>
<fantasai> reason to have separate longhands is needing them to cascade separately... if the only concern is what impacts they have, we can categorize within the spec<br>
<AmeliaBR> s/a11y, copy/a11y, HTML innerText, copy/<br>
<IanPouncey> q+<br>
<dael> florian: I am aware about diff IanPouncey mentioned between what screen readers do and what's in at. Idea is that text in AT would be end transformed text and have the original information so screen readers can make decision. In case of case transforms if every screen reader wants to do the same thing with it and the current AT does the transform already it will be uphill to untransform. For case transforms if it's a standard today fine let's leave it<br>
<bkardell_> are we on to the math case already?<br>
<dael> florian: But that's what I want to Japanese which is keep untransformed text and keep information about transforms so that screen readers can add extra information if they want. The Math case I think is kind of related. I don't thinkw e can rely on the transforms to change document semnatics.<br>
<dael> florian: If we want to introduce a new semantic differencec we have to introduce it in the document and that can impact the AT tree. We can't just change the font and claim it lets us introduce semantic differences that would change the meaning of the document. upper case is useful but not changing doc meanings. If we want to introduce math it will fail in all cases<br>
<dael> astearns: To respond to AmeliaBR- I think the idea of separating properties is interesting but maybe not entirely nec. If e want we can spec what happens to values or prop and they can differ.<br>
<dael> astearns: To respond to florian I think there is prob a fallback that can work for new math transforms. If you see support you get fractor, if you don't you do extra styling<br>
<dael> florian: And it disappears in read<br>
<dael> astearns: Fair<br>
<AmeliaBR> q+<br>
<astearns> ack astearns<br>
<astearns> ack IanPouncey<br>
<dael> florian: If you want to style that's fine. Introducing fundimentally different semantics is not fine.<br>
<florian> s/is not fine/won't work/<br>
<Rossen> :)<br>
<dael> IanPouncey: Cautious +1 to expose detail of transform and original content. I can see if there's any appetite for that. Hopefully wecan get idea if that's possible. Also acknowledging the prompt to add CSSAAM to this discussion<br>
<astearns> ack AmeliaBR<br>
<dael> AmeliaBR: Follow up on florian concern about semantics in document. The request for math transforms is from MathML as a way to desc behavior of MathML attribute in a way that can be consistantly impl. That is something where there is semantics in doc level but nice to be able to describe it. Maybe also use same effects in more decorative cases<br>
<dael> florian: Fair and useful so thing into a11y tree is the transformed and may be useful<br>
<dael> astearns: We're at time. The call bridge will stay open if people want to chat and then put the discussion in the issue<br>
<dael> astearns: Thank you all very much<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3775#issuecomment-479700875 using your GitHub account
Received on Thursday, 4 April 2019 00:03:51 UTC