Jason Knight

The less code you use, the less there is to break

May 18, 2018

To me the question doesn't even make sense. Style is style, behavior is behavior, the two should not even meet -- and when they do that's what class triggers or direct manipulation of Element.style are for.

What you are asking about -- IF I understand the question -- is not even something I would be doing with CSS or JavaScript in the first place! Though just mentioning inline-styles or SCSS style mental huffing midgetry sets my teeth on edge.

In that way, how you worded it almost sounds like the type of thing that when I come across it in a codebase, I go "now what the blue blazes is this doing HERE?" -- but I do a lot more accessible website development than I do rinky slow broken web crapplets that tell users with accessibility needs to go perform anatomically impossible acts upon themselves.

Though if I'm misunderstanding it, could you give an example of what you mean?

-- edit -- following the links on github, I see that it's this type of cranial bleeding:

class="bold right green big italic"

If you're using classes that way, or assigning ANY of those types of values from your JS, you clearly do not know enough about HTML, CSS, or JavaScript to be working with web technologies; go back to that HTML 3.2 with all those deprecated presentational tags and attributes that everyone so clearly misses!

This is why I think that "frameworks" like react (and by extension "Material UI") are half-witted ignorant incompetent bullshit created for and by people who have no business writing a single line of HTML!

Garbage like this PROVES IT!!!

<div class="jss279 jss315 jss322 jss335 jss345 jss368 undefined">
    <div class="jss84 jss88 jss85 jss369">
        <div class="jss393 jss370 jss371">
            <div class="jss394 jss378">
                <svg class="jss251 jss377" focusable="false" viewBox="0 0 24 24" aria-hidden="true">
                    <g>
                        <path d="M16 1H4c-1.1 0-2 .9-2 2v14h2V3h12V1zm3 4H8c-1.1 0-2 .9-2 2v14c0 1.1.9 2 2 2h11c1.1 0 2-.9 2-2V7c0-1.1-.9-2-2-2zm0 16H8V7h11v14z"></path>
                    </g>
                </svg>
            </div>
            <div class="jss396">
                <span class="jss399 jss407 jss397"></span>
            </div>
        </div>
        <div class="jss423 jss376">
            <p class="jss399 jss408 jss379">Used Space</p>
            <h2 class="jss399 jss404 jss380">
                49/50
                <small class="jss381">GB</small>
            </h2>
        </div>
        <div class="jss424 jss382">
            <div class="jss383 jss425">
                <svg class="jss251 jss384 jss387" focusable="false" viewBox="0 0 24 24" aria-hidden="true">
                    <g>
                        <path d="M1 21h22L12 2 1 21zm12-3h-2v-2h2v2zm0-4h-2v-4h2v4z"></path>
                    </g>
                </svg>
                <a href="#pablo" class="jss392">Get More Space...</a>
            </div>
        </div>
    </div>
</div>

A little semantics? Leveraging selectors? Any of this ring any bells? OH, what am I saying, of course not. That would involve actually learning how to use HTML and CSS before diving for the scripttardery.

There is NO excuse apart from complete ignorance and/or incompetence -- be it as vanilla markup or generated by JavaScript -- for that to be anything more than:

<div class="panel icon-used-space">
    <h2>Used Space</h2>
    49/50 <span>GB</span>
    <a href="#" class="icon-warning">Get More Space...</a>
</div>

THAT"S how stupid garbage like react and material ui are. WHY THE BLAZES do people make so much work out of something so huffing simple?!?

The point of CSS in JS is to tackle the issue of component based design in a world where applications are built across several platforms with the same pieces. I can have a single stylesheet with all my styles, but I'll be serving CSS I'm not using. Or I can bundle it into modules based on routes or components, but I still have to handle how I'd like to handle this process, either through something like Gulp or Webpack.

The CSS classes you pointed out get minified, it's actually more efficient (less physical code to serve), and with source maps we can review the unmodified source on the fly (or just view the source, you know, in the repo).

The issue with your example is how overtly simplified it is. What happens when my button CSS ("Get more space..") duplicates across other components? Do I add a .button class to the link? Then do I including the button.css in the root component? How do I handle variants based on the component? Are the stored locally in a css file based on the component? What if the changes are atomic, like slight size changes? Wouldn't it be easier to add a style to the button base class that allows modification using a .big or .small modifier? Is this not the same logic behind adding a .text-center global class -- but more efficient? This would result in an element with a couple scrambled style names like you mentioned, and a smaller overall CSS footprint in exchange for extra text to load (especially if we only load CSS we use).

And that's just the button. The h2 element is probably similar and requires a .header type spec to apply styling. Because the h2 in this component might be a header we use in content areas, but it'll differ from the h2 we use in navigational components. Styles based on DOM elements can only go so far, and they're often not specific enough to merit placing in the relative CSS of the sidebar say (.sidebar h2). And they're not global enough to merit bloating our app's CSS across all routes. So where do they go? A general h2.css file with all the variants?

But hey, you're part of the camp that doesn't have to worry about it because of your workflow. It's cool, different keystrokes for different folks. I'm in a camp that struggles with this kind of issue because of our architecture (one of the few exchanges we take for cool stuff like faster JS at scale 😉).

I was hoping to pick the brain of someone with this issue, and see how they tackle the issue, because as you can see from the first paragraph or so, there are lots of ways to slice this pie -- if you participate in the party.

Do I add a .button class to the link?

...you add the selector to the stylesheet in the so called "DRY" style, aka using CSS how it was designed to be used.

but I'll be serving CSS I'm not using

Or you could be pre-caching appearance of subpages you haven't even loaded yet.

But then 90%+ of websites and applications have ZERO legitimate excuse to have more than 48k of CSS apart from -- again -- developer ignorance and incompetence...

But sure, adding more elements to the DOM, more classes to the DOM, the code to do all that, failing to leverage semantics to keep the code tight and presentation where it huffing belongs, is somehow magically going to be faster, easier, or "more productive".

It's the same lies all these "frameworks" peddle that amounts to nothing more than a failure to even grasp what HTML is, what CSS is for, or how any of this stuff is even supposed to work.

See how these scripting twaddles will wrap a paragraph around the obvious section heading, a second level heading around something that is clearly NOT the section heading, "small" around something not being de-emphasized, slopping SVG into the markup where it's not cached across loads of the same or similar pages, and all the other "HTML? That's not a real programming language" BULLSHIT that results in these bloated halfwitted train-wreck laundry list of how NOT to use markup.

Likely from the same lack of knowledge that leads to people slopping "DIV for nothing" around UL or FORM because they' don't even realize those are perfectly good block level containers, using classes like "w3-red", "text-center", or "box-shadow" because they missed the entire reasoning for the tags and attributes deprecated in HTML 4 Strict, and are so unaware of the meanings of HTML tags they actually bought the LIE that the purpose of H1..H6 is to declare fonts in different weights and sizes.

They aren't.

I'll never grasp how creating two to ten times the HTML needed to do the job, or vomiting up a slew of JavaScript to make an even larger DOM with more rules that are slower to render is somehow easier, simpler, or better than just putting your damned presentation where it belongs -- where it can be cached and even pre-cached -- IN THE STYLESHEET!

The BEST it accomplishes is moving the same amount of code out of the stylesheet and into the markup/scripting. At WORST it's many times MORE code AND pisses on the entire reason HTML is separate from CSS and everything HTML 4 Strict was trying to get us to stop doing! As I've said repeatedly about front-end frameworks for over a decade, if you're going to do things that way you might as well go back to using tables for layout, FONT and CENTER tags, and outdated outmoded dumbass attributes like size, bgcolor, align, border, etc, etc, etc... That is CLEARLY the mindset people working with HTML and CSS in this manner miss and so desperately want back! Hello bleeding edge of 1997 style markup methodologies! It is for all intents and purposes undoing twenty years of progress.

It's as scatterbrained a bunch of nonsense as this BS being thrown around about moving style out of your stylesheet into the markup to "speed up rendering". It doesn't, and it defeats the purpose of having CSS.

Doesn't make a lick of sense ESPECIALLY when the result ignores the structural rules of HTML and tells users with accessibility needs to go f* themselves!

Though admittedly if you're using web technologies to build crapplets, you've already told such users where to stick it.

OH, and one final selling point, keeping it in the CSS means I can reskin the entire damned thing top to bottom WITHOUT screwing with the markup or the logic generating the markup if I've used sensible placement of semantically neutral containers (DIV and SPAN) with proper semantics. That's ANOTHER of the reasons separation of presentation from content EXISTS!

Search Hashnode