291–296 of 296 posts
Earlier quoted context omitted.
AFAIK using the tailwindcss-cli without npm makes it impossible to use Tailwind plugins, such as DaisyUI.
This is not true, here is a demo projects which uses the Hex Tailwind and DaisyUI: https://github.com/naymspace/backpex/tree/develop/demo
Earlier quoted context omitted.
AFAIK using the tailwindcss-cli without npm makes it impossible to use Tailwind plugins, such as DaisyUI.
I believe that is true, although there is a project which bundles Tailwinds and DaisyUI into a single standalone executable: https://github.com/dobicinaitis/tailwind-cli-extra I have not tried this out yet, personally.
FWIW, the tailwind binary from the official channel works great. I install it in my build.rs.
I think the reason why tailwind is as popular as it is, is because it really ties in with the "change something, save, then immediately see the result" loop and dx of modern day web development. Yes, this works with regular css too but it's the fact that you can do bigger changes inline quickly without making up a class (and god forbid you already have a different class affecting the same element and it gets hairy).…
And thereby you kill all inheritance, that is the while point of css. I find it more magic to change a single class at root and have the entire design reflow (on purpose) - Its beautifull when combined with shadowdom and wc
What I would really want is to be able to write tailwind css classes but then have it automatically turned into regular css that makes sense on save. I really don't like coming up with class names and such.
Earlier quoted context omitted.
yeah, the palette is neat. My main gripe with Tailwind is that it blends a set of design tokens (which I like) with a technology to apply them (which I don't like)
Maybe check out Open Props? https://open-props.style/
Earlier quoted context omitted.
Just copy and paste them out?
tailwindcolor.com is good for that
CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code. You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar metho…
> I simply don't see the appeal. - Not having to name CSS classes - Easier to read as it's inline with the rest of your HTML - Standardised way of naming so that everywhere uses the same conventions - Not having to manage a separate file and remove unused components - Being able to use media queries, which I couldn't do in a style tag - No risk of changing a class that is used elsewhere. CSS has global scoping which…
Most websites are maybe 20 components and localized pages. Not exactly that hard to name and keep constant. Can not think of names, just ask one of the AIs.
> - Easier to read as it's inline with the rest of your HTML
Only if you do a few styles. The moment you have mobile + desktop + dark/light you start to leave lines half a mile long.
> - Not having to manage a separate file and remove unused components
Counterpoint: Components/templates are still the same hell to manage.
> - Being able to use media queries, which I couldn't do in a style tag
CSS ... literally the bread and butter.
> - No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.
Counterpoint: You will end up with styles that are applied to parts, then copied, forgotten to change, and then have a mix of styles that conflict with each other.
And you do not use global scoped CSS, but localized per page. All you need is local CSS + a single parent id/class and voila. Local scoped will not mess with global. Do not do stupid stuff like button { style style style }. No, make global scoped iButton, so you never run into the issue off having parental styles doing funny things to child styles.
Let me introduce our lord and savvier called Nested CSS + Named CSS tags ... Reusable, standardized, ...
Tailscale is frankly a solution for front end JS frameworks, and less for any server rendered html. Use local CSS for html pages that are really local. No need to make global CSS for price cards that you only use on one page. But if something is used over multiple pages, buttons, ... that is global. Simple, no?
Ironically, i am in the process of actually removing Tailscale everywhere because the recent 3 > 4 upgrade screwed so much up. What stayed good? My actual CSS nexted/tag components that i never.
That is one of the issues with frameworks in general, etc, things between versions can really mean a lot more work vs just having everything "basic".
I feel a lot of issue that people have with CSS are more related to not having a proper understanding about CSS, and ignoring some basics. Like do not style base tags. Use nested + custom naming tags, local css + a local id/css and you have no issue with overlap. Best of all, you gain the ability to make easier reusable components as your CSS are the components, not some JS/... whatever call you need to do to render something. It gets messy fast if your breadcrumbs is a components with items, and you need to change something later on. But if its a basic breadcrumbs{} css, adding feature is just a matter of adding naming.
Trust me, took me years to get out of this mindset (and it helped that CSS evolved a lot but most people do not even realize that CSS today != what they know/grew up with)