Show HN: Myth – CSS the way it was imagined

The complexity of Sass/Less is starting to out-weigh the benefit of their features, for me at least.

Having said that, I don't know if this polyfills the var spec exactly.

You're often better off just using BEM style selectors and using the selector name for nesting.

.titlebar {} .titlebar-button {}

As for mixins, yeah, you get some benefit if you're trying to be super tricky. But that button you've created is used once or twice, plus you could just use CSS variables and colour functions.

The question is now whether the added complexity everywhere else is worth that tiny benefit. There are plenty of people who have built large front-end sites and found that Sass/Less in fact make it harder to maintain.

But honestly, this stuff is totally subjective in a lot of cases. Different projects, different tools. If it works for you then stick with it, for other people, Myth and Rework are perfect.

This is a contentious subject, so take everything I say as just, like, my opinion. Using generic class names like `titlebar` is likely to result in namespace collision. I define a project by modules, and use a slightly bastardized version of the block, element, modifier naming scheme to prevent this. It's verbose, but I consider the extra typing a reasonable price to pay for the ease of maintenance. For example: `.mod-modal`, `.mod-modal--title`, `.mod-modal--button_large_danger`. A sparse library of grid and spacing utility classes allow flexible formatting without having to write new definitions for every variation of your modules. Content hooks are provided for edge cases where you really do need to override some module styles for a specific page or design element. I use a `myproj-contentdescriptor` naming scheme. I apply these liberally but rarely define them in the stylesheet. The excessively convoluted naming scheme prevents leakage and interference from 3rd party libraries. It makes for some ugly-ass markup, but this is a pattern I've settled on after 10 years of CSS day job.

Edit: Ian just argued the same case more eloquently. This methodology seems to be gaining traction amongst framework authors over the last two years.

---

For nesting, the problem with nesting is that is messed with specificity way too much. Since adding an extra class inside a nested block is trivial, people start adding more and more. But even just 2 classes is already too much in my opinion. Ideally each component would have classes on each of its inner elements, so that the component-level styles always have a specificity of 0010:

  <div class="textfield">
    <label class="textfield-label"></label>
    <input class="textfield-input">
  </div>

  .textfield {}
  .textfield-label {}
  .textfield-input {}

But honestly, when working with small components there just isn't that much typing to justify the possible downsides. Sure I have to type out the extra selectors in the beginning a few more times, but its worth it to do without the unintended consequences of the magic.

The one case where nesting really does come in handy is for page-specific or app-specific stylesheet files. Places where you are adding the "glue" CSS that should always be namespaced to avoid collisions.

---

For mixins, I feel like they only seem useful if the components you're using are broken into small enough pieces to begin with. For example, if you want a complex gradient system on your buttons, put that inside your button styles and then don't touch it from anywhere else. If you're constantly needing to use a mixin to re-define those styles, something else is wrong. Because realistically how many different color variations of those buttons do you need to make? It should be somewhat limited, and they should be able to exist in a single file without issue.

Where things really get screwed is if you aren't versioning your mixins (which most people aren't doing). At that point, you're just tightly coupling changes to that mixins across your entire codebase. If you want to change the way the buttons implement the gradient, with the mixin system you go change the mixin, but now you need to visit every other component that uses that mixin and double-check that you didn't break anything.

Instead, if you didn't use a mixin and the component just contained its gradient logic (slightly more verbose maybe, but way more maintainable) then you don't have that problem.

The other solution is to strictly version your mixins using something like Component and maintain your mixins in a separate repository on GitHub that gets versioned, then that also works because each other component can peg the version of the mixin it is using.

---

My big takeaway from CSS though is that none of the solutions for it are nice right now. And most of these problems should disappear (I think) with proper native extension.

  .my-class {
    font-weight: bold;

    // use "placeholder selector":
    & > .other-class {
      // selector compiles to:
      // .my-class > .other-class
      border-width: 0;
    }
  }

    .header {
        background-color: orange;
    
        p {
            font-size: 16px;
        }
    }

future css => compatible css ?

It's in Chromium, not sure whether it's in Canary yet.