A Set of TailwindCSS Based Transactional HTML Email Templates
github.com
github.com
When many email clients forward an email, all styles in the document head are removed, which breaks emails that have not inlined their styles.
How does these templates handle responsiveness?
Handling responsiveness and still looking good in MSOutlook can be tricky.
Have these been tested using Litmus? I did not see any images of these templates in email clients.
I have done a bunch of work on emails, and found that building html emails that look good and render well on all popular email clients while staying responsive is tricky
That's source code from the project. Tailwind is just inline styles via CSS shorthand classes. I cannot understand why anyone would want this unless they are coming from bootstrap.
Tailwind is unreadable when glancing through source code, especially when styles get large. It's just a web fad.
A big one is that you don't have to think about abstractions or relationships between classes.
But instead think in terms of utility and really making it a language of it's own right.
I was hesitant but gave it a go. It was quite enjoyable and productive.
There's also the @apply which enabled you to still remove the duplication or build your own utilities on top of their skeleton.
Don't knock it till you try it!
1. Yes it's almost another language, you have to memorize shorthand syntax that is sometimes unintuitive.
2. I need something cross-platform, not a web specific tool. I've moved to RN Stylesheets for both native and web and I don't deal with normal CSS at all.
3. I don't have a problem naming classes, I find it helps maintaining later at the cost of slightly more time upfront. Plus you can compose multiple classes based on states. You can also reuse those classes within the same component. Seems difficult to do that if you inline things. If I did want to skip naming I would use something like JSXStyle/SnackUI instead of Tailwind (direct props, not shorthand strings).
Tailwind is great for web designers wanting to iterate a design quickly, that's about it. I feel you pay for it later though. It's ugly and unreadable at a glance. We just circled back to inline styles.
i always see this and never understand the pushback, or have people never worked on large apps spanning hundreds/thousands of components and have to maintain it.
it's a godsend when working on older components and i don't have to dig thru some other css file and figure out exactly how and why i named it. inline css doesn't allow to do transitions, animations, responsive breakpoints, etc. everything is there is contextual and i never break flow going from design to implementation. you still can have global styles or can have a master design guide.
My point was the end result is the same as inline, yes it's less verbose than inline but it's more obscure unless you have all the shorthand class names memorized. It's just a messy string, can you even make that type safe?
> and i don't have to dig thru some other css file
That's a separate issue solved via CSS-in-JS in general. I believe your styles should be isolated to your component, preferably in the same file, not global. That doesn't mean we have to shove styling in the className string attribute.
It's not the same as inline styles because it expresses things that inline styles fundamentally cannot. Inline styles don't have media queries or selectors.
> It's just a messy string, can you even make that type safe?
WTF? Is any other HTML class string typesafe?
Okay, it's as if you added media queries and selectors to inline styles. It's still a nightmare to read like inline styles. It's terse, but as a result it's also more cryptic. It leads to long strings of near gibberish until you carefully read it out.
> WTF? Is any other HTML class string typesafe?
My point is a className string is not typesafe, my styles are fully typed, because it's normal TypeScript. Shoving styles into a string would remove that feature.
I get autocomplete and type checking for the component styles, for example, if it's a view component then it only gets view styles, trying to apply "color" will result in a error.
It's incredibly useful to have autocomplete and type checking for your styles because there are so many combinations of properties. You don't want to supply a number when a string is expected for a font weight, you don't want to supply a value that isn't supported, you don't want to apply a text property that will have no effect on a view element.
Example: https://codesandbox.io/s/dazzling-leaf-rjv7v?file=/src/app/u...
It's gaining momentum and it has been around for 4 years (https://adamwathan.me/going-full-time-on-tailwind-css/, https://github.com/tailwindlabs/tailwindcss/commit/421c1b0d7...)
It was preceded by other similar frameworks, too. It's a pattern some people like, and it's productive enough that I suspect it'll stick around.
I meant "fad" in the sense that it's really popular right now, but it'll die down later on back to the few that it really clicks with.
I doubt it'll be the standard across the styling ecosystem, it'll be like Svelte, or at best like Vue, is to React.