[HN Gopher] Signals for Tailwind CSS (styling based on ancestor ...
___________________________________________________________________
Signals for Tailwind CSS (styling based on ancestor state via style
queries)
Author : throwaway888abc
Score : 30 points
Date : 2024-08-31 19:37 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| skeptrune wrote:
| This is really fun. SolidJS has the `classList` attribute which I
| use a lot in scenarios where this would work. I think a plugin
| like this would also be preferable so as to avoid the extra JS
| state code which really always feels like a cheap hack.
| paulddraper wrote:
| hover:[&>div]:bg-green-800 peer-checked:[&>div]:bg-green-800
|
| Anything to avoid writing CSS
| tptacek wrote:
| Well, yes, that is more or less the idea of Tailwind right?
| koito17 wrote:
| I've understood the point of Tailwind to be two things:
|
| 1. Allow styling to co-exist with your DOM layout rather than
| separate files
|
| 2. Provide a ready-to-use style system built atop utility
| classes
|
| Emphasis on "utility classes". This is what makes Tailwind
| different from e.g. Bootstrap.
|
| I don't think the point is to avoid writing CSS. The point is
| to write CSS in a way that allows it to be co-located with
| DOM layout, so that UI components can become self-contained
| pieces of code.
| paulddraper wrote:
| The last paragraph sounds like CSS-in-JS
| muratsu wrote:
| This is what most people want + some utility functions &
| good default variables (for colors etc).
|
| If you're doing relatively straightforward things,
| tailwind is super easy to work with and that's why a lot
| of people prefer it today. Having it inline makes it easy
| to digest (both for humans and LLMs) until things get
| complicated.
|
| I see this similar to using javascript in your project.
| When you start fresh on a new project, typescript can be
| seen as a bottleneck, slowing you down. As project
| evolves your needs also evolve and other solutions might
| be a better choice.
| koito17 wrote:
| CSS-in-JS solutions like Emotion provide something close
| to that! But they come with some drawbacks (e.g. needs
| careful setup for server-side generation, spends a few
| CPU cycles translating to CSS, breaks memoization unless
| one uses deep object comparison or stores the style data
| separately from the component).
|
| CSS modules provide a great alternative if one is willing
| to write CSS in separate files. Otherwise, Tailwind has
| provided a smoother experience than CSS-in-JS for me.
| krsdcbl wrote:
| Tbh I never really understood the reason for the
| existence of css-in-js either.
|
| Just do vanilla `<style> @scope { /* your component
| styles without any naming bloat ... */ } </style>` nested
| in the markup/jsx, and optionally leave merging any of
| that for perf optimisation to some rudimentary build
| tooling or hydration
|
| But also: I do see the QoL benefits of colocating styles
| & markup, but it has drawbacks aswell: it prevents you
| from being able to reuse design systems across different
| applications/codebases, and increases maintenance
| complexity and tech debt as soon as you introduce utility
| classes or any styling rules that aren't hard-tied to a
| singular component. Both issues scale painfully fast with
| the complexity of your App/UI, and impact Tailwind-based
| UIs even more in my experience.
| threatofrain wrote:
| If anything this puts a slightly higher burden on the dev
| because you're still always responsible for the underlying
| CSS, now you just have to be aware of how the utility
| classes map to CSS.
| djbusby wrote:
| And when the CSS is "inline" via classes vs raw style then
| you get consistent padding (p-4) vs some things that vary
| and are hard to update theme-wide (padding: 8px).
|
| It's basically putting a bunch of CSS into "vars" or
| macros.
| krsdcbl wrote:
| Exactly my point: it provides an interface to manage
| design tokens, instead of having to think about those
| constantly and litter your code with magic values
| everywhere.
|
| But the way this systemisation is integrated throws away
| most of the advantages. What good is having "p-4"
| abstracting "8px", when you then repetitively hardcode
| the alias all over your markup instead of defining
| individual, reusable and easily maintainable classes?
| krsdcbl wrote:
| I think this is precisely what I am ranting about.
|
| These two usecases is what makes Tailwind so useful and
| accessible for drafting stuff up, but also bear the
| pitfalls of tech debt to actually maintain and iterate the
| design system of complex ui systems
|
| What irks me is that so many people seem to be utterly
| unaware of this intent, and rather regard Tailwind as some
| sort of "better css", on the basis of not knowing much
| about CSS
|
| But a truly good and flexible design system needs all of it
| in the end:
|
| - a top layer config that allows definition and maintenance
| of design tokens
|
| - an intermediate layer of abstracted presets to ensure
| portability and maintainability of design system specific
| patterns
|
| - a lib-level layer of utilities to avoid having to force
| one-off declarations like the layout of a specific view
| into either of the other abstractions (Ex: "search results
| as 3 column grid on desktop" is not a design system
| concern, it's neither a "style", nor relevant to any other
| components or visual styles)
|
| When it comes to keeping styles & markup together, this has
| always been possible with simply using `<style>` tags in
| your templates or components. The performance impact is
| absolutely negligible IRL, and any leakage or selector
| naming concerns have also become a none-issue with `@scope`
|
| Don't get me wrong, Tailwind has the RIGHT IDEA! It solves
| to top level layer of managing the design system, which
| also is the main reason for it's success imho
|
| The big issue is that it is constantly being used the wrong
| way, @apply which would allow for proper abstraction of
| component styles is largely being ignored, and thus instead
| of forcing utility into superfluous class bloat like it's
| common in framework-less vanilla CSS integrations, most of
| it's users rather force the intermediate abstraction into
| the utility-only layer, producing unmaintainable garbage
| markup and utterly illegible and repetitive style
| declarations.
|
| And to get back to my original point: This comes imho from
| the widely prevalent fallacy that Tailwind ought to replace
| the "traditional way" of writing styles, and failure to
| understand that it is meant to merely extend on it &
| utility classes should be employed in moderation and for
| specific purposes in design-systemized UIs
| gedy wrote:
| > These two usecases is what makes Tailwind so useful and
| accessible for drafting stuff up, but also bear the
| pitfalls of tech debt to actually maintain and iterate
| the design system of complex ui systems
|
| Tailwind is really rotten for complete design systems,
| (I'm not just talking about an app's theme like colors
| and fonts)
| gedy wrote:
| > Emphasis on "utility classes". This is what makes
| Tailwind different from e.g. Bootstrap.
|
| Just FYI that Bootstrap 5+ has really good utility classes:
| https://getbootstrap.com/docs/5.3/utilities/background/
|
| This plus their component classes makes Bootstrap a lot
| more practical for most needs imho, and without needing
| some build step.
| krsdcbl wrote:
| I think OP is pointing to the irony of using an increasingly
| verbose and overly complex wrapper API that makes it utterly
| painful to maintain styles "just" to avoid learning css,
| which is regarded by many developers as confusing or hard to
| learn, but is actually much more accessible, legible and
| maintainable than what Tailwind had become by now.
|
| I might be reading a lot into this remark and mostly relying
| my own opinions here though.
|
| But throughout the years I've been seeing how CSS is
| universally met with insane prejudice and expectation of it
| being "too complicated" or painful to learn, and Tailwind
| being praised as the solution while actually being much more
| verbose and obfuscated, and time after time leading to
| irrecoverable tech debt, utterly illegible markup, and
| complete dead ends whenever style needs any kind of
| refactoring.
|
| Now that CSS is maturing and getting tons and tons of new
| features, Tailwind lags behind and keeps introducing more
| weird workarounds and hacks to be able to support all of it.
| The line in OPs comment is an example of it literally coming
| down to writing mutilated CSS selector statements directly to
| html attributes just to be able to do some of the stuff
| `:has()` enables, and creating horribly illegible markup and
| non-reusable styles in the process ...
|
| Imho the original issue leading to "stylesheets are a pain"
| was never really CSS itself (at least since module 4 & custom
| props), but rather the top level management of tokens in a
| design system to not have to memorize colors and sizes etc --
| Tailwind is simply collaterally fixing the right problem with
| the worst approach thinkable, but keeps being hailed as a
| holy grail by people who lack understanding of this.
| tptacek wrote:
| Thanks! This is helpful.
| llamaimperative wrote:
| Perhaps the point of Tailwind _isn 't_ to obviate the need
| to learn CSS. Which seems obviously true to me, given that
| if you don't know CSS you can't really use Tailwind very
| effectively.
|
| There's definitely a 0.1% long tail that's tricky with
| Tailwind (like this), but 99.9% of app styling is so
| ludicrously _fast_ in Tailwind as compared to writing raw
| CSS.
| aidos wrote:
| I disagree with the main motivations and benefit. For me
| it's always been about being able to handle hover states
| etc without having to leave the local context where I'm
| working. I don't think anyone can really write tailwind
| without understanding css.
| franga2000 wrote:
| Adobe Brackets had an interesting solution to the context
| switching problem. There was a keybind, I think CTRL+E,
| that would let you edit all the styles that apply to the
| current element in a kind of inline sub-editor. It was
| quite neat and I haven't seen it done in any other
| editor.
| spankalee wrote:
| You didn't have to leave the local context if you use
| very local stylesheets. Scoped CSS like shadow DOM, plus
| CSS text right with your component, helps a lot with
| this.
| wruza wrote:
| Style attribute lacks a selector ("color:red" vs. ".comp
| {color:red}"), forbidding the most useful use case.
| Shadow dom is an inspection nightmare used only by a few
| progressive web purists. Style.css is an untyped
| incoherent spaghetti. There's no really good place for an
| element style in current implementation.
| troupo wrote:
| CSS took 20 years to begrudgingly incorporate the most
| useful features of SASS, and these are still not wide
| spread or (like nesting) have become available barely a
| year ago.
|
| CSS is verbose, repetitive, error-prone, and requires
| insane workarounds to keep it manageable.
|
| There's a reason why SASS has been nearly a de-facto
| industry standard, and why abominations like BEM exist.
| krsdcbl wrote:
| SASS and LESS have their place, but they are tooling, not
| replacements
|
| The time it took for CSS to progress like this although
| is on Browser vendors, not on the language - lots of
| recent features that seem utterly late to the game have
| existed for years and years, but had to be deemed
| "unsafe" to use because of Safari, Firefox and other
| browsers that lag far behind the standard.
|
| And honestly, the critique you throw at CSS is all the
| more true for Tailwind actually, and imho only stands the
| test for _badly written_ code, which holds true for any
| language in any domain.
|
| And regarding why BEM exists: it's just a flavour of
| naming convention for your "API", nowhere mandated by CSS
| itself. Its main purpose is to optimise paint performance
| and keeping your component naming lean and transparent.
| You may very well simply write expressive and specific
| queries instead of defining naming conventions for your
| components.
|
| But I'm unsure if we talk about the same things in the
| end, cause none of those points get any better with
| Tailwind, rather the opposite.
| meiraleal wrote:
| Not really. The example is worse than CSS in many ways and
| the idea of tailwind wasn't to be worse than CSS.
| muratsu wrote:
| I didn't know about the @container queries, they look
| interesting.
|
| Having said that, I'm not a huge fan of pushing more state logic
| to CSS. I understand the benefits (from the github page) but
| pushing more text into the style string without thinking about
| tooling (how to debug etc) is dangerous.
| tengbretson wrote:
| Write-only code is so hot right now
| meiraleal wrote:
| It is a hype phase. Everybody adds tailwind, later everybody
| removes tailwind. We need to find ways to be busy anyway.
| montroser wrote:
| Tailwind is both great and terrible. The trick is to take just
| the good parts and not let it poison the rest. Let it make easy
| things easier, but don't let it take over and make the hard
| things impossibly difficult.
|
| Here's how to do it: use Tailwind only for layout (margin,
| padding, flex) and brand consistency properties like text size,
| line height, colors etc. Beyond that, anything that requires
| changing presentation based on state, embrace CSS. It was meant
| for this, and remains the best solution. Invest in learning CSS
| because it will still be here in 20 years.
| Griever wrote:
| I'm a strong advocate for Tailwind, and I believe that this
| approach is truly effective. In my experience, this subset of
| Tailwind has been sufficient for every project I've worked on
| that used it. Moreover, I've observed that it often converts
| skeptics into supporters.
| ericyd wrote:
| This is refreshing to hear. The DSL provided by this plugin
| feels like an entire new language to learn. My experience with
| Tailwind has been positive but I'm not sure I want to learn new
| ways of doing the same things just to stay within a pure
| Tailwind framework.
| caesil wrote:
| Tailwind is CSS though? Like, it much more strongly maps to
| individual styles than most other popular style frameworks and
| systems.
| wruza wrote:
| _style queries_
|
| As expected, they didn't stop with :has and slowly turn it into a
| subturing abomination.
| inopinatus wrote:
| NSFW but I just want to point out that using form validity
| semantics we are not constrained to telegraphing state within
| local element hierarchy/adjacency but can in fact toggle a
| binary, selectable CSS state from anywhere on a page.
|
| https://codepen.io/inopinatus/pen/vYxrOeR
___________________________________________________________________
(page generated 2024-08-31 23:00 UTC)