-
Notifications
You must be signed in to change notification settings - Fork 676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-text] text-transform's design, intent and reality resolution #3775
Comments
Thanks for raising this. You are right that there is a disconnect, and that we should get to the bottom of it. I draw different conclusions though. I think the current situation is muddled in three overlapping ways:
I think that while this doesn't prove the original intent of text-transform to be correct, it also doesn't prove that the current reality is a clear good match for users' needs. It could mean that the current approach is the right one, or it could mean that the current approach is a tolerable approximation because the cases where it really makes a difference haven't been exposed yet. My assumption is that it is the later:
Based on that, I'd suggest a different path forward than @bkardell
If we do that, we can continue to use text-transform for its intended purpose. If we don't, we will need to accept that text-transform only works as originally intended in the cases where the transform is reversible by the assistive technologies, and may have to give up on it solving solving the broader related i18n problem. @bkardell notes that:
I'd like a double check on this: is it indeed an intentional change? It could be, but it could also be an accidental side effect of rendering the accessibility tree off the render tree rather than the DOM. Or it could be the "implementation shortcut" I mentioned earlier, achieving the same effect as exposing the untransformed text and applying the transform in the assistive technology (in most cases so far, but not in all i18n cases) . I wouldn't be surprised if it were accidental, nor if it was the "implementation shortcut". If it is a conscious decision distinct form the implementation shortcut, I am really curious as to what the reasons are. |
This is (as Brian said in his original post) a conscious decision. I can't speak to the |
I fully trust that you know what you're talking about, and understand the needs of AT users better than I do. The problem is not one of believing, but of understanding. I'm not interested in being right, I'm interested in solving the problem. I didn't merely state that I thought my approach was right, I explained why. I would appreciate if you point out where I'm wrong, or if I'm not wrong what additional considerations I am missing. Merely stating that you know better doesn't help get to a conclusion. |
Joanie has explained this multiple times: I'm not sure what I can possibly add to those explanations at this point.
This absolutely isn't what I did. I said "we have spoken with numerous screen reader users who are developers themselves and understand all the facts, and they have consistently said they want the transformed text exposed by the AT under all circumstances". It seems that you're stuck on that particular point - you don't seem to believe, even after hearing it from multiple different people, that that is actually what AT users want. I can only assure you that having spoken to AT users who know enough to make an informed decision, that they do want that, and ask you to take that on faith. |
Expecting assistive tech to "undo" a text-transform is not reasonable: transforms are lossy operations. (E.g., once mixed-case text is converted to all uppercase, you cannot deduce the original casing from the rendered text and transform operation.) The options are:
Now, asking for all those implementers to make those changes would make sense if there was a strong accessibility purpose. But we've had multiple accessibility experts say that for the most commonly implemented text transformations this is not what users want. Unless we get evidence to the contrary from people doing usability research with assistive tech users, I don't think we're going to convince anyone to change their implementations. So, the next question is: what to do about text transformations where exposing the transformed character would be bad for accessibility? Which seems to be only the (recently added & still not widely implemented) |
I really is not because I don't believe you. It is also not because I don't care about users of screen readers. Please don't assume ill intent on my part. Please also extend me back the courtesy of believing that I too might know what I am talking about as well. I have read Joanie's points. I have not dismissed them.
But implementer convenience doesn't trump end user's needs, and speakers of languages written in something else than the Latin alphabet are users too. Here's an example based on an sentence in an ad on my screen right now:
This means “Free WIFI service on domestic flights". If you use
If I ask MacOS's VoiceOver to read that string, the pronunciation of the word "service" is garbled and is not understandable, even with the content correctly language tagged. |
That's fair. I apologise.
This is a reasonable point.
I think the issue is that it would likely constitute a regression for users until all ATs caught up, which may never happen.
Totally agreed, but we have to be pragmatic as well - for the That logic may or may not apply for other text transformations.
That sounds like a much worse experience than the |
Thank you Alice, apology accepted. I really appreciate. Allow me to apologize in turn to you, Brian, Joanie, and anyone else who felt that what I wrote was dismissive of your expertise. Regardless of my intent, which was not to dismiss, if you felt that way, I was misbehaving, and I am sorry. Based on all that, what I'm hearing is that the way things are currently implemented give the expected result the vast majority of the time for a low implementation cost, and that switching to what I have been suggesting in order to cover the remaining i18n cases would be much more expensive, and would make things worse if the transition was poorly coordinated between browsers vendors and AT vendors (which is likely to happen when the AT vendor and the Browser vendor are not the same). I think that's a fair point, and justifies a lack of appetite for switching. At the same time, even though you say (and I believe you) that this is not generally what people want, I think it would be OK for an screen-reader to have a setting allowing the user to ask for transformed text to be read as if untransformed. If anyone wanted to do that, it would not necessarily have to be implemented by changing the text in the accessibility tree to untransformed; it could be done by having an extra attribute carrying the necessary information. I'm not saying that most users want this, nor that most screen readers ought to have that option. Just that it would be inappropriate for the spec to forbid that. If we agree on the above, then I think we can consider that from a user's point of view, the differences between the current approach and the one I suggested earlier are implementation details of What I would not like for us to do is change the design of text-transform to require that ATs must never convey the untransformed content to the user, and to add new values to
In conclusion, I think that:
I think that this would be good because:
|
@frivoal: If you remove the capitalized-via-transformed text, every screen reader which wants to present that capitalized text as part of its standard presentation is going to have to do extra work:
As for why this transformation is needed, I, as the screen reader developer, am not putting those dot-6 instances in the braille text or adding a tone for each capitalized word. I'm taking the rendered text -- which, again, all user agents give us -- and passing it along pretty much as-is to the libraries which do that actual work. Those lower-level libraries need the transformed text. People already complain that screen readers are non-performant. Please don't give us even more work to do. The user agent has already done the work to render the transformed text and can give it to screen readers for free. Regarding presenting the untransformed text (i.e. treat it as if it were not capitalized), screen readers and their users can already do that for speech quite easily: They just disable the capitalization presentation settings. Then, when the speech libraries do their thing, they fail to use higher pitch, they fail to say "cap" and they fail to play a tone because they've been configured not to do so. The end result is the text sounds uncapitalized. |
I think fundamentally @AmeliaBR is on to it here but I want to add a few questions that I think are important and amelia intends but are not explicitly stated:
|
Probably the best way to introduce such a thing would be through the browser, rather than the screen reader, as an accessibility override of the CSS ( Edited to add: a "no text-transform" setting might also have other accessibility applications in the browser, e.g. for some people with dyslexia all caps is problematic. Maybe also full-width. |
I would argue that |
Sure, but that's the entire point: when the text is too small, some authors do this anyway, but if they do it in the source document, the correct pronunciation is lost. This transform is not an invitation to use large kana where small kana should be used. The whole point is that if large kana is going to be displayed, authors should be able to still use small kana in the document. |
Sure, which is why I am no longer proposing to do that.
Right, and in my last message, I am saying that we should continue to do that. See "4.1" You sound like you're disagreeing with me, but you're writing in opposition to points that I am not defending. |
Apologies. I'm afraid some of the comments got a tad long and I missed (or misread) 4.1. Thanks for the clarification. |
I think I was not clear in my previous message, so I'll try again. I have tried making it shorter, but I'm only moderately successful here at being both succinct and complete. No matter what we say about the accessibility tree, there exists cases where HTML documents are rendered without CSS:
Therefore, we cannot reasonably have a model in which is would be wrong and forbidden for a UA/AT to present the untransformed text. I am not saying that there is a requirement for AT to present the untransformed text. I am saying that a requirement that no UA/AT must ever do so is not reasonable and could not be enforced even if we did decide on it. Because of the above conclusion, the following claim would be invalid:
text-transforms cannot be relied on to be applied in all cases, and so they cannot be used to introduce semantic essential differences. It is not reasonable to write a contract or an algorithm with Once I've said that, I've made no requirement on how accessibility trees must store the text, or on how assistive technologies must present it. The best way to present a given piece of content, knowing how css wants to style it, in various environments, is a separate question. All I am saying is that it is indeed a question, and "transforms must be preserved always" does not derive from the inherent design of the text-transform property. It has been stated that the vast majority—possibly all—users of assistive technologies, wanted in the vast majority of the cases—possibly all—that when text-transform changes the case of some text, that they be presented with the result of the transformation. This is the intentional behavior of screen readers today, implemented via how the accessibility tree is built. Since the current behavior is desired, let's not change it. This is because users want it this way, not because of anything inherent to There is, however, no strong compatibility requirement that transforms other than case transforms ( |
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: text-transform's design, intent and reality resolution<dael> github: https://github.com//issues/3775 <dael> astearns: Wanted to have this introduced so can make a bit of progress before bringing in more people <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 <astearns> s/birtles/bkardell_/ <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 <florian> q+ <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 <astearns> ack bkardell_ <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 <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 <IanPouncey> q+ <astearns> ack florian <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 <Rossen> q+ <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 <AmeliaBR> q+ <iank_> q+ <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. <dael> florian: I think we need to discuss transform by transforms, but can't say all must be preserved <astearns> ack fantasai <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. <dael> fantasai: Someone suggested creating a custom font, I don't want to get intot hat arms race <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 <astearns> ack IanPouncey <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 <florian> q+ to respond to IanPouncey <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 <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 <astearns> ack Rossen <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/ <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 <fantasai> Point about delivering transformed text through AT meaning screenreaders can't access original text even if they want to is imho important <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 <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 <dael> Rossen: Other thing I want to give a big shout out, CSSAOM would be ideal place to continue this discussion <astearns> ack AmeliaBR <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 <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 <dael> AmeliaBR: By putting it all in text-transform it forcecs us to treat them the same for exposing before or after transform values <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. <dael> AmeliaBR: If mathML comes through it's very important to expose transformation. <fantasai> generally, editing text with text-transform turned on is going to be very confusing regardless... <iank_> q- <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 <astearns> q+ <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 <astearns> ack florian <Zakim> florian, you wanted to respond to IanPouncey <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 <AmeliaBR> s/a11y, copy/a11y, HTML innerText, copy/ <IanPouncey> q+ <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 <bkardell_> are we on to the math case already? <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. <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 <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. <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 <dael> florian: And it disappears in read <dael> astearns: Fair <AmeliaBR> q+ <astearns> ack astearns <astearns> ack IanPouncey <dael> florian: If you want to style that's fine. Introducing fundimentally different semantics is not fine. <florian> s/is not fine/won't work/ <Rossen> :) <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 <astearns> ack AmeliaBR <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 <dael> florian: Fair and useful so thing into a11y tree is the transformed and may be useful <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 <dael> astearns: Thank you all very much |
From the post telcon discussion, a few points which I though were worth recording (other people who were there feel free to correct my interpretation or add other points):
|
I see that https://bugzilla.mozilla.org/show_bug.cgi?id=1541668 has been filed on this. In looking at how Gecko might be persuaded to ignore the Which raises the question in my mind, should |
As long as |
I think so, in order to retain a single order of operations for string manipulation, because there are steps that aren't included in
|
so... I was debating whether to add this to the conversation, but now I feel like I have to.
is also not a thing that would appear to reflect reality when I tested it. Chromium and webkit browsers for me seem to copy and plain-text-paste as transformed text, matching the AT (which totally makes sense to me and is maybe a whole other thread I dont want to pull on) but FF does not - which, I guess means that it gets the value for the AT and the plain text paste differently? |
That's come up before (sorry, I don't have a reference to previous discussion offhand). Personally, I consider the chromium/webkit behavior to be a bug. |
I think that AT are actually doing two thing which conceptually (and would it be practical to give users the choice actually?) are very different modes of operation. It's mixing them that causes confusion.
CSS only specifies requirements for 1 and they entail ignoring properties which are for visual media only (though not |
My understanding is that the question here was in essence: "Can we agree that it is a fundamental part of the design of text-transform that it must in all cases be reflected everywhere including in the screen-reader rendering, and therefore that we can base decisions about future values on that fact?" I believe the answer is no. It is true that there are values of text-transform that affect the rendering in screen readers, and that's intentional on their part. For example changes of case. However:
The design principle, to me, is that text-transform does not alter the meaning of the styled text. User agents such as screen readers that provide a non-visual rendering may take that styling into account when deciding how to present the text, but it is not a thing that should be relied on as a design principle of this feature. (Whether users of a particular implementation can rely on that implementation doing is separate, and not particularly relevant here.) The way to apply that principle to the proposed math related text-tranform would be:
|
This was included in the proposal as I thought it could help motivate the feature for people who for some reason are not interested in native math rendering support or even don't like MathML (but apparently, this had the opposite effect). For example, I believe MathJax or KaTeX generates something like For native MathML implementation, this use case is not important at all, so I'm happy if the CSS spec say text-transform shouldn't be used for semantics.
For the record MathML3 is outdated, the reference for CSS-based browser implementation is mathvariant: https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute Note that @bkardell plans to open new CSS issues for the proposals and relaunch the discussion soon, so hopefully we can move "CSS Extensions for Math Layout" to relevant CSS specs instead. We could improve the MathML Core spec to clarify it is expected that the change for mathvariant affects non-visual renderings as you suggested. Actually we already had that in mind, but were waiting for a consensus on the present CSSWG issue. |
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: [css-text] text-transform's design, intent and reality resolution<dael> github: https://github.com//issues/3775 <florian> https://github.com//issues/3775#issuecomment-652733256 <dael> AmeliaBR: Is brian here? <Rossen_> q? <dael> florian: I'd like to speak about it anyway <dael> florian: Comment jsut posted <dael> florian: Issue not suggesting we change spec. It was fundimental design of text transform. If we can all agree fundamentally text tansform behaves in a certain way we can use that to build other things. It seems clear we can't agree this is the way it works <dael> florian: I can give more details, but I think conclusion is no we can't agree, please close this. <dael> florian: I can give arguments why I think it's the opposite, but the conclusion is we cannot agree it's this other thing. <dael> Rossen_: Anyone from Igalia here to talk about this? <dael> myles: Are you proposing close? <dael> florian: Yes, close with no prejudice. I have nothing against hte math features. Can we agree the fundamental meaning of the document, no we cannot. <dael> myles: I'm happy to close <dael> AmeliaBR: I think we have to formally agree to disagree in sense of accepting some values of text-transform might have meanings that should pass to assistive and some should be stylistic and that's just the way it is. We cna't seem to agree all one or the other <dael> fantasai: I disagree with that. There are values that are clearly only presentational. There are other values...entire putpose of text transform being in css is to make it presentational. a11y layer might want to know and it's appropriate to pass some information to it. I think text-transform beign a css property is not intended to convey semantics. <dael> fantasai: If you're using a11y api it may take aspects into account but it should not be used for semantics <fantasai> s/aspects/aspects of presentation/ <fantasai> s/it should/text-transform should/ <dael> florian: Personally I agree with fantasai but issue was that it is in all cases semantic. We certainly have not agreed it's always semantic and never presentational. Maybe we convinced people of fantasai view. THere's nothing to be done here. <dael> fantasai: I'll take an action item to put some text in the spec clarifying where we're at. We'll review text and decide if we like it <dael> AmeliaBR: If you write what you said it's an improvement and as far as we can move forward with this. <dael> ACTION fantasai put some text in the spec clarifying where we're at on issue #3775 |
In certain use cases, text-transform is functionally equivalent to font-variant. A plausible use case is small caps through Google Fonts – you have to do it with text-transform because Google Fonts does not preserve OpenType features so small caps, when offered, is always a separate font. I do this myself and while I prefer to use OT features, I have to keep doing this as long as I have to use Google Fonts. |
Fwiw I support closing this issue. I feel like our discussions and @fantasai's recent edits to attempt better are fine (I think - 'document' is a much better word than 'text' here, for one) and we should be unblocked for the related discussion. That said, I think it might be better phrased to say that I don't think this is the right issue/venue for the larger question(s) that I think still hold a bit for me. I just think that this isn't the right issue or place to clarify this further, it probably isn't this narrow or even about a single issue - some of the principles of how/why we design things and how we think they should work, and how they work in practice etc seem like they are sometimes a little muddy and could use a clear articulation of design principles that all of the necessary groups (not just CSSWG) can agree to. In retrospect, I think this is precisely what W3C TAG design principles is talking about, so, hopefully that's a better place than this and I think we should close the issue. |
I'd like to add my point of view. It seems to me that the problem here is that the distinction between semantics and presentation is being dangerously blurred if text is copy/pasted in uppercase, or pronounced with emphasis, because it has a text-transform applied to it. I think this is a dangerous way of thinking about things: the semantics should be in the markup, and the CSS should be ingorable and potentially evanescent styling only. Florian gave some examples of how CSS may not be present when the text is read. Here are some other scenarios where i think pronouncing or copying the transformed text rather than what's in the markup actually introduces incorrect semantics, and breaks the intended use of the text-transform property. Florian already mentioned the Japanese case, with the kana that is resized purely for the benefit of visual readers. The actual text that is read or copied needs to maintain the distinction between small and normal sized kana for proper comprehension by TTS, for copy/paste, for searching, etc. This is really important, but the obvious solution is being elbowed out. I may have missed it (the thread is long), but i don't remember anyone proposing an alternative solution to this real-world problem that needs to be addressed. Bringhurst's Elements of Typographic Style shows examples of uppercased headings, run-in sideheads, upper-cased text following versals. The style that the i18n WG uses for documents used to apply text-transform to remove capital letters from L2 and L3 headings. However, we certainly wanted people copying that heading to have the capitals in the unstyled text – what we did was just intended to be sugar-coating. And in fact a while ago we actually removed that transform from the L3 headings, and changed L2 headings to ALL CAPS (using the Gill Sans font, which is specially designed to make such text readable) (see an example at https://www.w3.org/International/questions/qa-visual-vs-logical.en). No semantics where changed here. We don't want screen readers shouting the L2 headings at people, or emphasising them in any special way because they are all caps. If we did, we'd have put the ALL CAPS in the markup, since that's the semantic layer. It's common, when using drop caps, to continue the first word on the line using uppercase letters. Again, this is a purely stylistic device, which may not be appropriate or desirable in documents if those same docs are viewed in a different visual context. The intent is not to emphasise the first word in any way when rendering it through TTS, or copy/pasting the text into a different page with different style conventions. These presentational devices seem to reflect the intended purpose of the text-transform property. I'm concerned that we are likely to break these useful applications, without recourse, by assuming that style information carries semantics. |
The note is in place, @bkardell who opened this issue originally supports closing, and subsequent comments by @acli and @r12a are going in the same direction. Agenda+ to confirm closing. |
@frivoal I'm not sure we need meeting time for this. We made non-normative editorial changes that are enough for this iteration, and I think we can just close this with “commenter satisfied” for the disposition of comments. |
Please note: Chrome changed the behavior of copying to the clipboard a while ago, and now text-transform does not affect the actual text copied to the clipboard. |
It would appear that there is some real disagreement about text-transform and a gap of understanding between spec authors and implementation realities that I was not previously aware of (the gap, not the implementation). Had I been paying closer attention I could have pointed this out sooner and we might have been in an ever so slightly better place, so apologies for that.
Let me briefly summarize the state of things, as I see them.
The CSSWG designed the text-transform property (long ago) to exhibit specific qualities for both accessibility and copy/paste. Namely, thinking that is was important that this was stylistic in nature, not exposed to AT and that one should be able to get the meaning directly from the document content, even if there was no CSS.
Text-transform got used a lot on the web, including by people who understood it this way - in part, because many people explained it that way.
Browsers currently at least, and for a while now, actually do not work this way. They expose the transformed text, universally. They didn't always, but they do now - and they do this consciously because they believe that that is the right thing to do.
The CSSWG was not aware of this reality and continued to operate under that design. On Sept 2018, @frivoal opened a bug to (re-)add support for the
full-size-kana
([css-text-3] text-transform: full-size-kana #3143) transform and based choices of that on the understanding of their original designs (# 1 above)Firefox implemented support. To date, they are the only ones (I believe, according to compat tables) who support it. Firefox's accessibly tree does indeed contain the transformed text.
Based on how things actually work in practice, @fred-wang made a proposal that seems to fit into the platform in a number ways very well and similarly to much in the platform - but the fact that it specifically desires the actual behavior brought to light the disconnect between the two communities
So... we are kind of stuck now having a conversation where some members of the csswg feel that this is problematic and seems like a bug, not a feature and need to be fixed - and accessibility folks who disagree. This seems especially unfortunate for two reasons: First, but less importantly, because until this is resolved, I feel like no one is going to want to resolve on the specific ask of #3745 * which is a real shame because it seems like that is important to moving that larger and important effort forward.
Second, and most importantly, because it seems very unfortunate for everyone involved outside of this discussion. That is, if the experts and authors of specs and implementations cannot agree then what hope do average developers have of understanding and making things that actually service the real users that we all care about?
Here are my own 2 cents:
text-transform
dates back to CSS 1 when situations were much different. There were no accessible browsers when it was imagined, there was no ARIA, AT, nor tools, nor underlying subsystems and so on.I believe that as much as we may have tried to reason about things, they were, in part, even later on, somewhat aspirational and speculative. For various reasons, I do not believe it was even possible to include the right people or understand the right problems at the time for 'now'.
Fast forward though and these things do exist and are robust and there is a universally deployed, significantly interoperable answer to "how does text-transform actually work" today and there has been for some time. That arrived over time with feedback, practice, tools and users and millions of people consume "bajillions" of pages of existing content with those today and.. well.. the shape of it all is not what we might have understood or imagined.
There are now experts whose entire careers are now focused on these problems and more "natural pressures" in the ecosystem to ensure that they are coming up with the best kinds of answers. So... I am kind of inclined to resolve this by
a) taking them at their word and trusting their expertise that this is not a bug and not going to change
b) working to actually understand how things really work and try to better understand perspectives
c) celebrate that it works and it works the same
d) Teach and build on it so that CSSWG has good parameters for when adding a text-transform value might be good or bad.
This last one is important because until now (or at least until recently depending on how you want to classify the kana stuff) it has been limited to capitalization and that is one classification of things. How CSSWG members imagined this 'worked' wasn't really correct and it turns out that making something all caps is not actually going to scream random bits of text at people using a screen reader in ways that they can't hope to understand. But the kana stuff was considered differently and we should probably make an effort to review whether that is actually 'different' or still fine before it gets more widely used or implemented, and yes, it would be helpful for the MathML-related proposals.
The text was updated successfully, but these errors were encountered: