[csswg-drafts] [css-text] design, intent and reality resolution (#3775)

bkardell has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text] design, intent and reality resolution ==
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.

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

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

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

4. 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` (#3143) transform and based choices of that on the understanding of their original designs (# 1 above)

5. 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_.

6. 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 #3746 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.





Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3775 using your GitHub account

Received on Thursday, 28 March 2019 17:11:14 UTC