[css-pseudo-4] ::nth-letter pseudo-element
#3208
Comments
|
I've published a demo earlier this week for |
|
All of these examples (and I expect, nearly all reasonable examples you could dredge up beyond these) are fancy headings; any usage of ::nth-letter in body text would almost certainly be... dodgy at best. One-off effects on top-level headings in a document still seem to be well-handled by just putting some (For example, I don't think any of those examples work if a "real" element splits the character, like |
|
Yeah... |
|
@upsuper @tabatkins I don't think any reasonably marked up document would put an element boundary there, so it's OK for that to be handled as a simplified error of some kind. I think the basic point is that pseudo-elements of this type make implementers very unhappy* so a moderately convincing use case with an easy workaround is likely not enough motivation.
|
|
@tabatkins said:
Like I said, I knew it would be difficult to implement. Still, I'm surprised that difficulty of implementation would win out over the accessibility problems of wrapping individual letters in a bunch of
Dredge up. Interesting. |
The hierarchy of concerns tells us that certain players in the space matter more than others; user-a11y is generally more important than implementation difficulty. It is not, however, absolute - Solving the a11y issues can be done more simply than adding
? I'm confused, it looks like you might be reading some deep meaning into my wording? |
|
Author of Splitting.js here. The difficulty of implementation is an issue I'm sure, but Bonus points if You can see some of the really creative ways folks have utilized Splitting for text, and it's not isolated to decorative headings. More use cases can be found in GSAP with its SplitText plugin. In the interim, I would love some proper accessibility support for splitting up text with |
|
Worth mentioning that we've had lots of discussion in SVG about how to handle features that assign properties to individual characters (w3c/svgwg#631). However, the conclusion we made there was to stict to predictable parsing (codepoints) over typographical elegance — an approach that isn't at all consistent with CSS |
|
See also w3c/svgwg#537, and in particular the linked-to examples showing how complicated this is for some scripts, eg https://w3c.github.io/i18n-tests/quick-tests/svg-counting/svg-counting-001. |
|
Perhaps there should be a more extensive snapshot profile, i. e. as a separate specification, that also included properties or values, but as a selector, |
|
Snapshot profile is dead (luckily), it's just the draft hasn't been updated accordingly yet (I'm going to make a relevant PR this weekend). IMO, there is already no problem with accessing any character of the text (as well as with selecting DOM elements basing on their contents) from JS APIs. It's styling these things that CSS developers have demanded for years but can't do yet. |
|
Accessing characters from JS is problematic when you get into Emoji or extended Unicode ranges where some “characters” are actually multiple, like the “family” emojis 👨👩👧👦
The current solution is a messy RegEx pattern matching specific ranges of
characters (see some discussion here shshaw/Splitting#25).Having a built in RegEx matched to target ligatures/combined characters Would be a huge help.
|
|
@shshaw well, |
|
Thinking… Maybe that's a use case better suited for shadow DOM? If scripting is confined therein, authors reaching for reusable components needn't be concerned much. The text could be programatically split into text nodes in the light corresponding to grapheme clusters and |
|
Here's a use case for
If there's reason enough to support dropcaps, there should be reason enough to support them correctly, not superficially. |
|
You could do this with However, here's an idea. How about we introduce control over which letters are considered part of the first-letter by using Unicode joiners? We could we specify that the That would allow us to support this example with |
|
It's possible to ask font designers to include these kinds of examples as single characters, but not likely to happen. I tried I think it's an interesting idea to control it with a Unicode word joiner. That should work for all the use cases I can think of. Thanks! |
A common use case for nth-letter/ nth-word / etc. are code or more general text editors and annotations for grammar, syntax, spelling, entities (NLP), etc. Which often require overlapping markup (see standoff properties / annotations for more). In above use cases styling the characters is insufficient: You will also want to register event listener, arbitrary data, … on it. So I’m not convinced an extension of the CSS spec would be a good idea. Except for using canvas/ CSS Houdini, I currently don’t see a good alternative to using a million span tags that wrap each character. To keep the markup readable I'm storing the plain text string in a data attribute of e.g. a paragraph tag. (however markup readability shouldn’t be a concern if you can inspect a readable JSON of the content) <p aria-description="Hello World">
<span annotations={...}>H</span>
<span annotations={...}>e</span>
<span annotations={...}>l</span>
<span annotations={...}>l</span>
<span annotations={...}>o</span>
...
</p>
|
I'd like to propose that there be an
::nth-letterpseudo-element in CSS.I've written about it on my website.
Previous calls:
The last time this came up, @frivoal said:
But also:
I would argue that the strong use cases are being demonstrated every day by any site using these JavaScript libraries:
Or these logo examples in the wild:
...along with most of these variable font demos.
Whether using HTML, or using JavaScript libraries, the only way to target specific letters is to wrap them in uneccessary elements. This can cause accessibility issues—a logo being read out letter-by-letter, for example, rather than as a whole word.
I understand that this would be hard to implement (given that
::first-letterwas hard enough) but I think the use-cases and accessibility benefits could outweigh the potential difficulty.The text was updated successfully, but these errors were encountered: