Tags: separation



Big ol’ Ball o’ JavaScript | Brad Frost

Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.

Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”

Reluctant Gatekeeping: The Problem With Full Stack | HeydonWorks

The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.

Absolutely spot on! And it cuts both ways:

Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.

When to use CSS vs. JavaScript | Go Make Things

Chris Ferdinandi has a good rule of thumb:

If something I want to do with JavaScript can be done with CSS instead, use CSS.

Makes sense, given their differing error-handling models:

A JavaScript error can bring all of the JS on a page to screeching halt. Mistype a CSS property or miss a semicolon? The browser just skips the property and moves on. Use an unsupported feature? Same thing.

But he also cautions against going too far with CSS. Anything to do with state should be done with JavaScript:

If the item requires interaction from the user, use JavaScript (things like hovering, focusing, clicking, etc.).

‘Sfunny; I remember when we got pseudo-classes, I wrote a somewhat tongue-in-cheek post called :hover Considered Harmful:

Presentation and behaviour… the twain have met, the waters are muddied, the issues are confused.

Design Doesn’t Care What You Think Information Looks Like | Rob Weychert

A terrific piece by Rob that is simultaneously a case study of Pro Publica work and a concrete reminder of the power of separating structure and presentation (something that I worry developers don’t appreciate enough).

Don’t get stuck on what different types of information are “supposed” to look like. They can take whatever shape you need them to.

Keep ’em Separated — ericportis.com

I share the concerns expressed here about the “sizes” attribute that’s part of the new turbo-powered img element (or “the picture element and its associates”, if you prefer). Putting style or layout information into HTML smells bad.

This is a concern that Matt Wilcox has raised:

Change the design and those breakpoints are likely to be wrong. So you’ll need to change all of the client-side mark-up that references images.

I can give you a current use-case: right here on adactio.com, you can change the stylesheet …so I can’t embed breakpoints or sizes into my img elements because—quite rightly—there’s a separation between the structural HTML layer and the presentational CSS layer.