Це відео не доступне.
Перепрошуємо.
Utility First CSS Isn’t Inline Styles | Sarah Dayan | CSS Day 2024
Вставка
- Опубліковано 7 лип 2024
- All sessions are available right now for our Early Adopter members, and we'll make a talk available for everyone each week: / @webconferencesamsterdam
--
Slides: noti.st/sarahd...
About Sarah: frontstuff.io
More about CSS Day: cssday.nl or / cssdayconf
Receive conference announcements in your inbox: cssday.nl/subs...
When people compare utility classes with inline styles, they're not referring to the limitations of inline styles. Obviously utility classes are much more powerful. The comparison is usually about overloading the html with dozens of classes for each element. One has to write so many classes that one cannot help but feeling one's writing CSS directly inside html, very much like with inline styles.
Instead of constructing the way an element looks like on the css file (where it should be), one is building the appearance directly into the html. How does this element look like? Instead of checking the css file, I need to look both to tailwind docs AND the html!
I share your skepticism, but I do find it interesting that the 'separation of concerns' between HTML and CSS was never really there. Often, to achieve a styling goal, one is left with no choice but to restructure the markup. The idea that markup is strictly semantic and unrelated to styling is a fantasy. Even CSS grid is not a powerful enough tool to prevent me from touching my markup if I'm only interested in making a 'visual' change. An HTML document is a way of serializing data for the end-users visual system. The structure of the document is inseparable from the way it is styled. The 2 documents are rarely changed independantly. But yes, there is that overhead of learning the framework, there's the ugliness of a long string of classes, there's the repetition, there's the need to add a comment above elements to describe what they are. Tailwind advises that we should just create another component every time we want to re-use a collection of styles. No thanks, my project explorer is already hard enough to navigate and then I also have to... oh... 'name things'. The 'reusable palate' is overrated, especially when you consider that you often want to re-use 'groups of atoms' instead of just atoms, and so you create an old-school 'class', and there goes all discoverability/predictability that the atomic CSS palate is meant to solve. Tailwind fixes some issues but then introduces new ones. I also don't love HTML+CCS. Styling is messy and imprecise and chok-full of pinch-your-noes hacks.
15:50 It's actually the framework's breakpoints for responsiveness that is usually my biggest annoyance. You get ease of use but you also get someone else's design choices. Otherwise I'd probably have been a tailwind zealot by now.
You can change them 🙂
The reason tailwind.config.js exists. 😬
My god ❤
there's always more to CSS, many ways to write and design better software
I'm gonna have to respectfully disagree with this one. The issue with inline styles isn't that you can't conditionally target psudo states. It's that you've effed up your HTML
How is using utility classes f’ing up html different from using ‘semantic’ classes? Or what is the better alternative?
Watch the video rather than just reading the title before commenting in the future.
Just to get rid of the usual utility CSS straw man, I maintain a project that uses scss, and actively develop one using Tailwind CSS. This “dozens” of classes has never happened to me (I’m sure it’s happened to some). In most cases I have a couple to a handful of classes on one element. In extreme cases I might have around 10. If Tailwind CSS can’t handle some new CSS feature, it’s easy to develop your own utility classes that use the new feature. I also notice Tailwind CSS encourages people to break React components into smaller, simpler components to avoid repeating Tailwind CSS strings. I’d argue that’s usually a good thing. Unlike many commenters here, however, I will **NOT** argue that my way is the only way, and others’ ways are wrong or stupid. In fact, if I had learned an interview candidate had that attitude, I’d insist on not hiring them. I like scss, and I like Tailwind CSS more.
This is a good talk, but I have one critique. Bringing in "atomic css vs semantic css" dilutes your talk. I much rather this sticks to the topic "utility first CSS vs inline styles".
This is the most confusing part of the talk for me: `.clearfix` is a utility class, but it is not atomic. if you make it atomic, it would be this `.after:table.after:clear-both.after:content-['']` (i am not a tailwind expert, this is just an example to illustrate the point, not the actual classes). I think this section would lose some viewers because it is kind of off topic.
nerds forget they can just have both.
I'm using utility classes so yea, they can be cool, but I will never use a bloated framework like tailwind which take the concept to the extreme.
It’s evident you’ve not used it if you think it’s bloated. Tailwind only outputs what you use.
I don't understand why all the performance-obsessed developers are OK with mucking up HTML with wild inline CSS or ridiculous "utility" class frameworks with CSS pre-processers out there. The Idiocracy movie is reality now.🤷♂
Wdym? Inline styles are the fastest way for a client to load css :)
@@SaroVerhees Do your own research on the HTML protocol purpose, user agents, external CSS, and caching.
because it is not an issue anymore, its just an ”issue” now that people for some reason still love to complain about like an old girlfriend.
@@KristianTheDesigner This substantiates the point. The same "developers" who are obsessed with performance, memory usage, file sizes, and optimized large applications have 0 issue with unnecessarily bloated and poorly structured HTML shipped over browsers, and call folks "boomers" and "old girlfriend" 🤔🤷♂.
@@mrdmajor Also I still prefer CSS, but I don't call people who like tailwind idiots :)