HTML Guides

The revert keyword is one of the CSS-wide keywords defined in the CSS Cascading and Inheritance specification (along with initial, inherit, and unset). These keywords are valid values for every CSS property. When applied, revert rolls back the cascade to the value the property would have had if no author-level styles were applied — effectively reverting to the browser's default stylesheet (or the user stylesheet, if one exists).

Older versions of the Nu HTML Checker (the engine behind the W3C HTML Validator) did not fully recognize revert as a valid CSS-wide keyword for all properties, which caused this false positive. This has been fixed in newer versions of the validator. If you're using a local or outdated instance of the validator, updating to the latest version should resolve the issue.

Since this is a validator bug rather than a code issue, you have a few options: ignore the warning, update your validator, or use an alternative approach if you need a clean validation report. For example, you could use unset instead, which behaves similarly in many cases (though not identically — unset reverts to the inherited or initial value, while revert reverts to the user-agent default).

Examples

Code that triggers the false positive

This inline style uses revert on font-size, which is perfectly valid CSS but may trigger the validator warning:

<p style="font-size: revert;">This paragraph uses the browser's default font size.</p>

Workaround using unset

If you need to pass validation on an older validator instance, unset can serve as a partial substitute. Note that unset behaves differently from revert — it resets to the inherited value (for inherited properties like font-size) rather than the user-agent default:

<p style="font-size: unset;">This paragraph inherits the font size from its parent.</p>

Using revert in a stylesheet

The revert keyword is especially useful when you want to undo author styles for specific elements. This is valid CSS and should not produce errors in up-to-date validators:

<style>

p {

font-size: 2rem;

}

.default-size {

font-size: revert;

}

</style>

<p>This paragraph has a 2rem font size.</p>

<p class="default-size">This paragraph reverts to the browser default font size.</p>

All CSS-wide keywords

For reference, all of these CSS-wide keywords are valid for font-size and every other CSS property:

<div style="font-size: initial;">Uses the property's initial value</div>

<div style="font-size: inherit;">Inherits from the parent element</div>

<div style="font-size: unset;">Resets to inherited or initial value</div>

<div style="font-size: revert;">Reverts to the user-agent default</div>

<div style="font-size: revert-layer;">Reverts to the previous cascade layer</div>

The font-size property defines the size of text in CSS and accepts a specific set of value types. When the W3C validator reports that a value "is not a font-size value," it means the value you provided doesn't match any of the accepted formats. Browsers may attempt to ignore or guess what you meant, but this leads to unpredictable rendering across different browsers and devices.

This error commonly occurs for a few reasons:

• Missing units on numeric values. Writing font-size: 16 instead of font-size: 16px. In CSS, unitless numbers (other than 0) are not valid lengths.
• Typos in units or keywords. For example, font-size: 16xp, font-size: 1.2erm, or font-size: lage.
• Using values from the wrong property. For example, font-size: bold (which belongs to font-weight) or font-size: center.
• Invalid or unsupported syntax. For example, font-size: 16 px (with a space between the number and unit) or font-size: auto (which is not valid for this property).

Valid font-size value types

Examples

Incorrect: missing unit on a number

<p style="font-size: 16;">This triggers a validation error.</p>

The value 16 is not valid because it lacks a CSS unit. Browsers may ignore this declaration entirely, leaving the text at its default or inherited size.

Correct: number with a valid unit

<p style="font-size: 16px;">This text has a valid font size.</p>

Incorrect: typo in the unit

<p style="font-size: 1.2erm;">Typo in the unit.</p>

Correct: proper em unit

<p style="font-size: 1.2em;">Correct em unit.</p>

Incorrect: value from the wrong property

<p style="font-size: bold;">Bold is not a font-size value.</p>

Correct: using a valid keyword

<p style="font-size: large;">Using a valid size keyword.</p>

Incorrect: space between number and unit

<p style="font-size: 16 px;">Space before the unit is invalid.</p>

Correct: no space between number and unit

<p style="font-size: 16px;">No space between number and unit.</p>

Full document example

<!DOCTYPE html>

<html lang="en">

<head>

<title>Font Size Example</title>

<style>

.heading {

font-size: 2rem;

}

.body-text {

font-size: 1em;

}

.small-print {

font-size: 80%;

}

.responsive {

font-size: clamp(1rem, 2.5vw, 2rem);

}

</style>

</head>

<body>

<h1 class="heading">Valid heading size</h1>

<p class="body-text">Body text at 1em.</p>

<p class="small-print">Small print at 80%.</p>

<p class="responsive">Responsive text using clamp().</p>

</body>

</html>

To resolve this validation error, review every font-size declaration in your CSS or inline styles. Make sure each value is either a recognized keyword, a number immediately followed by a valid unit, a percentage, or a supported CSS function like calc(). If you intended 0, that is the one numeric value that does not require a unit — font-size: 0 is valid, though rarely useful in practice.

The font-stretch property selects a normal, condensed, or expanded face from a font family. Its valid keyword values are ultra-condensed, extra-condensed, condensed, semi-condensed, normal, semi-expanded, expanded, extra-expanded, and ultra-expanded. It also accepts percentage values (e.g., 50% to 200%). The value bold doesn't fit into any of these categories because it describes font weight (thickness of strokes), not font width (how narrow or wide the characters are).

This error usually happens due to one of two mistakes:

1. Confusing font-stretch with font-weight: You intended to make text bold but accidentally used the wrong property.
2. Typo or copy-paste error in the font shorthand: When writing shorthand font declarations, the various sub-properties can easily get mixed up.

The W3C validator flags this because browsers will ignore invalid CSS values, meaning your intended styling won't be applied. Fixing it ensures your styles work as expected across all browsers and pass validation.

How to Fix It

• If you want bold text, use font-weight: bold (or numeric values like 700).
• If you want wider or narrower characters, use font-stretch with a valid value like condensed or expanded.
• If you need both, apply each property separately or use the font shorthand correctly.

Examples

Incorrect: Using bold with font-stretch

This triggers the validation error because bold is not a valid font-stretch value:

<p style="font-stretch: bold;">This text won't render as expected.</p>

Fixed: Using font-weight for boldness

If the intent was to make the text bold, switch to font-weight:

<p style="font-weight: bold;">This text is bold.</p>

Fixed: Using font-stretch correctly for width

If the intent was to adjust the character width, use a valid font-stretch value:

<p style="font-stretch: expanded;">This text uses an expanded font face.</p>

Using both properties together

You can combine font-weight and font-stretch when you need both bold text and a different font width:

<style>

.styled-text {

font-weight: bold;

font-stretch: condensed;

font-family: Arial, sans-serif;

}

</style>

<p class="styled-text">This text is bold and condensed.</p>

Valid font-stretch values reference

Here's a quick overview of all valid keyword values for font-stretch:

<style>

.condensed { font-stretch: condensed; }

.normal-width { font-stretch: normal; }

.expanded { font-stretch: expanded; }

.custom-width { font-stretch: 75%; }

</style>

<p class="condensed">Condensed text</p>

<p class="normal-width">Normal width text</p>

<p class="expanded">Expanded text</p>

<p class="custom-width">75% width text</p>

Note that font-stretch only works if the selected font family includes condensed or expanded faces. If the font doesn't have these variations, the property will have no visible effect even with valid values.

The font-style and font-weight properties serve different purposes. font-style controls whether text appears in a normal, italic, or oblique style, while font-weight controls how thick or thin the characters are rendered. Writing font-style: bold is a mistake because bold is not among the accepted values for font-style. Browsers will ignore the invalid declaration entirely, meaning your text won't become bold at all — it will simply render in the default weight.

This error typically comes from confusing the two properties or misremembering which property handles boldness. The valid values for each property are:

• font-style: normal, italic, oblique, or oblique with an angle (e.g., oblique 10deg)
• font-weight: normal, bold, bolder, lighter, or numeric values from 100 to 900

To fix this issue, replace font-style: bold with font-weight: bold. If you intended to make text both bold and italic, you'll need to use both properties separately.

Examples

Incorrect — using bold with font-style

This triggers the validation error because bold is not a valid font-style value:

<p style="font-style: bold;">This text won't actually be bold.</p>

Correct — using font-weight for boldness

Move the bold value to the font-weight property:

<p style="font-weight: bold;">This text is bold.</p>

Correct — combining bold and italic

If you want text that is both bold and italic, use both properties:

<p style="font-weight: bold; font-style: italic;">This text is bold and italic.</p>

Correct — using font-weight in a stylesheet

You can also apply bold styling through a <style> block or external stylesheet, using either keyword or numeric values:

<style>

.emphasis {

font-weight: bold;

}

.light {

font-weight: 300;

}

.heavy {

font-weight: 900;

}

</style>

<p class="emphasis">This text is bold (weight 700).</p>

<p class="light">This text is light (weight 300).</p>

<p class="heavy">This text is extra heavy (weight 900).</p>

Note that the keyword bold is equivalent to the numeric value 700, and normal is equivalent to 400. Numeric values give you finer control over text weight, especially when using variable fonts or font families that offer multiple weight variations.

The font-style CSS property controls whether text is displayed in a normal, italic, or oblique face from its font-family. It has a limited set of accepted values, and the W3C validator will flag any value that falls outside this set.

This error commonly occurs for a few reasons:

• Confusing font-style with font-size: Since both properties start with font-, it's easy to accidentally type font-style: 1.2em when you meant font-size: 1.2em. Numeric and length values are not valid for font-style.
• Confusing font-style with font-weight: Writing font-style: bold is invalid because bold is a font-weight value, not a font-style value.
• Typos in keyword values: Misspelling a valid keyword, such as font-style: itallic or font-style: oblque, will trigger this error.
• Using the oblique angle syntax incorrectly: While oblique can accept an optional angle (e.g., oblique 10deg), providing an angle without the oblique keyword or using an invalid unit will cause a validation error.

Using invalid CSS values can lead to unpredictable rendering across browsers. Most browsers will ignore the entire declaration when they encounter an invalid value, meaning your intended styling won't be applied at all. Keeping your CSS valid ensures consistent behavior and makes debugging easier.

Valid font-style values

The accepted values for font-style are:

• normal — displays the normal face of the font family.
• italic — selects the italic face; falls back to oblique if unavailable.
• oblique — selects the oblique face; optionally accepts an angle value (e.g., oblique 10deg). The angle defaults to 14deg if omitted.
• Global CSS values: inherit, initial, revert, revert-layer, unset.

Examples

Incorrect: size value applied to font-style

This is the most common mistake — using a length value that belongs on font-size:

<p style="font-style: 1.2em;">This text has an invalid font-style.</p>

Correct: use font-size for size values

<p style="font-size: 1.2em;">This text has a valid font size.</p>

Incorrect: using bold with font-style

<p style="font-style: bold;">This text has an invalid font-style.</p>

Correct: use font-weight for boldness

<p style="font-weight: bold;">This text is bold.</p>

Incorrect: misspelled keyword

<p style="font-style: itallic;">This text has a typo in font-style.</p>

Correct: properly spelled keyword

<p style="font-style: italic;">This text is italic.</p>

Correct: using oblique with an angle

<p style="font-style: oblique 12deg;">This text is oblique at 12 degrees.</p>

Quick reference for commonly confused properties

If you're unsure which property to use, here's a quick guide:

The font-weight property controls the boldness or thickness of text characters. Unlike many other CSS properties, it does not accept length units such as px, em, or %. Instead, it uses a specific set of keywords or unitless numeric values to indicate the desired weight. Supplying an unrecognized value causes the declaration to be ignored by the browser, meaning your intended styling won't be applied, and the text will fall back to the inherited or default weight.

The accepted values for font-weight are:

• Keywords: normal (equivalent to 400), bold (equivalent to 700), bolder (relative, one step heavier than the parent), lighter (relative, one step lighter than the parent).
• Numeric values: Any number from 1 to 1000. Historically only multiples of 100 (100 through 900) were valid, but the CSS Fonts Level 4 specification expanded this to any value in the 1–1000 range. Note that many validators and older browsers may still only recognize the 100–900 multiples.

This matters for standards compliance and predictable rendering. An invalid font-weight value is silently discarded by browsers, which can lead to confusing visual results — especially when you expect a specific weight from a variable font or a multi-weight font family.

To fix this issue, identify the invalid value in your CSS and replace it with one of the accepted values listed above. If you were using a pixel or other unit value, simply remove the unit and choose an appropriate numeric weight. If you used a misspelled keyword (e.g., bolded or heavy), replace it with the correct keyword.

Examples

Incorrect: using a length unit

p {

font-weight: 20px;

}

The validator reports this because 20px is not a valid font-weight value. The property does not accept length units.

Incorrect: using an invalid keyword

h2 {

font-weight: heavy;

}

The keyword heavy is not recognized by the CSS specification for font-weight.

Correct: using valid numeric values

p {

font-weight: 300;

}

h2 {

font-weight: 700;

}

Correct: using valid keywords

p {

font-weight: lighter;

}

h2 {

font-weight: bold;

}

Full HTML example

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="UTF-8">

<meta name="viewport" content="width=device-width, initial-scale=1.0">

<title>Font Weight Example</title>

<style>

.light {

font-weight: 300;

}

.regular {

font-weight: normal;

}

.semi-bold {

font-weight: 600;

}

.bold {

font-weight: bold;

}

</style>

</head>

<body>

<p class="light">This text uses a light font weight (300).</p>

<p class="regular">This text uses a normal font weight (400).</p>

<p class="semi-bold">This text uses a semi-bold font weight (600).</p>

<p class="bold">This text uses a bold font weight (700).</p>

</body>

</html>

Quick reference of common numeric weights

Keep in mind that the actual visual effect of a numeric weight depends on whether the loaded font family provides a matching weight. If a font only includes 400 and 700 weights, the browser will map other values to the nearest available weight.

The CSS font shorthand property has a specific syntax defined in the CSS specification. At minimum, it requires both a font-size and a font-family value. Optionally, you can prepend font-style, font-variant, and font-weight, and you can append a line-height value after the font-size using a slash separator. The full syntax looks like this:

font: [font-style] [font-variant] [font-weight] font-size[/line-height] font-family;

When the W3C validator reports that a value "is not a font-family value," it means the parser reached a point in the font declaration where it expected to find a font family name but instead found something it couldn't interpret as one. This often happens in two scenarios:

1. Using font when you meant a specific property — For example, writing font: 300 when you only intended to set the font weight. The validator tries to parse 300 as a complete font value, and since there's no font-size or font-family, it fails.
2. Incomplete font shorthand — Providing some values but forgetting the mandatory font-family at the end, such as font: 300 16px without a family name.

This matters because browsers may ignore an invalid font declaration entirely, causing your text to render with default or inherited styles instead of what you intended. Keeping your CSS valid also ensures consistent behavior across different browsers and helps maintain clean, predictable stylesheets.

How to fix it:

• If you only need to set a single font-related property, use the specific property (font-weight, font-size, font-style, font-variant, or font-family) instead of the font shorthand.
• If you want to use the font shorthand, make sure you include at least font-size and font-family, and that all values appear in the correct order.
• Remember that the font shorthand resets any omitted font sub-properties to their initial values, so use it deliberately.

Examples

Incorrect: Using font to set only the weight

<p style="font: 300;">This text has an invalid font declaration.</p>

The validator reports that 300 is not a valid font-family value because the font shorthand expects at least a font-size and font-family.

Correct: Using font-weight directly

<p style="font-weight: 300;">This text has a light font weight.</p>

Incorrect: Missing font-family in the shorthand

<p style="font: italic 300 16px;">This is also invalid.</p>

Even though font-style, font-weight, and font-size are all present, the required font-family is missing.

Correct: Complete font shorthand

<p style="font: italic 300 16px/1.5 'Helvetica', sans-serif;">This is valid.</p>

This includes all components in the correct order: font-style, font-weight, font-size/line-height, and font-family.

Correct: Minimal valid font shorthand

<p style="font: 16px sans-serif;">Only size and family — the minimum required.</p>

Correct: Using individual properties instead of the shorthand

<p style="font-style: italic; font-weight: 300; font-size: 16px; line-height: 1.5; font-family: 'Helvetica', sans-serif;">

Each property set individually.

</p>

Using individual properties avoids the pitfalls of the shorthand and gives you explicit control without accidentally resetting other font sub-properties.

The gap property is a shorthand for row-gap and column-gap, used in CSS Grid, Flexbox, and multi-column layouts to define spacing between items or tracks. According to the CSS Box Alignment specification, the accepted values for gap are length values (px, em, rem, %, vh, etc.), the normal keyword, or the calc() function. The keyword auto — while valid for many other CSS properties like margin, width, and grid-template-columns — is simply not part of the gap property's value grammar.

This confusion often arises because developers are accustomed to using auto for spacing in other contexts. For instance, margin: auto is a common centering technique, and auto is widely used in grid track sizing. However, the gap property serves a different purpose: it defines a fixed or computed gutter size between items, and auto has no defined meaning in that context.

Why this matters

• Standards compliance: Using an invalid value means the browser will ignore the entire gap declaration, falling back to the default value of normal (which is typically 0px in Grid and Flexbox). This can lead to unexpected layout results where items have no spacing at all.
• Cross-browser consistency: While some browsers may be lenient with invalid CSS values, others will strictly discard them. This creates inconsistent layouts across different browsers and versions.
• Maintainability: Invalid CSS values can mask the developer's intent, making it harder for others (or your future self) to understand what spacing was desired.

How to fix it

Replace auto with a valid value for gap:

• A specific length: gap: 16px;, gap: 1rem;, gap: 0.5em;
• A percentage: gap: 2%;
• The normal keyword: gap: normal; (resolves to 0px in Flexbox and Grid)
• A calc() expression: gap: calc(1rem + 4px);
• Two values for row and column separately: gap: 16px 24px;

If you were using auto because you wanted the browser to determine the spacing dynamically, consider using a percentage value, a viewport-relative unit (vw, vh), or CSS clamp() for responsive gutters.

Examples

Incorrect: using auto as a gap value

<div style="display: grid; grid-template-columns: 1fr 1fr; gap: auto;">

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

This triggers the validation error because auto is not a valid gap value. The browser will discard the declaration entirely.

Correct: using a fixed length

<div style="display: grid; grid-template-columns: 1fr 1fr; gap: 16px;">

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

Correct: using separate row and column gaps

<div style="display: grid; grid-template-columns: 1fr 1fr; gap: 12px 24px;">

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

Correct: using a percentage for responsive spacing

<div style="display: flex; flex-wrap: wrap; gap: 2%;">

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

</div>

Correct: using clamp() for fluid responsive gaps

<div style="display: grid; grid-template-columns: 1fr 1fr; gap: clamp(8px, 2vw, 32px);">

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

This approach gives you a gap that scales with the viewport width, bounded between 8px and 32px — a useful alternative if you were reaching for auto to get flexible spacing behavior.

The grid-column property is a shorthand for grid-column-start and grid-column-end. It defines where a grid item is placed horizontally within a CSS Grid layout. The validator checks that inline style attributes and <style> blocks contain valid CSS, and it will flag any value that doesn't conform to the property's grammar.

Why This Happens

Several kinds of invalid values can trigger this error:

• Using 0 as a line number. CSS Grid lines are 1-indexed. Line 0 does not exist, so values like grid-column: 0, grid-column: 0 / 3, or grid-column: span 0 are all invalid.
• Typos or unrecognized keywords. Values like grid-column: center or grid-column: full are not valid unless they match named grid lines you've explicitly defined.
• Malformed shorthand syntax. Missing the / separator, using commas instead, or providing too many values will cause a parse error.
• Using span incorrectly. The span keyword must be followed by a positive integer or a named line, e.g., span 2. Writing span -1 or span 0 is invalid.

Valid Syntax

The grid-column shorthand accepts:

grid-column: <grid-line> / <grid-line>;

Each <grid-line> can be:

• A positive or negative integer (but not 0) representing a grid line number
• A named grid line (e.g., content-start)
• The span keyword followed by a positive integer or a name (e.g., span 2)
• auto

If only one value is provided (no /), the end line defaults to auto.

Why It Matters

Invalid CSS values are ignored by browsers, meaning the grid item will fall back to automatic placement. This can cause unexpected layout shifts. Ensuring valid values improves standards compliance, makes your layout predictable across browsers, and prevents silent failures that are hard to debug.

Examples

❌ Invalid: Using 0 as a line number

<div style="display: grid; grid-template-columns: repeat(3, 1fr);">

<div style="grid-column: 0 / 3;">Item</div>

</div>

Grid lines start at 1, so 0 is not a valid line number.

✅ Fixed: Using a valid line number

<div style="display: grid; grid-template-columns: repeat(3, 1fr);">

<div style="grid-column: 1 / 3;">Item</div>

</div>

❌ Invalid: Unrecognized keyword

<div style="display: grid; grid-template-columns: repeat(3, 1fr);">

<div style="grid-column: full;">Item</div>

</div>

The value full is not a valid grid line value unless it's a named line defined in the grid template.

✅ Fixed: Using span to cover all columns

<div style="display: grid; grid-template-columns: repeat(3, 1fr);">

<div style="grid-column: 1 / -1;">Item</div>

</div>

Using -1 refers to the last grid line, effectively spanning all columns.

❌ Invalid: span 0

<div style="display: grid; grid-template-columns: repeat(4, 1fr);">

<div style="grid-column: span 0;">Item</div>

</div>

The span keyword requires a positive integer. 0 is not valid.

✅ Fixed: Using a positive span value

<div style="display: grid; grid-template-columns: repeat(4, 1fr);">

<div style="grid-column: span 2;">Item</div>

</div>

❌ Invalid: Malformed syntax with a comma

<div style="display: grid; grid-template-columns: repeat(3, 1fr);">

<div style="grid-column: 1, 3;">Item</div>

</div>

✅ Fixed: Using the / separator

<div style="display: grid; grid-template-columns: repeat(3, 1fr);">

<div style="grid-column: 1 / 3;">Item</div>

</div>

The start and end lines must be separated by a /, not a comma.

Quick Reference of Valid Patterns

When in doubt, check that every numeric value is a non-zero integer and that the overall format uses / to separate the start and end values.

The grid-template-columns property defines the column track sizes of a CSS grid container. When the W3C validator reports that a particular value "is not a grid-template-columns value," it means the parser encountered something it cannot interpret as a valid track size or track listing.

This error can be triggered by many common mistakes: a simple typo (like auто instead of auto), using a CSS custom property (the validator may not resolve var() references), forgetting units on a length value (e.g., 100 instead of 100px), using JavaScript-like terms (e.g., undefined or null), or using newer syntax that the validator's CSS parser doesn't yet support.

While browsers are generally forgiving and will simply ignore an invalid grid-template-columns declaration, this means your grid layout silently breaks — the container won't form a grid as intended, and content may stack in a single column. Fixing validation errors ensures your layout works predictably across browsers and makes your stylesheets easier to maintain.

Valid values

The grid-template-columns property accepts these value types:

• none — the default; no explicit grid columns are defined.
• Length and percentage values — px, em, rem, %, vh, vw, etc. (e.g., 200px, 50%).
• The fr unit — distributes remaining space proportionally (e.g., 1fr 2fr).
• Keywords — auto, min-content, max-content.
• The repeat() function — shorthand for repeated track patterns (e.g., repeat(3, 1fr)).
• The minmax() function — sets a minimum and maximum size for a track (e.g., minmax(150px, 1fr)).
• The fit-content() function — clamps the track to a given maximum (e.g., fit-content(300px)).
• Named grid lines — defined with square brackets (e.g., [sidebar-start] 200px [sidebar-end content-start] 1fr [content-end]).
• Any combination of the above.

Common causes

1. Typos or made-up keywords — values like undefined, inherit-grid, or misspelled units.
2. Missing units — writing 100 instead of 100px. The fr unit, px, and all other units are mandatory (only 0 can be unitless).
3. Invalid function syntax — missing commas or parentheses in repeat() or minmax().
4. CSS custom properties — var(--cols) may trigger validator warnings because the validator cannot resolve the variable at parse time. This is typically a false positive.

Examples

Incorrect: invalid keyword

<style>

.grid {

display: grid;

grid-template-columns: undefined;

}

</style>

Incorrect: missing unit on a length

<style>

.grid {

display: grid;

grid-template-columns: 200 1fr;

}

</style>

Incorrect: malformed repeat() syntax

<style>

.grid {

display: grid;

grid-template-columns: repeat(3 1fr);

}

</style>

Correct: using fr units

<style>

.grid {

display: grid;

grid-template-columns: 1fr 2fr;

}

</style>

Correct: mixing lengths, fr, and auto

<style>

.grid {

display: grid;

grid-template-columns: 250px 1fr auto;

}

</style>

Correct: using repeat() and minmax()

<style>

.grid {

display: grid;

grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));

}

</style>

Correct: named grid lines with track sizes

<style>

.grid {

display: grid;

grid-template-columns: [sidebar] 240px [content] 1fr [aside] 200px;

}

</style>

If the validator flags a var() custom property usage and you're confident the variable resolves to a valid value at runtime, the warning can generally be disregarded — this is a known limitation of static CSS validation. For all other cases, double-check spellings, ensure every numeric value (other than 0) has a unit, and verify that function syntax includes the correct commas and parentheses.

The grid-template-rows property defines the size of each row in a CSS grid layout. The W3C validator checks that every value in the declaration conforms to the CSS Grid specification. When you see this error, the validator has encountered something it cannot parse as a valid track size.

Common causes of this error include:

• Typos or invalid units — writing 100 px (with a space), 100pixels, or 1 fr instead of 1fr.
• Using values from other properties — for example, flex, inline, or space-between are not valid row track sizes.
• Incorrect function syntax — missing commas in repeat(), providing wrong arguments to minmax(), or using unsupported functions.
• Missing units — writing a bare number like 100 instead of 100px (zero is the only number that doesn't require a unit).
• Using newer syntax not yet recognized — some cutting-edge features like subgrid or the masonry value may trigger validation warnings depending on the validator's supported spec level.

The grid-template-rows property accepts these valid value types:

• Length values: 100px, 5em, 10rem, 20vh
• Percentages: 50%, 33.3%
• Flexible lengths: 1fr, 2fr
• Keywords: auto, min-content, max-content, none
• Functions: repeat(), minmax(), fit-content()
• Named lines: [row-start] 100px [row-end]

This matters for standards compliance and forward compatibility. While browsers may be lenient and ignore invalid values, relying on that behavior can lead to layouts that silently break. Valid CSS ensures your grid behaves predictably across all browsers.

Examples

Incorrect — invalid values

<style>

/* ERROR: "full" is not a valid track size */

.grid-a {

display: grid;

grid-template-rows: full auto;

}

/* ERROR: space between number and unit */

.grid-b {

display: grid;

grid-template-rows: 100 px 200 px;

}

/* ERROR: bare number without a unit */

.grid-c {

display: grid;

grid-template-rows: 100 200;

}

/* ERROR: missing comma in repeat() */

.grid-d {

display: grid;

grid-template-rows: repeat(3 1fr);

}

</style>

Correct — valid track sizes

<style>

/* Fixed pixel heights */

.grid-a {

display: grid;

grid-template-rows: 100px auto;

}

/* Flexible units */

.grid-b {

display: grid;

grid-template-rows: 1fr 2fr;

}

/* Repeat function with correct syntax */

.grid-c {

display: grid;

grid-template-rows: repeat(3, 1fr);

}

/* Minmax with auto */

.grid-d {

display: grid;

grid-template-rows: minmax(100px, 1fr) auto;

}

</style>

Full working example

<!DOCTYPE html>

<html lang="en">

<head>

<title>Grid template rows example</title>

<style>

.grid-container {

display: grid;

grid-template-rows: 80px minmax(150px, 1fr) auto;

gap: 8px;

height: 400px;

}

.grid-container > div {

background: #e0e0e0;

padding: 16px;

}

</style>

</head>

<body>

<div class="grid-container">

<div>Row 1 — fixed 80px</div>

<div>Row 2 — between 150px and 1fr</div>

<div>Row 3 — auto-sized to content</div>

</div>

</body>

</html>

Using fit-content() and named lines

<style>

.grid {

display: grid;

grid-template-rows: [header] fit-content(100px) [main] 1fr [footer] auto;

}

</style>

If your value looks correct but the validator still flags it, check whether you're using a very new CSS feature like subgrid or masonry. These may not yet be recognized by the validator even if some browsers support them. In that case, the warning can be acknowledged while keeping the value intentionally.

The height CSS property defines the height of an element's content area. According to CSS specifications, it accepts several value types: length values (like px, em, rem, vh, cm), percentages (%), and keywords such as auto, min-content, max-content, and fit-content. When the validator encounters a value that doesn't belong to any of these accepted types, it reports a type incompatibility error.

This error commonly occurs in a few scenarios:

• Missing units on numeric values. In CSS, a bare number like 100 is not a valid length. The only exception is 0, which doesn't require a unit because zero is the same in any unit system. Writing height: 100; instead of height: 100px; is invalid CSS.
• Unrecognized keywords. Using a word that isn't a valid CSS keyword for height, such as big, small, or full, will trigger this error. These are not part of the CSS specification for the height property.
• Values from the wrong property. Sometimes values valid for other properties get mistakenly used with height. For example, height: bold; or height: block; are type mismatches because those keywords belong to font-weight and display, respectively.
• Typos or syntax errors. A stray character, misspelled unit (e.g., 100xp instead of 100px), or malformed calc() expression can also cause this error.

While modern browsers often try to recover from invalid CSS by ignoring the offending declaration, this means the height rule silently has no effect, which can lead to unexpected layout behavior. Writing valid CSS ensures your styles work predictably across all browsers and avoids hard-to-debug rendering issues.

How to Fix It

1. Add a valid unit to any bare numeric value. Use px, em, rem, vh, %, or another valid CSS length unit.
2. Use only recognized keywords for height: auto, min-content, max-content, fit-content, or fit-content(<length>).
3. Check for typos in both the value and the unit.
4. Validate calc() expressions to ensure the types inside are compatible (e.g., you can't add a length and a color).

Examples

Incorrect: Missing unit on a numeric value

<style>

.box {

height: 100; /* invalid — no unit specified */

}

</style>

Incorrect: Unrecognized keyword

<style>

.box {

height: big; /* invalid — "big" is not a CSS keyword for height */

}

</style>

Incorrect: Misspelled unit

<style>

.box {

height: 250xp; /* invalid — "xp" is not a recognized unit */

}

</style>

Correct: Valid length values, percentages, and keywords

<style>

.fixed {

height: 200px;

}

.relative {

height: 70%;

}

.viewport {

height: 100vh;

}

.flexible {

height: auto;

}

.zero {

height: 0;

}

.intrinsic {

height: min-content;

}

.calculated {

height: calc(100vh - 60px);

}

</style>

Correct: Using height in context

<div style="height: 300px;">

<p style="height: 50%;">

This paragraph is 150px tall because its parent has a defined height.

</p>

</div>

Keep in mind that percentage-based height values only work when the parent element has a defined height. If the parent's height is auto, a child with height: 50% will behave as if it were set to auto as well. When in doubt, use an absolute length like px or a viewport unit like vh, or set height: auto to let the content determine the element's size.

The W3C validator checks inline styles and embedded stylesheets for valid CSS. When it encounters a height declaration with multiple values or an unrecognized value, it flags the error because height is not a shorthand property — it only accepts one value at a time. This differs from properties like margin or padding, which accept multiple values to target different sides of an element.

This error commonly occurs when you:

• Accidentally provide two values, perhaps confusing height with a shorthand property (e.g., height: 100px 50px;).
• Include a typo or invalid unit (e.g., height: 100ppx; or height: 100pixels;).
• Use a CSS function incorrectly (e.g., height: calc(100% 20px); — missing the operator).
• Copy a value meant for another property, such as pasting a grid-template-rows value into height.

Browsers may silently ignore invalid height declarations, causing your element to fall back to its default sizing (auto). This can lead to unexpected layout behavior that's difficult to debug. Keeping your CSS valid ensures consistent rendering across browsers and helps catch mistakes early.

Valid values for height

The height property accepts exactly one of the following:

• Length values: 100px, 10em, 5rem, 20vh, etc.
• Percentage values: 50%, 100%
• Keyword values: auto, max-content, min-content, fit-content(200px)
• Global values: inherit, initial, revert, unset
• Calc expressions: calc(100% - 20px), calc(50vh + 2rem)

Examples

Incorrect: too many values

<style>

.box {

height: 100px 50px; /* Error: height only accepts one value */

}

</style>

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

Incorrect: unrecognized value

<style>

.box {

height: 100pixels; /* Error: "pixels" is not a valid unit */

}

</style>

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

Incorrect: malformed calc() expression

<style>

.box {

height: calc(100% 20px); /* Error: missing operator between values */

}

</style>

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

Correct: single length value

<style>

.box {

height: 100px;

}

</style>

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

Correct: percentage value

<style>

.box {

height: 50%;

}

</style>

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

Correct: calc() with proper operator

<style>

.box {

height: calc(100% - 20px);

}

</style>

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

Correct: keyword value

<style>

.box {

height: auto;

}

</style>

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

If you need to set both width and height, remember they are separate properties and must be declared individually. If you were trying to set a minimum and maximum height, use min-height and max-height as distinct declarations instead of combining values into a single height property.

Negative values for the CSS height property are invalid and will be rejected by browsers.

The CSS height property accepts only non-negative values. Valid values include auto, lengths like 100px or 10em, percentages like 50%, and viewport units like 100vh. A negative value such as height: -50px has no defined meaning for box dimensions and violates the CSS specification.

This error typically appears when height is set inline via the style attribute, and the W3C validator flags it during HTML validation. Common causes include typos, incorrect calculations in server-side templates, or JavaScript that generates a negative value and writes it into the markup.

If the intent is to hide or collapse an element, use height: 0 combined with overflow: hidden instead. If the intent is to shrink an element relative to some reference, use calc() with a positive result, such as height: calc(100% - 50px).

HTML examples

Invalid: negative height value

<div style="height: -100px;">

Content here

</div>

Valid: using zero height or calc()

<!-- Collapse an element -->

<div style="height: 0; overflow: hidden;">

Hidden content

</div>

<!-- Subtract from a reference value -->

<div style="height: calc(100vh - 100px);">

Content here

</div>

A non-standard value high is being used for the prefers-contrast media feature in a <style> block or style attribute, but the valid values are no-preference, more, less, and custom.

The prefers-contrast media feature detects whether the user has requested more or less contrast through their operating system or browser settings. Early drafts of the specification used high and low as values, and some older references still mention them. The current specification replaced these with more and less.

The W3C validator flags high because it checks CSS within HTML documents against current standards. Even though some browsers may still accept high as an alias, it is non-standard and should be replaced with more.

The mapping from old to new values:

• high → more
• low → less

HTML example with the issue

<style>

@media (prefers-contrast: high) {

body {

background: white;

color: black;

}

}

</style>

Fixed example

<style>

@media (prefers-contrast: more) {

body {

background: white;

color: black;

}

}

</style>

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:

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

Examples

Incorrect: @import after a style rule

<style>

body {

margin: 0;

}

@import url("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");

}

@import url("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>

@import url("reset.css");

@import url("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";

@import url("base.css");

@import url("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.

A CSS selector in your style element or style attribute contains an ID that doesn't follow valid CSS syntax rules.

In CSS, ID selectors must begin with a # followed by a valid CSS identifier. A valid CSS identifier cannot start with a digit, two hyphens, or a hyphen followed by a digit, unless the identifier is properly escaped. This error commonly occurs when your HTML element has an id that begins with a number (like id="1section") and your CSS references it directly as #1section.

While HTML5 allows id values to start with numbers, CSS does not accept those values as-is in selectors. You have two options: rename the id to start with a letter or underscore, or escape the leading digit in your CSS selector using a backslash (e.g., #\31 section). Renaming the id is almost always the simpler and more maintainable approach.

Invalid ID selector

<style>

#1section {

color: red;

}

</style>

<div id="1section">Hello</div>

Fixed: Use a valid identifier

<style>

#section-1 {

color: red;

}

</style>

<div id="section-1">Hello</div>

If you cannot change the id in the HTML, escape the digit in CSS:

<style>

#\31 section {

color: red;

}

</style>

<div id="1section">Hello</div>

The \31 is the Unicode code point for the character "1", and the space after it separates the escape sequence from the rest of the identifier. This is valid CSS but harder to read, so renaming the id is the preferred fix.

The W3C validator parses inline CSS values character by character. When it encounters a numeric value for the left property, it expects the characters that follow to be part of a valid number (digits, a decimal point, or e for scientific notation) or a recognized CSS unit. If it instead finds an unexpected letter like n, it raises this error. This can happen in several ways:

• Missing units: Writing left: 10; instead of left: 10px;. The CSS specification requires a unit for all non-zero length values. While some browsers may interpret unitless numbers in quirks mode, this is invalid CSS and produces unpredictable results across browsers.
• Typos in units: Writing something like left: 10n; or left: 10xp; where the intended unit was px but a typo introduced invalid characters.
• Template or scripting artifacts: Dynamically generated values like left: {{offset}}px; that weren't properly resolved, leaving non-numeric characters in the output.
• Using calc() incorrectly: Writing left: 10 + 5px; instead of left: calc(10px + 5px);.

The left property accepts the following value types:

• Lengths: A number followed by a unit such as px, em, rem, vw, vh, ch, etc. (e.g., left: 10px;)
• Percentages: A number followed by % (e.g., left: 50%;)
• Keywords: auto, inherit, initial, unset, or revert
• Functions: calc(), min(), max(), clamp(), etc.
• Zero: The value 0 is the only number that does not require a unit.

Invalid CSS not only triggers validation errors but can cause layout issues. Browsers may ignore the entire declaration, falling back to the default value, which can break your intended positioning. Ensuring valid CSS improves cross-browser consistency and maintainability.

Examples

Missing unit (triggers the error)

<div style="position: absolute; left: 10;">

Positioned element

</div>

The validator reads 10 and then encounters the ; (or in other cases a stray letter like n), which is not a valid part of a CSS length value.

Typo in unit (triggers the error)

<div style="position: absolute; left: 10xn;">

Positioned element

</div>

Fixed with a valid length unit

<div style="position: absolute; left: 10px;">

Positioned element

</div>

Fixed with a percentage

<div style="position: absolute; left: 50%;">

Positioned element

</div>

Fixed with the auto keyword

<div style="position: absolute; left: auto;">

Positioned element

</div>

Fixed with calc()

<div style="position: absolute; left: calc(50% - 20px);">

Positioned element

</div>

Zero without a unit (valid)

<div style="position: absolute; left: 0;">

Positioned element

</div>

Always double-check that every non-zero numeric value for left (and other length-based properties like top, right, bottom, width, margin, etc.) includes a valid CSS unit. If you're generating styles dynamically, verify that template variables resolve to proper values before rendering.

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.

<div style="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.

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

Invalid: Misspelled unit

The unit xp does not exist in CSS.

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

Valid: Using a length value

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

Valid: Using a percentage

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

Valid: Using the auto keyword

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

Valid: Using zero without a unit

Zero does not require a unit in CSS.

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

Valid: Using inherit

<div style="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.

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

1. 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.

2. Validate the number before using it. In JavaScript, use Number.isNaN() or isFinite() to check that a computed value is valid before applying it.

3. Provide a sensible fallback. If the calculation might fail, default to a known-good value like 0 or normal.

4. 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:

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

The JavaScript that likely produced it:

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

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

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

✅ Fixed: Validate the value before applying it

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

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

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

This produces valid inline CSS:

<p style="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>

<p class="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:

<!-- Pseudocode for a template engine -->

<!-- Only output the style attribute if the value is a valid number -->

<p style="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.

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:

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

Remove the invalid character:

<p style="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.

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

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

<!-- Misspelled keyword -->

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

<!-- Invalid unit -->

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

<!-- Malformed number -->

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

<!-- Unsupported keyword -->

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

<!-- Negative value -->

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

✅ Correct: valid line-height values

<!-- Keyword -->

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

<!-- Unitless number (recommended) -->

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

<!-- Length with px -->

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

<!-- Length with em -->

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

<!-- Percentage -->

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

Full document example

<!DOCTYPE html>

<html lang="en">

<head>

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

</head>

<body>

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

<p style="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.

Negative values for the CSS line-height property are invalid and browsers reject them.

The line-height property sets the height of each line box, so a negative value has no meaning and violates the CSS specification. Valid values are normal, a unitless multiplier like 1.5, a length like 24px or 1.5em, or a percentage like 150%. A unitless number is usually the best choice, since it scales with the element's font size and avoids the inheritance quirks that fixed lengths can cause.

This error usually appears when line-height is set inline through the style attribute, where the W3C validator catches it during HTML validation. A common cause is a calculation in a template or script that produces a negative number and writes it into the markup.

To fix it, replace the negative value with a positive one, or use normal for the browser's default spacing. Tighter lines are fine as long as the value stays positive, such as line-height: 0.9.

HTML examples

Invalid: negative line-height value

<p style="line-height: -0.5em;">

Paragraph text

</p>

Valid: positive value or normal

<!-- Unitless multiplier, scales with font size -->

<p style="line-height: 1.5;">

Paragraph text

</p>

<!-- Browser default spacing -->

<p style="line-height: normal;">

Paragraph text

</p>

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

1. Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
2. Use 0 without a unit if you want zero margin: margin-bottom: 0 is valid and preferred over margin-bottom: 0px.
3. Use a keyword value if appropriate: margin-bottom also accepts auto, inherit, initial, revert, and unset.
4. 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

<div style="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

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

Correct: zero margin (no unit needed)

<div style="margin-bottom: 0;">Content</div>

Correct: using a keyword value

<div style="margin-bottom: auto;">Content</div>

Incorrect in a stylesheet

<html lang="en">

<head>

<title>Example</title>

<style>

.card {

margin-bottom: px;

}

</style>

</head>

<body>

<div class="card">Content</div>

</body>

</html>

Fixed stylesheet

<html lang="en">

<head>

<title>Example</title>

<style>

.card {

margin-bottom: 16px;

}

</style>

</head>

<body>

<div class="card">Content</div>

</body>

</html>

Watch out for preprocessor issues

If you use a CSS preprocessor like Sass or Less, a common source of this error is an empty or undefined variable:

/* If $spacing resolves to empty, this produces "margin-bottom: px;" */

.card {

margin-bottom: $spacing + px;

}

Instead, ensure the variable includes the unit or has a valid fallback:

$spacing: 16px;

.card {

margin-bottom: $spacing;

}

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.

The spacing() function is not a valid CSS value. It does not exist in any CSS specification.

The spacing() notation is commonly found in utility-based frameworks like Tailwind CSS or custom design systems where it acts as a shorthand for spacing scales. However, browsers and the W3C validator do not recognize it as valid CSS.

If you're using a build tool or preprocessor, make sure spacing() is being compiled into a valid CSS value before it reaches the browser. If you're writing plain CSS, replace it with a standard CSS length value such as px, rem, em, or use a CSS custom property.

How to Fix

Replace spacing(3) with a valid CSS length value:

#content::after {

margin-bottom: 0.75rem;

}

Or use a CSS custom property to create your own spacing scale:

:root {

--spacing-3: 0.75rem;

}

#content::after {

margin-bottom: var(--spacing-3);

}

Both approaches produce valid CSS that the W3C validator will accept. If your project relies on a framework that provides spacing(), check that your build pipeline (e.g., PostCSS, Sass, or Tailwind) is correctly transforming it into standard CSS before deployment.