Re: [csswg-drafts] [css-text] text-transform's design, intent and reality resolution (#3775)

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.


-- 
GitHub Notification of comment by r12a
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3775#issuecomment-682635143 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 28 August 2020 14:39:11 UTC