Setting a background color on html instead of on body may confuse people as it will make the latter "shrink" vertically--as this demo shows. May be better/safer to style body.

How would feel about adding Stylus and LESS versions of sanitize.scss?

I can make a PR with the current version of the SCSS file converted into those preprocessors if you want.

word-break: break-all and overflow-wrap: break-word seem to only be suggested across internet as a solution to non-wrapping long words/URLs, which easily break flexible layouts.

... but I couldn't find any drawbacks on having this as default across the site. It doesn't sound like it would break anything (except, well, words) so what do you think about adding it to sanitize.css on html?

When text is selected by the user, a background highlight is shown to indicate the range of text that is selected. For users of the FireFox browser on Windows machines running High-Contrast mode the text selection highlight is invisible when custom colors are used. For accessibility purposes, it is best practice to not overwrite text selection colors.

Please consider removing the following. ::-moz-selection { background-color:#b3d4fc; color:#000; text-shadow:none }

::selection { background-color:#b3d4fc; color:#000; text-shadow:none }

All radio input styles are being removed in iOS Safari but not other browsers. Is this intended behavior? They were easy enough to add back in, but it seemed like the goal was to keep the default OS/browser radio styles intact - I've only seen this not be the case in iOS Safari.

sanitize.css is published v2.1.0 for npm but not for bower. Why is the version of the bower package supplied as the older version? I wish the bower package is published as v2.1.0.

This should enable consumption via npm-css (and mostly likely parcelify).

Also added npm scripts so all that is required to build is:

$ git clone https://github.com/jonathantneal/sanitize.css
$ cd sanitize.css
$ npm install
# Make modifications
$ npm start
# Newly built css file awaits

Come to think of it, you might not even need to publish a built css file and building it on demand using postinstall scripts. see https://docs.npmjs.com/misc/scripts I'm not sure what best practice is, as I'm new to modules that need build steps but I'll let you know once I know more.

Closes https://github.com/jonathantneal/sanitize.css/issues/1

Really want img { max-width: 100% } for every site I ever make, but the html padding in page.css is pretty awkward.

https://github.com/csstools/sanitize.css/blob/5bd695fdc7be25221c542810a72c174a33d6fb00/page.css#L5-L13

Hello, I'm comparing css normalizers, and sanitize.css seems to be pretty ideal. However, there is a part of this one which seems like a good idea:

@media(prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    transition: none !important;
    animation: none !important;
    scroll-behavior: auto !important;
  }
}

Perhaps it's worth adding to this?

I know there is gh-pages, although I didn't know this until I read the previous issues about HTML tests. So test HTML could be made more prominent for people wanting to contribute or test Sanitize.css out.

Perhaps a "tests" directory with specific tests for each case would be useful.

Also, the use of PhantomCSS for visual regression testing could be really useful when testing on updates. Could possibly even automate the entire process and simply run it from "" in the package.json.

@jonathantneal * { background-color: inherit; } is a major cause of pain for us.

Especially in large projects which import components from external projects (read: enterprise scale apps and website).

For example, global components like header, footer, login forms are breaking because of that: for example, transparent elements in a global component, assume undesired background colors from their container element in an app which requires that component.

This has been a major cause of pain for us since we started using sanitize.css, because there is no way to reverse this rule - you'd have to manually add over-riding rules for each HTML element you want to fix - even though the correct background rules are already present in their respective components' stylesheets.

Please consider dropping it, because otherwise we would be forced to drop using sanitize.css, which we favor due to it being great project with a modern approach.

Thanks, Tom Alon Wix.com

More info can be found here: https://www.zachleat.com/web/fluid-images/

Relates to #170 but in this case it also avoids multi-weight selectors by using :where().

README.md information is out of date and needs to be updated

Planned Changes

1. Deletion of the phrase "IE support"

In v13, :where is used, and :where is not IE-compatible, so the phrase "IE-compatible" should be removed.

refer: https://caniuse.com/?search=where

2. Update on Area Features

The information in part Features is out of date and needs to be updated. Since I don't know what the overall changes are, I will try to fix the selectors of existing rules and those that have already been removed.

e.g.

html { → :where(:root)

a, area, button, input, label, select, summary, textarea, [tabindex] {
  -ms-touch-action: manipulation;
  touch-action: manipulation;
}

↓

delete

It seems like latest activities on this project was more than a year ago. Is this project not maintained anymore? What do you recommend we use instead if so?

Would you be interested in adding svg to the list of elements in assets.css? Had to do that for a project to fix scaling issues, so figured I'd mention it here. Thanks!

Fixes #233 without breaking voiceover

A fix mostly inspired by https://github.com/twbs/bootstrap/blob/1df098361cac04217d6a464c80e890c4335ecb5c/scss/mixins/_visually-hidden.scss