7 ms·

Yeah that's definitely true that it doesn't support all of the features of Sass or LESS. But it does support some of the core features that people use everyday,

Yeah that's definitely true that it doesn't support all of the features of Sass or LESS. But it does support some of the core features that people use everyday, and could replace a lot of the need for preprocessing. From everything I've seen nesting rules is an anti-pattern. It's useful for writing code as fast as possible, but for any project of reasonable size maintenance is a far bigger worry than LOC per second, and nesting makes for some horrible to maintain CSS. Until we have native extending in CSS you're much better off going the "one-class-per-element" route for maintenance. As for mixins, I actually think they are an anti-pattern too. They're usually used for two different things. The first is to simply make vendor-prefixing easier, which this library already eliminates. For example the LESS homepage shows mixins being used when really it's just a regular old `border-radius` property. And the second is for extending classes with groups of properties, but mixins are a bad practice there because they just duplicate the code instead of doing any smart inheritance, so you end up with huge code bloat. The real missing feature from preprocessors in my opinion is the idea of "extending", but I wanted to wait for the CSS spec for extensions to be more thought out before adding it, in case it varies a lot from how preprocessors do it. --- The reason this came about is because we went back to writing pure CSS at Segment.io (after having used LESS, Stylus and Sass at different points) and realized that we shouldn't need to give up things like variables just because we don't want the extra weight of a new syntax.

loupeabody 13y ago
Is there a grunt module for Myth? Thanks very much for this, I'm looking forward to using it.
- ianstormtaylor 13y ago
  Nope, just released the CLI/Node API today and haven't used Grunt personally. But would welcome someone making one! :)
crazygringo 13y ago
If you think nesting rules is an anti-pattern, I feel like you've never worked on a large-scale web project. When you need to ensure that sections of pages are self-contained, and components likewise, you need to start every rule with ".titlebar" or ".large-button", etc. Nesting just makes your CSS much cleaner, by writing ".titlebar" once instead of 30 times (for each of the 30 rules that apply to things inside the title bar), and making your stylesheet more organized and easier to browse. It doesn't mean you need to nest every single element, but it's a fantastic tool for organization, particularly when multiple people are working on a project. Likewise, I feel like you're missing one of the main points of mixins -- that they allow you to repeat commonly used calculations that may involve multiple properties in complex ways. For example, a mixin I often use lets me create a vertical gradient by specifying a base color and a brightess spread amount, instead of start/end colors. It's incredibly valuable, and it also allows me to automatically support IE and specify a fallback base color. Mixins are hugely valuable for creating classes based on sprite positioning too. Going back to pure CSS without mixins would be a huge step backwards in maintainability for any project of decent size which I've worked on. Obviously, both nesting and mixins can be abused or used inappropriately, but I'd never call them anti-patterns -- to the contrary, they're essential for front-end development on sites that reach a certain level of complexity, for cleanly factored code.
- anthonyshort 13y ago
  Actually, nesting like that creates unneeded higher specificity. You'll end up with .titlebar .titlebar-button and you'll end up running into race-conditions with specificity and the ordering of your CSS will then become important. 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.
  - porker 13y ago
    +1 for BEM, OOCSS or whatever each author calls it (Snook has his own name IIRC). Having written CSS for a decade and decided what semantics CSS had and how it should be structured, I was very surprised when I actually gave BEM/OOCSS/Whatever a go. It works. And I don't like going back now.
  - sogen 13y ago
    thx for the BEM tip!
- pault 13y ago
  I don't always agree with Ian's opinions, but he definitely has experience with large scale web projects. 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.
philipwalton 13y ago
I agree 100% with Ian. I came here to say the exact thing, but he beat me to it.
robertnealan 13y ago
When nesting is used incorrectly it's absolutely an anti-pattern (my first LESS project regrettably mimicked the HTML structure with nesting), but when everything is kept as semantic/modular as possible and nesting is avoided except where obvious (a UL class that styles the children LI/A tags, etc) it can be a great help in keeping your CSS simple and understandable. While it's more difficult to replicate the same issues in native CSS due to the friction involved of copying/pasting the same elements/classes over and over, I don't think that should be a reason to entirely avoid a tool that can be a great benefit in the long run. On the other hand, per our email I have to say I'm more and more skeptical of the benefit and long-term maintainability of SCSS @extends and @mixin except in special circumstances.
stormbrew 13y ago
I feel like a lot of the fear of nesting came about in the era when you couldn't do direct-child selection reliably. I'm pretty sure this is something that was overcome a long time ago now, though. It's a lot easier to limit and control the application possibilities with: .blah > .blorp than it is with .blah .blorp without resorting to .blah-blorp prefixing.
- alanh 13y ago
  Yes! True. And it’s easy to do this with Sass (here, shown in SCSS syntax): .my-class { font-weight: bold; // use "placeholder selector": & > .other-class { // selector compiles to: // .my-class > .other-class border-width: 0; } }
deleted 13y ago
[deleted]
alanh 13y ago
> just because we don't want the extra weight of a new syntax Sass defaults to .scss syntax, which is exactly CSS syntax. Okay, exactly a superset. Since it merely adds $variables and other features, you are free to ignore them and just write “pure CSS” but with variables. What am I missing?
Flenser 13y ago
If/when you do add extensions will it be easy to add sourcemap support as well?

loupeabody 13y ago

Is there a grunt module for Myth? Thanks very much for this, I'm looking forward to using it.

ianstormtaylor 13y ago
Nope, just released the CLI/Node API today and haven't used Grunt personally. But would welcome someone making one! :)

crazygringo 13y ago

If you think nesting rules is an anti-pattern, I feel like you've never worked on a large-scale web project. When you need to ensure that sections of pages are self-contained, and components likewise, you need to start every rule with ".titlebar" or ".large-button", etc. Nesting just makes your CSS much cleaner, by writing ".titlebar" once instead of 30 times (for each of the 30 rules that apply to things inside the title bar), and making your stylesheet more organized and easier to browse. It doesn't mean you need to nest every single element, but it's a fantastic tool for organization, particularly when multiple people are working on a project. Likewise, I feel like you're missing one of the main points of mixins -- that they allow you to repeat commonly used calculations that may involve multiple properties in complex ways. For example, a mixin I often use lets me create a vertical gradient by specifying a base color and a brightess spread amount, instead of start/end colors. It's incredibly valuable, and it also allows me to automatically support IE and specify a fallback base color. Mixins are hugely valuable for creating classes based on sprite positioning too. Going back to pure CSS without mixins would be a huge step backwards in maintainability for any project of decent size which I've worked on. Obviously, both nesting and mixins can be abused or used inappropriately, but I'd never call them anti-patterns -- to the contrary, they're essential for front-end development on sites that reach a certain level of complexity, for cleanly factored code.

anthonyshort 13y ago
Actually, nesting like that creates unneeded higher specificity. You'll end up with .titlebar .titlebar-button and you'll end up running into race-conditions with specificity and the ordering of your CSS will then become important. 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.
- porker 13y ago
  +1 for BEM, OOCSS or whatever each author calls it (Snook has his own name IIRC). Having written CSS for a decade and decided what semantics CSS had and how it should be structured, I was very surprised when I actually gave BEM/OOCSS/Whatever a go. It works. And I don't like going back now.
- sogen 13y ago
  thx for the BEM tip!
pault 13y ago
I don't always agree with Ian's opinions, but he definitely has experience with large scale web projects. 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.

philipwalton 13y ago

I agree 100% with Ian. I came here to say the exact thing, but he beat me to it.

robertnealan 13y ago

When nesting is used incorrectly it's absolutely an anti-pattern (my first LESS project regrettably mimicked the HTML structure with nesting), but when everything is kept as semantic/modular as possible and nesting is avoided except where obvious (a UL class that styles the children LI/A tags, etc) it can be a great help in keeping your CSS simple and understandable. While it's more difficult to replicate the same issues in native CSS due to the friction involved of copying/pasting the same elements/classes over and over, I don't think that should be a reason to entirely avoid a tool that can be a great benefit in the long run. On the other hand, per our email I have to say I'm more and more skeptical of the benefit and long-term maintainability of SCSS @extends and @mixin except in special circumstances.

stormbrew 13y ago

I feel like a lot of the fear of nesting came about in the era when you couldn't do direct-child selection reliably. I'm pretty sure this is something that was overcome a long time ago now, though. It's a lot easier to limit and control the application possibilities with: .blah > .blorp than it is with .blah .blorp without resorting to .blah-blorp prefixing.

alanh 13y ago
Yes! True. And it’s easy to do this with Sass (here, shown in SCSS syntax): .my-class { font-weight: bold; // use "placeholder selector": & > .other-class { // selector compiles to: // .my-class > .other-class border-width: 0; } }

deleted 13y ago

[deleted]

alanh 13y ago

> just because we don't want the extra weight of a new syntax Sass defaults to .scss syntax, which is exactly CSS syntax. Okay, exactly a superset. Since it merely adds $variables and other features, you are free to ignore them and just write “pure CSS” but with variables. What am I missing?

Flenser 13y ago

If/when you do add extensions will it be easy to add sourcemap support as well?