Add a default background and color on :root?

[Pizzacus]

So I wanted to suggest this because as it turns out, some browsers don't set the body's background to #FFFFFF or its colour to #000000 by default, this can happen on some browser themes or if the user set their own colours.

And this breaks many many websites, but many people who use settings and themes like that blame it on the devs of the website.

Since not a lot of devs are aware of this and yet most people would want to have a reliable background and text colour, maybe it would be a good idea to add

:root {
    background: #FFF;
    color: #000;
}

Since :root has the lowest CSS priority, it should not break anything, most people apply the background on html or body anyway.

I don't wanna debate on if those people are right or wrong to change their default background and text colour, there is also no actual HTML or CSS standards saying browsers should set the background to a certain colour as far as I'm aware, so it's not like they're 100% wrong.

I am not sure if this is in the minimalistic scope of your project, I do feel like it is because it is a very elemental reset that you could argue would help many websites out there. And that, if more people were aware of this, everyone would start their project by resetting the background and text colour.

[Pizzacus]

According to a friend of mine, merely setting the GTK theme to a dark theme like Adawaita dark makes Firefox use dark background light text by default, so it is likely it is actually a very common thing.

[lunakurame]

^ i can reproduce that on Gentoo. i have to explicitly disable "use system colors" in Firefox' settings to unbreak half of the internet

[sammdu]

I was going to open a new issue for this! I think the most important elements affected are input and textarea.

Here's an example of Ubuntu18.04 with the GNOME theme Flat-Remix-DARK, displaying https://www.calculator.net/triangle-calculator.html

As you can see the drop-down menues and text-boxes have dark backgrounds, while the text stays black; this makes typing an incredible inconvenience.

I think the following should suffice:

input,
textarea {
    background-color: #fff;
    color: #000;
}

[sammdu]

Some details are crossed out but you can see the buttons and favicons have all been altered.

[Pizzacus]

I think it's because you put it in a Firefox theme file it may impact the UI, normal websites are not able to do stuff like, that I assure you

[sammdu]

I see. But l think it's a good idea to keep the impact of this as small as possible and we can go from there later on. It's minireset.css after all, and I think that's possibly why the author is hesitant to merge the pull request as it is, because he wants to keep the functions of this reset file minimal. :root might be too broad of a impact surface for now; but possible for the future.

[Pizzacus]

I don't think so you just add it to the file and you're done, it wouldn't have any secondary effect as far as I'm aware as :root only targets the top element of the page, really these two issues are pretty much the same things (browser themes ruining UI) so I don't see why you would take one and not the other

[sammdu]

@Pizzacus How about the scrollbar? I need to test that out at some point.

[Pizzacus]

While scrollbars are usually themed, I don't see how this would ever cause any problems, as they're to the side, not over the background, so it doesn't matter what colour they are.

[sammdu]

@Pizzacus I don't think it's about "causing problems" per se. The scrollbar is part of a consistent user experience, and I don't think it's the call of a reset stylesheet how it appears. Some websites have them styled carefully, others like my own website simply disable them.
However when a reset tool decides to apply or change a particular style, that's a statement that the tool is taking one position over another.
The goal of minireset I believe, is to create a clean slate for css styling for with minimal change for broad applications. On that ground, I think it's best to leave as many things un-touched as possible.

[Pizzacus]

Whoops, I forgot to reply to this.

The goal of minireset I believe, is to create a clean slate for css styling for with minimal change for broad applications. On that ground, I think it's best to leave as many things un-touched as possible.

Indeed but can you explain to me why we would put a default background on inputs, and not on the overall page, when it is the exact same issue of browser defaults not being what a dev would expect or be able to predict.

Like, it's really the exact same thing, if you fix one, you may as well fix the other.

[sammdu]

I guess I think of the scrollbar as a widget of the browser, and not as an element of the webpage; therefore, not touching the scrollbar is consistent browser experience for the user, whereas default white background is consistent development experience for the developer.

When you are one of the very few webpages modifying scrollbar by default, it's kinda like running QT apps under GNOME, if you've had the experience.

Most browsers know to default the page background to white, and that has been the convention for most other html elements as well; by setting textboxes to be white explicitly, it's not so much taking a side as much as it is ensuring the convention is followed. When textboxes are affected by a theme, that breaks the convention and thus a lot of pages that follow the convention. Not to mention the changes made by the theme makes these default textboxes unusable.

On the other hand, the scrollbar was always untouched by the webpage, until a few years ago with CSS3 where you can customize it. By setting the scrollbar a certain default way, thus imply "taking a side' and affecting too much. Plus, let's not touch it of it's not broken.

[sammdu]

This conversation reminds me of political debates comparing a conservative distribution of power versus a progressive distribution of power; both have pros and cons.

However, I think minireset is designed to do the minimum possible to create a consistent development experience, and that's why I suggest changing as few things as possible.

[Pizzacus]

Most browsers know to default the page background to white

This is false we just explained it, Firefox may set the page to black by default on some themes, there is even an option in the settings to change it.

As you said, it is a convention to set the page background to white and the text to black, but not all browsers follow it, while developpers would expect them to, so like that, we can fix it, and it's only one single line along with the other stuff you're already normalising in the PR.

And I've never talked about touching the scrollbar, scrollbar styling is too inconsistent across browsers anyway.

[sammdu]

I have been busy, but just got time to test out setting :root by default. This is my code:

<!DOCTYPE HTML>
<html>
<head>
  <title>Demo</title>
  <style>
  :root {
    background-color: #fff;
    color: #000;
  }
  body {
    background-color: #1a1a1a;
  }
  </style>
</head>
<body>
  <center style="color: #fff;"><h1>Sample Text<h1></center>
</body>
</html>

As you can see, the background is not rendered as expected:

---

whereas without setting :root by default:

<!DOCTYPE HTML>
<html>
<head>
  <title>Demo</title>
  <style>
  /* fix firefox dark GTK theme issue */
  input,
  textarea {
    background-color: #fff;
    color: #000;
  }
  body {
    background-color: #1a1a1a;
  }
  </style>
</head>
<body>
<center style="color: #fff;"><h1>Sample Text<h1></center>
</body>
</html>

the background renders properly:

---

pseudo-elements can be tricky at times, so it is wise to not touch them whenever possible.

[Pizzacus]

Ah, I see, the reason why that is is probably that the :root element takes the background of <body> if no other background is set.

So my next question was "is this a standardised thing", and the answer is yes.

https://drafts.csswg.org/css-backgrounds-3/#body-background

3.11.2. The Canvas Background and the HTML Element

For documents whose root element is an HTML HTML element or an XHTML html element [HTML]: if the computed value of background-image on the root element is none and its background-color is transparent, user agents must instead propagate the computed values of the background properties from that element’s first HTML BODY or XHTML body child element. The used values of that BODY element’s background properties are their initial values, and the propagated values are treated as if they were specified on the root element. It is recommended that authors of HTML documents specify the canvas background for the BODY element rather than the HTML element.

There is, unfortunately, no way to replicate this behaviour in CSS while setting default values... If we set a default on body then there will be problems if someone tries to set it on html, if we set it on html then there may be some problems with setting it on body

This has nothing to do with the use of pseudo-elements, :root is just the same as writing html.

---

But the real question is is this acceptable? I'm really not sure, I do think that setting a default on :root or html is the best, it's still less likely to break stuff, even if you found an instance where it does, since normally, the body element will take the whole screen, so it doesn't matter what colour the :root is any more.

But yeah, perhaps the best solution would be to petition W3C to make white the standard background xD different colours always break websites and yet browsers still use them because... reasons!

[sammdu]

@Pizzacus I decided to test it this way because I tried to use it on a login modal I was working on, and the login modal did not take up the whole screen obviously, then the background started acting weird.
To respond to your comment, this is what I mean by avoiding to take a position with minireset. By keeping clear of more aggressive defaults, this stylesheet can remain "mini" and "inclusive".
However, I appreciate your dedicated efforts to get this right.