A way to reset ellipsis on larger screens?

[benface]

text-overflow's default value is clip; there should be a utility to set it to that value so we can reset/remove ellipsis on larger screens.

Three options:

• Rename ellipsis to overflow-ellipsis and introduce overflow-clip
• Rename ellipsis to text-ellipsis and introduce text-clip
• Keep ellipsis as-is and introduce no-ellipsis

I think I'm leaning towards option 3.

[hacknug]

I'd go with .text-ellipsis and .text-clip since it looks like we're going to be able to use any <string> as the value of the property soon (once level 4 lands on browsers). Maybe .to-ellipsis and .to-clip are safer options so classes don't collide with other core plugins using just text.

https://developer.mozilla.org/es/docs/Web/CSS/text-overflow#Values
https://drafts.csswg.org/css-overflow-4/#overflow-string

[benface]

Good point @hacknug! However I think ellipsis-[key] would be a better name than text-[key] or to-[key] when the property becomes configurable (e.g. ellipsis-dash for -), and the default key could be ellipsis which would generate a simple ellipsis class just like border, rounded, shadow, etc. So perhaps no-ellipsis should be ellipsis-none (which would really apply text-overflow: clip haha)?

[hacknug]

My issue with this is that ellipsis is nothing but the name of the … character 🤷‍♂

[benface]

@hacknug Yeah, that's fair. I actually looked it up before posting my previous comment and had seen that an ellipsis was also "the omission from speech or writing of a word or words that are superfluous or able to be understood from contextual clues", but that might be a different definition of it that doesn't refer to a character or series of characters at all. I just think text-[key] wouldn't really work if the key was something like dash, and to-[key] is too obscure. I also like that my solution is backward compatible (there would still be an ellipsis class). But if it doesn't make sense... might just have to go with text-overflow-[key].

[hacknug]

Yeah, I think that definition wouldn't apply in this case because you're truncating text, not omitting superfluous content that can be understood from contextual clues. I just wanted to point this in case it was something you hadn't consider.

Why do you think .text-dash wouldn't work? Just asking because I'm more interested in understanding what your considerations more than the actual class name (hoping I don't use obscure names on my plugins haha).

[benface]

Why do you think .text-dash wouldn't work?

Well, it's missing the idea of truncating text / overflow. I suppose the user could just make the key overflow-dash instead if they wanted it to be clearer (since the only default values would be ellipsis and clip), but there's still the issue of potential collisions with other text-* classes.

[hacknug]

Agree. The only reason I proposed that is because core seems to use the .text-whatever convention for all those plugins haha.I'd probably go with .to-whatever which I also think is far from ideal but…

[benface]

Decided to go with no-ellipsis for now (done in 9ae2dee), since the text-overflow: <string> syntax is not supported in any browser other than Firefox and the spec is still a Working Draft. Also I really like no-ellipsis and how it fits with some of Tailwind's built in utilities like no-underline and not-italic.