61–70 of 109 posts
Stop using CSS and go with modular SCSS
> Stop using CSS... Maybe I am stupid here, but doesn't SCSS just render out to CSS?
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.
Please don't. Tags have semantics for important reasons. Even if you're removing one of those by overriding the default styles, the semantics of tags are still used e.g. for screenreaders. It's not a mistake that HTML 5 added a ton of new semantic tags like , , , and .
This stems from the fact that I have inherited the task of re-writing a very large (at least for one person, I feel) task of re-writing an internal framework that is really gotten too burdensome to add anything to. I have been contemplating instead of trying to get crazy with a ton of different selectors where you end up with a pattern like this:
``` .selector .selector1 li, .selector .selector1 li a { some-style: some-value; } ```
Which I find A little crazy compared to something like this:
``` [class*="selector selector1] { some-style: some value; } ```
or my person favorite:
``` ul > li > a { color: blue; } ```
While these examples are I think very simplistic (I don't wanna junk up the page with tons of stuff) I've met alot of resistance to this idea, and splunking other frameworks for inspiration (Shout out to https://bulma.io ! I like their work, its really wonderful FYI.) I don't see alot of this.
While the resistance I've met from others who have some input on this project (and rightly so, they're also part of our stellar in house design team) seem to resist this idea, but haven't articulated why.
I was wondering if it comes down to: is there actually an issue with using these heavily vs some of the older semantics or, which I feel is quite possible, people have done things for so long one way its hard to see another way?
While its seemingly less verbose sometimes (not always) I feel like the new selectors give you a way to combat specificity problems by controlling when context around your classes is better than having ton of different classes and nesting those over and over.
Am i missing something?
Earlier quoted context omitted.
If we're going that way, you might as well include that particular file only on that page.
I would rather have one single request for a large static asset, than multiple small requests for per page based css. In my experience CSS files typically fall in the range 50-100KB. I'd rather not have to pay the perf penalty every time I load a new page considering the typical file size.
see https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD...
and
https://medium.com/@asyncmax/the-right-way-to-bundle-your-as...
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…
Earlier quoted context omitted.
I think the preference against ids is covered over point #2 about specificity. id styles will always override class styles, so when you're trying to apply a class-based style guide to an element that's already been styled with an id, you end up having to use !important which just creates a similar specificity problem for someone else down the line. Of course, you can still do this if you want to. To quote Chris Rock,…
If it's been styled with an id then it's already specially called out in the CSS. Either remove that, or add the id to the selector with the style.
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…
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".
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.
z-index: 2147483647;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.
Way more self describing. No team member will ask which one is reusable and which one is not.
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.