krsdcbl

if the styles only concern the context you work on, this could easily be done with vanilla scoped inline styles

If those declarations are relevant to multiple components within your codebase, then you'll still need to leave the context when your styles are inlined and therefore declared in multiple places

It definitely isn't, my point is that it seems to be largely is misunderstood as this being it's main purpose.

Tailwind is unquestionably accelerating drafting up a custom UI, and also makes this much more approachable for webdevs unaccustomed to CSS

The pitfall of declaring all your styles as strings of shorthands in html atts also might never hit you if your UI doesn't get too complex and/or never needs refactoring - but it hits hard if your codebase had grown to a certain scale over the years, and you suddenly need to change or refactor larger parts of the UI

Curious about your expectations: Do you rely on utility classes only in your workflow, or do you split reusable patterns into "original CSS"-like @apply blocks?

And how would you categorise the complexity of the Apps/UIs you build like this?

I'm very interested in the specifics of successful applications of Tailwind that the maintainers keep deeming a good solution, since CSS as a whole is one of my main scopes and I've had quite some projects that where basically some variation of writing custom brand-lib frameworks for teams who embraced Tailwind at first, but in time ended up hard locked when needing to refactor or iterate their UI

This is the core fallacy though, imho: css ITSELF is already the tool for "mapping individual styles" to DOM elements.

Oldschool "CSS Frameworks" are libraries intended to bootstrap UI creation by providing abstractions of those mappings for a set of universally required UI patterns.

Tailwind pioneered the idea of "functional css" as a means to fix the "one-off classes" style bloat for anything that is NOT a specific component pattern (think "this specific archive view should be presented as a 3 column grid")

But when you end up aliasing all of CSS with such utilities, and then writing your styles to markup atts directly ... you aren't using a "framework" anymore, you simply "wrapped" most of CSS itself in a bunch of rainbow tables and littered it all over your markup, resulting in a highly illegible and unstructured style system

Further down the thread I've left some lengthy comments arguing for exactly this.

There are two concerns in defining and maintaining design systems that are (so far) hard or impossible to manage well with vanilla CSS & decoupled styles:

1. Design Token & "swatching" to make integration accessible and maintainable for non-designers 2. Declaration of anything that is neither a concern of this core design system, nor part of explicitly scoped component-styles

Tailwind patches both, and this is the foundation of it's success -- the issue causing any App that relies purely on Tailwind to end up FUBAR beyond a certain scale/complexity, is that the bulk of Tailwind users seem to misappropriate those tools (specially the utility shorthands) to declare ALL the styles.

It's not completely on them either, since Tailwind needs to solve a conundrum: which utilities are meant to be utilities?

Drawing a line while retaining universal applicability is impossible, so Tailwind ended up just wrapping all of the available rules into utilities ... which then requires to extend the syntax to pass design tokens to any of those.

The result is a Framework that originated in trying to provide those 2 missing links, but ended up looking like a complete replacement of CSS.

And since these are precisely the challenges that used to be blockers for anyone whose primary scope is NOT the styling/design layer, and who therefore can't be expected to concern themselves with design system theory or good knowledge of CSS, it quickly ended up in the current ubiquity of UIs getting implemented using a misguided kind of "html style attribute only" paradigm in their entirety -- despite Tailwind originally following a much more nuanced and sensible idea.

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.

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

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?

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.

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.

this makes so much sense - speaking German and English fluently, my brain always defaulted to interpret "ij" in dutch as "ee’" - but it took your comment to make me understand that it's indeed correct, and actually why

fun fact, this had me realise the term isn't some kind of in joke spawned of a colleague's mind, but actually a meme in the progess of becoming one

Death strandings naming is not too far from very common naming conventions throughout history, it's a nicely subtle touch.

Glenn Miller, Gregory Porter and Sam Smith just happen to have been more inclined to make music.

thanks, just realised I mix those up quite frequently

> the privacy fight is just completely unwinnable

I'm afraid it is, in the current state of things.

Another depressing example is how we collectively seem to accepted to keep referring to "unique fingerprinting and observation throughout any activity of the web and apps" as "Cookies! :))", while way too many people even blame EU privacy laws for all the purposefully annoying and misleading dark patterns used by the very entities spying on them.

But you can't blame anyone for choosing convenience and preference over a threat that is utterly overwhelming to mitigate, to the point of feeling impossible to avoid anyway.

Not to mention that a number of people rely on very specific UI features -- OP could well be my colleague, who has a muscular condition and simply cannot press "Ctrl + C" without discomfortable effort, or by constantly moving his other hand between mouse and keyboard. Others in turn may even be completely unable to do either, and fully rely on a pointer device to use GUI applications.

The only chance to win the privacy war is by providing and maintaining free and open alternatives that respect and protect your privacy, and are not only on par with, but better and more user friendly than the existing spyware.

Yet this is a single example that actually was resolved, while far from the only inconsistencies and bugs.

While from an engine side, the situation with bugs lingering for years, and web features that still can't be used way, way after even Safari managed to implement them is not insignificant.

It's not broken or actually bad software, but it's struggling to keep up with the Browsers it's meant to be an independent alternative for.

This makes UX and feature parity a HUGE concern!

Loosing market share through inconveniencing users in turns means web devs will have increasingly less incentive to. work around it's quirks and issues, which even further shifts the Browser market towards a handful of huge, profit oriented companies - which is without exaggeration a threat to maintaining an open web.

its a conundrum. WebKit is a great engine, but nearly all good implementations are provided by Corps who's interests have very little to do with providing a good browser, and lots to do with what you do with that browser.

Firefox in turn might be one of the last major alternative Engines that is maintained by a company who's mission indeed is in a large parts to provide you with a good browser, but seems to progressively struggle to do so, while the engine is a good part of that problem aswell.

I find it harder and harder to deal with the many issues in daily usage -- and from a dev standpoint, FF is slowly surpassing Safari as the main blocker for being able to adopt new web frontend features.

I dearly hope Mozilla can get back on track. Accessing the open web shouldn't end up depending on a pick of Google, Microsoft or Apple.

... * proceeds to remind u on next app launch unless you click [yes] *

It's fascinating how specific words in different languages can be, yet how they have a range of meaning that still relates them closely.

"solstafir" means almost the same, but more precisely translates as "crepuscular rays" -- the beams of sunlight sometimes emerging right at twilight, when the sun passes clouds just on the edge of the horizon.

how i learned about that: Solstafir was one actually of the first bands i discovered through early-ish open internet. I stumbled upon them on former rokk.is back when i was in school, where they used to distribute their music for free.

but it may very well be seen as a mark of English pragmatism, or other more fitting attribution of archetypes, in return.

Interpretations of cultural origins of expressions in either language and romantic admiration for the shapes that words take is neither meant as a qualification of the speakers, nor is the fascination for one culture automatically meant to be entitled or hostile towards another.

You may very well admire the poetic yet observative nature of Japanese composita, as well as take delight in uncommon, inventive and elegantly rythmic English idioms. You may as well interpret freely what you see in them. All without putting one above the other, or regarding them as competitors.

And I'll be happy to have learned both today!

I'm rather reading this as a reaction to EU law making standardized usb c mandatory on phones.

if the government in question is supportive of said problem entities, they won't "deal" with it

If the government in question has free reign on regulating said traffic, it's an avenue for repressions and censorship

Otherwise it's a legal matter to seek action against such entities, which is already how it works

(... but I'm afraid we're actually mostly talking about "scenario 1 entities" here, which makes it futile to seek action from the very offices that already play a role in making it harder to use existing legal means)

Same, i struggle to find a good explanation. 50 a month is definitely pretty low as well for where i come from, but the median for a family of four would still be around 20-25% of the numbers reported in the article. A couple consuming 1/6 of those 58kWh would be on the higher end. (Austria)

such laws are unlikely to be implemented as temporary measures, which op specifically talks about.

I'm asking myself if this might be a good application for a WebGL shader?

The issue with "theming to look sketched" is the same as with "hand drawn looking components" - it has to be integrated for your specific DOM or App, totally defying the purpose of "making someone understand this is a quick sketch". Because by now, it's far beyond being a sketch.

I think you're missing an important demographic, people with even minor motoric or visual impairments, who'd face great friction when accessing information, if it weren't for technologies that let us adapt UIs to various physical circumstances of their usage.

A phone screen becomes a well sized and flexible canvas, given sufficient dexterity and eye sight.

It can easily be a comparatively tiny medium as well.

omw to "consologgi = console.log"

It was "fun" when tinkering with some really creative special concern, it was an insufferable pain when your job was finding ways to layout all the "fun" designers envisioned who weren't highly familiar with CSS.

Before position and float madness and all, we used to abuse tables -- because layouts for complex information do work best in grid systems. Now CSS finally has a module that serves this purpose, and brings a huge amount of flexibility to make formerly painful stuff easy.

I'm not even talking about "page layouts" as a whole, just simple particle patterns like "a big icon with a title + description to it's right" is so so much cleaner and easier to do in markup AND css with grid.

Embrace the tools, and if you dislike them - you may as well just not use them. But thinks like grid make simple, stupid, deadlined webdesign _work_ so so much less of a grind.

(speaking as a General Graphic Designer who's also been deep, deep in CSS since before 2.1)

my thoughts exactly - i think this points to a possible naming issue, since "masonry" is a relatively vague alias that does not really describe the underlying layouting logic, it just became ubiquitous enough for people building webstuff to understand because of that one jQuery plugin back in the days.

A better approach might be to lean on the "grid" naming, but still silo it off via an own display directive (a bit like "block" and "inline-block" have shared properties, but also mutually exclusive behaviours)

So maybe an own `display: flex-grid;` could be an interesting solution?

This separate layout mode would avoid "result-specific" nomenclature like "masonry", and could lean on both flexbox & grid to achieve that look: - using `grid-auto-flow` to set a "masonry axis" & distribution logic - using _either_ `grid-template-columns` or `grid-template-rows` to specify the "lanes" - and to make my frankensteinian display-mashup even worse (or genius! for you to decide), the grid items could in turn abuse `flex-grow, flex-shrink, flex-basis` to control their height/width within the main "masonry" axis

I heavily agree!

This take is imho dangerously conflates personal taste and motivation with "should a heavily generalized and clearly purposed layout system be complicated with some magic keyuword options to serve your specific intents?", and misappropriates the assumption that people like and use this form layout as a reason to approve the latter.