Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

221–230 of 435 posts

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

#221
post #163

Earlier quoted context omitted.

HTML is the content layer. CSS is the presentation layer.

Yes, this is the exact harmful idea that I was talking about. If this were true than there would be no 'reader mode' in browser. Or the reader mode would not modify the html at all. What you see in reader mode is the content layer. HTML is a part of the presentation layer.

Are you arguing that things like headers and navbars (which reader mode hides) are part of the presentation layer, not the content layer?

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

#222
post #179
post #18

Earlier quoted context omitted.

I use Tailwind and have all kinds of "screen reader" directives in my templates. Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them. It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".

> Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them. I have heard "we don't have blind customers" argument many times before. Apart from ethical issues that this raises, ADA requirements, technically, don't care if you have blind users or not. Accessibility is still required...

It's a great way to make an easy $10-30k as a law firm too when you sue them. Especially when you have definitive statements like "we purposely don't care about a11y until we get sued for it."

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

#223
post #201
post #153

Earlier quoted context omitted.

> Oh no! And what are the opening examples on any of the "proper pure-as-god-intended CSS" sites? The first example on https://developer.mozilla.org/en-US/docs/Learn_web_developme... : Instructions for life: Eat Sleep Repeat p { font-family: sans-serif; color: red; } li { background-color: greenyellow; border: 1px solid black; margin-bottom: 5px; } No divs and spans in sight.

True! And Mozilla is one of the good guys. What I should've said in my hastily written comment should have been: "and other implementations of the same (or other) functionality isn't divs and spans?" I think my only true criticisms for Tailwind example would be: - should've probably used h2/h3 for card titles. Though this is dependent on where and how the card is used - should've done more with the meta (number / dat…

> HTML doesn't have a card element.

I feel like this is a bad example because “card” is a presentation thing, not a content thing. On a social media site, you can have cards with submissions, in which case is the proper tag – and “card” is just a way to style the submission, so it deserves to be a class.

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

#224

We also moved away from Tailwind — Pico CSS. It feels like a breath of fresh, modern CSS air. We actually loved it so much that we’ve taken over maintenance of a fork, and just released our Pico successor candidate: https://blades.ninja/

It is really fun that the navbar has unaligned elements. (Docs is lower)

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

#225
post #193
post #159

Earlier quoted context omitted.

> And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely. The client still has to decompress it and waste processing power parsing all the repeated text.

Premature optimisation doesn’t even fully express how absolutely ridiculously futile it is to try and make your website faster by having fewer CSS selectors. It’s like my grandparents worrying about immediately switching off their LED ceiling lamps when they leave a room - meant well, but utterly meaningless.

If this was the case, it wouldn’t take several seconds to open devtools on sites that use Tailwind.

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

#226
The purpose of web is to display various things and let the user interact with them.

Nobody cares about true REST (modern day RESTful is a different thing), HATEOAS or semantic web. People tends to simplify things.

We probably can live with just 7 html tags,, , , , , , and CSS.

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

#227

Earlier quoted context omitted.

> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex. > placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors In my opinion, it's the opposit…

Your framing assumes incompetence across the board which is unlikely to be true for a framework of its popularity. Consider instead competent people are working on projects with different needs and they’ve recognized there are trade offs to both approaches and still decided Tailwind makes sense in their situation.

[flagged]

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

#228
post #54

> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

> nothing about tailwind forces you to build inaccessible or "div soup" apps

https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

So what if it does not "force" you?

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

#229
post #54

Earlier quoted context omitted.

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

> nothing about tailwind forces you to build inaccessible or "div soup" apps https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... So what if it does not "force" you?

Now do CSS in real life use

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

#230
post #54

Earlier quoted context omitted.

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex. > placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors In my opinion, it's the opposit…

Premature DRY and premature attempt at separation of concerns have resulted in absolutely horrible spaghetti code in too many code bases.

Many times it's fine to repeat yourself. Many times it's fine for a component to cross multiple concerns.

Post reply on HN