[css-text] text-transform's design, intent and reality resolution

@frivoal

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.

edit to correct the typo'ed off-by-one issue I accidentally linked to

@bkardell

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:

The original design of text-transform does not prevent assistive technologies from also applying the transform to the text if it would be appropriate for the way they are presenting it to the user.
Users of assistive technologies do not experience the accessibility tree directly. They experience the way screen readers (or their other assistive tool of choice) renders it to them. For such users, there is no observable difference between the accessibility tree containing transformed text vs the accessibility tree containing untransformed text to which the screen reader then applies the transform. But the later allows the assistive technology to make a choice about when to apply it or not, while the former does not.
For now, the values of text transform that have been broadly implemented are those related to capitalization. Roughly speaking, case transforms are reversible, so voice synthesis can render uppercase text identically to lowercase text (macOS's VoiceOver does).

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:

I'd expect an upper-casing text transform to be the stylistic in the same way as a font-feature or a color change would be, and therefore that it should not in general be preserved, to avoid having ::first-line { text-transform: uppercase} result in the first line being read in a screaming voice or spelled out, neither of which seem the intended effect. Indeed, in macOS, VoiceOver reads uppercase and lowercase text identically. The uppercasing may be used in the visual rendering to signal that something is a section heading, or maybe the content of an <em> element. The AT already has access to that information, and can signal it. It doesn't need to scream/enunciate/ping on top of that, and if it did want to, it can key that off the style rather than the text.
Similarly, unless the screen reader undoes the transform or otherwise renders it moot, exposing the transformed text breaks text-transform: full-width. Using it to display "IBM" as "ＩＢＭ" can be desirable in Chinese / Japanese / Korean text (particularly but not only in vertical text), but that doesn't mean that it should be read aloud as "full width Latin capital letter I, full width Latin capital letter B, full width Latin capital letter M". I still want to hear IBM. It's significantly worse if the word isn't an acronym to begin with.
Exposing only the transformed string defeats the point of text-transform: full-size-kana: りょ and りよ are different (the first is ryo, the second is riyo), but at the very small font sizes sometimes used in ruby, using the smaller ょ in りょ can make the text hard to see, and so authors sometimes want to display りよ instead of りょ despite the difference. The whole point of doing it using text-transform: full-size-kana rather than by hard-coding りよ into the DOM is so that screen readers can read it as ryo instead of riyo. For example, if the ruby for 無料 (which means free / costless) is encoded (as it should) as むりょう, that is read is muryō, and all is understandable. If it is encoded (or rendered into) むりよう/muriyō, this could be misinterpreted as 無利用, which means "useless". For a sighted reader, the potential confusion is probably preferable to the letter being too small to read, and they would see the original ideographs next to it, clearing things up if they can read them. But for someone going through a screen reader, it could be pretty confusing. If the screen reader reads both the original text and the ruby, you still hear "free and useless", and if it sustitutes the ruby for the original text, you would just hear "useless", instead of the intended "free (free)". Moreover, this transform is not reversible, so if the transformed text is exposed to the screen reader, there is no way the screen reader can untransform it to read it correctly.

Based on that, I'd suggest a different path forward than @bkardell

Changes to assistive technologies:
1.1. ATs that currently effectively undo the transform (either by actually undoing it internally, or by rendering the transformed and untransformed content identically) don't need to do anything.
1.2. ATs that do to expose some special effect on transformed content (e.g. play a tone, or change voice pitch, in the case of an uppercase transform) should look up the style information and trigger the special effect based on that.
Browser engines should switch to exposing the untransformed text in the accessibility tree

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:

[browsers] 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.

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.

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 full-size-kana case, but please believe us when we say 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. That is working as intended, regardless of how anyone who doesn't use a screen reader or other AT habitually may feel about it.

please believe us

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:
#3745 (comment)
#3745 (comment)

I'm not sure what I can possibly add to those explanations at this point.

Merely stating that you know better doesn't help get to a conclusion.

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.

@frivoal

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:

Expose the transformed text as the effective text content after CSS processing (which also includes whitespace normalization, removing any display: none or visibility: hidden text, inserting CSS generated content, etc.). This is what all modern browsers seem to do.

HTML (both WHATWG and W3C versions) also currently requires text-transform to be exposed as part of the innerText IDL property (which also exposes the whitespace and hidden element processing, but does not include CSS generated content).
Expose the transform as a style attribute on the original text (similar to how bold/italic formatting are exposed to accessibility APIs), and expect assistive tools to determine how to expose the transformation to end users. From everything we've heard, it sounds like this would require a lot of implementation changes from a lot of different software types.

Browsers would need to separate text transform from the other CSS text processing steps and keep track of the intermediary result. Accessibility APIs may need to be modified to have a way to expose the text-transform operation. Assistive tech would need to check for the transform style & find a way to expose it to users, which may involve implementing an equivalent character-by-character transformation step.

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) full-size-kana option. @frivoal: were options other than text-tranform considered for handling this typographic style? Would it make sense to describe the change in terms of a font-size adjustment instead of a conversion to different characters?

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.

Joanies' comment explains that users of a screen reader want the screen reader to be able to do something like
```
Use higher pitch
Play a tone
Say "cap"
```
I believe that. Users want this. Ok. I have faith in your understanding of AT users's expectations. That does not say why it is desirable to do that based on the text in the accessibility being pre-transformed, rather than the screen reader triggering those effects based on the styling information.

It also does not say why they don't apply the same effect (higher pitch, playing a tone, saying cap etc), when using font-variant: small-caps;, or if screen readers already do that, why they couldn't look up the text-transform property the same way.
She has said:

Screen readers, as a general rule, want to present the content sighted users see. Exactly how it got rendered is, more often than not, irrelevant.* Furthermore, it's a drag for an AT to have to take every single bit of accessible text, retrieve some additional property "just in case", and occasionally do additional work to transform it. The render tree already contains the final/displayed version, so please share that with me. 😄

*But if any ATs might have a need, exposing the transform property as an attribute on the accessible object shouldn't hurt anything and should be relatively easy to implement within the user agent.

That leads me to believe that it would be equally good from AT users's point of view if the accessibility tree exposed the untransformed string + the transform, and screen reader did the transformation / effect themselves. It certainly would just be less convenient for screen-readers implementers. "It would be less convenient to implement" may be an argument worth considering, but it is very different argument than "It would be wrong". I've already acknowledged that it was a more convenient implementation strategy (as long as we only care about case transforms), and I was asking if there were reason other than that.

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:

国内線でWIFI Serviceは無料！

This means “Free WIFI service on domestic flights".

If you use text-transform: full-width (not the full-size-kana entry recently introduced), which is a perfectly reasonable thing to do for typographical reasons, it gets turned into

国内線でＷＩＦＩ　Ｓｅｒｖｉｃｅは無料！

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.

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.

That's fair. I apologise.

It also does not say why they don't apply the same effect (higher pitch, playing a tone, saying cap etc), when using font-variant: small-caps;, or if screen readers already do that, why they couldn't look up the text-transform property the same way.

This is a reasonable point. font-variant styles do not get exposed the same way - this is either an oversight, or a reflection of the fact that smallcaps styles do differentiate between capitals and lower case letters unlike the text-transform case, or somewhere in between.

...
That leads me to believe that it would be equally good from AT users's point of view if the accessibility tree exposed the untransformed string + the transform, and screen reader did the transformation / effect themselves. It certainly would just be less convenient for screen-readers implementers. "It would be less convenient to implement" may be an argument worth considering, but it is very different argument than "It would be wrong". I've already acknowledged that it was a more convenient implementation strategy (as long as we only care about case transforms), and I was asking if there were reason other than that.

I think the issue is that it would likely constitute a regression for users until all ATs caught up, which may never happen.

But implementer convenience doesn't trump end user's needs,

Totally agreed, but we have to be pragmatic as well - for the text-transform: uppercase case, users have a "good enough" experience without anyone needing to change anything, and would not be happy if a change were to lead to them missing information.

That logic may or may not apply for other text transformations.

If you use text-transform: full-width (not the full-size-kana entry recently introduced), which is a perfectly reasonable thing to do for typographical reasons, it gets turned into

国内線でＷＩＦＩ　Ｓｅｒｖｉｃｅは無料！

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 sounds like a much worse experience than the text-transform: uppercase situation, I agree. It doesn't seem unlikely that if you were to ask a Japanese-speaking screen reader user (who for all I know may use a different screen reader which already works around this problem) whether this was the experience they wanted, we would get a different answer to the text-transform: uppercase situation, and it doesn't seem unreasonable to treat these cases differently based on their different merits.

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 text-transform. They get the content rendered in the most appropriate way, with a range of presentational options based on which software they're using.

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 text-transform that rely on that assumption so much that meaning of the document changes if you do not apply the transform.

It would do a disservice to AT users to restrict the allowable options
it would be break forward compatibly of existing browsers that do not have that feature with new content that would use it
it would break the content when network problems cause css to fail to load
it would break the content when viewed with UAs that don't support CSS (crawlers, RSS distribution of the same content, etc)

In conclusion, I think that:

The exact shape of the data exposed in the accessibility tree and other accessibility oriented APIs is out of scope for CSS.
Separately from the specific accessibility tree API design, the design of text-transform itself needs to be that the semantics of the text are unaffected, and therefore it MUST be acceptable to convey the text untransformed to the user, and that ATs (or other tools, like reader mode or alexa or what have you) MAY take styling information including text-transform into account when presenting that text to the user (and possibly that they SHOULD take that information into account for case related transforms, but I'd say that that too is out of scope for CSS).
Any values that clash with this model don't belong in that property.
In the spec where we define the accessibility tree (or in a note in the CSS spec if there's not good normative spec to host this for now), we probably need to define:
4.1. for compat with existing ATs (and because we may well do the same thing again even if we did not have the compat constraint), the text in the accessibility tree must? should? be pre-transformed for the case-related text-transforms
4.2. that non-case transforms (full-width, full-size-kana) must not be reflected in the text of accessibility tree
4.3. To support the ability of ATs to give further presentational options to their users, we should expose the transform property as an attribute on the accessible object, as suggested by joanie in [css-text] Add new CSS text-transform values for math #3745 (comment)

I think that this would be good because:

it doesn't require changes to existing implementations of case-related text transforms
It does allow non-case related, i18n text-transforms to work out of the box with existing screen readers when browsers start supporting these values
it enables the broadest range of presentational options for screen-readers that care to offer them to their users
it does not stop us from adding the math related transforms discussed in [css-text] Add new CSS text-transform values for math #3745 (I'll give details in a separate comment, probably in that issue, how we can reconcile the two).

@frivoal

@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:

Check every last element just in case it's been capitalized via text-transform. Odds are it hasn't been, but one never knows.
Do the actual transformation -- taking into account any localization issues.

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.

@AmeliaBR

what to do about text transformations where exposing the transformed character would be bad for accessibility?

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:

can those two things share a property if necessary (ie, is it ok/desirable if AT does something diff with kana stuff if that is what should happen)
1.1) If not, is it really too late to reimagine that one as something that isn't called text-transform? If so, can someone tell me why? I'm sure if that is the case there is a reason, it would be helpful to have right here if possible. It seems to me it is relatively recently to have been brought back to wg and ff's is the only implementer and it seems problematic on this already.

Maybe most importantly: How do we decide this? I would like to propose that we really need people who are not in the wg involved in that conversation because a number of wg folks have reasoned about this very differently historically and I'm not sure we are fully well suited to judge. Some of this may be answered by florians statement about what is not in the domain vs what is, but I think we need to articulate carefully there or be sure we include the right experts at any question

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.

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 (text-transform: none !important). Anything else would have all the same implementation obstacles of requiring browsers to expose both transformed and untransformed text to the screen reader.

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.

@fantasai

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.

@bkardell

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

@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.

Navigation Menu

Repository navigation

[css-text] text-transform's design, intent and reality resolution #3775

40 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-text] text-transform's design, intent and reality resolution #3775

Description

Activity

frivoal commented on Mar 29, 2019

alice commented on Mar 29, 2019

frivoal commented on Mar 29, 2019

alice commented on Mar 29, 2019

AmeliaBR commented on Mar 29, 2019

frivoal commented on Mar 29, 2019

alice commented on Mar 29, 2019

frivoal commented on Mar 29, 2019

joanmarie commented on Mar 29, 2019

bkardell commented on Mar 29, 2019

AmeliaBR commented on Mar 29, 2019

40 remaining items

bkardell commented on Aug 19, 2020

r12a commented on Aug 28, 2020

frivoal commented on Sep 1, 2020

astearns commented on Sep 7, 2020

yisibl commented on Jun 5, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions