- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Sun, 27 Aug 2023 22:08:00 +0000
- To: public-css-archive@w3.org
> We have a whole history of tension between trying to provide high level features baked into the platform for editing, and providing the right primitives to enable (js-based) editors to built such features effectively. And as @tabatkins [pointed out earlier](https://github.com/w3c/csswg-drafts/issues/8874#issuecomment-1563410963), this is purely a visualizing feature. Though as @johannesodland [wrote](https://github.com/w3c/csswg-drafts/issues/8874#issuecomment-1563223038), it should also be capable of displaying special characters like soft hyphens, zero-width spaces (U+200B, U+FEFF), etc. So it might affect text formatting in some cases. To me, showing invisible characters seems a natural fit for CSS. And it is something where CSS should pave the cowpath. Because of the requirement of being a purely visual effect, I also think `text-transform` may not be the right fit. Maybe a new `text-visibility` or `character-visibility` property or something along those lines. A few questions that come to my mind: * Should the visualizing characters be predefined? * Should authors be able to change them? If so, to what degree (i.e. only replace the predefined ones or also declare new ones or remove predefined ones)? * Should they be stylable? (Many editors display them differently from the rest of the text. So if the answer is yes, then we'd need a new pseudo-element for that.) * Should this be a pure CSS solution or a combination of CSS and DOM APIs like for the Custom Highlight API? Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8874#issuecomment-1694773105 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 27 August 2023 22:08:02 UTC