Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS: The bad bits and how to avoid them

joeforshaw.com

Post reply on HN
Print view View original

71–80 of 109 posts

Re: CSS: The bad bits and how to avoid them

#71

Post by sametmax »

mattigames wrote: post #70
sametmax wrote: post #67

Earlier quoted context omitted.

Well if what you style is the main content/header/footer area, and there is should only be one of it per page, using an id is a good way to enforce it as well as document it. If you made it a class, I would assume I can reuse it elsewhere. Now it's ony true for stuff you can't reuse, but unless you are building a boostrap competitors, there are actually a lot of things you never reuse in a real website.

Not at all; some simple effects like a stick-to-the-top header usually require cloning such element using JavaScript; and even if such effects are not needed right now they may be added in the near future, so no, there is not a single time where having an ID over a class makes sense.

Since I'm more of a backend dev, I'm going to take your advice and try it on my next work. Let's learn something today.

Re: CSS: The bad bits and how to avoid them

#72

Post by RobertRoberts »

poxrud wrote: post #61
RobertRoberts wrote: post #25

Earlier quoted context omitted.

> Stop using CSS... Maybe I am stupid here, but doesn't SCSS just render out to CSS?

For me the best thing about scss is the ability to nest selectors. This makes your code a lot easier to read and more organized. Of course having functions, mixins, extends is also nice. Saying scss is pointless because it outputs regular css is the same as saying that es6 is pointless because it can be represented as regular es5.

>...es6 is pointless because it can be represented as regular es5.

Let's be reasonable, that's more like comparing CSS 2 to CSS 3. :P

Everything I've read and discussed with others in the industry, SCSS seems to be useful for far large projects with many designers and programmers stepping over eachother. I work for a smaller company, and we build very clean CSS, and would not benefit at all from SCSS.

Recently a friend at another medium sized company switched to SCSS "because". Seriously, it was one designer that liked one feature from some library that required some build tool that required SCSS... So they all have to learn SCSS now. No other reason.

Re: CSS: The bad bits and how to avoid them

#73

Post by reificator »

sametmax wrote: post #67
mattigames wrote: post #65

Earlier quoted context omitted.

There is not a single time I had though to myself "This should have been an ID instead of a class"; but there are hundreds of times where I have though to myself "This should have been a class instead of an ID".

Well if what you style is the main content/header/footer area, and there is should only be one of it per page, using an id is a good way to enforce it as well as document it. If you made it a class, I would assume I can reuse it elsewhere. Now it's ony true for stuff you can't reuse, but unless you are building a boostrap competitors, there are actually a lot of things you never reuse in a real website.

Once I needed to make an internal IE addon to listen for certain elements being selected on pages outside of our control. (to ensure we never collected sensitive data for compliance reasons, long story. Trust me it makes more sense in context than it does in a single paragraph.)

My co-worker wanted to grab by id and attach listeners, but I was convinced that wouldn't work. I wanted to listen at the top level and filter down by id/class/etc...

The first production test was .com/login. It had a login widget on the navbar and a login widget in the main content section. Both the username and the password field had the same id in the navbar and the content. So the addon did the right thing on the navbar, but not in the content, and we had to go back and redo it thanks to id reuse.

My point is, elements with ids are rarely unique. I've never regretted using a class instead of an id. I've regretted using an id instead of a class. And I really regretted third parties using ids instead of classes.

Please don't use ids. Your unique elements won't be for long, I guarantee it.

Re: CSS: The bad bits and how to avoid them

#74

Post by Blahah »

stefanchrobot wrote: post #15

I'd add one thing: avoid multiple classes on a single element; use mixins to avoid duplication. I tend to do so even for classes that have some toggle state, i.e. .some-class-active.

does this have a performance benefit or are you recommending it for the code clarity?

Re: CSS: The bad bits and how to avoid them

#75

Post by sharpercoder »

talmand wrote: post #44
Someone1234 wrote: post #34

Earlier quoted context omitted.

> In my opinion, most CSS bad bits are a byproduct of bad use, not a problem of the language(?) itself. I've seen far too many bad languages come and go to believe that anymore. People used to say that about PHP and VB6 too. PHP eventually stopped with the "only bad programmers use me badly" and grew up, and VB6 died. A win in both cases. CSS could be far better; and bad practices won't disappear until doing it the r…

The ability for good practices is already there, just too many people would rather complain about their bad practices to bother learning the good practices and blame the language.

-it is not possible to decrease scope

-tooling is hard e.g. to detect unused styles

-scope problems are a pain to debug

-some constructs are awkward (e.g. tooltips with :before and positioning styles)

-vertical text behaves unexpected wrt box model

-variables are suboptimal

There are probably a lot more.

Re: CSS: The bad bits and how to avoid them

#76

Post by Kequc »

I've heard about BEM many times and been forced to use it on a lot of projects. It seems to be reasonably commonplace I was hoping for some smaller tips so here's one I use very often.

Vertical height of text comes up a lot in CSS. It seems many people do not make liberal enough use of the line-height property. Line height is a magic bullet when you need some text to take up the correct amount of space.

With it, and your element styled to inline-block, of float left, or however you are using it. You are able to modify the font size later on without having any effect on the element's surroundings. It's also automatically centered vertically and you can change it without much effort.

Not enough people using line-height.

Re: CSS: The bad bits and how to avoid them

#77

Post by setr »

reificator wrote: post #73
sametmax wrote: post #67

Earlier quoted context omitted.

Well if what you style is the main content/header/footer area, and there is should only be one of it per page, using an id is a good way to enforce it as well as document it. If you made it a class, I would assume I can reuse it elsewhere. Now it's ony true for stuff you can't reuse, but unless you are building a boostrap competitors, there are actually a lot of things you never reuse in a real website.

Once I needed to make an internal IE addon to listen for certain elements being selected on pages outside of our control. (to ensure we never collected sensitive data for compliance reasons, long story. Trust me it makes more sense in context than it does in a single paragraph.) My co-worker wanted to grab by id and attach listeners, but I was convinced that wouldn't work. I wanted to listen at the top level and filt…

A friend once told me about a girl in their cs 101 class, who learned about arrays, and proceeded to make every variable an array. When queried, she responded, "I might end up realizing I need a multiple of the variable, and this way I won't have to change anything when I do".

Re: CSS: The bad bits and how to avoid them

#78

Post by jacobwilliamroy »

no_wizard wrote: post #63

I have been writing a lot of CSS (well SCSS) lately and this seems like a good time as any (though I admit somewhat off topic) about a question I have regarding the newer Combination & Multiple selectors https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduct... and Attribute Selectors https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduct... This stems from the fact that I have inherited the task of re-wr…

Generally you would want to avoid descendant and child selectors. With rules like

  ul > li > a

  .selector .selector1 li a
The system will check ALL anchor tags and move left until it has completely matched the rule. This makes the above selectors extremely expensive (perfomance-wise) and can cause slow page-loads. Tag selectors and universal selectors are generally a bad idea for this same reason.

And using inheritance to select elements indirectly is actually better for performance than directly selecting the inheriting elements. For example, if you want to set typography for an entire page, instead of selecting all p and h1 tags, just select the body tag.

Here's a link to a more in-depth explanation of all of the above with examples:

http://mdn.beonex.com/en/CSS/Writing_Efficient_CSS.html

Re: CSS: The bad bits and how to avoid them

#79

Post by totallymike »

majewsky wrote: post #62

> Often there’s an argument to use tags to create a default set of styles. For most sites, it’s usually a good idea. However, if you’re just overriding those styles pretty much everywhere, I’d say don’t bother. Put them in generic utility classes (e.g. .paragraph, .heading-1, etc) and use them as you need. Please don't. Tags have semantics for important reasons. Even if you're removing one of those by overriding the…

I think the argument is against adding rules to tags to create a default set of styles, not against using semantic tags throughout the page.

If my understanding is correct, the argument is to use

  
    .my-article {
      background-color: fuchsia;
    }
  
  ...
rather than

  
    article {
      background-color: fuchsia;
    }
  
  ...

Re: CSS: The bad bits and how to avoid them

#80

Post by RobertRoberts »

talmand wrote: post #48
romaniv wrote: post #47

Earlier quoted context omitted.

This argument doesn't stop a myriad of widely used JavaScript frameworks that rely on custom attributes. Besides, if you really care about validity, you can use It's still shorter, more readable and avoids repetitions. The difference becomes even more pronounced as the complexity of your styling goes up.

My argument about the attribute is not invalid because they are doing it the wrong way. Custom attributes for HTML should make use of the data attribute, as you point out. One could use data attributes in such a way, I have, but in the past it was something to avoid due to performance issues. To be fair, I don't know the latest performance figures on attribute selection.

>My argument about the attribute is not invalid because they are doing it the wrong way.

The problem with this argument is that just a few years ago everything ReactJS does now was the wrong way, but for some reason today, it's the best way. So which is it?

It seems to me, that unless it's broken, or goes against an explicit rule from the browser/code designers of html/css etc... it's totally valid. And if it doesn't "feel correct", then maybe it's a trend waiting to happen. inline javascript styles

Post reply on HN