HTML Guides for CSS

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

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

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

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

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

How to fix it:

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

Examples

Incorrect: Using font to set only the weight

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

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

Correct: Using font-weight directly

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

Incorrect: Missing font-family in the shorthand

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

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

Correct: Complete font shorthand

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

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

Correct: Minimal valid font shorthand

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

Correct: Using individual properties instead of the shorthand

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

Each property set individually.

</p>

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

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

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

Why this matters

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

How to fix it

Replace auto with a valid value for gap:

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

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

Examples

Incorrect: using auto as a gap value

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

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

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

Correct: using a fixed length

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

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

Correct: using separate row and column gaps

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

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

Correct: using a percentage for responsive spacing

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

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

</div>

Correct: using clamp() for fluid responsive gaps

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

<div>Item 1</div>

<div>Item 2</div>

<div>Item 3</div>

<div>Item 4</div>

</div>

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

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

Why This Happens

Several kinds of invalid values can trigger this error:

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

Valid Syntax

The grid-column shorthand accepts:

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

Each <grid-line> can be:

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

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

Why It Matters

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

Examples

❌ Invalid: Using 0 as a line number

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

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

</div>

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

✅ Fixed: Using a valid line number

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

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

</div>

❌ Invalid: Unrecognized keyword

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

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

</div>

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

✅ Fixed: Using span to cover all columns

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

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

</div>

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

❌ Invalid: span 0

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

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

</div>

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

✅ Fixed: Using a positive span value

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

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

</div>

❌ Invalid: Malformed syntax with a comma

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

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

</div>

✅ Fixed: Using the / separator

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

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

</div>

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

Quick Reference of Valid Patterns

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

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

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

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

Valid values

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

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

Common causes

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

Examples

Incorrect: invalid keyword

<style>

.grid {

display: grid;

grid-template-columns: undefined;

}

</style>

Incorrect: missing unit on a length

<style>

.grid {

display: grid;

grid-template-columns: 200 1fr;

}

</style>

Incorrect: malformed repeat() syntax

<style>

.grid {

display: grid;

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

}

</style>

Correct: using fr units

<style>

.grid {

display: grid;

grid-template-columns: 1fr 2fr;

}

</style>

Correct: mixing lengths, fr, and auto

<style>

.grid {

display: grid;

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

}

</style>

Correct: using repeat() and minmax()

<style>

.grid {

display: grid;

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

}

</style>

Correct: named grid lines with track sizes

<style>

.grid {

display: grid;

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

}

</style>

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

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

Common causes of this error include:

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

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

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

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

Examples

Incorrect — invalid values

<style>

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

.grid-a {

display: grid;

grid-template-rows: full auto;

}

/* ERROR: space between number and unit */

.grid-b {

display: grid;

grid-template-rows: 100 px 200 px;

}

/* ERROR: bare number without a unit */

.grid-c {

display: grid;

grid-template-rows: 100 200;

}

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

.grid-d {

display: grid;

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

}

</style>

Correct — valid track sizes

<style>

/* Fixed pixel heights */

.grid-a {

display: grid;

grid-template-rows: 100px auto;

}

/* Flexible units */

.grid-b {

display: grid;

grid-template-rows: 1fr 2fr;

}

/* Repeat function with correct syntax */

.grid-c {

display: grid;

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

}

/* Minmax with auto */

.grid-d {

display: grid;

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

}

</style>

Full working example

<!DOCTYPE html>

<html lang="en">

<head>

<title>Grid template rows example</title>

<style>

.grid-container {

display: grid;

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

gap: 8px;

height: 400px;

}

.grid-container > div {

background: #e0e0e0;

padding: 16px;

}

</style>

</head>

<body>

<div class="grid-container">

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

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

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

</div>

</body>

</html>

Using fit-content() and named lines

<style>

.grid {

display: grid;

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

}

</style>

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

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

This error commonly occurs in a few scenarios:

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

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

How to Fix It

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

Examples

Incorrect: Missing unit on a numeric value

<style>

.box {

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

}

</style>

Incorrect: Unrecognized keyword

<style>

.box {

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

}

</style>

Incorrect: Misspelled unit

<style>

.box {

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

}

</style>

Correct: Valid length values, percentages, and keywords

<style>

.fixed {

height: 200px;

}

.relative {

height: 70%;

}

.viewport {

height: 100vh;

}

.flexible {

height: auto;

}

.zero {

height: 0;

}

.intrinsic {

height: min-content;

}

.calculated {

height: calc(100vh - 60px);

}

</style>

Correct: Using height in context

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

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

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

</p>

</div>

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

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

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

The left property accepts the following value types:

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

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

Examples

Missing unit (triggers the error)

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

Positioned element

</div>

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

Typo in unit (triggers the error)

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

Positioned element

</div>

Fixed with a valid length unit

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

Positioned element

</div>

Fixed with a percentage

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

Positioned element

</div>

Fixed with the auto keyword

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

Positioned element

</div>

Fixed with calc()

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

Positioned element

</div>

Zero without a unit (valid)

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

Positioned element

</div>

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

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

Common causes of this error include:

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

The valid values for the left property are:

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

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

Examples

Invalid: Using an unsupported keyword

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

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

Invalid: Missing unit on a non-zero number

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

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

Invalid: Misspelled unit

The unit xp does not exist in CSS.

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

Valid: Using a length value

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

Valid: Using a percentage

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

Valid: Using the auto keyword

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

Valid: Using zero without a unit

Zero does not require a unit in CSS.

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

Valid: Using inherit

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

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

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

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

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

How to Fix It

1. Trace the source of the value. Search your codebase for where letter-spacing is set. If it's an inline style, look at the JavaScript or server-side code that generates it.

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

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

4. Fix the root cause. Determine why the calculation produces NaN — common causes include missing data attributes, undefined variables, or parsing non-numeric strings.

Examples

❌ Invalid: NaN concatenated with a unit

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

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

The JavaScript that likely produced it:

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

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

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

✅ Fixed: Validate the value before applying it

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

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

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

This produces valid inline CSS:

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

✅ Fixed: Using a static CSS value

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

<style>

.spaced-text {

letter-spacing: 0.1rem;

}

</style>

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

✅ Fixed: Server-side template with a guard

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

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

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

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

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

Valid letter-spacing values for reference

The letter-spacing property accepts:

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

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

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

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

Common causes of this error include:

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

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

Examples

Invalid character instead of semicolon

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

<style>

h1 {

color: blue@

font-size: 24px;

}

</style>

Replace @ with a proper semicolon:

<style>

h1 {

color: blue;

font-size: 24px;

}

</style>

Smart quotes in font-family

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

<style>

body {

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

}

</style>

Use straight double quotes instead:

<style>

body {

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

}

</style>

Stray character in an inline style

An accidental backtick in a style attribute triggers the error:

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

Remove the invalid character:

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

Invisible non-breaking space

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

<style>

.box {

display:\u00A0flex;

}

</style>

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

<style>

.box {

display: flex;

}

</style>

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

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

Common mistakes that trigger this error include:

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

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

Valid line-height values

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

Examples

❌ Incorrect: invalid values that trigger the error

<!-- Misspelled keyword -->

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

<!-- Invalid unit -->

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

<!-- Malformed number -->

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

<!-- Unsupported keyword -->

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

<!-- Negative value -->

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

✅ Correct: valid line-height values

<!-- Keyword -->

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

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

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

<!-- Length with px -->

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

<!-- Length with em -->

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

<!-- Percentage -->

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

Full document example

<!DOCTYPE html>

<html lang="en">

<head>

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

</head>

<body>

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

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

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

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

</body>

</html>

Tip: unitless vs. percentage/length

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

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

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

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

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

HTML examples

Invalid: negative line-height value

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

Paragraph text

</p>

Valid: positive value or normal

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

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

Paragraph text

</p>

<!-- Browser default spacing -->

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

Paragraph text

</p>

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

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

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>

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

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

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

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

Fix: Replace middle with center:

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

Invalid: typo in the value

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

Fix: Correct the spelling:

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

Invalid: using a non-existent value

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

Fix: Choose a valid alignment value:

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

Invalid: using a vertical alignment value

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

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

Valid examples showing all common values

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

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

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

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

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

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

The value inter-ideograph is not part of the CSS text-justify specification and will not pass validation.

The text-justify property controls how the browser distributes spacing when text-align is set to justify. The value inter-ideograph was an Internet Explorer proprietary extension that added extra spacing between ideographic (CJK) characters and words. It was never standardized by the W3C and is not recognized by modern browsers.

The valid values for text-justify in the current CSS Text Module Level 3 specification are:

• auto — the browser chooses the best justification method based on the content language. For CJK text, most browsers already apply inter-ideograph-style spacing automatically with this value.
• inter-word — spacing is distributed between words only (best for Latin scripts).
• inter-character — spacing is distributed between characters (useful for CJK text).
• none — disables justification.

For content that mixes CJK and Latin text, auto is usually the best choice, since the browser will apply appropriate spacing rules for each script.

HTML examples

Before (invalid)

<p style="text-align: justify; text-justify: inter-ideograph;">

This text uses a non-standard value.

</p>

After (valid)

<p style="text-align: justify; text-justify: auto;">

This text uses a valid value. The browser applies

appropriate justification based on the content language.

</p>

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

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

✅ Fixed: value within range

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