Have you considered the following?

/*
 * Remove the gap between images, videos, audio and canvas and the bottom of
 * their containers: h5bp.com/i/440
 */
audio,
canvas,
img,
svg,
video {
    vertical-align: middle;
}

Hello!

The code lines which are linked in the readme are outdated. :C

Thomas

CONTRIBUTING.md currently includes a reference to running npm run test, but there are no tests set up yet - this line in the Contributing file is a bit confusing.

Check to see if -ms-overflow-style is inherited. If not, set it to inherit. This way, IE (and Edge?) get the nice appearing / disappearing scrollbars on the page and any overflowed element (like a <pre> with code) that we enjoy on Chrome, Firefox, and Safari.

* {
    -ms-overflow-style: inherit;
}

:root {
    -ms-overflow-style: -ms-autohiding-scrollbar;
}

Just pointing out that the current code overrides the user’s default font-size (that may be set in most browsers’s preferences, including IE, Firefox and Chrome), as would any font-size value using units other than %, em, or rem (or ex but that’s marginal).

Current Sass code:

$root-font-size: 16px !default;
:root {
    font: #{$root-font-size}/#{$root-line-height} $root-font-family;
}

Compiled CSS:

:root{font:1pc/1.5 sans-serif}

(I guess the conversion of 16px to 1pc is something which minify-css does in order to win just one character. A bit overkill. ^^)

Is this an intentional decision to override user settings?

I understand that not many users will have set up their browser to use a different base text size, and with many websites not respecting this preference they are even less likely to use this preference, but I’d still advise against resetting user settings in boilerplate code.

The following line in sanitize.scss:

font: if(variable-exists(root-font-size), $root-font-size, 100%)/#{if(variable-exists(root-line-height), $root-line-height, 1.5)} if(variable-exists(root-font-family), $root-font-family, sans-serif);

is being compiled to:

font: 66.66667% sans-serif

instead of:

font: 100%/1.5 sans-serif;

This only occurs after upgrading node-sass from 3.4.2 to 3.5.1. I don't know whether this is an intentional change in the compiler or a regression in LibSass 3.3.5.

Hi. I've not seen this property on cursor before, is this a typo? On a site I'm working on it's causing some links to have a text selection cursor rather than a pointer (in FireFox - Chrome, however, seems fine).

After checking the sanitize css in this checker https://jonassebastianohlsson.com/specificity-graph/ It seems it could be improved with a bit of minor juggling. Thoughts?

* {
    background-repeat: no-repeat;
    font-size: inherit;
    line-height: inherit;
    margin: 0;
    padding: 0;
}

*,
:before,
:after {
    border-style: solid;
    border-width: 0;
    box-sizing: inherit;
}

:before,
:after {
    text-decoration: inherit;
    vertical-align: inherit;
}

::-moz-selection {
    background-color: #b3d4fc; /* required when declaring ::selection */
    color: #4c2b03;
    text-shadow: none;
}

::selection {
    background-color: #b3d4fc; /* required when declaring ::selection */
    color: #4c2b03;
    text-shadow: none;
}

a {
    text-decoration: none;
}

audio,
canvas,
iframe,
img,
svg,
video {
    vertical-align: middle;
}

button,
input,
select,
textarea {
    background-color: transparent;
}

button,
input,
select,
textarea {
    color: inherit;
    font-family: inherit;
    font-style: inherit;
    font-weight: inherit;
}

button {
    overflow: visible; /* Internet Explorer 11- */
    -webkit-appearance: button; /* iOS 8+ */
}

details {
    display: block; /* Edge 12+, Firefox 40+, Internet Explorer 11-, Windows Phone 8.1+ */
}

html {
    -ms-overflow-style: -ms-autohiding-scrollbar; /* Edge 12+, Internet Explorer 11- */
    overflow-y: scroll; /* All browsers without overlaying scrollbars */
    -webkit-text-size-adjust: 100%; /* iOS 8+ */
}

main {
    display: block; /* Android 4.3-, Internet Explorer 11-, Windows Phone 8.1+ */
}

pre {
    overflow: auto; /* Internet Explorer 11- */
}

progress {
    display: inline-block; /* Internet Explorer 11-, Windows Phone 8.1+ */
}

small {
    font-size: 75%; /* All browsers */
}

summary {
    display: block; /* Firefox 40+, Internet Explorer 11-, Windows Phone 8.1+ */
}

table {
    border-collapse: collapse;
    border-spacing: 0;
}

template {
    display: none; /* Android 4.3-, Internet Explorer 11-, iOS 7-, Safari 7-, Windows Phone 8.1+ */
}

textarea {
    overflow: auto; /* Edge 12+, Internet Explorer 11- */
    resize: vertical;
}

input {
    -webkit-border-radius: 0 /* iOS 8+ */
}

code,
kbd,
pre,
samp {
    font-family: monospace, monospace;
}

select {
    -moz-appearance: none;    /* Firefox 40+ */
    -webkit-appearance: none /* Chrome 45+ */
}

button,
select,
textarea {
    min-height: 1.5em;
}

nav ol,
nav ul {
    list-style: none;
}

select::-ms-expand {
    display: none;/* Edge 12+, Internet Explorer 11- */
}

select::-ms-value {
    color: currentColor;/* Edge 12+, Internet Explorer 11- */
}

[type="button"],
[type="date"],
[type="datetime"],
[type="datetime-local"],
[type="email"],
[type="month"],
[type="number"],
[type="password"],
[type="reset"],
[type="search"],
[type="submit"],
[type="tel"],
[type="text"],
[type="time"],
[type="url"],
[type="week"] {
    min-height: 1.5em;
}

[aria-busy="true"] {
    cursor: progress;
}

[aria-controls] {
    cursor: pointer;
}

[aria-disabled] {
    cursor: default;
}

:root {
    background-color: #ffffff;
    box-sizing: border-box;
    color: #000000;
    cursor: default;
    font: 100%/1.5 sans-serif;
    text-rendering: optimizeLegibility;
}

[hidden] {
    display: none; /* Internet Explorer 10- */
}

audio:not([controls]) {
    display: none; /* Chrome 44-, iOS 8+, Safari 9+ */
}

svg:not(:root) {
    overflow: hidden; /* Internet Explorer 11- */
}

input[type="button"],
input[type="reset"],
input[type="submit"] {
    -webkit-appearance: button;/* iOS 8+ */
}

input[type="number"] {
    width: auto;/* Firefox 36+ */
}

input[type="search"] {
    -webkit-appearance: textfield;/* Chrome 45+, Safari 9+ */
}

input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-decoration {
    -webkit-appearance: none;/* Chrome 45+, Safari 9+ */
}

[hidden][aria-hidden="false"] {
    clip: rect(0 0 0 0);
    display: inherit;
    position: absolute
}

[hidden][aria-hidden="false"]:focus {
    clip: auto;
}

While doing some testing with this reset I ran into some issues where descendent elements were getting undesired borders. Adding * { border: 0; }was useful for me.

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.

How about to create test.html like normalize.css ?

@Alhadis wrote:

the default tab-width of 8 characters used by systems and terminals really doesn't cut it for the web. When code's indented with hard tabs, they're almost always 4-characters wide, not 8. Maybe have a global stylesheet rule to set the tab-size to a sensible value?

This seems like a exactly the kind of opinionated feature meant for Sanitize.css.

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.

Like https://github.com/rackt/react-router/blob/master/CHANGELOG.md . What do you think ?

npm is a great way to package and distribute css now! You can preprocess with grunt or other build tools right out of node_modules, and even better, @import right out of node_moduels using things like browserify

Would you be interested in adding this to npm?

• Do we need to change the main file to /gulpfile.js or /dist/sanitize.css or /sanitize.scss?
• How to handle scss vs css?

Kudos on the dist folder @jonathantneal

Should sources be going up a directory? It's current implementation would insinuate the .map was nested in a css/maps/ folder or something. Is this standard practice? I would expect to drop all these into the same folder and maps just work™

In lieu of changing "sources":["../sanitize.css"] to "sources":["sanitize.css"] maybe put the maps into a css/maps folder so they work automatically?

What are your thoughts on integrating any of these features?

• https://github.com/corysimmons/reeeset#features

Happy to start working on this project instead of duplicating our efforts (I think you guys are way ahead of me too so far as all your weird tweaks go). 👍

1. Go to https://10up.github.io/sanitize.css/
2. Click "Download SCSS" or "Download CSS"

Expected: the clicked file shows up

Actual: Error 404

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.

A vertical scrollbar on the page effectively takes up some horizontal space.
When this happens after some user action (e.g. opening a content pane) this could result in the layout shifting slightly to the left.

This can be avoided by always taking up this space: :root { overflow-y: scroll; }

But I'm pretty sure you have good reasons not to include it ;)

-ms-overflow-style: -ms-autohiding-scrollbar;

Does something like this need to be in sanitize.css? This actually makes scrollbars run over my content which no other browser does AFAIK and just makes stuff look mis-aligned on the right side of the page.

https://github.com/10up/sanitize.css/blob/master/sanitize.css#L29

These are invalid right? I'm not crazy right?

* { 
  position:relative;
  overflow:hidden; 
}

https://twitter.com/paul_irish/status/524959136782364672

I want to use pure CSS version with CSS variables, but /lib/sanitize.css contains & selectors (for example, here), and /sanitize.css doesn't use CSS variables.

Is this mistake, or does it require to be compiled?
If I should compile them, how to?
(Compiling with scss after renaming lib/sanitize.css -> sanitize.scss seems to produce expected pure CSS, but I don't think it is the correct way...)

You guys just forgot this right?

http://unstoppablerobotninja.com/entry/fluid-images

Not properly indented:

Empty rulsets:

Selectors not newlined:

Comments touching:

GitHub's default huge-ass tab indents (fix with .editorconfig):

Lack of semi-colons in some places:

etc. ad infinitum.

TLC please.

It looks like the latest version of this available on bower is 1.1.0. Any way you could push the latest version up?

*, :before, :after { border-style: solid; border-width: 0; }

is this really needed? I don't see what this is supposed to fix?

It causes google map arrows to be positioned wrong.

nav ol,
nav ul {
    list-style: var(--nav-list-style, none);
}

Not exactly sure what this code does, I'm guessing it defaults list-style to none (as I don't see --nav-list-style defined in the code). I know this is common practice, but this might not make sense of nested lists. Would something like this make more sense?

nav > ol,
nav > ul {
    list-style: var(--nav-list-style, none);
}

Just a heads up, when I installed v3 my typography went haywire. Thinking i would need to tune some things in order to get it working again. Back to normalize for now however.

Whoooboy, this statement messed up my project. (lines 196–198)

I don't think this is intuitive behavior at all. At the very least, it should be a variable.

Using Genesis Framework who have put extensive work into accessibility in their latest version like underlining links. Thought this would be a good place to start http://genesis-accessible.org/

If this isn't the scope of sanitize.css please delete issue.

@jonathantneal text-rendering: optimizeLegibility is buggy on Windows and Linux:

microsoft/vscode#192 (comment)

The implementation has known bugs on Windows and Linux, which can break font substitition, small-caps, letter-spacing or cause text to overlap.

Maybe for now it'd be better to not include it by default?

https://github.com/jonathantneal/sanitize.css/blob/master/sanitize.scss#L99

expecting:

seeing:

Was looking for more-or-less parity with normalize.css, would you say this is how code elements are intended to be rendered by default with sanitize.css?

Just ran into an issue with Firefox's default button padding and had to use something from normalize to fix it:

/**
 * Remove inner padding and border in Firefox 4+.
 */

button::-moz-focus-inner,
input::-moz-focus-inner {
  border: 0;
  padding: 0;
}

Is that something you'd consider adding to sanitize.css? Really useful stuff by the way - enjoying the switch from normalize a lot so far.

What is your take on applying global properties such as background-repeat:no-repeat; or background-position:0 0;? It seems to me that basically the starting point for every background image setting and yet it almost always needs to be reset to these values.

Good news! I’ll have some time to resolve the remaining sanitize.css issues and release v4. Here are the major changes I’m planning. I’d love your feedback.

Normalize

• Everything (not reset) from normalize.css v4.

Being kept

• Remove margin and padding (margin: 0; padding: 0).
• Remove tapping delay (touch-action: manipulation).
• Remove the text decoration on links.
• Remove the list style within navigation sections.
• Fills default to the text color (fill: currentColor).
• Limit the resize to vertical on text areas.
• Remove repeated backgrounds by default background-repeat: no-repeat.
• Specify default text selection styles.
• Specify default form styles.

Being removed

• Don’t reset borders border-style: solid; border-width: 0;. While I really enjoy not worrying about border-style. Unfortunately, like overflow: hidden, it comes with unexpected consequences that make it not worth the benefits.
• Autohiding scrollbars (-ms-overflow-style: -ms-autohiding-scrollbar;).

Being considered

• Be border box aggressive (* { box-sizing: border-box; }).
• Inherit all font properties (* { font: inherit; }).
• Move page background to body (from :root).
• Default flex to columns (flex-flow: column).
• Default flex shink to 0 (flex-shrink: 0;).

Not being considered

• Inherited display (display: inherit).
• Hidden overflow (overflow: hidden) because it creates unexpected consequences.
• Relative position (position: relative) because it creates unexpected consequences.

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.

@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

Not sure if it fits the scope of sanitize.css, but what about hiding those by default?

input::-ms-clear,
input::-ms-reveal {
    display: none;
}

@jonathantneal how do you feel about adding a CHANGELOG.md file to help keep track of changes between version bumps?

http://keepachangelog.com/ has some great reasoning around why to do so and a good format as well.

It would be great to have this hosted on a CDN. I suggest both CDNJS and JsDeliver:

• https://github.com/cdnjs/cdnjs#adding-a-new-or-updating-an-existing-library
• https://github.com/jsdelivr/jsdelivr#how-to-submit-or-update-projects

We need to send PRs to both CDN repos as per their requirements...

Cheers

In sanitize.scss and sanitize.styl form-element-min-height variable or function, applied root-line-height with '%' unit, compile to raw scss code or min-height: ;. Is this behavior correct?

SCSS CodePen
https://codepen.io/m-iskw/pen/wMGLqo?editors=010#0

Stylus CodePen
https://codepen.io/m-iskw/pen/GoZbQo?editors=010

Time to sync and release sanitize.css v4.

I guess the $default-nav-list-style is none because you assume navigation lists should not be styled as lists. Do we not have to remove the default (left-)padding too then?

nav ol,
nav ul {
    list-style: $default-nav-list-style;
    padding-left: 0;
}

I wonder if some of the variable names in this project could be made to be a little more semantic. For instance:

--form-element-background-color targets button, input, select, textarea but perhaps --control-background-color or --form-control-background-color would be more appropriate. Form lacks a certain specificity, especially since there is a <form> element.

I would apply the outcome of the above issue to --form-element-min-height.

--monospace-font-family targets code, kbd, pre, samp but perhaps --markup-font-family or --keyboard-font-family would be more appropriate. I‘m not sure monospace accurately describes the meaning of these elements.

I shouldn’t leave this issue open too long if there isn’t much feedback from the community.

Would you recommend using sanitize.css for email templates too? Thanks a lot!

Mat Marquis wrote an article about optimizeLegibility earlier this year that suggests it causes serious performance issues, especially on mobile devices. Does it make sense to override the browser's (apparently sensible) default for text-rendering?

I find this handy, and just wanted to share. Others might find this a useful baseline feature:

q::before {content: "“"}
q::after {content: "”"}

http://codepen.io/anon/pen/rVpZgL

It's better for readability if readers can distinguish easily between a quote beginning or a quote ending. Thanks for sanitize-- I learned a few nice tricks I've put into use.

Firefox ignores the min-height property on select elements. Regular height should be used on all input-like elements except textarea.

Is there any performance issues of using global universal star selector *?