[BinaryIdiot]

No but ultimately specifying it in two places could be better.

So first off if you want it to literally be the same then you could do something like:

  h1, button {
    color: #343434;
  }

That would make them the same. You could also do

  .primaryColor {
    color: #343434;
  }

Then set the elements which should have a primary color with that class.

But if you could break my first example apart and set it in two places just as easily. But that's setting it at a high level element itself. You could even go crazier and set EVERYTHING to that color but ultimately many of these decisions have to be context based to decide.

[sangnoir]

What if want to use the primary color as the background-color to a nav element and as the border-color to inputs and textareas as well? If the designer changes to a different shade, do you do a global search-and-replace?

The way I see it, CSS preprocessors allow for code reuse via composition - vanilla CSS restricts you to inheritance.

[tonyhb]

Css is quite frankly bullshit (ie. fickle), but I'm proud of it.

The actual art of making visuals usable within a screen is pretty hard to make a language out of. With postcss and react css modules there are advancements. And still, it's one of the things that I have to put the least amount of effort in for the most amount of gain.

[BinaryIdiot]

> What if want to use the primary color as the background-color to a nav element and as the border-color to inputs and textareas as well? If the designer changes to a different shade, do you do a global search-and-replace?

I already explained this? You set it at the top level. Have a set of top level HTML elements / classes that set all of these defaults. Then everything inherits from those. Only one place to change them.

[sangnoir]

> I already explained this? You set it at the top level

Not quite: 'color', 'background-color' and 'border-color' are 3 separate properties that can't be be inherited from one place using vanilla CSS

[BinaryIdiot]

Those are three different ways of coloring something (and very rarely are exactly the same in my experience). Using variables to make those three the same color is an abuse of DRY in my opinion.

[sangnoir]

> Using variables to make those three the same color is an abuse of DRY in my opinion.

I disagree - as a matter of fact, a lot of CSS frameworks have the concept of a "primary color" that is used in the manner I have described. Additionally,following your idea of DRY would render CSS variables pointless in CSS preprocessors as mixins cover that use-case (setting the same property).

[snarfy]

> Then set the elements which should have a primary color with that class.

But now your markup is littered with styling classes, and you could end up with a .secondary button with a .primaryColor class.

In vanilla css, the only way to really define something like a primary color just once and have it apply correctly to all elements is to define it at a high level in a deeply nested cascade. This of course all breaks as soon as you add a container element and have to go back and add another level of nesting to your css.

Variables in css should be standard.

[bphogan]

Just a nitpick.

I hate, hate, hate having to alter my HTML to apply styles. The idea of

<h1 class="primaryColor">

totally creeps me out. I do it because other people refuse to use preprocessors and think that altering the HTML to include presentational details is fine (see Bootstrap.)

But it still feels gross to me.

[BinaryIdiot]

> totally creeps me out. I do it because other people refuse to use preprocessors and think that altering the HTML to include presentational details is fine (see Bootstrap.) But it still feels gross to me.

To be fair HTML is the presentation. I can understand not wanting to mix business logic from JavaScript into a page but CSS is just the other half of HTML.

If it makes it nicer you could use more generic class terms (such as page information or HTML structure location, etc).

[bphogan]

HTML is not the presentation.

HTML is the content and description of content. You put a <strong> tag around text to make it strong emphasis.

CSS is the presentation. Your browser sees the <strong> tag and applies its default style of making it bold.

[BinaryIdiot]

They're both the presentation. Showing emphasis and structuring content is as much part of the presentation as CSS, maybe even more so if you care about backwards compatibility and graceful degradation.

This is just incredibly pedantic. For all practical purposes HTML + CSS is the presentation. Toss JavaScript into that if you want. Front-end work is the presentation.

[bphogan]

It's not pedantic. It's the way it was designed. Just because people use tables for layout doesn't mean they were intended for that.

As far as graceful degradation, If I open a properly built page in a text-only browser, there are no styles. There's no real emphasis or bolding. There's just text. Because CSS didn't exist.

Now, if you want to live in the early part of the decade when it was OK to put inline styles and background colors in your HTML, that's fine. But the world evolved beyond that. HTML with <body bgcolor" is deprecated.

Because HTML is the content. CSS is how it looks. And JS is how it works.