HTML Guides - issues tagged as css

A “style” element in “body” must be the first child of its parent.

Attribute “height” not allowed on element “table” at this point.

The <table> element in HTML supports a limited set of attributes — primarily global attributes like class, id, and style. The height attribute was never part of the HTML standard for tables (unlike width, which was valid in HTML 4 but has since been deprecated). Despite this, many browsers historically accepted height on <table> as a non-standard extension, which led to its widespread but incorrect use.

Because height is not a recognized attribute on <table>, using it means your markup is invalid and may behave inconsistently across browsers. Some browsers might honor it, others might ignore it entirely, and future browser versions could change their behavior at any time. Relying on non-standard attributes makes your code fragile and harder to maintain.

The fix is straightforward: remove the height attribute from the <table> element and use CSS to set the desired height. You can apply the CSS inline via the style attribute, or better yet, use an external or internal stylesheet with a class or ID selector.

Examples

❌ Invalid: `height` attribute on `<table>`

<tr>

<td>Score</td>

</tr>

<tr>

<td>Alice</td>

</tr>

</table>

This triggers the validator error: Attribute "height" not allowed on element "table" at this point.

✅ Fixed: Using inline CSS

<tr>

<td>Score</td>

</tr>

<tr>

<td>Alice</td>

</tr>

</table>

✅ Fixed: Using a CSS class (preferred)

<style>

.tall-table {

height: 300px;

}

</style>

<tr>

<td>Score</td>

</tr>

<tr>

<td>Alice</td>

</tr>

</table>

Using a class keeps your HTML clean and makes it easy to adjust the styling later without touching the markup. Note that min-height is often a better choice than height for tables, since table content can naturally grow beyond a fixed height, and min-height ensures the table is at least a certain size without clipping content.

Bad value X for attribute “media” on element “link”: Deprecated media feature “max-device-width”. For guidance, see the Deprecated Media Features section in the current Media Queries specification.

The device-width and device-height media features (along with their min- and max- prefixed variants) originally referred to the physical dimensions of the device's entire screen, regardless of how much space was actually available to the document. In practice, this distinction caused confusion and inconsistent behavior across browsers. On most modern devices and browsers, device-width and width return the same value anyway, making the device-* variants redundant.

The device-* media features were frequently used as a proxy to detect mobile devices, but this was never a reliable approach. A narrow browser window on a desktop monitor would not trigger a max-device-width query even though the available layout space was small. Conversely, modern phones and tablets with high-resolution screens can report large device widths that don't reflect the actual CSS viewport size. The viewport-based alternatives (width, height, aspect-ratio) more accurately represent the space available for rendering your content.

Using deprecated media features causes W3C validation warnings and may eventually lose browser support entirely. Replacing them ensures your stylesheets are future-proof, standards-compliant, and behave consistently across all devices and window sizes.

How to fix it

Replace any device-width, device-height, or device-aspect-ratio media feature (including min- and max- prefixed versions) with the corresponding viewport-based equivalent:

Deprecated feature	Replacement
`device-width`	`width`
`min-device-width`	`min-width`
`max-device-width`	`max-width`
`device-height`	`height`
`min-device-height`	`min-height`
`max-device-height`	`max-height`
`device-aspect-ratio`	`aspect-ratio`

The width media feature describes the width of the viewport (the targeted display area of the output device), including the size of a rendered scroll bar if any. This is the value you almost always want when writing responsive styles.

Examples

Incorrect: using deprecated `max-device-width`

This triggers the validation error because max-device-width is deprecated:

Correct: using `max-width` instead

Replace max-device-width with max-width to query the viewport width:

Incorrect: using deprecated `min-device-width` in a range

Correct: using viewport-based equivalents

Incorrect: using deprecated `device-aspect-ratio`

Correct: using `aspect-ratio`

Applying the same fix in CSS `@media` rules

The same deprecation applies to @media rules inside stylesheets. While the W3C validator specifically flags the media attribute on <link> elements, you should update your CSS as well:

/* Deprecated */

@media only screen and (max-device-width: 768px) {

.sidebar { display: none; }

}

/* Correct */

@media only screen and (max-width: 768px) {

.sidebar { display: none; }

}

If your site relies on a <meta name="viewport"> tag (as most responsive sites do), the viewport width already matches the device's CSS pixel width, so switching from device-width to width will produce identical results in virtually all cases.

Bad value X for attribute “media” on element “link”: Deprecated media feature “min-device-width”. For guidance, see the Deprecated Media Features section in the current Media Queries specification.

The device-width, device-height, and device-aspect-ratio media features (including their min- and max- prefixed variants) refer to the physical dimensions of the entire screen, not the available space where your content is actually rendered. This distinction matters because the viewport size — the area your page occupies — can differ significantly from the full device screen size. For example, a browser window might not be maximized, or browser chrome might consume screen real estate. Using device-based queries means your responsive breakpoints may not match what users actually see.

These features were also commonly used as a proxy for detecting mobile devices, but this approach is unreliable. A small-screened laptop and a large tablet can have similar device widths, making device-based detection a poor heuristic. The W3C deprecated these features and recommends using viewport-based alternatives that more accurately reflect the rendering context of your document.

Beyond standards compliance, using deprecated media features can cause issues with future browser support. While current browsers still recognize them, there is no guarantee they will continue to do so. Replacing them now ensures your stylesheets remain functional and forward-compatible.

How to fix it

Replace each deprecated device-* media feature with its viewport-based equivalent:

Deprecated feature	Replacement
`device-width`	`width`
`min-device-width`	`min-width`
`max-device-width`	`max-width`
`device-height`	`height`
`min-device-height`	`min-height`
`max-device-height`	`max-height`
`device-aspect-ratio`	`aspect-ratio`
`min-device-aspect-ratio`	`min-aspect-ratio`
`max-device-aspect-ratio`	`max-aspect-ratio`

The width media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport including the size of a rendered scroll bar (if any). This is almost always the value you actually want when building responsive layouts.

Examples

Incorrect: using deprecated `min-device-width`

This triggers the validation error because min-device-width is deprecated:

Correct: using `min-width` instead

Replace min-device-width with min-width to query the viewport width:

Incorrect: using `max-device-width` for a mobile breakpoint

Correct: using `max-width`

Incorrect: using `device-aspect-ratio`

Correct: using `aspect-ratio`

Incorrect: combining multiple deprecated features

Correct: using viewport-based equivalents

The same replacements apply when these deprecated features appear in CSS @media rules or in the media attribute on <style> and <source> elements. Updating them across your entire codebase ensures consistent, standards-compliant responsive behavior.

Bad value X for attribute “sizes” on element “img”: Bad CSS number token: Expected a minus sign or a digit but saw “a” instead at “auto,”.

The sizes attribute works together with srcset to help the browser choose the most appropriate image source for the current layout. It accepts a comma-separated list of entries, where each entry is an optional media condition followed by a CSS length value (called a "source size value"). The browser evaluates these entries to determine the intended display width of the image before it downloads it. Valid length values include viewport-relative units like 100vw, absolute units like 472px, or calc() expressions like calc(100vw - 2rem).

The value auto was not part of the original HTML specification for the sizes attribute. However, the sizes="auto" value has been added to the HTML living standard specifically for use with lazy-loaded images (loading="lazy"). When both loading="lazy" and sizes="auto" are present, the browser can defer size calculation until layout time, since the image won't be fetched immediately anyway. Some validators may not yet recognize this newer addition, or the error may appear because auto is being used without loading="lazy", or combined incorrectly with other size entries like sizes="auto, 100vw".

This validation error matters for several reasons. First, if the browser doesn't understand the sizes value, it may fall back to a default of 100vw, which could cause it to download a larger image than necessary, hurting performance. Second, malformed attribute values can lead to unpredictable behavior across different browsers. Third, standards compliance ensures your markup works reliably now and in the future.

How to Fix

You have a few options depending on your situation:

Replace auto with a valid CSS length. If you know the intended display size of the image, specify it directly. This is the most broadly compatible approach.
Use sizes="auto" only with loading="lazy". If you want the browser to automatically determine the size, ensure you also include loading="lazy" and a width attribute on the image. Note that some validators may still flag this until they update their rules.
Remove auto from a comma-separated list. If you have something like sizes="auto, (max-width: 600px) 100vw, 50vw", remove the auto entry entirely.

Examples

Incorrect: Using `auto` without lazy loading

This triggers the validation error because auto is not a valid CSS length in the traditional sizes syntax.

<img

src="image.jpg"

srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"

sizes="auto, 100vw"

alt="A scenic mountain landscape"

>

Fixed: Using a valid CSS length value

Replace auto with a concrete size or a set of media-conditioned sizes.

<img

src="image.jpg"

srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"

sizes="(max-width: 472px) 100vw, 472px"

alt="A scenic mountain landscape"

>

In this example, when the viewport is 472 pixels wide or smaller, the image takes up the full viewport width (100vw). For wider viewports, the browser knows the image will display at 472px wide and selects the best source from srcset accordingly.

Fixed: Using `auto` with lazy loading

If you want the browser to determine the display size automatically, pair sizes="auto" with loading="lazy" and explicit dimensions.

<img

src="image.jpg"

srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"

sizes="auto"

width="600"

height="400"

loading="lazy"

alt="A scenic mountain landscape"

>

The width and height attributes help the browser reserve the correct space in the layout, and loading="lazy" allows the browser to defer both loading and size calculation until the image is near the viewport.

Fixed: Using `calc()` for dynamic sizing

If your image sits inside a container with padding, you can use calc() for a precise size hint.

<img

src="image.jpg"

srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"

sizes="calc(100vw - 2rem)"

alt="A scenic mountain landscape"

>

Bad value X for attribute “sizes” on element “img”: Bad CSS number token: Expected a minus sign or a digit but saw “"” instead at Y.

CSS: “align-items”: “auto” is not a “align-items” value.

The align-items property controls how flex or grid items are aligned along the cross axis of their container. While many CSS properties accept auto as a value, align-items is not one of them. The CSS specification defines a specific set of accepted values, and using auto will cause the declaration to be ignored by browsers, potentially breaking your intended layout.

This mistake often stems from confusion with the related property align-self, which does accept auto as its default value. When align-self is set to auto, it defers to the parent container's align-items value. However, align-items itself has no such delegation mechanism — it is the property that sets the default alignment for all items in the container.

The valid values for align-items include:

normal — behaves as stretch in flex containers and has context-dependent behavior in other layout modes.
stretch — items are stretched to fill the container along the cross axis (the default behavior in flexbox).
center — items are centered along the cross axis.
flex-start / start — items are aligned to the start of the cross axis.
flex-end / end — items are aligned to the end of the cross axis.
baseline / first baseline / last baseline — items are aligned based on their text baselines.
self-start / self-end — items are aligned based on their own writing mode.

If you intended the default behavior, use stretch (for flexbox) or normal. If you were trying to reset the property, use initial, unset, or revert instead of auto.

Examples

Incorrect: using `auto` as a value

</div>

This triggers the validation error because auto is not a recognized value for align-items.

Fixed: using `stretch` for default flexbox behavior

</div>

Fixed: using `center` to center items

</div>

Fixed: using `flex-start` to align items to the top

</div>

Correct use of `auto` with `align-self`

If your intention was to let a specific child item defer to its parent's alignment, use align-self: auto on the child element instead:

<p>Centered item</p>

<p style="align-self: auto;">Also centered (defers to parent)</p>

<p style="align-self: flex-end;">Aligned to the end</p>

</div>

Here, align-self: auto is valid on individual items and tells them to inherit the align-items value from the container.

CSS: “align-self”: X is not a “align-self” value.

CSS: “aspect-ratio”: X is not a “aspect-ratio” value.

The aspect-ratio CSS property defines the preferred width-to-height ratio of an element's box. Browsers use this ratio when calculating auto sizes and performing other layout functions, adjusting the element's dimensions to maintain the specified proportion even as the parent container or viewport changes size.

The ratio is expressed as <width> / <height>. If the slash and height portion are omitted, height defaults to 1. So aspect-ratio: 2 is equivalent to aspect-ratio: 2 / 1. The property also accepts the auto keyword, which tells the element to use its intrinsic aspect ratio (if it has one), and a combined form like auto 3 / 4, which prefers the intrinsic ratio but falls back to the specified one.

This validation error typically occurs for several reasons:

Using invalid separators or syntax, such as a colon (:) instead of a slash (/), e.g., aspect-ratio: 16:9.
Providing units, such as aspect-ratio: 16px / 9px. The values must be unitless positive numbers.
Using zero or negative numbers, which are not valid. Both parts of the ratio must be positive (> 0).
Providing a string or unrecognized keyword, such as aspect-ratio: wide or aspect-ratio: "16/9".
Missing spaces around the slash, though this is less common — 16/9 may work in browsers but the canonical form uses spaces: 16 / 9.
Using the property in inline style attributes validated against an older CSS level where aspect-ratio wasn't yet recognized by the validator.

Getting this value right matters for layout consistency across browsers. An invalid value will be ignored entirely by the browser, meaning the element won't maintain any aspect ratio, potentially breaking your design. It's especially important for responsive images, video containers, and card layouts where maintaining proportions is critical.

Examples

Incorrect: using a colon as the separator

The colon syntax (common in video specifications) is not valid CSS. The validator will reject 16:9 as an aspect-ratio value.

Incorrect: using units in the ratio

The ratio values must be unitless numbers. Adding px or any other unit makes the value invalid.

Incorrect: using zero in the ratio

Both numbers in the ratio must be strictly positive. Zero is not allowed.

Correct: standard ratio with a slash

Correct: single number (height defaults to 1)

This is equivalent to aspect-ratio: 2 / 1.

Correct: square ratio

Correct: using the `auto` keyword

The element uses its intrinsic aspect ratio if available.

Correct: combining `auto` with a fallback ratio

The browser prefers the image's intrinsic ratio, but if it hasn't loaded yet or has no intrinsic ratio, it falls back to 4 / 3. This is useful for preventing layout shift while images load.

Correct: using global CSS values

Global values like inherit, initial, unset, revert, and revert-layer are also valid.

CSS: “background-attachment”: X is not a “background-attachment” value.

CSS: “background-color”: Lexical error at line L, column C. Encountered: ";" (59), after : "#".

CSS: “background-color”: “X” is not a “background-color” value.

The background-color property accepts a specific set of color value types defined in the CSS Color specification. When you provide something that doesn't match any of these types — like a plain number, a misspelled keyword, or a malformed hex code — the validator flags it as an invalid value.

Common mistakes that trigger this error include:

Bare numbers like 0 or 255 — numbers alone aren't colors, even if you intended black or white.
Misspelled color keywords like grren instead of green, or trasparent instead of transparent.
Malformed hex codes like #GGG, #12345, or missing the # prefix entirely.
Incorrect function syntax like rgb(255 0 0 0.5) when mixing legacy comma syntax with modern space syntax improperly, or using rgba with only three arguments.
Invalid units or strings like background-color: 10px or background-color: "red" (color values should not be quoted).

While browsers are generally forgiving and will simply ignore an invalid background-color declaration, this means your intended styling silently fails. The element falls back to its inherited or default background, which can cause visual bugs, poor contrast, or accessibility issues that are hard to track down. Validating your CSS catches these problems early.

Valid color formats

The background-color property accepts these value types:

Named keywords: red, blue, transparent, currentcolor, etc.
Hex notation: #rgb, #rrggbb, #rgba, #rrggbbaa
RGB/RGBA: rgb(255, 0, 0) or rgb(255 0 0 / 0.5)
HSL/HSLA: hsl(120, 100%, 50%) or hsl(120 100% 50% / 0.5)
The keyword inherit, initial, unset, or revert

Examples

Invalid: bare number as a color

A plain number like 0 is not a valid color value, even though black could be represented as all zeros in RGB.

<style>

.banner {

background-color: 0;

}

</style>

Invalid: misspelled keyword

<style>

.banner {

background-color: trasparent;

}

</style>

Invalid: quoted string

Color values must not be wrapped in quotes.

<style>

.banner {

background-color: "red";

}

</style>

Invalid: malformed hex code

Hex codes must be 3, 4, 6, or 8 characters after the #.

<style>

.banner {

background-color: #12345;

}

</style>

Fixed: using a named color keyword

<style>

.banner {

background-color: black;

}

</style>

Fixed: using a hex color

<style>

.banner {

background-color: #000000;

}

</style>

Fixed: using `rgb()` notation

<style>

.banner {

background-color: rgb(0, 0, 0);

}

</style>

Fixed: using `rgba()` for semi-transparency

<style>

.banner {

background-color: rgba(0, 0, 0, 0.5);

}

</style>

Fixed: using `hsl()` notation

<style>

.banner {

background-color: hsl(210, 50%, 40%);

}

</style>

Fixed: using `transparent`

<style>

.banner {

background-color: transparent;

}

</style>

CSS: “background-image”: Parse Error.

When the CSS parser encounters a background-image value it cannot understand, it flags a parse error. This doesn't necessarily mean the browser won't render your styles — browsers are often more forgiving than validators — but it does indicate that your CSS doesn't conform to the specification. Invalid CSS can lead to unpredictable rendering across different browsers, makes your code harder to maintain, and may cause styles to silently fail in certain environments.

Common causes of this error include:

Missing the url() function around image paths.
Unquoted or improperly quoted URLs containing special characters like spaces or parentheses.
Typos in CSS function names (e.g., lnear-gradient instead of linear-gradient).
Using vendor-prefixed values (e.g., -webkit-linear-gradient) in contexts where the validator expects standard CSS.
Invalid gradient syntax, such as missing color stops, incorrect angle units, or malformed function arguments.
Using CSS custom properties (variables) or newer syntax in a style attribute, which the validator's CSS parser may not fully support.

To fix this, review the exact background-image declaration the validator is pointing to. Make sure all URLs are wrapped in url(), all gradients use correct function names and valid arguments, and all strings are properly quoted and closed.

Examples

Missing `url()` function

A bare file path without the url() wrapper is invalid:

Wrap the path in url():

Typo in gradient function name

Invalid gradient syntax

Missing color stops or using incorrect angle notation causes parse errors:

Angles need a unit (like deg), and gradients need at least two color stops:

Unescaped special characters in URL

File paths with spaces or parentheses need to be quoted:

Vendor-prefixed values

Using non-standard prefixed syntax can trigger a parse error in the validator:

Use the standard, unprefixed syntax instead. Modern browsers no longer need the prefix for gradients:

Multiple backgrounds with incorrect separator

Multiple background images must be separated by commas, not semicolons or spaces:

Moving styles to an external stylesheet

If the validator struggles with complex background-image values in inline style attributes, consider moving the CSS to a <style> block or external stylesheet, where the validator's CSS parser handles them more reliably:

<!DOCTYPE html>

<head>

<title>Background Image Example</title>

<style>

.hero {

background-image: url('hero.jpg');

background-size: cover;

}

</style>

</head>

<body>

</body>

</html>

CSS: “background”: only “0” can be a “length”. You must put a unit after your number.

CSS: “background-size”: X is not a “background-size” value.

CSS: “background”: X is an incorrect operator.

CSS: “background”: X is an incorrect URL.

CSS: “border-color”: “X” is not a “border-color” value.

The border-color property sets the color of an element's four borders. When the W3C validator reports that a given value "is not a border-color value," it means the value you provided doesn't match any recognized CSS color format. Common mistakes that trigger this error include using a bare number like 0 instead of a color, misspelling a color keyword (e.g., grren instead of green), forgetting the # prefix on a hex code, or passing an invalid argument to a color function.

This matters because browsers handle invalid CSS values unpredictably. When a browser encounters an unrecognized border-color value, it discards the entire declaration and falls back to the inherited or initial value (typically currentcolor). This can lead to inconsistent rendering across browsers and make your design behave in unexpected ways. Writing valid CSS ensures predictable, cross-browser results and keeps your stylesheets maintainable.

Valid color formats

The CSS border-color property accepts any valid <color> value, including:

Named keywords — red, blue, transparent, currentcolor, etc.
Hexadecimal — #rgb, #rrggbb, #rgba, #rrggbbaa
rgb() / rgba() — rgb(255, 0, 0) or rgb(255 0 0 / 50%)
hsl() / hsla() — hsl(0, 100%, 50%) or hsl(0 100% 50% / 0.5)

You can also specify one to four color values to target individual sides (top, right, bottom, left), following the standard CSS shorthand pattern.

Examples

Invalid: bare number instead of a color

A number like 0 is not a valid color value and triggers the error:

<style>

.box {

border: 1px solid;

border-color: 0;

}

</style>

Invalid: misspelled color keyword

Typos in color names are not recognized by CSS:

<style>

.box {

border: 1px solid;

border-color: grren;

}

</style>

Invalid: hex code missing the `#` prefix

Without the leading #, the value is treated as an unknown keyword:

<style>

.box {

border: 1px solid;

border-color: ff0000;

}

</style>

Fixed: using a named color keyword

<style>

.box {

border: 1px solid;

border-color: green;

}

</style>

Fixed: using a hexadecimal value

<style>

.box {

border: 1px solid;

border-color: #00ff00;

}

</style>

Fixed: using `rgb()` functional notation

<style>

.box {

border: 1px solid;

border-color: rgb(0, 128, 0);

}

</style>

Fixed: using `hsl()` functional notation

<style>

.box {

border: 1px solid;

border-color: hsl(120, 100%, 25%);

}

</style>

Fixed: setting different colors per side

You can provide up to four valid color values to control each border individually (top, right, bottom, left):

<style>

.box {

border: 1px solid;

border-color: red green blue orange;

}

</style>

Fixed: using `transparent` or `currentcolor`

The special keywords transparent and currentcolor are also valid:

<style>

.box {

border: 1px solid;

border-color: transparent;

}

.highlight {

color: navy;

border: 2px solid;

border-color: currentcolor;

}

</style>

If you're unsure whether a value is a valid CSS color, check the MDN <color> data type reference for the complete list of accepted formats.

CSS: “border-radius”: “none” is not a “border-radius” value.

The border-radius property controls the rounding of an element's corners. Its valid values include lengths (e.g., 5px, 1em), percentages (e.g., 50%), and CSS-wide keywords like inherit, initial, and unset. Unlike many other border-related properties, border-radius has no none keyword in its value syntax.

This confusion typically arises because developers associate "no effect" with the keyword none, which works for properties like border: none or text-decoration: none. However, border-radius describes a geometric measurement — the radius of the corner curve — so "zero radius" (0) is the correct way to express no rounding.

Using an invalid value means the browser will ignore the entire declaration. This can lead to unexpected results: if a parent stylesheet or an earlier rule sets a border-radius, your none declaration won't override it, and the element will retain its rounded corners. Fixing this ensures your CSS is standards-compliant, behaves predictably across browsers, and passes W3C validation.

How to fix it

To remove rounding, replace none with 0.
To set a specific radius, use a valid length (5px, 0.5em), a percentage (50%), or a CSS-wide keyword (inherit, initial, unset).
The same rule applies to the longhand properties: border-top-left-radius, border-top-right-radius, border-bottom-right-radius, and border-bottom-left-radius.

Examples

Incorrect: using `none`

<style>

.box {

border-radius: none; /* "none" is not a valid border-radius value */

}

</style>

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

Correct: removing rounded corners with `0`

<style>

.box {

border-radius: 0;

}

</style>

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

Correct: applying a specific radius

<style>

.circle {

width: 100px;

height: 100px;

border-radius: 50%;

}

.rounded {

border-radius: 8px;

}

.pill {

border-radius: 9999px;

}

</style>

<div class="circle">Circle</div>

<div class="rounded">Rounded</div>

<div class="pill">Pill shape</div>

Correct: resetting to the initial value

If you need to undo a border-radius set by another rule, you can use initial or unset, both of which resolve to 0:

<style>

.card {

border-radius: 12px;

}

.card.sharp {

border-radius: initial; /* Resets to 0 */

}

</style>

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

<div class="card sharp">Sharp-cornered card</div>

CSS: “border-X”: “undefined” is not a “color” value.

CSS: “border-style”: X is not a “border-style” value.

CSS: “border-top-width”: X negative values are not allowed.

CSS: “border”: “undefined” is not a “color” value.

The border shorthand property accepts up to three values: a width (e.g., 1px), a style (e.g., solid), and a color (e.g., black). When the validator encounters "undefined" in the color position, it rightfully rejects it because undefined is not a recognized CSS color keyword, hex value, or color function.

This issue most commonly appears in projects that use JavaScript to dynamically set inline styles. When a variable intended to hold a color value is undefined—perhaps because it wasn't initialized, a configuration value is missing, or a function didn't return a result—the rendered HTML ends up with a literal style="border: 1px solid undefined" in the markup. Build tools, templating engines, or server-side rendering can also produce this output if a variable isn't properly resolved.

Beyond failing validation, this is a real problem because browsers will discard the entire border declaration when they encounter an invalid value. This means the border won't render at all, which may break your layout or visual design in ways that are hard to debug. Ensuring valid CSS values keeps your styling predictable across all browsers.

How to fix it

Check for dynamic values. If the color is set via JavaScript or a templating engine, ensure the variable always resolves to a valid color string. Add fallback values or default assignments.
Replace the invalid value. Substitute undefined with a proper CSS color — a named color (red, black), a hex code (#333), an rgb() or hsl() function, or even transparent or currentcolor.
Remove the declaration. If no border is needed, remove the border property entirely rather than leaving an invalid value in place.

Examples

Incorrect: literal `undefined` as a color value

<div style="border: 1px solid undefined;">Content</div>

The validator rejects undefined because it is not a valid CSS color.

Incorrect: JavaScript producing `undefined` in markup

const borderColor = undefined; // missing configuration

document.getElementById("box").style.border = "2px dashed " + borderColor;

</script>

This produces border: 2px dashed undefined on the element.

Correct: using a valid color value

<div style="border: 1px solid black;">Content</div>

Correct: using a hex code or `rgb()` function

<div style="border: 2px dashed #ff6600;">Content</div>

<div style="border: 3px dotted rgb(0, 128, 255);">Content</div>

Correct: providing a fallback in JavaScript

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

const borderColor = getUserColor() || "#333";

document.getElementById("box").style.border = "2px solid " + borderColor;

</script>

By using || "#333", you ensure a valid color is always applied even when getUserColor() returns undefined.

Correct: using separate border properties

If you prefer more granular control, you can define each border sub-property individually:

<div style="border-width: 1px; border-style: solid; border-color: black;">Content</div>

Valid `border` shorthand reference

The border shorthand follows this pattern:

selector {

border: <width> <style> <color>;

}

Width: 1px, 2px, thin, medium, thick
Style: solid, dashed, dotted, double, groove, ridge, inset, outset, none
Color: any valid CSS color — named colors (red, blue), hex (#000), rgb(), hsl(), currentcolor, or transparent

All three values are optional in the shorthand, but any value you do include must be valid. The string undefined is never a valid CSS value. If your styles are generated dynamically, always validate or sanitize the output before it reaches the HTML.

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

css
color

The color property, along with properties like background-color, border-color, and outline-color, expects values that conform to the CSS Color specification. The validator triggers this error when it encounters something that doesn't match any valid color syntax. Common causes include:

Plain numbers like 0 or 123 — numbers alone aren't colors.
Typos in color keywords such as grean instead of green, or trasparent instead of transparent.
Malformed hex values like #GGG (invalid hex characters) or #12345 (wrong number of digits — hex colors must be 3, 4, 6, or 8 digits).
Incorrect function syntax such as rgb(255 255 255 / 50) missing the % on the alpha value, or using legacy commas mixed with modern space-separated syntax.
Missing units or hash symbols like 000000 instead of #000000.

This matters because browsers handle invalid color values unpredictably. Most will simply ignore the declaration entirely, which means the element inherits its color from a parent or falls back to the browser default — potentially making text unreadable against its background. Writing valid CSS ensures consistent rendering across all browsers and improves the maintainability of your code.

Valid CSS color formats

CSS supports several color formats:

Format	Example	Notes
Named colors	`red`, `blue`, `transparent`	148 predefined keywords
Hexadecimal	`#ff0000`, `#f00`	3, 4, 6, or 8 digits
`rgb()` / `rgba()`	`rgb(255, 0, 0)`	Comma or space-separated
`hsl()` / `hsla()`	`hsl(0, 100%, 50%)`	Hue, saturation, lightness
`currentcolor`	`currentcolor`	Inherits the current `color` value

Examples

Invalid: plain number as a color

A bare number is not a recognized color value:

<style>

.example {

color: 0;

}

</style>

Invalid: typo in a color keyword

<style>

.example {

background-color: trasparent;

}

</style>

Invalid: hex value missing the `#` prefix

<style>

.example {

color: 000000;

}

</style>

Invalid: hex value with wrong digit count

<style>

.example {

color: #12345;

}

</style>

Fixed: using a named color keyword

<style>

.example {

color: black;

}

</style>

Fixed: using a hexadecimal color

<style>

.example {

color: #000000;

}

</style>

Fixed: using `rgb()`

<style>

.example {

color: rgb(0, 0, 0);

}

</style>

Fixed: using `hsl()`

<style>

.example {

color: hsl(0, 0%, 0%);

}

</style>

Fixed: using `rgba()` for semi-transparent color

<style>

.example {

color: rgba(0, 0, 0, 0.5);

}

</style>

Fixed: correcting the `transparent` keyword typo

<style>

.example {

background-color: transparent;

}

</style>

If you're unsure whether a value is valid, browser DevTools can help — most browsers will strike through or ignore invalid property values in the Styles panel, giving you a quick visual indicator of the problem.

CSS: “color”: X is not a valid color 3 or 6 hexadecimals numbers.

css
color

Hexadecimal color values in CSS must follow a specific format: the # symbol followed by exactly 3 or 6 hexadecimal digits. Each digit can be a number from 0 to 9 or a letter from A to F (case-insensitive). A 3-digit hex code is shorthand where each digit is expanded by duplication — for example, #F00 is equivalent to #FF0000. Common mistakes that trigger this error include using the wrong number of digits (e.g., 1, 2, 4, or 5), including non-hexadecimal characters (like G, Z, or special symbols), or omitting the # prefix.

The color CSS property sets the foreground color of an element's text and text decorations. It also establishes the currentcolor value, which acts as an indirect value for other properties like border-color. Because color cascades to many visual aspects of an element, an invalid value can cause the entire declaration to be ignored, meaning the element may inherit an unexpected color or fall back to browser defaults.

This matters for consistency across browsers. While some browsers may attempt to guess what you meant with a malformed hex code, others will discard the value entirely. This leads to unpredictable rendering. Using valid color values ensures your styles are applied reliably everywhere.

Note that CSS also supports 4-digit and 8-digit hex values (which include an alpha/transparency channel, e.g., #F00A or #FF0000AA). However, the W3C validator's inline style checker may not recognize these newer formats depending on the CSS level being validated. If you need transparency, consider using the rgba() function for broader validation compatibility.

Examples

Invalid hex color values

These examples will trigger the validation error:

<p style="color: #F;">Hello</p>

<p style="color: #FF;">Hello</p>

<p style="color: #FF00;">Hello</p>

<p style="color: #FF000;">Hello</p>

<p style="color: #FG0000;">Hello</p>

<p style="color: FF0000;">Hello</p>

Valid hex color values

Use exactly 3 or 6 hexadecimal digits after the #:

<p style="color: #F00;">Hello</p>

<p style="color: #FF0000;">Hello</p>

<p style="color: #FFF;">Hello</p>

<p style="color: #333333;">Hello</p>

<p style="color: #3a7bd5;">Hello</p>

Alternative color formats

If hex values are causing issues, CSS offers several other valid ways to specify colors:

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

<p style="color: rgb(255, 0, 0);">Hello</p>

<p style="color: rgba(255, 0, 0, 0.5);">Hello</p>

<p style="color: hsl(0, 100%, 50%);">Hello</p>

HTML Guides for css

Invalid example

Valid example

Examples

❌ Invalid: height attribute on <table>

✅ Fixed: Using inline CSS

✅ Fixed: Using a CSS class (preferred)

How to fix it

Examples

Incorrect: using deprecated max-device-width

Correct: using max-width instead

Incorrect: using deprecated min-device-width in a range

Correct: using viewport-based equivalents

Incorrect: using deprecated device-aspect-ratio

Correct: using aspect-ratio

Applying the same fix in CSS @media rules

How to fix it

Examples

Incorrect: using deprecated min-device-width

Correct: using min-width instead

Incorrect: using max-device-width for a mobile breakpoint

Correct: using max-width

Incorrect: using device-aspect-ratio

Correct: using aspect-ratio

Incorrect: combining multiple deprecated features

Correct: using viewport-based equivalents

How to Fix

Examples

Incorrect: Using auto without lazy loading

Fixed: Using a valid CSS length value

Fixed: Using auto with lazy loading

Fixed: Using calc() for dynamic sizing

Invalid example

Valid example

Examples

Incorrect: using auto as a value

Fixed: using stretch for default flexbox behavior

Fixed: using center to center items

Fixed: using flex-start to align items to the top

Correct use of auto with align-self

Invalid example

Valid example

Examples

Incorrect: using a colon as the separator

Incorrect: using units in the ratio

Incorrect: using zero in the ratio

Correct: standard ratio with a slash

Correct: single number (height defaults to 1)

Correct: square ratio

Correct: using the auto keyword

Correct: combining auto with a fallback ratio

Correct: using global CSS values

Invalid example

Valid example

How to fix it

Examples

❌ Incomplete hex value (triggers the error)

✅ Fixed with a valid hex color

❌ Truncated or invalid hex digits

✅ Fixed with a proper 3-digit shorthand hex color

✅ Alternative valid color formats

✅ Defensive approach for dynamic values

Valid color formats

Examples

Invalid: bare number as a color

Invalid: misspelled keyword

Invalid: quoted string

Invalid: malformed hex code

Fixed: using a named color keyword

Fixed: using a hex color

Fixed: using rgb() notation

Fixed: using rgba() for semi-transparency

Fixed: using hsl() notation

Fixed: using transparent

Examples

Missing url() function

Typo in gradient function name

Invalid gradient syntax

Unescaped special characters in URL

Vendor-prefixed values

❌ Invalid: `height` attribute on `<table>`

Incorrect: using deprecated `max-device-width`

Correct: using `max-width` instead

Incorrect: using deprecated `min-device-width` in a range

Incorrect: using deprecated `device-aspect-ratio`

Correct: using `aspect-ratio`

Applying the same fix in CSS `@media` rules

Incorrect: using deprecated `min-device-width`

Correct: using `min-width` instead

Incorrect: using `max-device-width` for a mobile breakpoint

Correct: using `max-width`

Incorrect: using `device-aspect-ratio`

Correct: using `aspect-ratio`

Incorrect: Using `auto` without lazy loading

Fixed: Using `auto` with lazy loading

Fixed: Using `calc()` for dynamic sizing

Incorrect: using `auto` as a value

Fixed: using `stretch` for default flexbox behavior

Fixed: using `center` to center items

Fixed: using `flex-start` to align items to the top

Correct use of `auto` with `align-self`

Correct: using the `auto` keyword

Correct: combining `auto` with a fallback ratio

Fixed: using `rgb()` notation

Fixed: using `rgba()` for semi-transparency

Fixed: using `hsl()` notation

Fixed: using `transparent`

Missing `url()` function

Invalid: hex code missing the `#` prefix

Fixed: using `rgb()` functional notation

Fixed: using `hsl()` functional notation

Fixed: using `transparent` or `currentcolor`

Incorrect: using `none`

Correct: removing rounded corners with `0`

Incorrect: literal `undefined` as a color value

Incorrect: JavaScript producing `undefined` in markup

Correct: using a hex code or `rgb()` function

Valid `border` shorthand reference

Invalid: hex value missing the `#` prefix

Fixed: using `rgb()`

Fixed: using `hsl()`

Fixed: using `rgba()` for semi-transparent color

Fixed: correcting the `transparent` keyword typo

Validate at scale.
Ship accessible websites, faster.