My links show up as black when they should be purple

[Sam]

On my webrings page the links show up as black even when I specified that links should show up as purple, I honestly have no idea how or why this is happening and I need someone to help me fix it 

[Melooon]

If you inspect your links, you can see your purple is getting overwritten by black because the onionring2.css file is being used instead of your inline css (see attached screenshot). CSS replaces whatever comes before with whatever comes after, so if you are adding the onionring2.css after your inline css code, it will replace it. So just move the onionring2.css link above your inline css code ^^

EDIT: "OtakuRing" is injecting the onionring2.css code, so you need to put your inline purple code AFTER that (ideally after all of them to make sure some other ring does not cause the same issue)

[Dan Q]

CSS replaces whatever comes before with whatever comes after, so if you are adding the onionring2.css after your inline css code, it will replace it.

This is mostly true, but @Sam might also be able to work-around the problem by exploiting specificity.

I've never been the best at remembering my CSS specificity rules, but the short of it is that ordering is a tie-breaker for rules with the same specificity. So if you can make your "make all links purple" rule more-specific than the overriding "make all links black" rule, that would also work.

Right now you have a rule like this:

Code

a {
  color: #c28cff;
}

That means, "all links are purple". But here's a more-specific rule that amounts to the same thing:

Code

body a {
  color: #c28cff;
}

That one says, "all links in the body of the page are purple". It amounts to the same thing (where else would links be except in the body of your page?!), but the latter rule can't be simply overridden by some stylesheet that just says what colour links are.

That might turn out to be a more-elegant solution for @Sam. Take a look!

[Melooon]

more-specific rule that amounts to the same thing

Now you've dug yourself into the hole of having to explain specificity verses cascade, I was avoiding that

For anyone who needs a quick explanation: CSS has a number of rules and regulations that decide what CSS commands get rendered on the page and what ones get ignored. The biggest two are specificity and cascade.

Cascade is what command came last; e.g. if I have "div {color = red}" at the top of the page then "div {color = green}" further down the page. The text in all divs will be green, because the green command overwrote the red command (it cascaded down to it).

Specificity is different; it asks how specific was the selector command (the "div" part); so "div" means select the all divs, but "header div" means select all divs within a "header" tag. Its more specific and so it ends up on its own cascade. "header div {color = red}" at the top of the page, followed by "div {color = green}" further down the page, will now still result in all non-header divs being green, but divs in the header will be red.

There's a lot more to it than that, but cascade and specificity are reaallly important fundamentals to learn as part of CSS - this seems like a decent introduction here.

[Dan Q]

If you want to get super-cutting-edge, there's a new CSS feature called layers (so new it's not covered in that article!... but still widely-supported enough that it's safe to use). With layers, you can override the relative cascade order of entire blocks of CSS at once!

For example, if you wanted to ensure that your links are purple even if the external stylesheet you're importing tries to override that, you could use the following CSS:

Code

/* Import the external stylesheet into a layer with the name 'external' */
@import url('//example.com/external.css') layer(external);

/* Write my own styles into the 'my-styles' layer */
@layer my-styles {
  a {
    color: #c28cff;
  }
}

/* Specify that the external stylesheet is ordered BEFORE my styles (giving my styles greater cascade priority) */
@layer external, my-styles;

Doing this is cleverer than fighting with the "order" or "specificity" characteristics of the cascade, because it means that it's easy for you to do your own overrides. For example, if your own 'my-styles' section later changed the colour of some links a.special { color: red; }, to make links with class 'special' turn red... that wouldn't work if you'd used my specificity override because 'body a' beats 'a.special' in specificity rankings. You'd have to say 'body a.special'... ugh!

And layering is expandable. If your CSS is spread over a couple of different CSS files you can import them both into the same layer. It doesn't matter which you load when: you might even load some files only on some pages, skipping them when they're not needed to improve performance! But you're still in control of the relative order in which the CSS rules are considered.

So yeah: layers are exciting and might become a big thing in future, but right now they're cutting-edge... but they do represent yet another way to solve the problem!

(As always with CSS: there are usually six different ways to solve any given problem, and the right one... "depends"!)

[goat]

Code

.mainboxes a {
color: purple; }

will target that very specific area rather than all links on the body of a page

so there's that as an option too :3