search

benface / tailwindcss-typography

Tailwind CSS plugin to generate typography utilities and text style components
ISC License
245 stars 5 forks source link

A way to reset `ellipsis` on larger screens? #5

Closed benface closed 5 years ago

benface commented 5 years ago

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:

I think I'm leaning towards option 3.

hacknug commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

benface commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Decided to go with no-ellipsis for now (done in 9ae2deeea388e5bfd9c91ab8936a7a0ee5e01161), 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.