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

11–20 of 109 posts

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

#11

Post by mephitix »

CSS Grid really helped me understand/wrangle z-index and stacking contexts. For example, within a grid you can use grid-row/grid-column to position an overlay over a grid item. The z-index will be scoped to that stacking context.

Modular CSS I think is a huge step forward - I totally agree that global scope is killer. As much as people love to hate on CSS-in-JS, I enjoy using styled-components a lot. I've noticed since using it I've been composing CSS instead of inheriting or overriding styles.

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

#12

Post by bluetwo »

I tend to write CSS for projects by hand without a pre-processor, borrowing from previous projects only when called for.

One of the things I've been doing recently that helps debugging a lot is to group the attributes within a css class into three, separated by a line.

1) Things that control where the item shows up.

2) Things that control the overall appearance of the item, like size and background.

3) Things that control appearance of things within the item, like font color.

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

#13

Post by bluetwo »

ars wrote: post #6

There's nothing wrong with styling on an id. You could put the style right in the HTML tag, or on the page where it's used, but with dynamic pages (and static stylesheets) both options will cost you bandwidth. And they split up your styles into separate places. So putting the style on the id is the right thing to do, and I don't understand why the author is against it. If I need my footer to look a certain way, then…

Sure, the author is describing good practice, not best practice.

If you have a choice, use class, then if you need to modify a specific use of the class, use id.

I would still use .footer instead of #footer. Of course you should consider as well.

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

#14

Post by interfixus »

commandlinefan wrote: post #10
magic_beans wrote: post #2

The world really doesn't need another "What to Avoid with CSS" list. This list also assumes the use of a CSS pre-processor.

Well, I liked it. I had never heard of BEM before, either, so I'll definitely take a look at that. What gets me about CSS is that, in spite of having used it now for about 20 years, I still don't have an intuitive feel for it. With everything else I work with, I start out with an experimental approach: if I change this, I see this, if I change that, I see this other thing; after usually a few weeks of experimentation…

Hear, hear! Working exclusively in scss, maintaining orderliness and decent discipline, and having - like you - been at it for close on twenty years, I still keep a constant wary eye on my output screen, I still get regular surprises there, I still rely on the browser dev-tools, and I sorely miss the 3d representations they used to have, at least in Firefox.

I have learned to simply accept css for what it is: An unholy legacy kludge we have to live with. Just don't let's speculate on the millions and millions of wasted man-hours over the years.

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

#17

Post by abhirag »

drinchev wrote: post #9

I'm a huge fan of 1 & 2, so I end up using CSS with only class names. This helped me deliver maintainable and reliable stylesheets that other devs like. Most importantly using only class names you will gain : 1. Your HTML / CSS is easier to maintain. 2. Is faster to develop. 3. Is faster to refactor. 4. Is more portable. 5. Is faster for the browser. I even wrote a blog post about it [1]. http://www.drinchev.com/blog…

This might be right up your alley -- http://tachyons.io/ I also use a similar approach and thus love functional CSS :)

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

#18

Post by pg_bot »

There is a different and IMO better way to solve the global scope problem in CSS. Adapted from the Paul Irish method of executing JS you can use data attributes to conditionally write CSS. For example a new user controller would output the controller and action names as data attributes on the body. I then have a separate css file under `assets/users/new.scss` which only contains css for that page. Your Sass code looks something like:

  [data-controller="user_controller"][data-action="new"] {
    .header {
      background-color: blue;
    }
  }
This method keeps you organized and completely removes the biggest problem most people have with CSS.

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

#19

Post by soperj »

>If you told any back-end developer that they had to use a programming language that gave all variables global scope, made every object’s internal state visible, let any other developer override their code, they’d probably resign on the spot

Isn't that the case with Javascript?

Post reply on HN