Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

Post reply on HN
Print view View original

301–310 of 435 posts

Re: Moving away from Tailwind, and learning to structure my CSS

#301

Post by u_fucking_dork »

odnckwmxkwdj wrote: post #88
mgraczyk wrote: post #82

Earlier quoted context omitted.

CSS is badly designed and uses a confusing, separate DSL with arbitrary rules designed before the Internet was widely used, before web apps existed, before smartphones etc It's trash and throwing it out is good. Not learning it is good. Tailwind is a solution to a real problem. More importantly, AI is good at it already and it's unlikely humans will need to understand HTML/CSS at all within a year or two. There's no…

“CSS is bad” Why? “Because reasons.” Care to explain? “No need to learn it anymore, my AI can do it for me” Okay, but why is it bad to learn it “Reasons” Uh… what?

[flagged]

Re: Moving away from Tailwind, and learning to structure my CSS

#303

Post by TonyAlicea10 »

gf000 wrote: post #250
TonyAlicea10 wrote: post #137

Earlier quoted context omitted.

It’s not Tailwind the tech, it’s the ergonomics of the tool. Tailwind’s design loop encourages “let me add a div so I have a place for my CSS class”. I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design. Basic HTML authoring is good practice for many reasons.

> let me add a div so I have a place for my CSS class As opposed to what exactly? HTML doesn't let you lay out stuff properly without at least some structural divs that have no meaning. If we have the proper aria properties for example, why does it really matter if I have extra divs (which is, again, irrespective of tailwind)

I can do a lot of layout without divs. Adding aria to divs is an anti-pattern and likely a worse experience than semantic elements.

You might need some extra divs for layout sure. But I guarantee less than most people are using if they markup their content first.

Remember divs mean nothing. So the opening example on the Tailwind website is the accessible equivalent of “blah blah blah”.

Re: Moving away from Tailwind, and learning to structure my CSS

#304

Post by The_President »

danaw wrote: post #281
The_President wrote: post #247

Earlier quoted context omitted.

Proclaiming professional advice on the internet should compel you to bother using proper caps and punctuation. To your point - you are addressing the symptoms of bad understanding of CSS and it's relationship to the DOM. While tailwinds is a useful tool, it's not particularly special.

could you read what i wrote? if capitalizing words make me unprofessional, so be it :shrug:

It's evident that proofreading your own comment might be more effective if it were written more carefully from the start.

Most people indent their code for legibility - if someone showed up to a code base and didn't do that, it could be offputting to anyone reading it.

Re: Moving away from Tailwind, and learning to structure my CSS

#305

Post by culi »

efortis wrote: post #105

CSS Modules are a simpler solution to cascading problems. They create unique class names, so your classes don't clash [1]. And they don't have the two main downsides of TW, which are readability [2] and tooling. Tooling for debugging and experimenting interactively with Chrome and FireFox DevTools. [1] https://x.com/efortis/status/1888304658080256099 [2] https://github.com/ericfortis/tailwind-eye

Don't most modern CSS tools create unique class names? I know styled-components did.

Recently I've been using linaria which is a drop-in replacement for styled-components (exact same API) but its zero runtime. All the CSS is compiled during build (similar to vanilla extract, panda CSS, etc).

I really prefer things like styled-components or Linaria or CSS Modules where you can just write straight up CSS. If you ever decide to switch your tool you should always be able to just copy-paste your CSS away. You don't get that with Tailwind or "styles-as-objects" stuff (StyleX)

Re: Moving away from Tailwind, and learning to structure my CSS

#307

Post by stefan_lec »

extra88 wrote: post #194
u_fucking_dork wrote: post #55

Earlier quoted context omitted.

And how does tailwind or the structure of the underlying html of the page change or affect that?

If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem. For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigg…

This is not true. Tailwind defaults to rem as the underlying length unit for almost everything. You have to go to extra effort in most cases to use px.

Re: Moving away from Tailwind, and learning to structure my CSS

#308

Post by skydhash »

aleksiy123 wrote: post #280
skydhash wrote: post #275

Earlier quoted context omitted.

> With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply. There's only one algorithm, the cascade. And it's described here[0]. And just like any code you write, try not to write complex selectors. If you're not sure two styles are equal, it's better to write two different rules. And just like styling works in any system, you go from generic (standard html elements) to very…

that’s exactly the part that is anti locality of behaviour. I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated. Call it composition over cascade. To be clear I think it’s possible to do this without tailwind. And tailwind has other out of the box features/opinions. But it works well enough without too much fri…

> that’s exactly the part that is anti locality of behaviour.

It is not. Because it fits the concept of "web pages" as documents and forms (which most web apps are, even if they're trying to pass as desktop applications.

> I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated.

And you're very welcome to do what you want. But there's no need to bash cascading as it's a good solution for web pages.

Re: Moving away from Tailwind, and learning to structure my CSS

#309

Post by stefan_lec »

TonyAlicea10 wrote: post #137
zero_shift wrote: post #59

Earlier quoted context omitted.

What does Tailwind have to do with accessibility? Most significant HTML markup is block level elements. The CSS is completely orthogonal. I feel like old-school frontend devs bring up accessibility as a kind of bogeyman. It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until s…

It’s not Tailwind the tech, it’s the ergonomics of the tool. Tailwind’s design loop encourages “let me add a div so I have a place for my CSS class”. I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design. Basic HTML authoring is good practice for many reasons.

This is nonsense, you can stick classes on semantic HTML elements just as easily as on a div.

And screen readers can handle elements nested inside a grouping div just fine, that’s how div’s are supposed to be used. The accessibility issues with div’s are when people repurpose them to take the place of existing semantic elements, because doing so requires handling a bunch of aria roles and attributes manually, and something invariably gets missed.

Re: Moving away from Tailwind, and learning to structure my CSS

#310

Post by timr »

aleksiy123 wrote: post #237
mcv wrote: post #235

Earlier quoted context omitted.

I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

I think this assertion is where most of the conflict comes from. There is a fair amount of people that disagree with the premise that it should be separated in that way (Including me). I personally like this essay by the author of htmx on the topic https://htmx.org/essays/locality-of-behaviour/ Also just better composition imo. Practically I think this means components of scoped css, html, js. People never seem to ha…

There’s absolutely no tension between locality of behavior and separation of concerns in CSS: you’re putting styles on the elements in the document. The styles are defined elsewhere.

It’s like arguing that all of your source code should go in one big file because one file is less than two files, which means greater localization.

Post reply on HN