Це відео не доступне.
Перепрошуємо.

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...

КОМЕНТАРІ • 25

  • @radadadadee
    @radadadadee Місяць тому +17

    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!

    • @stephenpaul7499
      @stephenpaul7499 14 годин тому

      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.

  • @robinheyer708
    @robinheyer708 Місяць тому +1

    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.

    • @SarahDayanDev
      @SarahDayanDev Місяць тому +2

      You can change them 🙂

    • @yatharthx
      @yatharthx Місяць тому

      The reason tailwind.config.js exists. 😬

  • @riceputiGiandomenico
    @riceputiGiandomenico Місяць тому +6

    My god ❤

  • @cguser
    @cguser Місяць тому +2

    there's always more to CSS, many ways to write and design better software

  • @Turabbo
    @Turabbo Місяць тому +7

    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

    • @JoepKockelkorn
      @JoepKockelkorn 26 днів тому +1

      How is using utility classes f’ing up html different from using ‘semantic’ classes? Or what is the better alternative?

    • @MutantNinjaDonut
      @MutantNinjaDonut 22 дні тому

      Watch the video rather than just reading the title before commenting in the future.

  • @ft2bme
    @ft2bme 28 днів тому

    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.

  • @MikeMai
    @MikeMai Місяць тому +2

    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".

    • @MikeMai
      @MikeMai Місяць тому

      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.

  • @trejohnson7677
    @trejohnson7677 2 дні тому

    nerds forget they can just have both.

  • @saintpumpkin
    @saintpumpkin 24 дні тому +1

    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.

    • @MutantNinjaDonut
      @MutantNinjaDonut 22 дні тому +1

      It’s evident you’ve not used it if you think it’s bloated. Tailwind only outputs what you use.

  • @mrdmajor
    @mrdmajor Місяць тому +2

    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.🤷‍♂

    • @SaroVerhees
      @SaroVerhees Місяць тому

      Wdym? Inline styles are the fastest way for a client to load css :)

    • @mrdmajor
      @mrdmajor Місяць тому

      @@SaroVerhees Do your own research on the HTML protocol purpose, user agents, external CSS, and caching.

    • @KristianTheDesigner
      @KristianTheDesigner Місяць тому

      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.

    • @mrdmajor
      @mrdmajor Місяць тому +2

      @@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" 🤔🤷‍♂.

    • @SaroVerhees
      @SaroVerhees Місяць тому +3

      @@mrdmajor Also I still prefer CSS, but I don't call people who like tailwind idiots :)