Interesting idea on Medium
I saw the first article about BEMāing your JS when it first came out and said nothing because Iām not into hardcore JS. But after reading this, my reaction is still: WHY? All this so you wonāt write CSS with more than an one word? Ridic.
1 Like
Seems like an over-simplified perspective of the matter.
Programming is best done when you can limit side-effects. It makes it easier to run tests if you can isolate the scope of a detail.
As projects get bigger, more CSS rules are floating around and impacting much wider than their intended target. What was once an asset (the cascading bit) becomes an annoyance.
For example .header .title vs .header > .title. Someone adding a new subsection in the header is now affected by a rule they may not know exists, due to the size of the projectās CSS or dependencies they import which they have little to no control over.
To me the concept makes sense, though itās one I donāt expect to be using. Additional dependencies that can be avoided with common-sense rules has āAVOIDā written all over it.
That being said, LESS and SCSS have shown me the same warning signs and yet people adopted them eagerly with open arms. Seems like quite a few people think CSS needs improvement and this is just another example of an attempt to do so.
Ps.
What does ānot into hardcore JSā mean? You only use jQuery-flavored JS? No front-end libraries? No JS frameworks? No Javascript pre-processors (grunt, gulp etc)? No simple server in JS? No complex server in JS?
"They say the devilās water - it aināt so sweet
You donāt have to drink right now
But you can dip your feet
Every once in a little while"
When You Were Young - The Killers
grunt, gulp are not js pre-processors. They are both task runners and when beautifully configured leads to nice constant integration on your dev machine. Iāve used both
Traditionally if you are coding and you save a file, you would maybe reload your browser right and test, maybe next time you would see a syntax error or an exeption or something else.
Now consider this each time what if each time you edit a file working directory,
*jshint or jscs(llint tool and style checkers) run to check syntax and code style.
*code bundler bundles all my code to one file
*unit tests are run if error am told
*copy to dev folder
*browser reload automatically
Now al this happens automagically and fast so that all i now do is
*work on file and save
*if error i fix
*check browser
Still looking for a way to remove the save from the process so that i just work and the computer knows its time to save, maybe autosaving at 30000 milliseconds interval or something.
That is how it works. People bring down and build up new things. Its examplary creativity. The questions we should be asking includes
Is it really worth it.
How does this style factor into the workflow already present among devs.
What do other experts in the field think about this.
This would be a great invention if it pulls through with W3C.
What are they promising.
- Modularity of page components in a styling capacity.
- Interference from other page components is nullified.
We already have nice js frameworks/libs that provide for us data binding. This means that i can now actually design page components in html and still back it up with structures from the js lib/framework in such a way that it handles the user interations quite nicely.
Adding both of this together and you have a a fully modular page component.
Think about this, we would have form elemens, buttons, headers, search bars ā¦etc all pre packaged in such a way that you are sure it wonāt affect you page layout at all.
- I want a search bar of size 500*45
- Got to xyz.com to dowload the page component.
- Programatically configure to 500*45
- your work is done.
It would be great if the lead designer could configure a global css file for a url and then leave the styling of other page components to junior designers with the trust that they wonāt break each others work.
People have abused the ācascadingā bit of CSS. I donāt write my CSS this way. I loosely follow the BEM methodology.
Which means I would have .header, then .header-title. If I want to write a style for a header title link, then Iāll do .header-title__link. And the beauty of the current version of SCSS is that I can still nest all that this way:
.header {
background: #ffffff;
&-title {
font-size: 20px;
&__link { text-decoration: underline}
}
}
If I want to add another element to header like meta, then Iāll have .header-meta.
Not only does this greatly reduce over-specificity for me, but it also means if I decide to add another section, itās not going to affect what Iāve written already. What we need is to work smarter, not throw more tools at everything. I shouldnāt and will never use JS to import CSS.
SCSS already solves a LOT of these problems for me. I modularize my SCSS files so that I know where to find everything. All that code above, for instance, will be in a file called _header.scss. Which using the same grunt I can grab all the sub files and save as ONE CSS. If your code is already modularized like this you and your team wonāt have problem finding it. Iām of the firm belief that your should be modularized from the backend not the front.
The method above also seems to make the assumption that everyone is using a frontend JS framework. Iām not. To me, itās unneccssary for what Iām currently doing. I hope that also answers your ps. Iāve worked with AngularJS and can use it fairly decently but I donāt care for it so much.
is it really worth it.
How does this style factor into the workflow already present among devs.
What do other experts in the field think about this.
@Okeke_Arthur_Ugochuk I already answered the first one. I donāt think it is, and by trying to treat CSS like a programming language, they are overcomplicating it. I appreciate the experimentation, as such gave us things like SASS and Grunt, and know that in large teams CSS can get wonky, but Iāll pass on this one. For people using React like the OP, it must be a godsend, for others, it just looks tedious. Then thereās alarming over-reliance on JS. Always consider the users who may not have JS for one reason or the other!!!
Re: what do other experts think. Seyi got this link from when I retweeted another expertās tweets:
This post really made me smile. PointSS noted :). But allow me to clarify some assumptions for sake of clarify and technical correctness for members of this community.
The BEM MindBEMding ā getting your head āround BEM syntax ā Harry Roberts ā Web Performance Consultant looks nice and is something i would study soonest.
**I shouldn't and will never use JS to import CSS.**I think you are missing the point there. The usefulness of this idea/concept is not who is importing who but that we can restrict css to one area of the page without it interferring with other page components
**SCSS already solves a LOT of these problems for me.I modularize my SCSS files so that I know where to find everything** Again it's not just code modularization but Full modularization. We've already solved the problem of where to find everything. In my environment, i don't care where anything is, it just figures itself out since i use a bundle file(Not self promoting, just making a point clearer).That is another topic for another day. There are tradeoffs to consider. I think stating clearly why just a backend modularization works for you and the tradeoffs would help make things clearer for all.
Though they used React as their example, this is much more than that. I think the final assumption would be everyone is using a javascript enabled browser. I think so because, like i said, if it passes through W3C then it would be something the browser vendors would implement.
I agree that its not within the scope of CSS to have some very programmatic features but then i think this is not trying to change CSS but trying to dictate how it should behave globally. Implementation details will defer among developers.
That is there implementation. I personally would not use it as is. I know the what the idea is, iāve heard it discussed about it with some folks some time ago. I await what W3C has to say on standard implementation details.
That statement is fast becoming a cliche but then again, it is a valid one. Many devices today have javascript interpreters preinstalled. It is the defacto web client scripting language and should be enabled.
Finally this is more than javascript, that is just their implementation.
@onyeka have you considered writing on how your dev team/group use BEM concept and SASS?
Sounds like youāre advocating not using the cascading part of CSS.
I see the merit, but completely avoiding cascading seems excessive.
Case in point: nested elements.
What happens when you want similarly styled elements that vary only slightly when nested, like comments in a comment thread? Do you create styles for each individual depth or do you let the styles cascade and vary them just a little bit at each step?
@onyeka have you considered writing on how your dev team/group use BEM concept and SASS?
Unfortunately, I donāt know if Iām qualified. The most recent and only design team I worked with was obligated to use Bootstrap (ugh), though itās worth commending how Bootstrapās less files are extremely modular. BEM usage is something Iāve known about for a while, but only started using in earnest when building my latest project. I fought it for a while because it seemed verbose, but Iāve spent a lot less time overriding thing classes since I took it on.
@akamaozu I donāt completely avoid it, whatās above is an example that requires you to add a class to everything (which we should do IMO), but sometimes I will do something like .header a. Honestly, Iāve come to realize nesting is a pain. I rarely nest more than 2 levels deep.
For singular elements I know will be repeated I style them on their own. For instance. All my buttons use a .btn class. If I want modifications of that button I will pair this with .btn__small or .btn__blue.
What happens when you want similarly styled elements that vary only slightly when nested, like comments in a comment thread? Do you create styles for each individual depth or do you let the styles cascade and vary them just a little bit at each step?
Iām going to say both? Itās hard to say without knowing how the code is written and what is changed.
<ul class="comment-thread">
<li class="comment">
...
<ul class="comment-children">
<li class="comment depth-1">...</li>
</ul>
</li>
</ul>
Everything here has a class, but thereās an extra class on the nested comment. If I wanted to change the background of the nested element I will still do .comment.depth-1. Honestly, it depends on what exactly is being modified. If many elements will be modified as you go deeper it would make sense to just give them their own styles, no?
Interesting thread. Anyone here familiar with smacss?
Yes! I think itās another guide that I very loosely followed, but mostly just in terms of how I organized my code. These days I donāt try to hard to follow any set guide.
Yup. Itās not a rigid framework, but more a way to think about organizing your css. Iāve found it quite helpful. Iām not particularly sold on local css myself, because with respect to theming and overall look and feel, you do need some global style principles. Having to recreate this global style in every module, whether by importing the relevant files or redeclaring it in a local file, seems a bit inefficient to me.
I have noticed that these solutions seem to be coming from people doing a lot of JS framework ā¦ work. So itās possible theyāre inventing solutions to problems they created themselves.
Thereās this other one which also looks like a mess http://acss.io
āSo itās possible theyāre inventing solutions to problems they created themselves.ā
Lol. True. Itās surprising how often this is the case.