HTML Guides for CSS

The correct value is nowrap (without a hyphen), not no-wrap.

The flex-wrap CSS property controls whether flex items are forced onto a single line or can wrap onto multiple lines. It accepts three values: nowrap (the default), wrap, and wrap-reverse. A common mistake is writing no-wrap with a hyphen, likely because the white-space CSS property uses nowrap and no-wrap interchangeably in some contexts, or simply because it looks more natural in English. However, for flex-wrap, only the unhyphenated nowrap is valid.

HTML Example With the Issue

<div style="display: flex; flex-wrap: no-wrap;">

<p>Item 1</p>

<p>Item 2</p>

</div>

Fixed HTML Example

<div style="display: flex; flex-wrap: nowrap;">

<p>Item 1</p>

<p>Item 2</p>

</div>

A font-family list contains something that is not a font name, most often a CSS-wide keyword such as inherit placed next to other families.

font-family takes a comma-separated list of family names, like "Open Sans", Arial, sans-serif, usually ending in a generic family such as serif, sans-serif or monospace. The CSS-wide keywords inherit, initial, unset and revert are also valid, but only as the entire value. font-family: inherit passes; font-family: inherit, sans-serif and font-family: Arial, inherit fail, and the validator names the keyword in the message. Browsers ignore the whole declaration, so the element gets whatever font it would have without that rule.

The same message appears when a size or a weight ends up in the list, as in font-family: 16px Arial or font-family: "Open Sans", 700. Those values belong in font-size and font-weight, or in the font shorthand, which takes them before the family.

To fix it, use inherit on its own when the element should take its parent's font, or list real family names with a generic family at the end. A keyword added as a last-resort fallback does nothing useful, because the generic family already covers the case where none of the named fonts is available.

Invalid example

<style>

.card {

font-family: inherit, sans-serif;

}

.note {

font-family: 16px Arial;

}

</style>

Valid example

<style>

.card {

font-family: inherit;

}

.note {

font-size: 16px;

font-family: Arial, sans-serif;

}

</style>

.card uses inherit alone, and the size on .note has its own font-size declaration.

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

Type	Examples	Notes
Absolute keywords	xx-small, x-small, small, medium, large, x-large, xx-large, xxx-large	Browser-defined sizes
Relative keywords	smaller, larger	Relative to the parent element's font size
Length units	16px, 1.2em, 0.9rem, 12pt, 1vw	Must include a unit (except 0)
Percentages	100%, 120%, 80%	Relative to the parent element's font size
Math functions	calc(1rem + 2px), clamp(1rem, 2vw, 3rem)	CSS math expressions that resolve to a length

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 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 value of the --global-vw custom property has a math expression that combines values of incompatible types.

The Kadence WordPress theme sets this variable on .wp-site-blocks to the viewport width minus half the scrollbar width: calc(100vw - (0.5 * var(--scrollbar-offset))). A theme script measures the scrollbar and stores its width in pixels in --scrollbar-offset. Full-width rows built with Kadence Blocks read var(--global-vw, 100vw) to extend past the content column.

A custom property can hold almost any value, so the validator doesn't check whether the result is a length. It does check the math inside calc(), min(), max() and clamp(), where the values you add or subtract must have the same type. Subtracting a unitless number from a length, as in calc(100vw - (0.5 * 15)), triggers this error. Browsers reject that expression too. Every property that reads the variable becomes invalid at computed-value time and acts as if it were unset. The 100vw fallback in var(--global-vw, 100vw) doesn't apply, because the variable is defined.

The value Kadence writes by default passes the check, because the validator doesn't type-check an expression that contains var(). If your page shows this error, something else on the site has replaced the theme's value. Look for custom CSS or a child theme that redefines --global-vw, and add the missing unit to the number.

Invalid example

<style>

.wp-site-blocks {

--global-vw: calc(100vw - (0.5 * 15));

}

</style>

Valid example

<style>

.wp-site-blocks {

--global-vw: calc(100vw - (0.5 * 15px));

}

</style>

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

Value	Meaning
grid-column: 2	Start at line 2, end at auto
grid-column: 2 / 5	Start at line 2, end at line 5
grid-column: 1 / -1	Span from first to last line
grid-column: span 3	Span 3 columns from auto-placed start
grid-column: 2 / span 3	Start at line 2, span 3 columns
grid-column: auto / auto	Fully automatic placement

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.

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

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

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

An invalid value was assigned to the margin-bottom CSS property, and the W3C validator rejected it because it does not match any accepted syntax for that property.

The margin-bottom property accepts a length (e.g., 10px, 2em), a percentage (e.g., 5%), auto, or the global keywords inherit, initial, revert, and unset. The validator raises this error when the value is misspelled, uses a wrong unit, is missing a unit entirely, or contains an otherwise unrecognized token.

Common causes:

• A bare number without a unit, like margin-bottom: 10 instead of margin-bottom: 10px. Zero is the only length value that does not require a unit.
• A typo in the unit or keyword, like margin-bottom: 10 px (with a space) or margin-bottom: auто (mixed character encodings).
• An invalid keyword, like margin-bottom: none. The margin-bottom property does not accept none.

Example with the error

<p style="margin-bottom: 10">This paragraph has an invalid margin.</p>

The value 10 is not valid because it lacks a unit.

Fixed example

<p style="margin-bottom: 10px">This paragraph has a valid margin.</p>

Adding a recognized unit like px, em, rem, or % fixes the error. If the intended value is zero, margin-bottom: 0 is valid without a unit.

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.

Malformed gradient syntax such as missing parentheses, invalid color stops, or incorrect direction keywords can also produce this error. For instance, linear-gradient(right, red, blue) is invalid because directional keywords require the to prefix.

Vendor-prefixed values used without the matching prefix on the property can trigger issues as well. Using -webkit-gradient() as a value for the standard mask-image property may not validate.

Examples

Incorrect: bare image path without url()

<div style="mask-image: mask.png;">

Content here

</div>

Correct: image path wrapped in url()

<div style="mask-image: url('mask.png');">

Content here

</div>

Incorrect: typo in gradient function name

<div style="mask-image: linear-gradiant(to right, transparent, black);">

Content here

</div>

Correct: properly spelled gradient function

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

Content here

</div>

Incorrect: missing to keyword in gradient direction

<div style="mask-image: linear-gradient(right, transparent, black);">

Content here

</div>

Correct: direction uses the to keyword

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

Content here

</div>

Incorrect: unsupported keyword

<div style="mask-image: overlay;">

Content here

</div>

Correct: using none to explicitly disable masking

<div style="mask-image: none;">

Content here

</div>

Correct: multiple mask layers

<div style="mask-image: url('star.svg'), linear-gradient(to bottom, black, transparent);">

Content here

</div>

Correct: radial gradient as a mask

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

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.

Examples

Incorrect: arbitrary keyword as a mask value

<div style="mask: star-shape;">

Masked Content

</div>

The value star-shape is not a recognized mask value and will be rejected by the validator.

Incorrect: missing url() function

<div style="mask: star.svg;">

Masked Content

</div>

A bare file path is not valid. Image references must be wrapped in the url() function.

Correct: using url() to reference a mask image

<div style="mask: url(star.svg);">

Masked Content

</div>

Correct: using none to explicitly disable masking

<div style="mask: none;">

No Mask Applied

</div>

Correct: using a gradient as a mask

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

Fading Content

</div>

Correct: combining multiple shorthand values

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

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

The CSS min-width property has a quoted string as its value, such as "" or "200px", and strings are not valid for this property.

min-width accepts a length (200px, 12rem), a percentage (50%), 0, a calc() expression, the keywords auto, min-content, max-content and fit-content, and CSS-wide keywords like inherit. Anything wrapped in quotes is a CSS string, so min-width: "200px" is rejected even though min-width: 200px is fine. The validator repeats the string in the message: “""” means the declaration was min-width: "", an empty string.

An empty string usually comes from a template or page builder that wraps the value in quotes and prints nothing when the setting is blank. Quoted lengths often come from code copied out of JavaScript or JSON, where values are written as strings (minWidth: "200px").

To fix it, remove the quotes. If there is no value to set, remove the whole declaration; the default min-width is auto. Other bad values produce different messages: a number without a unit (min-width: 200) reports that only 0 can be unitless, and an unknown keyword (min-width: none) reports that values are not recognized.

Invalid example

<style>

.sidebar {

min-width: "";

}

.card {

min-width: "200px";

}

</style>

Valid example

<style>

.card {

min-width: 200px;

}

</style>

The empty declaration on .sidebar is gone, and the .card value has no quotes.

An invalid value was assigned to the padding-bottom CSS property inside a style attribute, and the W3C validator rejected it.

The padding-bottom property accepts a length (e.g., 10px, 2em), a percentage (e.g., 5%), or the keyword inherit. Values like auto, bare numbers without units, or unrecognized keywords are not valid. A common mistake is writing padding-bottom: 10 instead of padding-bottom: 10px, or using a value meant for a different property.

The validator specifically checks inline styles in style attributes against CSS grammar rules. Even if a browser silently ignores the bad value, the markup is still invalid.

Invalid example

<div style="padding-bottom: auto;">

Content here

</div>

The value auto is not valid for padding-bottom.

Valid example

<div style="padding-bottom: 10px;">

Content here

</div>

Use a supported value: a length with a unit (px, em, rem, %, etc.) or 0 (which does not require a unit).

The padding-right property defines the space between an element's content and its right border. According to the CSS Box Model specification, padding represents internal space within an element, and conceptually, negative internal space doesn't make sense — you can't have less than zero space between content and its border. This rule applies equally to all padding properties: padding-top, padding-right, padding-bottom, padding-left, and the padding shorthand.

Browsers will typically ignore or discard a negative padding value, meaning your intended layout adjustment won't take effect. Beyond simply being invalid CSS, this can lead to inconsistent rendering across browsers and unexpected layout behavior. Relying on invalid values makes your stylesheets fragile and harder to maintain.

If your goal is to pull an element closer to its neighbor or create an overlapping effect, margin-right is the appropriate property to use. Unlike padding, margins are explicitly allowed to have negative values. Negative margins reduce the space between elements or even cause them to overlap, which is often the actual intent behind a negative padding attempt.

How to Fix

1. Set the value to 0 or a positive number. If you simply want no padding, use 0. If you need some spacing, use a positive value.
2. Use margin-right for negative spacing. If you need to reduce external space or create overlap, switch to a negative margin instead.
3. Re-evaluate your layout approach. In some cases, using transform: translateX(), Flexbox gap, or Grid layout may achieve the desired result more cleanly than negative values on any property.

Examples

Incorrect: negative padding value

<style>

.sidebar {

padding-right: -10px;

}

</style>

<div class="sidebar">

<p>Sidebar content</p>

</div>

This triggers the validator error because -10px is not a valid value for padding-right.

Fixed: using zero or a positive value

<style>

.sidebar {

padding-right: 0;

}

</style>

<div class="sidebar">

<p>Sidebar content</p>

</div>

Fixed: using a negative margin instead

If the intent was to reduce external spacing on the right side, use margin-right:

<style>

.sidebar {

padding-right: 0;

margin-right: -10px;

}

</style>

<div class="sidebar">

<p>Sidebar content</p>

</div>

Fixed: using transform for visual offset

If the goal is to visually shift the element without affecting document flow, transform is another option:

<style>

.sidebar {

padding-right: 0;

transform: translateX(10px);

}

</style>

<div class="sidebar">

<p>Sidebar content</p>

</div>

Quick reference: padding vs. margin

Property	Negative values allowed?	Purpose
padding-right	No	Space between content and border
margin-right	Yes	Space between the element's border and surrounding elements

Choose the property that matches your layout intent, and remember that all four padding directions — padding-top, padding-right, padding-bottom, and padding-left — follow the same non-negative rule.

A CSS padding property contains a value the validator does not recognize as valid for that property.

The padding shorthand and its longhand variants (padding-top, padding-right, padding-bottom, padding-left) accept only <length>, <percentage>, or the keyword auto (in some contexts). Common causes of this error include:

• Using an invalid unit or misspelling a unit, such as 10xp instead of 10px.
• Omitting the unit on a non-zero value, such as padding: 10 instead of padding: 10px.
• Passing a color, keyword, or other unrelated value, such as padding: red or padding: bold.
• Including extra or misplaced values from a copy-paste error, such as padding: 10px 20px 30px 40px 50px (five values instead of the maximum four).
• Using CSS custom properties or newer syntax in an inline style attribute that the validator's CSS parser does not yet support.

The padding shorthand accepts one to four values, corresponding to the top, right, bottom, and left sides. Each value must be a non-negative length (like 0, 8px, 1em, 2rem) or a percentage.

HTML examples

Invalid padding value

<div style="padding: 10xp;">Content</div>

Fixed padding value

<div style="padding: 10px;">Content</div>