HTML Guides for CSS

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:2001fr;

}

</style>

Incorrect: malformed repeat() syntax

<style>

.grid{

display: grid;

grid-template-columns:repeat(31fr);

}

</style>

Correct: using fr units

<style>

.grid{

display: grid;

grid-template-columns:1fr2fr;

}

</style>

Correct: mixing lengths, fr, and auto

<style>

.grid{

display: grid;

grid-template-columns:250px1fr 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:100200;

}

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

.grid-d{

display: grid;

grid-template-rows:repeat(31fr);

}

</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:1fr2fr;

}

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

<htmllang="en">

<head>

<title>Grid template rows example</title>

<style>

.grid-container{

display: grid;

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

gap:8px;

height:400px;

}

.grid-container>div{

background:#e0e0e0;

padding:16px;

}

</style>

</head>

<body>

<divclass="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

<divstyle="height:300px;">

<pstyle="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.

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

<divstyle="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)

<divstyle="position: absolute;left:10xn;">

Positioned element

</div>

Fixed with a valid length unit

<divstyle="position: absolute;left:10px;">

Positioned element

</div>

Fixed with a percentage

<divstyle="position: absolute;left:50%;">

Positioned element

</div>

Fixed with the auto keyword

<divstyle="position: absolute;left: auto;">

Positioned element

</div>

Fixed with calc()

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

Positioned element

</div>

Zero without a unit (valid)

<divstyle="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.

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

Invalid: Missing unit on a non-zero number

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

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

Invalid: Misspelled unit

The unit xp does not exist in CSS.

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

Valid: Using a length value

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

Valid: Using a percentage

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

Valid: Using the auto keyword

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

Valid: Using zero without a unit

Zero does not require a unit in CSS.

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

Valid: Using inherit

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

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

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:

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

The JavaScript that likely produced it:

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

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

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

✅ Fixed: Validate the value before applying it

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

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

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

This produces valid inline CSS:

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

✅ Fixed: Using a static CSS value

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

<style>

.spaced-text{

letter-spacing:0.1rem;

}

</style>

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

✅ Fixed: Server-side template with a guard

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

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

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

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

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

Valid letter-spacing values for reference

The letter-spacing property accepts:

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

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

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

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

Common causes of this error include:

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

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

Examples

Invalid character instead of semicolon

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

<style>

h1{

color: blue@

font-size: 24px;

}

</style>

Replace @ with a proper semicolon:

<style>

h1{

color: blue;

font-size:24px;

}

</style>

Smart quotes in font-family

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

<style>

body{

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

}

</style>

Use straight double quotes instead:

<style>

body{

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

}

</style>

Stray character in an inline style

An accidental backtick in a style attribute triggers the error:

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

Remove the invalid character:

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

Invisible non-breaking space

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

<style>

.box{

display:\u00A0flex;

}

</style>

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

<style>

.box{

display: flex;

}

</style>

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

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

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

<!-- Invalid unit -->

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

<!-- Malformed number -->

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

<!-- Unsupported keyword -->

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

<!-- Negative value -->

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

✅ Correct: valid line-height values

<!-- Keyword -->

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

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

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

<!-- Length with px -->

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

<!-- Length with em -->

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

<!-- Percentage -->

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

Full document example

<!DOCTYPE html>

<htmllang="en">

<head>

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

</head>

<body>

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

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

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

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

</body>

</html>

Tip: unitless vs. percentage/length

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

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.

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

<divstyle="mask-image: mask.png;">

Content here

</div>

Correct: image path wrapped in url()

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

Content here

</div>

Incorrect: typo in gradient function name

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

Content here

</div>

Correct: properly spelled gradient function

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

Content here

</div>

Incorrect: missing to keyword in gradient direction

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

Content here

</div>

Correct: direction uses the to keyword

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

Content here

</div>

Incorrect: unsupported keyword

<divstyle="mask-image: overlay;">

Content here

</div>

Correct: using none to explicitly disable masking

<divstyle="mask-image: none;">

Content here

</div>

Correct: multiple mask layers

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

Content here

</div>

Correct: radial gradient as a mask

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

Content here

</div>

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

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

<divstyle="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

<divstyle="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

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

Masked Content

</div>

Correct: using none to explicitly disable masking

<divstyle="mask: none;">

No Mask Applied

</div>

Correct: using a gradient as a mask

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

Fading Content

</div>

Correct: combining multiple shorthand values

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

Masked Content

</div>

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

Correct: multiple mask layers

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

Multi-layer Mask

</div>

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

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

<divstyle="padding-bottom: auto;">

Content here

</div>

The value auto is not valid for padding-bottom.

Valid example

<divstyle="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>

<divclass="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>

<divclass="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>

<divclass="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>

<divclass="sidebar">

<p>Sidebar content</p>

</div>

Quick reference: padding vs. margin

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

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

Fixed padding value

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

An invalid value was assigned to the CSS right property, meaning the validator does not recognize the value you provided.

The CSS right property specifies the horizontal offset of a positioned element from the right edge of its containing block. It only accepts specific value types: a length (e.g., 10px, 2em), a percentage (e.g., 50%), auto, inherit, initial, unset, or revert. Any other value — such as a typo, a missing unit, or an unsupported keyword — will trigger this validation error.

A common mistake is forgetting the unit after a number. In CSS, 0 is the only length value that can be written without a unit. Writing something like right: 10 instead of right: 10px is invalid. Another common cause is using an unrecognized keyword or passing a value meant for a different property.

Invalid Example

<divstyle="position: absolute;right:10;">

This box has an invalid right value.

</div>

The value 10 is missing a unit, so the validator rejects it.

Fixed Example

<divstyle="position: absolute;right:10px;">

This box is correctly positioned.

</div>

Adding a valid unit like px, em, rem, or % resolves the issue. If you intended no offset, use right: 0 or right: auto.

The text-align CSS property controls horizontal alignment of inline-level content within a block element. When the W3C HTML validator encounters an inline style attribute containing a text-align value it doesn't recognize, it flags the error with a message like CSS: "text-align": X is not a "text-align" value, where X is the offending value.

This error commonly occurs for a few reasons:

• Confusing text-align with vertical-align: Using middle, top, or bottom — these are vertical-align values, not text-align values.
• Typos: Writing cetner instead of center, or rigth instead of right.
• Using non-standard values: Trying values like auto, none, or arbitrary strings that aren't part of the specification.
• Confusing CSS properties: Using Flexbox or Grid alignment values like flex-start or space-between with text-align.

While most browsers will silently ignore an invalid text-align value and fall back to the inherited or default alignment, relying on this behavior is problematic. It makes your intent unclear, can lead to inconsistent rendering, and signals that there may be a deeper misunderstanding in your styling approach. Valid CSS ensures predictable behavior across all browsers and assistive technologies.

Valid values for text-align

The start and end values are logical properties that respect the document's writing direction (dir attribute or direction CSS property), making them ideal for internationalized content.

Examples

Invalid: using middle instead of center

A common mistake is using middle, which is a valid value for vertical-align but not for text-align:

<pstyle="text-align: middle;">This text will fail validation.</p>

Fix: Replace middle with center:

<pstyle="text-align: center;">This text is properly centered.</p>

Invalid: typo in the value

<h2style="text-align: cetner;">Heading</h2>

Fix: Correct the spelling:

<h2style="text-align: center;">Heading</h2>

Invalid: using a non-existent value

<divstyle="text-align: auto;">Some content</div>

Fix: Choose a valid alignment value:

<divstyle="text-align: left;">Some content</div>

Invalid: using a vertical alignment value

<pstyle="text-align: top;">Paragraph text</p>

Fix: If you intended horizontal alignment, use a valid text-align value. If you actually need vertical positioning, use vertical-align on an inline or table-cell element instead:

<pstyle="text-align: left;">Paragraph text</p>

Valid examples showing all common values

<pstyle="text-align: left;">Left-aligned text.</p>

<pstyle="text-align: right;">Right-aligned text.</p>

<pstyle="text-align: center;">Centered text.</p>

<pstyle="text-align: justify;">Justified text stretches to fill the full width of its container.</p>

<pstyle="text-align: start;">Start-aligned (respects text direction).</p>

<pstyle="text-align: end;">End-aligned (respects text direction).</p>

When fixing this error, double-check which property you actually need. If you want to center a block-level element itself (not its text content), text-align isn't the right tool — consider using margin: 0 auto or Flexbox instead. The text-align property is specifically for the horizontal alignment of inline content within its containing block.

A percentage value in your CSS exceeds the allowed range of 0 to 100.

CSS properties that accept percentage values — such as opacity, width, height, and others used in certain contexts — may be restricted to specific ranges. When you embed CSS in an HTML document (via the style attribute or a <style> element), the W3C HTML Validator checks these values and flags any that fall outside the permitted range.

A value like 100.01% is just slightly over the maximum of 100%. This is often a typo or a rounding error. While most browsers will silently clamp the value to 100%, it is still invalid and should be corrected.

HTML Examples

❌ Invalid: value out of range

<divstyle="width:100.01%;">Content</div>

✅ Fixed: value within range

<divstyle="width:100%;">Content</div>

In CSS, most numeric values of 0 don't need a unit — for example, margin: 0 is perfectly valid because the specification allows unitless zero for <length> values. However, this exception does not apply to <time> values. Properties that accept <time> values, such as transition-delay, transition-duration, animation-delay, and animation-duration, always require a unit (s for seconds or ms for milliseconds), even when the value is zero.

The CSS specification explicitly states that <time> values must include a unit. The unitless 0 shorthand is only permitted for <length> and a few other value types. While some browsers may silently accept transition-delay: 0 and treat it as 0s, this behavior is non-standard and not guaranteed across all browsers or future implementations. Relying on it can lead to inconsistent rendering and will fail W3C CSS validation.

This issue commonly appears when transition-delay is set as part of the transition shorthand, or when developers assume that 0 is universally valid without a unit in CSS.

How to fix it

Add the s (seconds) or ms (milliseconds) unit to any <time> value that is currently a bare 0:

• 0 → 0s or 0ms
• Check both longhand properties (transition-delay, transition-duration) and the transition shorthand.

Examples

Incorrect — unitless zero

<style>

.fade{

transition-delay:0;

transition-duration:0.3s;

transition-property: opacity;

}

</style>

<divclass="fade">Hello</div>

The validator reports: CSS: "transition-delay": "0" is not a "transition-delay" value.

Correct — with time unit

<style>

.fade{

transition-delay:0s;

transition-duration:0.3s;

transition-property: opacity;

}

</style>

<divclass="fade">Hello</div>

Incorrect — unitless zero in the transition shorthand

<style>

.btn{

transition: background-color 0.2s ease 0;

}

</style>

<buttonclass="btn">Click me</button>

The fourth value in the transition shorthand is the delay, and 0 without a unit is invalid.

Correct — shorthand with time unit

<style>

.btn{

transition: background-color 0.2s ease 0s;

}

</style>

<buttonclass="btn">Click me</button>

Multiple transitions

When specifying delays for multiple properties, ensure every <time> value has a unit:

<style>

.card{

transition-property: opacity, transform;

transition-duration:0.3s,0.5s;

transition-delay:0s,0.1s;

}

</style>

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

The same rule applies to transition-duration and the animation-delay and animation-duration properties — always include s or ms, even for zero values.

CSS distinguishes between pseudo-classes and pseudo-elements using different colon syntax. Pseudo-classes like :hover, :focus, and :active describe a temporary state of an element and use a single colon (:). Pseudo-elements like ::before, ::after, and ::first-line target a specific part of an element's rendering and use double colons (::). Writing ::hover conflates these two concepts — there is no pseudo-element called hover in any CSS specification.

This matters for several reasons. First, most browsers will silently ignore the invalid ::hover rule entirely, meaning your hover styles simply won't apply. Users will see no visual feedback when hovering over interactive elements like links and buttons, which hurts usability. Second, the lack of hover feedback can be an accessibility concern — sighted users rely on hover states to identify clickable elements. Third, invalid CSS can cause unpredictable behavior across different browsers and versions, making your site harder to maintain.

The confusion often arises because CSS2 originally allowed single colons for pseudo-elements (e.g., :before), and CSS3 introduced the double-colon syntax to clearly separate pseudo-elements from pseudo-classes. This means you might see both :before and ::before in the wild, which can make it tempting to assume that double colons work everywhere. The key rule to remember: states use one colon (:hover, :focus, :visited), and sub-element targets use two colons (::before, ::after, ::placeholder).

Examples

Incorrect: using double colons with hover

a::hover{

color: red;

}

button::hover{

background-color: blue;

}

Both rules above will trigger the validation error and will likely be ignored by browsers.

Correct: using a single colon with hover

a:hover{

color: red;

}

button:hover{

background-color: blue;

}

Correct usage of pseudo-classes vs. pseudo-elements

This example demonstrates how single-colon pseudo-classes and double-colon pseudo-elements are used together correctly:

a:hover{

color: red;

}

a:focus{

outline:2px solid blue;

}

a::before{

content:"→ ";

}

Full HTML document with valid :hover usage

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Hover Example</title>

<style>

a:hover{

color: red;

text-decoration: underline;

}

</style>

</head>

<body>

<ahref="#">Hover over this link</a>

</body>

</html>

Quick Reference

If you encounter this validation error, search your stylesheets for ::hover and replace every instance with :hover. The same fix applies if you accidentally use double colons with other pseudo-classes like ::focus or ::active.

The @font-feature-values at-rule lets you define human-readable names for OpenType font feature indexes, which you can then reference using properties like font-variant-alternates. For example, instead of remembering that swash index 1 maps to a "fancy" style, you can define a named value and use it semantically throughout your CSS. This is a legitimate and useful feature defined in the CSS Fonts Module Level 4 specification.

The validation error occurs because the W3C CSS validator does not always keep pace with newer CSS specifications. The @font-feature-values rule, along with its associated feature type blocks like @swash, @styleset, @character-variant, @ornaments, @annotation, and @stylistic, may simply not be in the validator's recognized grammar yet. This does not mean your CSS is broken or invalid — it means the validator has a gap in its coverage.

That said, there are practical reasons to consider alternatives. If you need to pass strict W3C validation (for example, as a project requirement or contractual obligation), or if you need to support older browsers that lack @font-feature-values support, the font-feature-settings property offers a more widely recognized way to activate OpenType features. The tradeoff is that font-feature-settings uses raw four-character OpenType feature tags instead of friendly names, making it less readable but more portable.

How to Fix

You have several options:

1. Ignore the warning. If your target browsers support @font-feature-values, the CSS is valid per the spec. The validator error is a false positive.
2. Move the at-rule to an external stylesheet. If you're validating HTML and the CSS is in a <style> block, moving it to an external .css file may help you separate concerns and skip CSS validation during HTML checks.
3. Replace with font-feature-settings. Use the lower-level property to activate OpenType features directly by their tag codes.

Examples

Code that triggers the validation error

@font-feature-values"MyFamily"{

@swash{

fancy:1;

}

}

p{

font-family:"MyFamily", serif;

font-variant-alternates:swash(fancy);

}

The validator does not recognize @font-feature-values and flags it as an error, even though this is spec-compliant CSS.

Fixed: Using font-feature-settings instead

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Font Feature Example</title>

<style>

p{

font-family:"MyFamily", serif;

font-feature-settings:"swsh"1;

}

</style>

</head>

<body>

<p>This text uses OpenType swash glyphs via font-feature-settings.</p>

</body>

</html>

The font-feature-settings property accepts OpenType feature tags directly. Common tags include "swsh" for swashes, "smcp" for small caps, "liga" for standard ligatures, and "onum" for oldstyle numerals. This approach avoids the unrecognized at-rule error entirely.

Fixed: Keeping @font-feature-values with a fallback

If you want to use the more readable @font-feature-values syntax while also providing fallback support, you can combine both approaches:

p{

font-family:"MyFamily", serif;

font-feature-settings:"swsh"1;

font-variant-alternates:swash(fancy);

}

@font-feature-values"MyFamily"{

@swash{

fancy:1;

}

}

Browsers that understand font-variant-alternates and @font-feature-values will use the named value. Others will fall back to font-feature-settings. The validation error will persist with this approach, but your CSS will be robust and spec-compliant regardless.

The @view-transition at-rule is valid CSS but is not yet recognized by the W3C CSS validator because it is a relatively new feature defined in the CSS View Transitions Module Level 2 specification.

The @view-transition at-rule opts a document into cross-document view transitions when navigating between two same-origin pages. It is placed in the CSS of the destination page (the page being navigated to) and accepts a navigation descriptor that controls when the transition activates.

@view-transition{

navigation: auto;

}

The navigation descriptor accepts these values:

• none — no cross-document view transition occurs (default).
• auto — the transition activates for same-origin navigations where the navigation type is traverse, push, or replace, as long as the navigation does not include a cross-origin redirect.

Because the W3C CSS validator has not yet added support for this at-rule, the warning cannot be fixed by changing your code. The CSS itself is correct per the specification. Browser support is available in Chromium-based browsers (Chrome 126+, Edge 126+).

You can safely ignore this validator warning. If you want a completely clean validation output, move the @view-transition rule into a separate stylesheet so it does not interfere with validation of the rest of your CSS, or suppress the warning in your CI pipeline.

The vertical-align property controls the vertical positioning of inline-level elements (like <span>, <img>, and <a>) and table-cell elements (<td>, <th>) relative to their surrounding content or cell. Unlike some other CSS properties (such as float or border), vertical-align has no none keyword. Attempting to use none results in an invalid declaration that browsers will ignore, meaning the element will fall back to the default value of baseline.

This mistake often happens when a developer wants to "reset" or "remove" vertical alignment. Since there is no none value, the correct approach is to either set vertical-align: baseline (the initial value) or remove the vertical-align declaration altogether.

The valid keyword values for vertical-align are:

• baseline — aligns the element's baseline with the parent's baseline (default)
• sub — aligns as a subscript
• super — aligns as a superscript
• text-top — aligns with the top of the parent's font
• text-bottom — aligns with the bottom of the parent's font
• middle — aligns the middle of the element with the baseline plus half the x-height of the parent
• top — aligns the top of the element with the top of the tallest element on the line
• bottom — aligns the bottom of the element with the bottom of the lowest element on the line

In addition to keywords, vertical-align also accepts length values (e.g., 5px, 0.5em) and percentage values (e.g., 50%), which offset the element relative to the baseline.

Using an invalid value like none causes a W3C validation error and means your intended styling is silently ignored by the browser. This can lead to unexpected layout results that are difficult to debug, especially in table layouts or inline formatting contexts where vertical alignment significantly affects appearance.

Examples

❌ Invalid: using none

<p>

Text with an <imgsrc="icon.png"alt="icon"style="vertical-align: none;"> inline image.

</p>

The validator will report that none is not a valid vertical-align value. The browser ignores the declaration and defaults to baseline.

✅ Fixed: using a valid keyword

If you want the image vertically centered with the text, use middle:

<p>

Text with an <imgsrc="icon.png"alt="icon"style="vertical-align: middle;"> inline image.

</p>

✅ Fixed: resetting to the default

If your intent was to "remove" any vertical alignment, use baseline (the initial value) or simply remove the property:

<p>

Text with an <imgsrc="icon.png"alt="icon"style="vertical-align: baseline;"> inline image.

</p>

❌ Invalid: none in a stylesheet for table cells

<style>

td.reset{

vertical-align: none;

}

</style>

<table>

<tr>

<tdclass="reset">Cell content</td>

</tr>

</table>

✅ Fixed: valid value for table cells

For table cells, the default vertical-align value is middle in most browsers. To explicitly reset it or set a specific alignment:

<style>

td.top-aligned{

vertical-align: top;

}

</style>

<table>

<tr>

<tdclass="top-aligned">Cell content</td>

</tr>

</table>

✅ Fixed: using a length value

You can also use a specific length to offset the element from the baseline:

<p>

Text with a <spanstyle="vertical-align:4px;">slightly raised</span> word.

</p>

Choose the value that matches your design intent — baseline to reset, middle or top for common alignment needs, or a specific length or percentage for precise control.

An invalid value was assigned to the CSS visibility property inside your HTML document.

The visibility property controls whether an element is visually displayed without affecting the document layout. Unlike display: none, a hidden element still occupies space on the page.

The accepted values for visibility are:

• visible — the element is shown (default).
• hidden — the element is invisible but still takes up space.
• collapse — used primarily with table rows and columns to remove them without affecting the table layout. On non-table elements, it behaves like hidden.

This error typically occurs when you use a value meant for a different property, such as none (which belongs to display), or a misspelled value like hiden or visble.

Invalid Example

<pstyle="visibility: none;">This text is hidden.</p>

The value none is not valid for visibility. You likely meant hidden or intended to use the display property instead.

Fixed Example

Using the correct visibility value:

<pstyle="visibility: hidden;">This text is hidden but still takes up space.</p>

Or, if you want the element to be fully removed from the layout, use display instead:

<pstyle="display: none;">This text is completely removed from the layout.</p>

The white-space property is a shorthand that combines the behavior of white-space-collapse and text-wrap-mode. When you use a value that doesn't match any of the accepted keywords — whether due to a typo, a made-up value, or a value that belongs to a different CSS property — the W3C validator flags it as invalid. This commonly happens when authors confuse values from related properties (like using break-spaces where it isn't supported in inline styles being validated, or misspelling nowrap as no-wrap).

Using invalid CSS values means browsers will ignore the declaration entirely, falling back to the default behavior (white-space: normal). This can cause unexpected text wrapping or whitespace collapsing that breaks your layout. Keeping your CSS valid ensures consistent rendering across browsers and makes your stylesheets easier to maintain and debug.

The accepted values for white-space are:

• normal — Collapses whitespace sequences, wraps text as needed (default).
• nowrap — Collapses whitespace but suppresses line breaks; text won't wrap.
• pre — Preserves whitespace and line breaks exactly as written, like the <pre> element.
• pre-wrap — Preserves whitespace and line breaks, but also allows text to wrap when necessary.
• pre-line — Collapses whitespace sequences into a single space, but preserves explicit line breaks and allows wrapping.
• break-spaces — Similar to pre-wrap, but trailing spaces and spaces at the end of lines don't hang and do affect box sizing.

Additionally, CSS Text Level 4 introduced shorthand combinations using white-space-collapse and text-wrap-mode keywords, such as collapse, preserve, wrap, and preserve nowrap. However, support for these newer shorthand forms varies, and older validators or browsers may not recognize them.

Global CSS values (inherit, initial, revert, revert-layer, unset) are also valid.

Examples

Incorrect: invalid value triggers the error

A common mistake is using no-wrap (with a hyphen) instead of the correct nowrap:

<pstyle="white-space: no-wrap;">This text should not wrap.</p>

Another common mistake is using a value from a different property entirely:

<pstyle="white-space: hidden;">This text has an invalid white-space value.</p>

Correct: using valid white-space values

<pstyle="white-space: nowrap;">This text will not wrap to a new line.</p>

<pstyle="white-space: pre-wrap;">This text preserves whitespace

and line breaks, but also wraps when needed.</p>

<pstyle="white-space: pre-line;">This collapses extra spaces

but preserves explicit line breaks.</p>

Correct: using the property in a <style> block

<!DOCTYPE html>

<htmllang="en">

<head>

<title>White-space example</title>

<style>

.no-wrap{

white-space: nowrap;

}

.preserve{

white-space: pre-wrap;

}

</style>

</head>

<body>

<pclass="no-wrap">This long paragraph will stay on a single line without wrapping.</p>

<pclass="preserve">This preserves multiple spaces

and line breaks exactly as written.</p>

</body>

</html>

If you encounter this validation error, double-check your white-space value for typos and confirm it matches one of the recognized keywords listed above.