HTML Guides

The @import rule allows you to pull in styles from another CSS file. According to the CSS specification, @import rules must precede all other at-rules (except @charset) and all style rules. When a browser encounters an @import after another valid CSS statement, it silently ignores the import. This means the styles you intended to load simply won't be applied, which can lead to broken layouts or missing designs that are difficult to debug.

The W3C validator catches this ordering problem and flags it because the misplaced @import will have no effect. Even though browsers won't throw a visible error, the imported stylesheet is completely discarded, making this a real functional issue rather than just a cosmetic validation warning.

The correct order inside a <style> element or CSS file is:

@charset (if needed, and only in external CSS files)
@import rules
All other CSS rules (@font-face, @media, style rules, etc.)

Examples

Incorrect: `@import` after a style rule

<style>

body{

margin:0;

}

@importurl("typography.css");

h1{

color: navy;

}

</style>

The @import is placed after the body rule, so the browser will ignore it entirely. The styles from typography.css will never be loaded.

Incorrect: `@import` after another at-rule

<style>

@font-face{

font-family:"MyFont";

src:url("myfont.woff2")format("woff2");

}

@importurl("reset.css");

</style>

Even though @font-face is an at-rule, it is not @charset or @import, so placing @import after it is invalid.

Correct: `@import` rules first

<style>

@importurl("reset.css");

@importurl("typography.css");

@font-face{

font-family:"MyFont";

src:url("myfont.woff2")format("woff2");

}

body{

margin:0;

}

h1{

color: navy;

}

</style>

All @import rules appear before any other statements, so they are valid and the imported stylesheets will be loaded correctly.

Correct: Multiple `@import` rules with `@charset`

In an external CSS file, you may also have a @charset declaration. It must come first, followed by @import rules:

@charset"UTF-8";

@importurl("base.css");

@importurl("components.css");

body{

font-family: sans-serif;

}

Alternatives to `@import`

While fixing the ordering resolves the validation error, it's worth noting that @import in CSS can cause performance issues because imported files are loaded sequentially rather than in parallel. Consider these alternatives:

Multiple <link> elements in your HTML <head> — these allow browsers to download stylesheets in parallel.
CSS bundling tools — build tools like Webpack, Vite, or PostCSS can combine multiple CSS files into one at build time, eliminating the need for @import at runtime.

If you do use @import, just make sure every instance appears at the very top of your stylesheet, before any other CSS rules.

CSS: Invalid ID selector.

CSS: “left”: Character n is neither a decimal digit number, decimal point, nor "e" notation exponential mark.

CSS
left

CSS: “left”: X is not a “left” value.

CSS
left

The left property specifies the horizontal offset of a positioned element — one that has its position set to relative, absolute, fixed, or sticky. The W3C validator checks CSS within style attributes and <style> elements, and it will flag any value it cannot recognize as a valid left value.

Common causes of this error include:

Misspelled or non-existent units: Writing 10 px (with a space), 10pixels, or 20ppx instead of 10px.
Unsupported keywords: Using values like none, center, or middle, which are not valid for the left property.
Missing units on non-zero numbers: Writing left: 10 instead of left: 10px. Zero is the only number that doesn't require a unit.
Typos in keyword values: Writing auто or autoo instead of auto.
CSS custom properties in inline styles: Using var(--offset) in a style attribute may trigger validation warnings depending on the validator's CSS level.

The valid values for the left property are:

<length>: A numeric value with a unit, such as 10px, 2em, 3rem, 1vw.
<percentage>: A percentage relative to the containing block's width, such as 50%.
auto: Lets the browser determine the position (this is the default).
Global keywords: inherit, initial, unset, and revert.

Using an invalid value means the browser will ignore the declaration entirely, which can break your layout. Fixing these values ensures consistent rendering across browsers and compliance with CSS standards.

Examples

Invalid: Using an unsupported keyword

The keyword none is not a valid value for the left property.

<divstyle="position: absolute;left: none;">Positioned element</div>

Invalid: Missing unit on a non-zero number

A bare number (other than 0) is not valid without a CSS unit.

<divstyle="position: relative;left:20;">Shifted element</div>

Invalid: Misspelled unit

The unit xp does not exist in CSS.

<divstyle="position: absolute;left:15xp;">Positioned element</div>

Valid: Using a length value

<divstyle="position: absolute;left:20px;">20 pixels from the left</div>

Valid: Using a percentage

<divstyle="position: absolute;left:50%;">Offset by 50% of containing block</div>

Valid: Using the `auto` keyword

<divstyle="position: absolute;left: auto;">Browser-determined position</div>

Valid: Using zero without a unit

Zero does not require a unit in CSS.

<divstyle="position: absolute;left:0;">Flush with the left edge</div>

Valid: Using `inherit`

<divstyle="position: relative;left: inherit;">Inherits left value from parent</div>

To fix this error, identify the invalid value the validator is reporting and replace it with one of the accepted value types listed above. If you intended to reset the position, use auto or 0. If you meant to remove a previously set left value, use initial or unset rather than an unsupported keyword like none.

CSS: “letter-spacing”: “NaNrem” is not a “letter-spacing” value.

NaN in JavaScript stands for "Not a Number" and appears when a numeric operation fails — for example, parsing a non-numeric string with parseFloat(), dividing 0 by 0, or referencing an undefined variable in arithmetic. When this NaN value gets concatenated with a unit string like "rem", the result is "NaNrem", which is meaningless to CSS. The browser cannot interpret it, and the W3C validator flags it as an invalid letter-spacing value.

This issue almost always originates from dynamically generated styles — either through JavaScript that sets inline styles, a server-side template that computes CSS values, or a CSS-in-JS library. The rendered HTML ends up containing something like style="letter-spacing: NaNrem", which the validator rightly rejects.

Beyond validation, this is a practical problem: the browser will ignore the invalid declaration entirely, so whatever letter-spacing you intended won't be applied. Your layout may look different than expected, and the invalid value in the markup signals a bug in your code that could affect other computed styles too.

How to Fix It

Trace the source of the value. Search your codebase for where letter-spacing is set. If it's an inline style, look at the JavaScript or server-side code that generates it.
Validate the number before using it. In JavaScript, use Number.isNaN() or isFinite() to check that a computed value is valid before applying it.
Provide a sensible fallback. If the calculation might fail, default to a known-good value like 0 or normal.
Fix the root cause. Determine why the calculation produces NaN — common causes include missing data attributes, undefined variables, or parsing non-numeric strings.

Examples

❌ Invalid: `NaN` concatenated with a unit

This is what the rendered HTML looks like when the bug occurs:

<pstyle="letter-spacing:NaNrem">Spaced text</p>

The JavaScript that likely produced it:

// Bug: getAttribute returns null if data-spacing is missing

letspacing=parseFloat(element.getAttribute('data-spacing'));

element.style.letterSpacing=spacing+'rem';// "NaNrem" if attribute is missing

✅ Fixed: Validate the value before applying it

letraw=parseFloat(element.getAttribute('data-spacing'));

letspacing=Number.isFinite(raw)?raw:0.1;// fallback to 0.1

element.style.letterSpacing=spacing+'rem';

This produces valid inline CSS:

<pstyle="letter-spacing: 0.1rem">Spaced text</p>

✅ Fixed: Using a static CSS value

If the letter-spacing doesn't need to be dynamic, the simplest fix is to use a plain CSS rule instead of computing it in JavaScript:

<style>

.spaced-text{

letter-spacing:0.1rem;

}

</style>

<pclass="spaced-text">Spaced text</p>

✅ Fixed: Server-side template with a guard

If a server-side template generates the style, add a check before rendering:

<pstyle="letter-spacing: 0.05rem">Spaced text</p>

Ensure your template logic verifies the value is numeric before injecting it into the markup. If the value is missing or invalid, either omit the style attribute entirely or use a safe default.

Valid `letter-spacing` values for reference

The letter-spacing property accepts:

The keyword normal (default, lets the browser decide)
Any valid CSS length: 0.1rem, 1px, 0.05em, 2px, etc.
0 (no extra spacing)

The numeric part must always be a real number — NaN, Infinity, and empty strings are never valid.

CSS: Lexical error at line X, column Y. Encountered: Z

A lexical error is a low-level parsing failure. Unlike a syntax error where the structure is wrong but the characters are individually valid, a lexical error means the parser cannot even form valid tokens from the input. The CSS specification defines a precise set of characters and sequences that are meaningful — property names, values, punctuation like ;, :, {, }, and so on. When the parser encounters something outside these expectations, such as @ where a ; should be, a curly ("smart") quote instead of a straight quote, or a stray Unicode character, it raises a lexical error.

This matters for several reasons. First, browsers handle invalid CSS unpredictably — some may skip the entire rule block, others may ignore only the broken declaration, and the behavior can vary across browser versions. This leads to inconsistent rendering for your users. Second, a single lexical error can cascade, causing the parser to misinterpret subsequent valid CSS as well, potentially breaking styles well beyond the offending line. Third, clean, valid CSS is easier to maintain, debug, and collaborate on.

Common causes of this error include:

Invalid characters used in place of punctuation — e.g., @, !, or # where a semicolon or colon should be.
Smart (curly) quotes — pasting CSS from word processors or CMS editors that convert "straight quotes" to "curly quotes" or 'curly apostrophes'.
Missing semicolons — while not always a lexical error, a missing ; can cause the next line's property name to be read as part of the previous value, producing unexpected character sequences.
Non-ASCII invisible characters — byte order marks (BOM), zero-width spaces, or non-breaking spaces that are invisible in most editors but invalid in CSS tokens.
Copy-paste artifacts — copying code from PDFs, websites, or chat applications that insert hidden formatting characters.

To fix the issue, go to the exact line and column the error references. Look at the character it reports as "Encountered" and determine what the correct character should be. If you can't see anything wrong, try deleting the characters around the reported position and retyping them manually — this eliminates invisible character problems.

Examples

Invalid character instead of semicolon

The @ symbol after blue is not valid CSS punctuation in this context:

<style>

h1{

color: blue@

font-size: 24px;

}

</style>

Replace @ with a proper semicolon:

<style>

h1{

color: blue;

font-size:24px;

}

</style>

Smart quotes in font-family

Curly quotes copied from a word processor cause a lexical error:

<style>

body{

font-family: \u201CHelvetica Neue\u201D,sans-serif;

}

</style>

Use straight double quotes instead:

<style>

body{

font-family:"Helvetica Neue", sans-serif;

}

</style>

Stray character in an inline style

An accidental backtick in a style attribute triggers the error:

<pstyle="color: red`;margin:0;">Hello</p>

Remove the invalid character:

<pstyle="color: red;margin:0;">Hello</p>

Invisible non-breaking space

Sometimes the error points to what looks like empty space. A non-breaking space (\u00A0) pasted from another source can hide between tokens:

<style>

.box{

display:\u00A0flex;

}

</style>

Delete the space and retype it as a normal ASCII space:

<style>

.box{

display: flex;

}

</style>

If you suspect invisible characters, use your text editor's "show whitespace" or "show invisible characters" feature, or paste the CSS into a hex editor to inspect the raw bytes. Configuring your editor to save files in UTF-8 without BOM also helps prevent encoding-related lexical errors.

CSS: “line-height”: X is not a “line-height” value.

The line-height CSS property controls the spacing between lines of text within an element. When the validator reports that a value "is not a line-height value," it means the value you provided doesn't match any of the accepted formats defined in the CSS specification.

Common mistakes that trigger this error include:

Misspelled keywords — writing norml or Normal instead of normal (CSS keywords are case-insensitive in browsers, but some validators may flag inconsistencies; the real issue is outright misspellings).
Invalid or missing units — using a unit the spec doesn't support (e.g., line-height: 1.5x;) or accidentally adding a unit to what should be a unitless value (e.g., confusing 1.5 with 1.5 em with a space).
Malformed numbers — typos like 1..5 or 24ppx.
Using unsupported keywords — values like auto, thin, or large are not valid for line-height.
Negative values — line-height does not accept negative numbers.

This matters for standards compliance and predictable rendering. While browsers may silently ignore an invalid line-height value and fall back to a default, this means your intended styling won't be applied — potentially causing overlapping text, poor readability, or inconsistent layouts across browsers. Fixing validation errors ensures your styles work as intended everywhere.

Valid `line-height` values

Format	Example	Description
Keyword	`normal`	Browser default (typically around 1.2)
Unitless number	`1.5`	Multiplied by the element's font size — recommended
Length	`24px`, `1.5em`, `2rem`	An absolute or relative length
Percentage	`150%`	Relative to the element's font size

The unitless number format is generally preferred because it scales properly with inherited font sizes, avoiding unexpected results in nested elements.

Examples

❌ Incorrect: invalid values that trigger the error

<pstyle="line-height: norml;">Text with an invalid line-height.</p>

<pstyle="line-height:1.5x;">Text with an unrecognized unit.</p>

<pstyle="line-height:1..5;">Text with a typo in the number.</p>

<pstyle="line-height: auto;">Auto is not valid for line-height.</p>

<pstyle="line-height:-1.5;">Negative values are not allowed.</p>

✅ Correct: valid `line-height` values

<pstyle="line-height: normal;">Browser default line height.</p>

<pstyle="line-height:1.5;">1.5 times the font size.</p>

<pstyle="line-height:24px;">Fixed 24px line height.</p>

<pstyle="line-height:1.5em;">1.5em line height.</p>

<pstyle="line-height:150%;">150% of the font size.</p>

Full document example

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Valid line-height Example</title>

</head>

<body>

<h1style="line-height:1.2;">A Heading with Tight Spacing</h1>

<pstyle="line-height:1.6;">This paragraph uses a unitless line-height of 1.6,

which is a common choice for body text readability. It scales correctly even

if child elements have different font sizes.</p>

</body>

</html>

Tip: unitless vs. percentage/length

A unitless line-height and a percentage line-height may look equivalent, but they behave differently with inherited styles. A unitless value is recalculated for each child element based on its own font size, while a percentage or length is computed once on the parent and that fixed value is inherited. For most cases, unitless numbers are the safest choice.

CSS: “margin-bottom”: “px” is not a “margin-bottom” value.

The W3C validator raises this error when it encounters a bare unit like px used as the value for margin-bottom without an accompanying number. In CSS, length values are always composed of two parts: a <number> and a <unit>. The token px alone is not a valid <length> value — it's just a unit identifier with no magnitude. This typically happens due to a typo, an accidental deletion of the numeric portion, or a templating/build tool that outputs an empty variable before the unit.

This matters for several reasons. First, browsers will discard the invalid declaration entirely, meaning margin-bottom will fall back to its default or inherited value — likely not what you intended. This can cause unexpected layout shifts across different pages or components. Second, invalid CSS can make debugging harder, since the silent failure may not be obvious until the layout breaks in a specific context. Third, clean, valid CSS is easier to maintain and signals code quality to collaborators.

How to fix it

Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
Use 0 without a unit if you want zero margin: margin-bottom: 0 is valid and preferred over margin-bottom: 0px.
Use a keyword value if appropriate: margin-bottom also accepts auto, inherit, initial, revert, and unset.
Check template variables: if you're using a preprocessor like Sass or a JavaScript framework that injects values, make sure the variable isn't empty or undefined before concatenation with the unit.

Examples

Incorrect: bare unit with no number

<divstyle="margin-bottom: px;">Content</div>

The value px is not a valid margin-bottom value. The browser will ignore this declaration.

Correct: numeric value with unit

<divstyle="margin-bottom:10px;">Content</div>

Correct: zero margin (no unit needed)

The same principle applies to any CSS property that expects a <length> value — always pair a number with its unit, or use 0 when no spacing is needed.

CSS: “margin-bottom”: “spacing(N)” is not a “margin-bottom” value.

CSS: “margin-left”: “px” is not a “margin-left” value.

CSS: “margin”: “px” is not a “margin” value.

css
margin

CSS: “margin-right”: “px” is not a “margin-right” value.

When you write margin-right: px, the browser cannot determine what margin to apply because px alone is not a recognized CSS value — it's just a unit suffix without a quantity. CSS length values are always a combination of a number and a unit (e.g., 10px, 1.5em, 20%), or a specific keyword like auto, inherit, or 0 (which doesn't require a unit). The lone px is meaningless on its own and will be ignored by browsers, which means your intended spacing won't be applied.

This issue typically arises in a few common scenarios:

A number was accidentally deleted during editing, leaving behind just the unit.
A CSS preprocessor variable or template expression failed to output a value, resulting in only the unit being rendered.
A typo or copy-paste error stripped the numeric portion.

Beyond simply not working, invalid CSS can cause unpredictable rendering differences across browsers. It also makes your code harder to maintain, as other developers may not understand the intended value.

To fix this, determine what numeric value you intended and place it directly before the px unit with no space between the number and unit. If no margin is needed, either remove the property entirely or set it to 0.

Examples

Incorrect: unit without a number

<divstyle="margin-right: px;">Content</div>

The validator reports that px is not a valid margin-right value because no number precedes the unit.

Fixed: complete value with number and unit

<divstyle="margin-right:10px;">Content</div>

Fixed: using zero (no unit required)

<divstyle="margin-right:0;">Content</div>

When the value is 0, no unit is needed since zero is the same in all units.

Fixed: using a keyword value

<divstyle="margin-right: auto;">Content</div>

The auto keyword is a valid value for margin-right and is commonly used for centering or pushing elements.

Watch for preprocessor or template issues

If you're using a CSS preprocessor or a templating language, make sure your variables resolve to complete values:

/* Incorrect — if $spacing is empty, this outputs "margin-right: px;" */

.sidebar{

margin-right: px;

}

/* Correct */

.sidebar{

margin-right:16px;

}

Other valid units

Any valid CSS length unit works, as long as a number precedes it:

<divstyle="margin-right:2em;">Em-based margin</div>

<divstyle="margin-right:5%;">Percentage-based margin</div>

<divstyle="margin-right:1.5rem;">Rem-based margin</div>

CSS: “margin”: Too many values or values are not recognized.

css
margin

The margin shorthand property sets the margin area on all four sides of an element. It accepts one to four values, where each value must be a valid CSS length (e.g., 10px, 1em, 0), a percentage, or the keyword auto. When the validator reports "Too many values or values are not recognized," it means either more than four values were supplied, or at least one of the values is something CSS doesn't understand — such as a misspelled unit, a missing unit on a non-zero number, or an invalid keyword.

Common causes of this error include:

Too many values: Providing five or more values (e.g., margin: 1px 2px 3px 4px 5px). The shorthand accepts a maximum of four.
Missing units: Writing a non-zero number without a unit (e.g., margin: 10 instead of margin: 10px). Only 0 is valid without a unit.
Typos or invalid units: Using a misspelled or nonexistent unit like margin: 10xp or margin: 10pixels.
Invalid keywords: Using a keyword that isn't recognized in the margin context (e.g., margin: none). The only non-global keyword margin accepts is auto.
Missing separators or extra characters: Including commas or other unexpected characters between values (e.g., margin: 10px, 20px). Values should be separated by spaces, not commas.

This matters because browsers may ignore or misinterpret an invalid margin declaration entirely, leading to broken or inconsistent layouts across different browsers. Writing valid CSS ensures predictable rendering and easier maintenance.

How `margin` shorthand values work

The number of values you provide determines how they are applied:

1 value: Applied to all four sides. margin: 10px → top, right, bottom, and left all get 10px.
2 values: First is top and bottom, second is left and right. margin: 10px 20px → top/bottom 10px, left/right 20px.
3 values: First is top, second is left and right, third is bottom. margin: 10px 20px 30px.
4 values: Applied clockwise — top, right, bottom, left. margin: 10px 20px 30px 40px.

Examples

❌ Too many values

/* Five values — invalid */

.box{

margin:10px20px30px40px50px;

}

❌ Missing unit on a non-zero number

.box{

margin:1020px;

}

❌ Invalid keyword

.box{

margin: none;

}

❌ Comma-separated values

.box{

margin:10px,20px;

}

✅ Correct: one to four valid values

/* All four sides */

.box{

margin:10px;

}

/* Top/bottom and left/right */

.box{

margin:10px20px;

}

/* Top, left/right, bottom */

.box{

margin:10px auto 20px;

}

/* Top, right, bottom, left */

.box{

margin:10px20px30px40px;

}

✅ Correct: using `auto` for centering

.container{

margin:0 auto;

}

✅ Correct: zero without a unit

.box{

margin:0;

}

✅ Correct: using global keywords

.box{

margin: inherit;

}

If you need to set margins on more than four sides independently (which isn't possible — elements only have four sides), you likely have a logic error. If you want fine-grained control, use the individual longhand properties (margin-top, margin-right, margin-bottom, margin-left) instead of the shorthand.

CSS: “margin-top”: “px” is not a “margin-top” value.

The margin-top property accepts several types of values: lengths (like 10px, 1.5em, 2rem), percentages (like 5%), the keyword auto, or the value 0. When you write margin-top: px, the browser encounters a bare unit with no associated number, which is meaningless — it doesn't know how many pixels you want. Browsers will ignore the invalid declaration entirely, which means margin-top will fall back to its default or inherited value. This can lead to unexpected layout results that may differ across browsers.

This error commonly happens due to a typo, an accidental deletion of the numeric portion, or a templating/build tool that failed to interpolate a variable (e.g., margin-top: ${value}px where value was empty). It can also occur when editing CSS quickly and removing the number while intending to change it.

Beyond just margin-top, this same principle applies to all CSS properties that accept length values — margin, padding, width, height, font-size, border-width, and many others. A bare unit without a number is never valid.

Note: The value 0 is the only numeric length that does not require a unit. Writing margin-top: 0 is perfectly valid and equivalent to margin-top: 0px.

How to fix it

Add the missing number before the unit. Determine the spacing you need and prepend it to the unit (e.g., 10px, 1.5em).
Use a valid keyword if you don't need a specific numeric value — auto or inherit, for example.
Check template variables if you use a preprocessor or templating system. Make sure the variable that provides the number is defined and not empty.

Examples

Incorrect: bare unit with no number

<divstyle="margin-top: px;">Content</div>

The validator reports that "px" is not a valid margin-top value because it lacks a numeric component.

Correct: number followed by a unit

<divstyle="margin-top:10px;">Content</div>

Correct: using zero without a unit

<divstyle="margin-top:0;">Content</div>

Correct: using a keyword value

<divstyle="margin-top: auto;">Content</div>

Incorrect in a stylesheet

<style>

.box{

margin-top: px;

}

</style>

<divclass="box">Content</div>

Correct in a stylesheet

<style>

.box{

margin-top:16px;

}

</style>

<divclass="box">Content</div>

Incorrect with CSS preprocessor output

If you use a preprocessor like Sass or a JavaScript framework, an undefined or empty variable can produce this error:

<divstyle="margin-top: px;">Content</div>

Ensure the variable has a valid numeric value so the rendered CSS is complete:

<divstyle="margin-top:20px;">Content</div>

CSS: “margin”: X is not a “margin” value.

css
margin

In CSS, property values such as lengths, percentages, and keywords are written without quotation marks. Quotes in CSS are reserved for specific contexts like content property strings, font family names with spaces, and url() paths. When you wrap a margin value (or any similar CSS property value) in double or single quotes, the CSS parser interprets it as a string literal rather than a set of length or keyword values. Since "0 0 1em 0" is a string and not a valid margin value, the declaration is ignored by browsers and flagged by the W3C validator.

This is a problem for several reasons. First, the style will silently fail — browsers discard CSS declarations they can't parse, so your intended margins won't be applied, potentially breaking your layout. Second, it indicates a misunderstanding of CSS syntax that could lead to similar errors in other properties. This mistake commonly occurs when developers confuse HTML attribute quoting rules with CSS value syntax, especially when writing inline style attributes where the attribute value itself is already quoted.

The margin property accepts one to four values, each of which can be a length (e.g., 10px, 1em), a percentage, auto, or a global keyword like inherit. None of these require quotes. The fix is straightforward: remove the quotation marks around the CSS value.

Examples

❌ Incorrect: margin value wrapped in quotes

In a <style> block:

<style>

.card{

margin:"0 0 1em 0";

}

</style>

In an inline style:

<pstyle="margin:'10px auto'">Hello</p>

Both of these produce the validator error because the CSS parser sees a quoted string instead of valid margin values.

✅ Correct: margin value without quotes

In a <style> block:

<style>

.card{

margin:001em0;

}

</style>

In an inline style:

<pstyle="margin: 10px auto">Hello</p>

Valid margin value formats

For reference, here are the accepted patterns for the margin property — none of which use quotes:

/* All four sides */

margin:1em;

/* Vertical | Horizontal */

margin:5% auto;

/* Top | Horizontal | Bottom */

margin:1em auto 2em;

/* Top | Right | Bottom | Left */

margin:2px1em0 auto;

/* Global keywords */

margin: inherit;

margin: initial;

margin: unset;

Watch out for inline style quoting confusion

A common source of this mistake is confusion about the quotes used for the HTML style attribute versus the CSS values inside it. The outer quotes delimit the attribute value for HTML — the CSS inside should not have its own quotes around property values:

<divstyle="margin:'1em'"></div>

<divstyle="margin: 1em"></div>

This same rule applies to other CSS properties like padding, border, font-size, color, and so on. If you see a similar validator error for any CSS property, check whether you've accidentally quoted the value.

CSS: “mask-image”: X is not a “mask-image” value.

The mask-image CSS property sets one or more mask layers for an element, controlling which parts are visible based on the mask's alpha channel or luminance. According to the CSS Masking specification, the property accepts a comma-separated list of mask references, where each individual value must be one of:

none — No mask layer is applied.
A <image> value — This includes url() references to image files (PNG, SVG, etc.) and CSS image functions like image().
A CSS gradient — Functions like linear-gradient(), radial-gradient(), conic-gradient(), and their repeating variants (repeating-linear-gradient(), etc.).

When the validator encounters a value that doesn't match any of these accepted forms, it flags the error. This matters because browsers will silently discard invalid mask-image declarations, meaning your intended masking effect won't apply, and the element will render as if no mask were set.

Common causes

Typos in gradient or function names are a frequent trigger. For example, writing linear-gradiant() instead of linear-gradient(), or radial-grad() instead of radial-gradient().

Bare image paths without url() will also cause this error. The value mask.png is not valid on its own — it must be wrapped as url('mask.png').

Unsupported keywords or arbitrary strings like mask-image: circle or mask-image: overlay are not valid. The only keyword mask-image accepts is none.

<divstyle="mask-image:radial-gradient(circle, black 50%, transparent 100%);">

Content here

</div>

Note that browser support for the unprefixed mask-image property has improved significantly, but some older browsers may still require the -webkit-mask-image prefix. When using the prefixed version, make sure to also include the standard property for forward compatibility. The W3C validator checks against the standard syntax, so always ensure your standard mask-image declaration uses valid values even if you also include prefixed versions.

CSS: “mask”: Too many values or values are not recognized.

css
mask

The mask CSS shorthand property allows you to hide parts of an element by masking or clipping it at specific points. It combines several longhand properties into one declaration: mask-image, mask-mode, mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and mask-composite.

Because mask is a shorthand that accepts values for many sub-properties, it's easy to trigger validation errors. Common causes include:

Too many values: Providing more values than the shorthand grammar allows, or duplicating values for the same sub-property.
Unrecognized values: Using vendor-specific values (like -webkit- prefixed keywords), typos, or values that belong to a different CSS property.
Incorrect value order: The shorthand has a specific grammar. For example, mask-size values must follow mask-position values and be separated by a /, similar to the background shorthand.
Mixing shorthand and longhand concepts: Trying to set values that aren't part of the mask shorthand grammar.

The formal syntax for a single mask layer is:

<mask-layer> = <mask-reference> || <position> [ / <bg-size> ]? || <repeat-style> ||

<geometry-box> || [ <geometry-box> | no-clip ] || <compositing-operator> ||

<masking-mode>

This is a problem for standards compliance because invalid CSS can lead to the entire declaration being ignored by browsers, causing your masking effect to silently fail. It also affects cross-browser compatibility — different browsers have varying levels of support for the mask shorthand, and using individual longhand properties is often more reliable.

To fix this issue:

Check each value in your mask declaration and ensure it's a valid value for one of the mask sub-properties.
Use longhand properties instead of the shorthand if you only need to set one or two aspects of the mask. This avoids ambiguity and improves readability.
Separate position and size with / if you're specifying both, e.g., center / contain.
Remove or separate vendor prefixes — use -webkit-mask for WebKit-specific syntax and the standard mask for standards-compliant syntax, but don't mix prefixed values into the unprefixed property.

mask-position: center;

mask-size: contain;

}

</style>

<divclass="masked">Content</div>

Using individual longhand properties avoids shorthand parsing issues entirely. Including the -webkit-mask-image prefix alongside the standard mask-image ensures broader browser support.

Incorrect: unrecognized value in the shorthand

<style>

.masked{

/* "luminance" is a mask-mode value but may not be recognized in the shorthand by all validators */

mask:url(mask.png) luminance;

}

</style>

<divclass="masked">Content</div>

Correct: using the longhand for mask mode

<style>

.masked{

mask-image:url(mask.png);

mask-mode: luminance;

}

</style>

<divclass="masked">Content</div>

When in doubt, splitting the mask shorthand into its individual longhand properties is the safest approach. It makes your intent explicit, avoids validation errors, and tends to have better cross-browser support.

CSS: “mask”: X is not a “mask” value.

CSS
mask

The mask CSS shorthand property allows you to partially or fully hide portions of an element by applying a graphical mask. It is a shorthand for several sub-properties including mask-image, mask-mode, mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and mask-composite. Because it's a shorthand, each value you provide must correspond to one of these sub-properties' accepted values. The validator triggers this error when it encounters a value that doesn't fit any of them — for example, an arbitrary keyword, a misspelled function name, or an unsupported syntax.

Common causes of this error include:

Arbitrary keywords — Using made-up names like star-shape or circle-mask that aren't valid CSS values.
Misspelled functions or keywords — Typos such as lnear-gradient() instead of linear-gradient(), or noen instead of none.
Browser-prefixed values without the standard value — Using -webkit-mask syntax or values that don't align with the standard mask property.
Invalid shorthand combinations — Providing sub-property values in an order or combination the shorthand doesn't accept.
Missing url() wrapper — Referencing an image file path directly without wrapping it in the url() function.

This matters for standards compliance because browsers may silently ignore invalid mask values, resulting in the mask not being applied at all. Your design could look completely different than intended, and the failure may be hard to debug without validation.

Valid `mask` values

The mask property accepts one or more comma-separated mask layers. Each layer can include:

none — No mask is applied.
url() — A reference to an SVG mask element or an image file (e.g., url(mask.svg), url(mask.png)).
CSS image functions — Such as linear-gradient(), radial-gradient(), conic-gradient(), image(), etc.
Geometry box keywords (for mask-clip / mask-origin) — Such as content-box, padding-box, border-box, fill-box, stroke-box, view-box.
Compositing keywords (for mask-composite) — Such as add, subtract, intersect, exclude.

Correct: using `none` to explicitly disable masking

<divstyle="mask: none;">

No Mask Applied

</div>

Correct: using a gradient as a mask

<divstyle="mask:linear-gradient(to right, transparent, black);">

Fading Content

</div>

Correct: combining multiple shorthand values

<divstyle="mask:url(mask.png) no-repeat center / contain;">

Masked Content

</div>

This sets the mask image, repeat behavior, position, and size in a single shorthand declaration.

Correct: multiple mask layers

<divstyle="mask:url(shape.svg) no-repeat,linear-gradient(to bottom, black, transparent);">

Multi-layer Mask

</div>

When fixing this error, double-check your value against the CSS Masking specification on MDN. If you're using vendor-prefixed versions like -webkit-mask, also ensure the standard mask property is present with valid values for forward compatibility.

CSS: “max-width”: “auto” is not a “max-width” value.

The max-width property sets the maximum width an element can grow to, preventing the computed value of width from exceeding the specified limit. While many CSS sizing properties accept auto as a value (for example, width: auto and margin: auto are perfectly valid), the max-width property does not. This is a common mistake because developers often assume auto is universally accepted across similar properties.

When a browser encounters max-width: auto, it will typically ignore the invalid declaration and fall back to the default value of none. While the page may still render as expected in some browsers, relying on this behavior is unreliable and non-standard. Writing valid CSS ensures consistent rendering across all browsers and makes your stylesheets easier to maintain and debug.

If your intent is to remove a maximum width constraint (effectively making max-width have no effect), use none — this is the default value. If you want the element to size itself based on its content, use max-content, min-content, or fit-content. If you need to reset the property to its initial value, use initial (which resolves to none).

Valid values for `max-width`

The max-width property accepts the following types of values:

none — No limit on the element's width (the default).
Length values — Such as 500px, 3.5em, 20rem, 80ch.
Percentage values — Such as 75%, relative to the containing block's width.
Keyword values — max-content, min-content, fit-content, or fit-content(<length>).
Global values — inherit, initial, revert, unset.

Examples

❌ Incorrect: using `auto` with `max-width`

<divstyle="max-width: auto;">

This container has an invalid max-width value.

</div>

This triggers the validation error because auto is not a valid max-width value.

✅ Fixed: using `none` to remove the constraint

If you want no maximum width limit (the most likely intent when writing auto), use none:

<divstyle="max-width: none;">

This container has no maximum width constraint.

</div>

✅ Fixed: using a specific length or percentage

If you want to cap the element's width at a specific size:

<divstyle="max-width:600px;">

This container will not grow beyond 600 pixels.

</div>

<divstyle="max-width:80%;">

This container will not exceed 80% of its parent's width.

</div>

✅ Fixed: using intrinsic sizing keywords

If you want the element's maximum width to be based on its content:

<divstyle="max-width: max-content;">

This container's max width is determined by its content.

</div>

CSS: “min-height”: Too many values or values are not recognized.

The min-height property sets the minimum height of an element. Unlike shorthand properties such as margin or padding, min-height accepts only a single value. Providing multiple space-separated values (e.g., min-height: 100px 200px) is invalid and will trigger this error.

This error commonly occurs for several reasons:

Multiple values provided: min-height is not a shorthand and does not accept more than one value.
Invalid units or typos: Using an unrecognized unit (e.g., 100pixels instead of 100px) or a misspelled keyword.
Using unsupported CSS functions or syntax: Some newer CSS features like min-height: fit-content(200px) may not be recognized by the validator or may lack browser support.
Confusing min-height with other properties: Accidentally using syntax meant for properties like grid-template-rows or minmax() expressions.
Missing units on non-zero values: Writing min-height: 100 instead of min-height: 100px. Zero is the only numeric value that doesn't require a unit.

According to the CSS specification, valid values for min-height include:

Value Type	Examples
Length	`0`, `100px`, `10em`, `5rem`, `50vh`
Percentage	`50%`, `100%`
Keywords	`auto`, `min-content`, `max-content`, `none`
Functions	`fit-content`, `calc(100vh - 50px)`

Fixing this issue ensures your CSS is standards-compliant and behaves predictably across browsers. Invalid min-height values will be ignored by browsers, which means your layout may not render as intended.

Examples

Incorrect: multiple values

<divstyle="min-height:100px200px;">Content</div>

min-height only accepts a single value. This is not a shorthand property.

Incorrect: missing unit

<divstyle="min-height:100;">Content</div>

Non-zero numeric values must include a unit.

Incorrect: invalid keyword or typo

<divstyle="min-height: inheret;">Content</div>

The keyword inherit is misspelled.

Correct: single length value

<divstyle="min-height:100px;">Content</div>

Correct: percentage value

<divstyle="min-height:50%;">Content</div>

Correct: using `calc()` for computed values

<divstyle="min-height:calc(100vh-80px);">Content</div>

Correct: using a keyword

<divstyle="min-height: min-content;">Content</div>

Correct: using `auto`

<divstyle="min-height: auto;">Content</div>

If you need to set both a minimum and maximum height on an element, use min-height and max-height as separate properties:

<divstyle="min-height:100px;max-height:400px;">Content</div>

CSS: “mso-X”: Property “mso-X” doesn't exist.

These mso- prefixed properties are most commonly introduced when content is copied and pasted from Microsoft Word or other Office applications into an HTML editor. Microsoft Office generates heavily styled HTML with dozens of proprietary CSS properties designed to preserve the document's formatting when rendered back in Office products. While browsers silently ignore these unknown properties, they clutter your markup, inflate file size, and violate web standards.

This is a problem for several reasons. First, these properties have no effect in any web browser — they are purely artifacts of Microsoft's internal rendering engine. Second, they significantly bloat your HTML, sometimes doubling or tripling the size of the markup. Third, they make your code harder to read and maintain. Fourth, they can cause issues with automated tools, linters, and content management systems that expect valid CSS. Finally, in the context of HTML email development, while mso- properties are sometimes intentionally used to target Microsoft Outlook's rendering engine, they should not appear in web pages intended for browsers.

How to Fix

Identify the source. Check if the content was pasted from Microsoft Word or another Office application. This is the most common origin.
Remove all mso- properties. Delete every CSS declaration that starts with mso-. They serve no purpose in a browser context.
Replace with standard CSS if needed. Some mso- properties have standard CSS equivalents. For example, mso-margin-top-alt can be replaced with margin-top, and mso-bidi-font-weight can be replaced with font-weight.
Use a paste-as-plain-text workflow. When copying from Word, paste as plain text first (Ctrl+Shift+V in many editors), then apply formatting using your own CSS.

Examples

❌ Incorrect: HTML with Microsoft Office properties

<pstyle="mso-spacerun: yes;mso-fareast-font-family:'Times New Roman';margin-bottom:.0001pt;mso-margin-bottom-alt: auto;mso-margin-top-alt: auto;mso-bidi-font-weight: bold;line-height: normal;">

This text was pasted from Microsoft Word.

</p>

<style>

.content{

mso-fareast-font-family:"Calibri";

mso-bidi-font-family:"Times New Roman";

font-family: Arial, sans-serif;

mso-line-height-rule: exactly;

line-height:1.5;

}

</style>

✅ Correct: Cleaned-up HTML with only standard CSS

<pstyle="margin-bottom:0;margin-top: auto;font-weight: bold;line-height: normal;">

This text was pasted from Microsoft Word.

</p>

<style>

.content{

font-family: Arial, sans-serif;

line-height:1.5;

}

</style>

Common `mso-` properties and their standard replacements

`mso-` Property	Standard CSS Equivalent
`mso-margin-top-alt`	`margin-top`
`mso-margin-bottom-alt`	`margin-bottom`
`mso-bidi-font-weight`	`font-weight`
`mso-bidi-font-style`	`font-style`
`mso-bidi-font-size`	`font-size`
`mso-fareast-font-family`	`font-family` (use a standard font stack)
`mso-line-height-rule`	No equivalent needed — remove it
`mso-spacerun`	No equivalent needed — remove it
`mso-tab-count`	No equivalent needed — remove it

Many mso- properties (like mso-spacerun and mso-tab-count) control behaviors specific to Microsoft's rendering engine and have no CSS equivalent at all. These can simply be deleted without any replacement. If your content originally came from Word, it's often best to strip all formatting and restyle the content from scratch using your own clean CSS.

CSS: “padding-block”: “auto” is not a “padding-block” value.

The padding-block shorthand property sets padding on the block-start and block-end sides of an element. In horizontal writing modes (like English), this corresponds to the top and bottom padding; in vertical writing modes, it maps to left and right. It's the logical equivalent of combining padding-block-start and padding-block-end.

The reason auto is invalid here is that padding, by definition in the CSS specification, must resolve to a definite size. Margins can be auto because the browser uses that value in layout algorithms to distribute remaining space (e.g., centering a block element with margin-inline: auto). Padding, however, adds space inside an element's border and has no such auto-distribution behavior defined in the spec. Attempting to use auto will cause the declaration to be ignored by browsers, meaning no padding is applied, which can lead to unexpected layout results.

This validation error often arises when developers confuse padding-block with margin-block, or when they copy centering patterns that work with margins and try to apply them to padding. If your intent was to center content, consider using margin-block: auto instead, or use Flexbox/Grid alignment properties.

How to Fix

Replace auto with a valid value:

Length values: 0, 10px, 1em, 1.5rem, etc.
Percentage values: 5%, 2% 1%, etc. (relative to the inline size of the containing block).
Two values: padding-block: 20px 10px; sets padding-block-start to 20px and padding-block-end to 10px.
CSS-wide keywords: inherit, initial, revert, revert-layer, or unset.

Correct: removing padding with zero

<style>

.box{

padding-block:0;

}

</style>

<divclass="box">No block padding.</div>

If you intended to center: use margin-block instead

<style>

.container{

display: flex;

flex-direction: column;

height:300px;

}

.centered{

margin-block: auto;

}

</style>

<divclass="container">

<divclass="centered">This element is vertically centered using margin-block: auto.</div>

</div>

The margin-block: auto approach works inside flex or grid containers to distribute space evenly, achieving vertical centering. This is likely what you want if you originally reached for padding-block: auto.

CSS: “padding-bottom”: “px” is not a “padding-bottom” value.

The padding-bottom property defines the amount of space between an element's content and its bottom border. Like all CSS length properties, it expects a length value — a number paired with a unit such as px, em, rem, %, vh, etc. The lone string px is just a unit identifier with no magnitude, so CSS parsers cannot interpret it as a meaningful measurement. This typically happens when a numeric value is accidentally deleted during editing, when a CSS preprocessor or template engine outputs an empty variable before the unit, or when code is manually written with a typo.

When the browser encounters an invalid value like padding-bottom: px, it discards the entire declaration and falls back to the default or inherited value. This can lead to unexpected layout shifts, where the spacing looks correct in one browser but breaks in another depending on how defaults are applied. Fixing these errors ensures consistent rendering across browsers and keeps your stylesheets standards-compliant.

How to fix it

Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
Use 0 without a unit if you want zero padding — writing padding-bottom: 0 is valid and preferred over 0px.
Check template variables — if you're using a preprocessor like Sass or a templating engine, make sure the variable that generates the number is not empty or undefined.
Remove the declaration entirely if padding-bottom is not needed, rather than leaving a broken value in place.

Examples

Incorrect: unit without a number

<divstyle="padding-bottom: px;">Content</div>

The value px alone is not valid because there is no number specifying the amount of padding.

Correct: numeric value with a unit

<divstyle="padding-bottom:10px;">Content</div>

Correct: zero padding (no unit needed)

<divstyle="padding-bottom:0;">Content</div>

Incorrect in an external stylesheet

.card{

padding-bottom: px;

}

Correct in an external stylesheet

.card{

padding-bottom:16px;

}

Common preprocessor pitfall

In Sass or similar tools, this issue often arises from an empty or undefined variable:

$spacing:null;

.card{

padding-bottom:#{$spacing}px;// Outputs "padding-bottom: px;" if $spacing is empty

}

The fix is to ensure the variable holds a valid number, or provide a fallback:

$spacing:16;

.card{

padding-bottom:#{$spacing}px;// Outputs "padding-bottom: 16px;"

}

Even better, include the unit in the variable itself to avoid concatenation issues:

$spacing:16px;

.card{

padding-bottom: $spacing;

}

CSS: “padding-bottom”: X is not a “padding-bottom” value.

HTML example with the issue

Fixed example

Examples

Incorrect: @import after a style rule

Incorrect: @import after another at-rule

Correct: @import rules first

Correct: Multiple @import rules with @charset

Alternatives to @import

Invalid ID selector

Fixed: Use a valid identifier

Examples

Missing unit (triggers the error)

Typo in unit (triggers the error)

Fixed with a valid length unit

Fixed with a percentage

Fixed with the auto keyword

Fixed with calc()

Zero without a unit (valid)

Examples

Invalid: Using an unsupported keyword

Invalid: Missing unit on a non-zero number

Invalid: Misspelled unit

Valid: Using a length value

Valid: Using a percentage

Valid: Using the auto keyword

Valid: Using zero without a unit

Valid: Using inherit

How to Fix It

Examples

❌ Invalid: NaN concatenated with a unit

✅ Fixed: Validate the value before applying it

✅ Fixed: Using a static CSS value

✅ Fixed: Server-side template with a guard

Valid letter-spacing values for reference

Examples

Invalid character instead of semicolon

Smart quotes in font-family

Stray character in an inline style

Invisible non-breaking space

Valid line-height values

Examples

❌ Incorrect: invalid values that trigger the error

✅ Correct: valid line-height values

Full document example

Tip: unitless vs. percentage/length

How to fix it

Examples

Incorrect: bare unit with no number

Correct: numeric value with unit

Correct: zero margin (no unit needed)

Correct: using a keyword value

Incorrect in a stylesheet

Fixed stylesheet

Watch out for preprocessor issues

How to Fix

Valid values for margin-left

Examples

Incorrect: unit with no number

Correct: number with a unit

Correct: zero margin (no unit needed)

Incorrect: empty variable in a template

Correct: using CSS custom properties with a fallback

Correct: in an external stylesheet

Quick checklist

How to Fix It

Examples

Incorrect: Unit Without a Number

Correct: Number Paired With Unit

Correct: Zero Margin (No Unit Needed)

Correct: Using a Keyword

Incorrect in an External Stylesheet

Correct in an External Stylesheet

Watch Out for Template Variables

Examples

Incorrect: unit without a number

Fixed: complete value with number and unit

Fixed: using zero (no unit required)

Fixed: using a keyword value

Watch for preprocessor or template issues

Incorrect: `@import` after a style rule

Incorrect: `@import` after another at-rule

Correct: `@import` rules first

Correct: Multiple `@import` rules with `@charset`

Alternatives to `@import`

Fixed with the `auto` keyword

Fixed with `calc()`

Valid: Using the `auto` keyword

Valid: Using `inherit`

❌ Invalid: `NaN` concatenated with a unit

Valid `letter-spacing` values for reference

Valid `line-height` values

✅ Correct: valid `line-height` values

Valid values for `margin-left`

How `margin` shorthand values work

✅ Correct: using `auto` for centering

Incorrect: bare image path without `url()`

Correct: image path wrapped in `url()`

Incorrect: missing `to` keyword in gradient direction

Correct: direction uses the `to` keyword

Correct: using `none` to explicitly disable masking

Valid `mask` values

Incorrect: missing `url()` function

Correct: using `url()` to reference a mask image

Correct: using `none` to explicitly disable masking

Valid values for `max-width`

❌ Incorrect: using `auto` with `max-width`

✅ Fixed: using `none` to remove the constraint

Correct: using `calc()` for computed values

Correct: using `auto`