Hacker News Reader

Comment by ulkesh | Hacker News Reader

Some thoughts:

- Good CSS design needs zero !important statements. Fix your specificity or your component architecture if you have a need to use !important.

- DRY is a good thing, not a bad thing. Maybe straight CSS isn't quite there yet but...

- Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS?

- Flexbox will be great once IE dies the well-earned death it deserves.

I'm very happy the author had great success with their setup. What works, works. But I hesitate to assume that just because it works without using DRY principles or other tooling, it means you shouldn't.

View on HN

Avoiding !important is generally very good advice, although the ZOMG NEVAH! approach is a bit overzealous IMHO.

One good example would be overriding random external styling (e.g. an included CSS file some plugin you use). If their stylesheet has very long and specific selectors, you can either repeat them entirely (#plugin .container .subcontainer .input-wrapper.input-wrapper-blue input[type=text]:first-child) or stay within your general selector-writing practices and use !important instead. I'd argue the latter is a better practice.

I agree with respect to 3rd party libraries. One of the things I hate most about Bootstrap is its amazing overuse of !important.

However, my context was mainly around architecting your own CSS, not as it relates to using someone else's.

My approach is to slap myself in the face each time I need to use !important. That's enough to prevent me from slipping into bad habits but leaves me with an option if rewriting my CSS to work around somebody else's (or my own) hacks would be more painful than a slap in the face.

I do occasionally get strange looks from my colleagues.

Just wear a rubber band on your wrist and snap that instead. Your colleagues will just think you're trying to stop smoking.

Or get a pavlok (I have one, it's rather neat, though the bluetooth is predictably terrible).

Secretly, I'm not that happy with flexbox. I think it's more intuitive in some cases, but I don't think it's more intuitive than floats and the like.

For example, I always feel like I want a `justify-self` property like `align-self`, but instead I must use `margin: auto` on the opposite side—in a flex row of elements, if I want the last one to be right aligned while the rest are hanging out in the center, I have to tell that last element to be `margin-left: auto`.

I think it's just an issue that it has taken so long to be useable (IEs :( ), there has been a lot of hype, and it's not quite the panacea I imagined it would be.

I agree that flexbox isn't particularly intuitive. I visit the "Complete Guide to Flexbox" at least a few times a day.

The real strength is how little of it you have to write. The most complex layouts I have only take a few lines of flex and they're way more responsive than their non-flex counterparts.

Using !important is often encouraged for state changes (e.g. ".is-showing" etc)

I'm surprised there is no polyfill-like thing for flexbox, or is there?

Can't be. Hm maybe with lots and lots of JS moving stuff around with absolute positioning, but otherwise you simply can't port flexbox to older css.

There is a JS polyfill. It's relatively popular, but I've never tried it. https://github.com/jonathantneal/flexibility

I'd be hesitant to use that in prod code - realistically you can achive fairly graceful degradation without it as long as you're prepared to accept a non pixel perfect layout.

Also, from the issues v2.X that polyfill appears be broken in IE9 atm, which is the last one with zero flex going on. (Fun fact, our metrics have ie9 and 10 with comparable userbases - fairly standard large public facing site. 9 is fully unsupported and IE10 is no longer an active target for our QA team beyond basic layout and functionality)

I do generally use a less mixin to shim all the tweener syntax tho.

Oh wow! Awesome, wish I knew before. This blows my mind, thanks!

css variables too

> - Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS?

Because there is so much tooling churn + barrier to entry. The point is that sometimes it's better to repeat yourself than to use the tool of the month.

Both the tools mentioned above LESS/SASS have been for 5+ years. There is churn in frontend tooling, but it is not a valid reason for not using LESS.

Usually this kind of attitude could be justified even if it was just a shitty anecdote, but with SCSS and LESS in particular I'm afraid you've chosen long lived, bulletproofed software that has tremendous adoption and community. Neither would be what anybody would call "the tool of the month".

If you're using React but not LESS or SASS then you have a strange attitude to "tool of the month" but it does explain antipathy towards DRY.

SASS is almost a decade old [0] and has been in wide-spread use for a long time. The tool churning you talk of is something I have only seen in JS land to such a degree.

Moreover, the barrier to entry to learning SCSS/LESS is really low if you know CSS.

[0] https://github.com/sass/sass/tree/4acf5158734013f08fca4be6e2...

Both are proven tools and should be used by any serious frontender. Pick SCSS, it's your most advanced option; you won't hit a limit in what you ultimately want to achieve.

Reply on news.ycombinator.com