
Reasonable System for CSS Stylesheet Structure - dhruvbhatia
https://github.com/rstacruz/rscss
======
bpatrianakos
These are all great ideas. The only thing I don't like about these types of
projects/guidelines is the almost religious, strict adherence to them that
some people who pick them up like to rant about.

The examples are great and realistic but they will inevitably break down in
any project with just a moderate amount of complexity. When this happens I see
people decide that they've done something wrong and think they either need to
restructure the UI to fit the guidelines or find a different set of guidelines
to fit their project. Both are wrong.

After years of studying these guidelines and trying to perfect the perfect,
most efficient, small, and understandable set of CSS styles I've come to the
realization that we need to simply accept that there are going to be
exceptions and that's okay. Yes, think in components, give classes sane names,
don't use ID attributes, etc. but also know that at some point you're probably
going to have to break a rule and it's not the end of the world. Think about
the problem for a few minutes but don't waste your time trying to shoehorn
your front end code to fit a set of guidelines so you can feel superior
because of your strict adherence to RCSS or SUITCSS or whatever. There are
more pressing issues than a few unused or single use classes. If you can
follow the rules more than 80% of the time then I say you're as close to
perfect as you'll ever be. Anything else is reaching for an impossible
standard.

It's funny that the stricter you adhere to some of these guidelines the less
productive you become as you spend more time thinking about how to create
components so they fit the rules rather than getting the damn styles to look
however you want.

My point being this: I love all the different philosophies and think they're
all worth studying but let's be realistic when it comes time to implement
stuff.

------
at-fates-hands
Naming conventions seems to be old school now that virtually everything is
being done with JS.

Using webpack's css-loader changes the game completely as pointed out by Mark
Dalgleish here:

[https://medium.com/seek-ui-engineering/the-end-of-global-
css...](https://medium.com/seek-ui-engineering/the-end-of-global-
css-90d2a4a06284)

 _Writing maintainable CSS is now encouraged, not by careful adherence to a
naming convention, but by style encapsulation during development._

I'm sure there will continue to be more JS solutions to getting rid of CSS
naming conventions, since it seems everything is being done with JS these
days.

~~~
kevin_thibedeau
At which point you no longer have graceful degradation when JS is disabled.
Web "designers" need to stop breaking the web with their code spew everywhere
ruining the basic functionality of HTML and CSS.

~~~
jackmoore
Sure you can... there is no reason why those JavaScript styles can't be
outputted to a css file in your preprocessing step.

------
MatekCopatek
I always feel like these naming conventions are just one big workaround for
the pain of a global namespace. We should tackle it with tools like CSS
Modules[0], not with something as flimsy and error-prone as a naming
convention.

[0] [https://github.com/css-modules/css-modules](https://github.com/css-
modules/css-modules)

~~~
bpatrianakos
CSS is not a programming language. You can't think about it the same way you'd
think about your backend code or even client side JS. The global namespace is
by design. It's a feature, not a bug. The whole point is to think about the
Cascade. You go from vague to specific and that way you have entire classes of
elements with base styles and specific components have additional styles
attached.

CSS modules is a cool idea but I don't think there's anything wrong with CSS
as it stands today. When you work in any language you need to understand and
work with the language you have and I think that a lot of criticism of CSS
boils down to "CSS doesn't work like this other language/paradigm I know and
like".

~~~
MatekCopatek
I humbly disagree.

No, CSS isn't a programming language, but that doesn't mean it can't use
functionalities that are typical of programming languages - just look at
variables, functions, arrays, maps and other features that preprocessors like
SASS have brought us.

While some approaches are a matter of taste/habit, I think there's an
extremely wide consensus that having everything available in global scope is
bad.

If the global namespace really is by design, then why are we adopting
conventions (such as the one in this very topic) that mostly aim to defeat it?
Prefixing class names to apply them only to a specific component is nothing
but a primitive way of limiting scope.

------
Wintamute
Hasn't this already been solved with SUITCSS?

[https://github.com/suitcss/suit/blob/master/doc/naming-
conve...](https://github.com/suitcss/suit/blob/master/doc/naming-
conventions.md)

~~~
lsdafjklsd
Yea SUITCSS is a great solution and it's completely cleared up so many CSS
issues my team has had in the past. Looking at rscss I kind of cringe because
it doesn't make it easy to reason about where classes are in the markup. Like
.search-form is affecting .submit, but looking at the template I have no idea,
and I also don't even know which file to look in.

------
smpetrey
I was under the impression that child selectors are specific in nature, and
they should be used later in the sheet, when declarations become increasingly
specific.

~~~
tobr
In a general sense, the child combinator is "more specific", i.e. there are
fewer elements that can match it. Combinators do not affect specificity
though.

See [https://developer.mozilla.org/en-
US/docs/Web/CSS/Specificity...](https://developer.mozilla.org/en-
US/docs/Web/CSS/Specificity#Selector_Types)

------
adamkochanowicz
Another alternative to BEM
[http://getkickstart.com/amadeus/](http://getkickstart.com/amadeus/)

~~~
adamkochanowicz
Or more precisely:
[http://getkickstart.com/amadeus/#selectors](http://getkickstart.com/amadeus/#selectors)

------
ilikescience
I like how readable it is, but nesting selectors:

    
    
      .parent .child .element {
    

is bad for performance — thus BEM's:

    
    
      .parent--child__element {

~~~
MatekCopatek
It's not as bad because of decreased performance (which is negligible) as it
is because of increased specificity, which has bigger day-to-day implications
in large apps.

------
skeoh
Very interesting project, although I believe the name suffers from RAS
syndrome: Reasonable System for [Cascading Style Sheets] Stylesheet Structure.

