elad2412/the-new-css-reset

The New Simple and Lighter CSS Reset

the-new-css-reset's Issues

Improving performance

I'm taking a closer look at my style recalculations, and it turns out the all CSS property is incredibly slow for no reason.

With no other CSS on the page, and a 4x CPU slowdown, I get ~14ms for a page of mine with ~200 elements on the page, which just this CSS:

*:where(:not(html, iframe, canvas, img, svg, video):not(svg *, symbol *)) {
  all: unset;
  display: revert;
}

If I exclude divs, like the following, my style recalculations drop to ~9ms:

*:where(:not(html, iframe, canvas, img, svg, video, div):not(svg *, symbol *)) {
  all: unset;
  display: revert;
}

If I also exclude spans, like the following, the time drops to ~4ms:

*:where(:not(html, iframe, canvas, img, svg, video, div, span):not(svg *, symbol *)) {
  all: unset;
  display: revert;
}

The crazy thing is that Chrome's user agent stylesheet, only sets display: block for div, and it doesn't even set anything for span.

So an insane amount of performance is being thrown out of the window for nothing really.

Possibly this should be taken into account, and some common elements, if not every element, should be special-cased and not be reset with all: unset.

Hyphenation not working in Chrome

hyphens: auto; word-break: break-word; word-wrap: break-word;
will not set an hyphen in chrome. When I uncheck all: unset in dev tools, hyphen is set.

Example in Codepen: https://codepen.io/tillschweneker/pen/abLKXLR

The meter is not visible

The unset: all property hides the meter element. To solve this, you need to add a appearance: auto rule for meter only.

Add text-size-adjust?

Hello!

I came across this article today on text-size-adjust and am wondering if it's worth setting it to none in the reset? Reading the MDN article, I'm not sure if unset does the same thing.

Contenteditable <pre> is no longer editable

It seems a <pre contenteditable> is no longer editable with all properties reverted:

/* preformatted text - use only for this feature */
pre {
  all: revert;
}

Is this the expected behavior?

Any plans to output css in JavaScript object notation syntax?

I myself am a creator of a library, and would love to update my normalize css to use this. However, my library uses css-in-js, so I won't be able to use it in its current state.

Will there be any plans to release a JS object syntax version of this css reset?

a:-webkit-any-link not completely overridden

The reset still leaves text-decoration: underline in place from the user agent stylesheet.

Could I use this css reset inside html email content?

I'm dealing with an issue that is our users are entering content into a WYSIWYG in a browser, and then that content ends up getting emailed to people. I'm trying to normalize the emails. I'm seeing things like ordered lists will be roman numerals some places but 123 numbers on other displays of the same content. Also some applications the table width will be as small as possible, and in other places the tables will have a min width applied. It's all over the place. I know this library doesn't say it supports email applications but I haven't been able to find anything closer.

Questions regarding the main selector reset

Hello I have two questions about this new cool reset. specifically this line:

the-new-css-reset/css/reset.css

Line 7 in a46b4e4

*:where(:not(iframe, canvas, img, svg, video):not(svg *, symbol *)) {

1. Can you please explain why there is a chain of :not instead of using single one?

:not(iframe, canvas, img, svg, video, svg *, symbol *)

2. Why there is a * at the beginning of the selector?

Thanks in advance.

CUSOR: POINTER disabled

I've an issue where the following is disabling CURSOR: POINTER in my custom stylesheet, even though my sheet comes after the reset:

*:where(:not(iframe, canvas, img, svg, video):not(svg *, symbol *)) { * all: unset; display: revert; }

Which of the elements (canvas, img, svg) does CURSOR: POINTER fall?

Here are bits of the HTML . . .

   <link rel="stylesheet" href="css/css-reset_v141.css">
   <link rel="stylesheet" href="css/relearn-29nov2021.css">

          <div class="masthead toggled_element">
               <div class="logo"><a href="#01">Fixed Header!</a></div>
               <div id="menu_toggle" class="toggled_element menu-toggle">
                    <div class="one"></div>
                    <div class="two"></div>
                    <div class="three"></div>
               </div>
          </div>

and my CSS.

.menu-toggle { cursor: pointer; width: 30px; position: absolute; right: 0; top: 7px; }

Recommended combinations with normalize, sanitize, resets

I've read your articles on Medium and CSS Tricks.

Can you recommend some combinations how would you do CSS init with or without this library? How is the relationship to sanitize, they are doing similar things (border-box, etc.) aren't they? So it's either one of the other?

I guess for older browser support, the only choice is either:

• normalize + reset.local
  or
• sanitize

And for newer browsers you recommend:

• normalize + new-css-reset

Is this correct?

Minimize use of revert

Since the point is to eliminate browser inconsistencies by not using the browser's default styles, in principle it should be better to not use revert (whose value can differ depending on browser) unless needed. For instance,

a, button {
    /* cursor: revert; */ 
    cursor: pointer;
}

Invisible caret in `contenteditable` with Firefox

Reproduce: https://codepen.io/pynnl/pen/VwzOLpx

Tested on:

• Windows 10 Education x64 19042.1348
• Chrome 96.0.4664.45
• Firefox 94.0.2

It works fine on Chrome. However on Firefox, the caret is invisible although the element is still editable.

Safari requires explicit styling for line-through on <s>

Perhaps include this in the README... I found that I needed to explicitly style the <s> element with line-through for Safari. Just doing a revert (which worked on Chrome) was not enough.

s {
    text-decoration-line: line-through;
}

min-width has to be resetted to 0 for flexbox

The "new" auto default value on min-width and max-width causes problems in Flexbox because flex-items do not shrink on small screens due to their content.

auto computes to 0 for most elements... except for flex-items and grid-items.

See: https://medium.com/the-crazy-coder/the-mystery-of-css-flex-layout-items-shrinking-8748145e96d9

Since auto is now default value for min-width, it can't be just resetted to 0 with initial, unset nor revert. We need to explicitly set it to 0.

See and try on Codepen: https://codepen.io/raphaelgoetter/pen/oLzzar?editors=1100

h1 still has margin-block-start / margin-block-end on chrome

Hi,

as you can see from the following pen and screenshot:
https://codepen.io/perni1984-the-sasster/pen/wvrBaBo?editors=1100

The <h1> still has margin-block-start and margin-block-end from the browsers user agent stylesheet. Is this intended?

I would have rather expected that those styles are resetted to be 0, but maybe I am missing something.

Firefox SVG sprite bug

I noticed a strange bug in Firefox when using a SVG sprite. Some shapes render fine but others don't.

CodeSandbox: https://codesandbox.io/s/reqrh
Test Files: https://github.com/nicolaibach/svg-firefox-bug

The bug goes away if symbol * is excluded explicitly:

*:where(:not(iframe, canvas, img, svg, video):not(svg *, symbol *))

Reset makes hr vanish

Hello,

all: unset resets all borders to zero, which makes <hr> tags disapear :

Codepen : https://codepen.io/raphaelgoetter/pen/rNvmWwY?editors=1100

<input type="color"> display problem

    <p>
      <label for="example-input-color">Color</label>
      <input type="color" id="example-input-color" placeholder="#fff">
    </p>

A display problem occurs with the Google Chrome browser (version 109.5414.74..0.5414.74): a long left border appears, using only The new CSS reset.

Thanks.

contenteditable rule allows editing when set to false

I believe the rule should look like this:

:where([contenteditable=true]) {
    -moz-user-modify: read-write;
    -webkit-user-modify: read-write;
    overflow-wrap: break-word;
    -webkit-line-break: after-white-space;
}

As per MDN docs: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content

The attribute must take one of the following values:

- true or an empty string, which indicates that the element is editable.
- false, which indicates that the element is not editable.

By not specifying a value for the attribute you are setting read-write on all elements that have that attribute regardless of it's value.

@charset at-rule and bundlers/processors compatibility

Hi, sorry if I miss something, but is there any particular reason to add an explicit @charset "utf-8"; here?7f52a2b. I'll try to explain what happens with my project because of this (please don't take it as offence because it's not implied).

Asking because:

1. it doesn't add any value nor solve any bugs unless the reset.css somehow intentionally served with a wrong charset header / tag attribute (see MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/@charset, the part before "Syntax", explaining how user-agent should decide which charset to use – it will eventually fall back to utf8 anyway)
2. even if it's served incorrectly, reset.css doesn't contain any non-ASCII symbol so it basically should look exactly the same in almost any encoding.
3. it might break backward compatibility with bundlers or pre/postprocessors

---

I'll stop on the 3rd reason for a moment.
@charset rule MUST be the first piece of text in the entire file, regardless what's inside. Imagine some of this situations:

1. a bundler, let's say it's Webpack, packs some CSS files into one bundle. Yes, reset.css should be the first stylesheet in this file anyway, but there might be some situations when it's not. In this case the resulting file will be:

/* some defaults stylesheet goes first for whatever reason. Maybe it's some additional reset rules which are allowed to be overriden by reset.css or anything else */

@charset
/* reset.css contents goes here*/

In this case, the whole file is malformed and user-agent will probably reject it (I didn't check it but it looks so according to MDN)

2. [this is my case] a postprocessor, let's say it's postcss with a custom number of plugins, adds some @mixin rules into every file it encounters (it's like a banner-plugin for webpack). in this case the reset.css becomes

@mixin mymixin {
...
}

@charset
/* reset.css contents goes here*/

In this case, postcss just throws an error and compilation fails.

3. Of course there might be other use cases I'm not aware of

---

For now, I have the following solutions:

1. downgrade the-new-css-reset to v1.8.4. This is bad because I basically opt-out of any updates to the package
2. write a custom plugin to postcss which would remove the @charset manually. This is bad because I manually do something which is considered to be a hack
3. write a custom Webpack rule which treats reset.css differently than any other stylesheet in the project. Doable but looks like a hack too
4. remove the charset line with any other tool, like a pre-build step. This is bad for the same reason
5. use some community plugin which removes the charset instead of me. This is bad because there are two of such plugins, one of them is abandoned/archived and the other one is shipped as a part of a huge cssnano project

After an hour of fiddling with postcss documentation I have a working 2) solution, and it's awful:

const tempRemoveCharset = () => ({
  postcssPlugin: 'tempRemoveCharset',
  Once: (root) => {
    if (!root.source || !root.source.input || !root.source.input.file.includes('reset.css')) {
      return;
    }

    const charset = root.nodes.find((node) => node.type === 'atrule' && node.name === 'charset');
    if (charset) charset.remove();
  },
});
tempRemoveCharset.postcss = true;

So in the end I decided to just downgrade (the solution 1)

Password input field placeholder turns into dots

https://github.com/elad2412/the-new-css-reset/blob/main/css/reset.css#L53

/* reset default text opacity of input placeholder */
::placeholder {
    all: unset;
}

This makes the placeholder text in password fields turn into dots. Without the reset it should display as plain text.

It has something to do with the -webkit-text-security css property...

Add comment with URL back to this github repo

Would be handy to have the URL back to https://github.com/elad2412/the-new-css-reset somewhere in the preamble comments at the top of the reset.css file.

sass/scss extension

For convenience, I suggest adding sass and scss files.

Problems with progress and draggable elements

Hi,

Your method render draggable true element not draggable and progress bar impossible to modify with css.

Had to fix by modifying the first line like this for the moment:
*:where(:not(iframe,canvas,img,svg,video,progress):not(svg *,symbol *)){all:unset;display:revert}

I'm on Safari but the problems was tested with Firefox and Chrome too

For Safari you have to revert -webkit-user-drag so let's assume you have to revert user-drag too.
using [draggable=true] {-webkit-user-drag: element;} not sure on the user-drag usage at the moment
(not tested on chrome and firefox and every element I want to be draggable are draggable="true" of course)

sorry for my poor English.

Question: Location of pre and modal

Hey there,

As I try to understand the cascade and what is happening in the reset, I have come to a question I don't understand and was hoping for some clarification.

Could you tell me what the reason is for reverting pre and modal rather than just adding to the list of not elements in the main reset statement?

Thank you much for your hard work and for taking the time to help a new designer learn.

Would you recommend any specific way(s) of processing this for older browser support?

:: marker { content: ""; } prevents list-styling

The following code from lines 69-72:

/* remove default dot (•) sign */
/* ::marker {
  content: "";
} */

overrides list-style on all ul and ol elements, preventing the use of list-styling entirely.

This can be fixed by the user by resetting ::marker via ::marker { content: initial } for the li in question, but some users might not be accustomed to using ::marker to style their lists, and so might not realize what is going wrong. (It's me. I am 'some users'.)

If this is intended, maybe the comment on this section could be updated for clarity.

Spelling mistake: specfity

specfity isn't a word, did you mean specificity?

Add "position: relative" to all elements

By default, all elements are set to position: static.

position: static and position:relative are the same thing, except for the fact that prosition: static render the z-index property innefective.

Suggested changes :

replace ▼

*,
*::before,
*::after {
    box-sizing: border-box;
}

By ▼

* {
    box-sizing: border-box;
    position: relative;
}
*::before,
*::after {
    box-sizing: border-box;
}

Is the fix for :where([contenteditable]) -webkit-line-break: after-white-space intended?

First and foremost, I'm a new web developer. I have a history of using HTML and CSS, from back in the 90s, but have never worked as a professional in the field, and therefore have little experience to speak of. I'm in a coding bootcamp right now, and recently found your CSS reset, and am playing around with it in my projects for the bootcamp. I say all of that to preface that my issue here could be misguided. Enough of that.

Is the following rule valid CSS? I'm specifically calling out the -webkit-line-break declaration. I've looked through the MDN for both line-break and white-space properties, and do not see any mentions of the after-white-space value. VS Code is also showing this declaration as a problem with the code. It's almost like this is a hack to use the :after pseudo-element, but even then, the MDN isn't showing a white-space (or after-white-space) value for the line-break property.

:where([contenteditable]) {
    -moz-user-modify: read-write;
    -webkit-user-modify: read-write;
    overflow-wrap: break-word;
    -webkit-line-break: after-white-space;
}

Thank you for taking a look at this, and if I am misguided, I welcome any feedback that could help me on my journey to learn to code. Have a good day.

TNCSSR + `-webkit-user-select: none` Breaks Text Input In Safari

When setting -webkit-user-select: none on the body, I can't type into text input fields in Safari, see here (code). Not sure what is happening exactly here (in Chrome everything works fine), but it seems related to TNCSSR. Feel free to delete if this is offtopic.

Problem with height of <select> in Safari

I have a that I hide with select { height: 0; overflow: hidden; opacity: 0; pointer-events: none; } But the height didn't apply until I add this : select {white-space: pre;}

Focus states & keyboard accessibility

First of all, thank you so much for building this! I've been trying it out in a few projects and it's honestly been a breath of fresh air to not have to constantly fight with default user agent styles to get things looking exactly the way I want.

That said, I do have some concerns around accessibility of the reset in its default configuration, specifically because it removes the default browser focus outlines. This is the reset working as intended, but as it grows in popularity I fear that people who use it might not realize this and will build apps with really poor accessibility for keyboard users by not providing any custom focus styles on top of the reset.

Some potential ideas to work around this:

1. We can make an exception for the default focus styles and not override them. This way usages will continue to have a reasonable default level of accessibility for keyboard users.
2. We can add a note in the readme, ideally very high up, mentioning that the reset removes focus styles, the consequences around that, and strongly recommend users to provide their own.

I would personally vastly prefer 1 as a safer default, but 2 is probably better than nothing if we want to err on the purist side and override as much styling as possible. Definitely open to other ideas as well, and happy to send a PR once we settle on the approach!

Browser error message regarding -webkit-line-break

Hello,
I am getting this in edge 102 (marked as an error):

Does the regular "line-break" need to be added?

Thank you.

img should also have `height: auto;`

Considering the following common markup:

<img src="image.jpg" width="800" height="600">

Because of max-width: auto, the image will be squished when the viewport gets smaller than 800px.

Resets H1 style to body style

<main><h1>Hello World</h1></main> displays as body text. Isn't a bit too hard?

Why reset inline elements <b> and <strong> to blocks?

Seems unintuitive.

Remove list-style on `summary`

summary has list style that needs to be removed.

https://codepen.io/idesmar/pen/JjvyJRa?editors=1000

make hidden attribute respected again

If an element gets a hidden attribute your current main reset is resetting it to its original display property. Can be fixed with a minor addition:

*:where(:not(iframe, canvas, img, svg, video, [hidden]):not(svg *, symbol *)) {

So the hidden attribute will force display: none like the browsers default behaviour.

all: unset isn't hyphens-friendly

Hello,

It seems that all: unset disallows hyphens property on elements (or another property which goes along with hyphens)

See : https://codepen.io/raphaelgoetter/pen/ZErGoae (uncomment all: unset to enable hyphens: auto)

all: unset strips line breaks from <pre>

I noticed code blocks using <pre> were missing line breaks. The problem seems to stem from this line:

*:where(:not(html, iframe, canvas, img, svg, video, audio):not(svg *, symbol *)) {
    all: unset;
    display: revert;
}

If I disable all: unset in devtools, line breaks return to <pre>. But for the life of me, I can't seem to figure out which CSS property it unsets to remove line breaks so I can add them back.

Here's an example with all: unset and while its disabled:

Thanks.

Specificity on selector for `all: unset;` is greater than `::slotted()`

When using this reset, I am unable to style slotted elements with ::slotted() without using !important.

Test example: https://codepen.io/noleli/pen/QWqWdWz

The CSS on lines 16 and 20 of the JavaScript should make both words red. Commenting out all: unset; in the reset fixes the problem (but negates the reset). Thanks!

Web component host reset

I've been using this reset with web components (via LitElement). In doing so, I've found that the reset (both unset: all and display: revert) causes a lot of problems related to styling the :host (shadow root) selector.

Problem

Research suggests that the specificity for the :host selector is intended to make it act as the default style for a custom element. Therefore, it is expected to be overridden by any other styles.

That places the shadow root in quite an awkward position following a reset. After all, the purpose of a reset is to strip browser styling. After that, any user-authored styling (including the defaults of custom elements) should be respected.

Solution

My solution is to add display: contents !important to the :host selector in each component. Then, if a custom root is desired, it can be implemented as a separate class, applied to a container element (like a div).

/* Pass through root */
:host {
	display: contents !important;
}

/* Custom root */
.container {
	display: flex;
}

This solution is ideal in my case, because I don't like that shadow roots participate in the document layout in the first place; I prefer the pass-through behavior of React fragments (<></>).

Related

Related external links:

• Is it possible to increase specificity host selector shadow root custom element?
• Why do element selectors supersede the :host selector in custom elements with shadow DOM

Adding <label> elements to the rule reverting the 'cursor' property

May I suggest adding label to the selector list of the rule that reverts the cursor property (line 23)? I tend to believe that CSS authors are much likelier to want the arrow cursor than the text caret for their labels.

First line causing problemas with flip cards in Safari

Problems with flip cards in Safari.
After removing the line below, the backface is hidden again, solving the problem. With it applied, even using the -webkit- prefix, the backface was mirrored. I currently use SASS, but even with vanilla CSS the problems occurs.

*:where(:not(html, iframe, canvas, img, svg, video):not(svg *, symbol *))
    all: unset
    display: revert

I also use version 8.0.1 of normalize.css, but in the tests I performed the behavior remained unchanged even with its removal.

Issue with specificity?

This code:

*:where(:not(html, iframe, canvas, img, svg, video, audio):not(svg *, symbol *)) {
    all: unset;
    display: revert;
}

is not only doing Remove all the styles of the "User-Agent-Stylesheet", except for the 'display' property.

Because specificity is so high you can't set, for example, word-spacing on body. Not even html body beats it. So what are the options? Isn't this an issue?

problem with counter-reset in nested lists (Firefox only)

Firefox has a problem with the numbering of nested ordered lists.

With the reset, the property "counter-reset" in Firefox is not set, so Firefox counts every list item continuously. All other browsers are using the standard: ol {counter-reset: list-item}, but for Firefox this must be explicitly set.

MWE:

list.txt

Use logical properties

REF: https://web.dev/learn/design/responsive-images/#constrain-your-images

I am still trying to digest that, but basically we need to use this:

img {
  max-inline-size: 100%;
}

instead of this(which is what this library is providing right now), to accommodate other writing modes

the-new-css-reset/css/reset.css

Lines 33 to 35 in f6bfae6

	img {
	max-width: 100%;
	}

Strange result with browsers on Windows

I have a strange result with this reset: the <head> <title> tag and the content of <script> tags within the body are displayed as content in the browser.

This happens only in browsers (tested in Chrome & Edge) on Windows.

I debugged the issue and found out that the error is caused by

*:where(:not(iframe, canvas, img, svg, video):not(svg *, symbol *)) {
  display: revert;
  all: unset;
}