Discussion on: 8 SCSS Best Practices to Keep in Mind

View post

I agree with all except on using IDs. IDs are meant to scope your following css rules nested on it, making it easier to find, adds scalability and performs much better regarding on how browsers render the views.

Also using IDs and adding !important statements are not equal in terms of specificity and priority. !important statements are priorized much more aggressively.

So you must add IDs on your styling for scoping code but not for adding properties that are likely to need an override. 😁

Annie Liao • Jul 12 '20

Cool, thanks for the tip Joel! I was a bit surprised too when I saw that the guideline advised against using IDs. I have been quite cautious about using !important statements though.

JoelBonetR 🥇 • Jul 12 '20

Some points on guides around here have their reasons that may not fit into your project or needs. Remember that html and css (or sass/scss) are not programming languages so there's no much point on getting "best practices" or "do this instead of that". They simply work or not, this tips are about increasing performance, readability or scalability.
With this in mind, there's tones of opinionated articles that didn't tested or benchmarked anything about the content, always test this tips by yourself 😁 assomeone else may go for performance and you want scalability or vice versa (some tips are contradictory depending on the tarjet), get that ones which fits best for you 😆

Gil Fewster • Jul 18 '20

CSS is a programming language.

But even it it wasn’t, why would you say there’s no point in teams or developers formulating lists of best practice which are most suited to their needs?

JoelBonetR 🥇 • Jul 18 '20

CSS is NOT a programming language. CSS is a design language to define how HTML (which is a markup language and in fact, not a programming language) elements should be displayed.

Dev teams can of course define a list of best practices for a given project (not a generic one for all projects) depending on the goal they want to achieve. That's performance, accessibility, readability, compatibility (with old browsers) or scalability, or a mix of some or all of them. But you'll find some points where doing something could benefit a target and harm another.

For example, using multiple isolated classes can definitely benefit readability and scalability but can harm compatibility with old browsers ( I.E. 6 and older wasn't good managing multiple classes on a single html element).

So if you are into a project where you need compatibility, you must take the decision on doing one or another, you can't keep it all. That's why there's no much point on defining some things as "css best practices" globally or generically.

I wrote an article of css best practices by myself some weeks ago that you can check here:
dev.to/joelbonetr/css-and-scss-bes...
where I tried to explain what I do and why I do this, so you can discern if it fits into your code or not.

I'm not giving compatibility to old browsers because the users of my client's sites that use old browsers are less than 0,05%. I don't care much about accessibility on standard projects (clients usually does not want to pay the extra analysis and development for it) so I usually go for performance and scalability to make the modifications faster (and cheaper) to us, and getting better SEO due to mobile friendly and site low weight.

After all, everyone has to check all best practices, understand the details of every statement and check if each one can fit into their needs or not for a given project.

Gil Fewster • Jul 18 '20

Why is CSS not a programming language?

JoelBonetR 🥇 • Jul 18 '20 • Edited

HTML and CSS are not programming languages because HTML and CSS are not generally “executed” by a computer. They are parsed by an engine, and then algorithms stored in a renderer determine execution tasks.

When you write <h1>foo</h1> , you’re not programming that element. You are denoting a piece of data. You haven’t “instructed” the browser to execute a task.

Likewise with CSS, anyone who’s written it for longer than 5 minutes knows that even something as simple as float: left; may not do that just because you asked. The browser will parse your instruction, and follow a set of algorithms over which you have no control to determine if and how something floats.

By the way you can't do anything different from a static webpage with HTML and CSS only, so that's not too different to what you can achieve using photoshop or microsoft word (you'll get a static content as result).

*Static meaning you can not interact with this view for store, modify or delete anything; no login, no user profile, no custom theme, no personal data... You can only read (view) the result "as is".

Gil Fewster • Jul 18 '20

CSS may not be executed directly, but it directly affects those algorithmically determined execution tasks. CSS is used to instruct, direct or modify the application's output.

You can certainly modify content with just HTML and CSS. CSS also has functions, variables, mathematical functions and boolean logic.

We can get pedantic about strict definitions of execution, runtime interpreters and the like if you wish, but why quibble?

JoelBonetR 🥇 • Jul 18 '20 • Edited

That's not a matter of discussion usually. You can not code an application using plain CSS, you cannot add functionality, only describe how the information is painted and styled 🤷🏻‍♀️
If you add enough features on CSS (server calls and handling of responses for example) it can become a programming language but you already have JavaScript for that tasks, which is a programming language.

Pham Minh Quang • Jul 31 '20

I think this article is very useful for the usage of IDs.

JoelBonetR 🥇 • Jul 31 '20 • Edited

It lacks some usages that have been used in the industry for some years, i mean scoping styles (not necessarily for styling the element itself).
For example:

#products {
  //Selectors for child elements of products id
}

This avoid unnecessary overrides, or adding extra unneeded classnames to elements with boilerplate such products-content-block, then you simply scope content-block inside #products.

This is more efficient on parsing and painting terms as CSSOM will find an ID instead seeking for all classnames on the entire project and then apply to matching elements which happens without IDs.
It's also meant for scalability as you will be able to find and edit quickly (and without overrides) an element inside a given scope on your project (specially when it grows a lot).

It will make your styles applying to .content-block only work inside #products, it's true, so it's your job to define styles that apply to all .content-block on the project and scope those who are specific from products page. Then you have custom styles when needed and global styles when needed.

This could seem a little bit disappointing at the beginning or with the mind on a little project, but avoids tones of issues when on a big project or a project that growth much more than expected.

I'm actually maintaining and developing over an e-commerce that receives more than 100k views a day. It was made with a customized prestashop and we need to apply this to all the entire project (which weights 1Gb of code approximately) because it was impossible to handle.
The reason was the same than always with CSS... Overrides, overrides over overrides, conditionally overrides due to redesigns and more redesigns... Now with the css scoped using page IDs and few script tweaks, the performance increased 15 points on pagespeed, the loading times decreased in 6 seconds (wow) and the user experience is much better. We started creating components too (migrating to a microservice architecture) so we can perform this practices from the beginning, and all styling is scoped inside each view component id attribute. No one of us (senior devs) thank for a moment on not using them for this purpose and junior devs understood quickly why to use them (as they needed to modify things on the old project too) 😂

Pham Minh Quang • Aug 2 '20

I think your CSS system is literally the reason why you have to use IDs. IMO, a redesign shouldn't be a big problem if your CSS system is strong and flexible. The IDs scoping may fasten the project of re-writing the CSS but it is just a temporary fix. As the project gets bigger, keep using IDs for scoping would result in a messy CSS base. I don't know exactly what is your product component looks like but for me, using some classes is enough to create various styles of the product component (BEM-like CSS naming does very well on handling these cases). In your example, the same result can be achieved using classes like .product .product__content-block {}. Thus, I don't think using ID, in this case, is a good idea. However, for frameworks like ReactJS where you can write CSS separately for each component, using IDs for scoping is understandable.

JoelBonetR 🥇 • Aug 2 '20

How many years of experience do you have on the industry?
When you make a project by yourself it's all nice, when you manage a project with 10+ devs, and during developments on it some left the company, some come in and so it's nearly impossible to keep all the code clean.
On the other hand BEM is nice but not perfect: lacks the ID scoping performance and make devs write more words for doing the same. Of course you can combine different methodologies into a single one which usually works better and it's more realistic.

It's the same situation on people developing microservices without thinking if it fits into their needs. Sometimes you'll need services, connected to microservices and maintaining a monolithic application that tbh could make no sense on refactoring it into a service/microservice architecture.

I asked you about your experience because juniors and students usually take the idea that those methodologies are meant to bring perfection and must be used "as is". Then, on a real world you can code the perfect architecture and methodology and when you end with your app the paradigm changed and you are outdated. This does not mean you need to recode all entire application to fit the trends, this mean you need to learn and understand deeply the reason to exist of this methodologies and discern which part could be useful for your project.

I've to remember a fact many times and I'm doing it again: IT is a science, this means try, combine, recombine, take conclusions and repeat.
It's like if you say me that water boils at 100°C and I could tell you well, this is approximately true at sea level but not on the everest or in a hole at 5km below sea level, also incorrect on other planet and so.
There's no perfection, there's no such a thing that works well everything, you always need context.

To conclude i need to answer your comments last part, BEM is understandable, but it olds bad on hughe projects. You will end with too large classnames and with multiline HTML declarations.

Also you don't need a js framework to build components, you can do it easily without js making a dispatcher and discerning where to show some html files (which has it's own css attached).

Moreover on some js frameworks you can make your css for being included on the same output element so it will make a non sense on scoping css using IDs because you already have your styling isolated. This is the only situation where i would not use IDs for scoping (because it's scoped already).

Pham Minh Quang • Aug 2 '20

Ah ye, you are right.