Validação HTML

Guias HTML para css

Aprenda como identificar e corrigir erros comuns de validação HTML sinalizados pelo W3C Validator — para que as suas páginas cumpram os padrões e sejam renderizadas corretamente em todos os navegadores. Consulte também o nosso Guias de acessibilidade.

Analise o seu site gratuitamente

CSS: "margin-bottom": "px" não é um valor de "margin-bottom".

The W3C validator raises this error when it encounters a bare unit like px used as the value for margin-bottom without an accompanying number. In CSS, length values are always composed of two parts: a <number> and a <unit>. The token px alone is not a valid <length> value — it’s just a unit identifier with no magnitude. This typically happens due to a typo, an accidental deletion of the numeric portion, or a templating/build tool that outputs an empty variable before the unit.

This matters for several reasons. First, browsers will discard the invalid declaration entirely, meaning margin-bottom will fall back to its default or inherited value — likely not what you intended. This can cause unexpected layout shifts across different pages or components. Second, invalid CSS can make debugging harder, since the silent failure may not be obvious until the layout breaks in a specific context. Third, clean, valid CSS is easier to maintain and signals code quality to collaborators.

How to fix it

Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
Use 0 without a unit if you want zero margin: margin-bottom: 0 is valid and preferred over margin-bottom: 0px.
Use a keyword value if appropriate: margin-bottom also accepts auto, inherit, initial, revert, and unset.
Check template variables: if you’re using a preprocessor like Sass or a JavaScript framework that injects values, make sure the variable isn’t empty or undefined before concatenation with the unit.

Examples

Incorrect: bare unit with no number

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

The value px is not a valid margin-bottom value. The browser will ignore this declaration.

Correct: numeric value with unit

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

Correct: zero margin (no unit needed)

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

Correct: using a keyword value

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

Incorrect in a stylesheet

<html lang="en">
<head>
  <title>Example</title>
  <style>
    .card {
      margin-bottom: px;
    }
  </style>
</head>
<body>
  <div class="card">Content</div>
</body>
</html>

Fixed stylesheet

<html lang="en">
<head>
  <title>Example</title>
  <style>
    .card {
      margin-bottom: 16px;
    }
  </style>
</head>
<body>
  <div class="card">Content</div>
</body>
</html>

Watch out for preprocessor issues

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

/* If $spacing resolves to empty, this produces "margin-bottom: px;" */
.card {
  margin-bottom: $spacing + px;
}

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

$spacing: 16px;

.card {
  margin-bottom: $spacing;
}

The same principle applies to any CSS property that expects a <length> value — always pair a number with its unit, or use 0 when no spacing is needed.

CSS: "margin-left": "px" não é um valor de "margin-left".

When the W3C validator reports that "px" is not a valid margin-left value, it means the CSS declaration is missing its numeric component. A bare unit like px is meaningless on its own — CSS needs to know how many pixels you want. This typically happens due to a typo, an accidental deletion, or a templating/build tool that outputted an empty variable before the unit.

This matters because browsers will discard the entire declaration as invalid, meaning margin-left will fall back to its default or inherited value. This can cause unexpected layout shifts and make your design behave inconsistently. The issue applies equally to any CSS length property, not just margin-left.

Valid values for margin-left

The margin-left property accepts:

A length value: a number followed by a unit, such as 10px, 2em, 1.5rem, 5vw
A percentage: e.g., 5%
The keyword auto
The value 0 (which requires no unit)

A unit without a preceding number (like px, em, or %) is never valid.

Examples

Incorrect: unit with no number

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

The browser cannot interpret px alone and will ignore the declaration entirely.

Correct: number with a unit

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

Correct: zero margin (no unit needed)

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

Incorrect: empty variable in a template

This issue often appears when a dynamic value is missing. For example, in a template:

<!-- If "spacing" is empty, this produces "margin-left: px;" -->

<div style="margin-left: {{spacing}}px;">Content</div>

To guard against this, ensure the variable always contains a valid number, or provide a fallback default.

Correct: using CSS custom properties with a fallback

If you’re working with CSS custom properties, you can use var() with a fallback value to prevent invalid declarations:

<div style="margin-left: var(--spacing, 10px);">Content</div>

Correct: in an external stylesheet

If the issue is in a linked stylesheet rather than inline styles, the same fix applies:

/* Incorrect */
.sidebar {
  margin-left: px;
}

/* Correct */
.sidebar {
  margin-left: 20px;
}

Quick checklist

Ensure every length value has a number before the unit (e.g., 16px, 1em, 2rem).
If you want no margin, use 0 — it’s the only numeric value that doesn’t need a unit.
If using templates or preprocessors, verify that variables resolve to actual numbers before being concatenated with units.
Consider using CSS calc() if you need computed values: margin-left: calc(2em + 4px);.

CSS: "margin": "px" não é um valor de "margin".

css
margem

CSS length values must always pair a number with a unit — writing just px, em, %, or any other unit without a preceding number is meaningless to the browser and will be ignored. This typically happens due to a typo, a copy-paste error, or a build tool / template that outputs a unit without its corresponding numeric value (e.g., a variable that resolved to an empty string concatenated with px).

When the W3C validator encounters margin: px in an inline style attribute, it flags the error because px on its own does not match any valid CSS value for the margin property. Valid values include lengths like 10px or 2em, percentages like 5%, the keyword auto, or the number 0 (which doesn’t need a unit). Browsers will discard the invalid declaration, meaning your intended spacing won’t be applied — potentially breaking your layout in subtle ways that are hard to debug.

This issue also applies to other CSS properties that accept length values, such as padding, width, height, top, left, border-width, font-size, and many more. The fix is always the same: ensure every unit has an accompanying number.

How to Fix It

Add the missing number before the unit: change px to something like 10px, 1.5em, or 20%.
Use 0 without a unit if you want zero margin — writing margin: 0 is valid and preferred over margin: 0px.
Use a keyword if appropriate, such as margin: auto for centering.
Remove the declaration if the margin value was unintentional or unnecessary.

If the value comes from a preprocessor, template engine, or JavaScript, check that the variable being interpolated is not empty or undefined before it gets concatenated with the unit string.

Examples

Incorrect: Unit Without a Number

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

The value px has no number, so this is invalid CSS.

Correct: Number Paired With Unit

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

Correct: Zero Margin (No Unit Needed)

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

Correct: Using a Keyword

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

Incorrect in an External Stylesheet

This same error can appear in a <style> block or linked stylesheet:

<style>
  .card {
    margin: px;
  }
</style>

Correct in an External Stylesheet

<style>
  .card {
    margin: 16px;
  }
</style>

Watch Out for Template Variables

A common cause in templating systems is an empty variable:

<!-- If spacing is empty, this produces "margin: px;" -->

<div style="margin: {{ spacing }}px;">Content</div>

To prevent this, ensure the variable contains the full value including the number, or add a fallback:

<div style="margin: 16px;">Content</div>

CSS: "margin-right": "px" não é um valor "margin-right".

When you write margin-right: px, the browser cannot determine what margin to apply because px alone is not a recognized CSS value — it’s just a unit suffix without a quantity. CSS length values are always a combination of a number and a unit (e.g., 10px, 1.5em, 20%), or a specific keyword like auto, inherit, or 0 (which doesn’t require a unit). The lone px is meaningless on its own and will be ignored by browsers, which means your intended spacing won’t be applied.

This issue typically arises in a few common scenarios:

A number was accidentally deleted during editing, leaving behind just the unit.
A CSS preprocessor variable or template expression failed to output a value, resulting in only the unit being rendered.
A typo or copy-paste error stripped the numeric portion.

Beyond simply not working, invalid CSS can cause unpredictable rendering differences across browsers. It also makes your code harder to maintain, as other developers may not understand the intended value.

To fix this, determine what numeric value you intended and place it directly before the px unit with no space between the number and unit. If no margin is needed, either remove the property entirely or set it to 0.

Examples

Incorrect: unit without a number

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

The validator reports that px is not a valid margin-right value because no number precedes the unit.

Fixed: complete value with number and unit

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

Fixed: using zero (no unit required)

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

When the value is 0, no unit is needed since zero is the same in all units.

Fixed: using a keyword value

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

The auto keyword is a valid value for margin-right and is commonly used for centering or pushing elements.

Watch for preprocessor or template issues

If you’re using a CSS preprocessor or a templating language, make sure your variables resolve to complete values:

/* Incorrect — if $spacing is empty, this outputs "margin-right: px;" */
.sidebar {
  margin-right: px;
}

/* Correct */
.sidebar {
  margin-right: 16px;
}

Other valid units

Any valid CSS length unit works, as long as a number precedes it:

<div style="margin-right: 2em;">Em-based margin</div>
<div style="margin-right: 5%;">Percentage-based margin</div>
<div style="margin-right: 1.5rem;">Rem-based margin</div>

CSS: "margin": Demasiados valores ou valores não são reconhecidos.

css
margem

The margin shorthand property sets the margin area on all four sides of an element. It accepts one to four values, where each value must be a valid CSS length (e.g., 10px, 1em, 0), a percentage, or the keyword auto. When the validator reports “Too many values or values are not recognized,” it means either more than four values were supplied, or at least one of the values is something CSS doesn’t understand — such as a misspelled unit, a missing unit on a non-zero number, or an invalid keyword.

Common causes of this error include:

Too many values: Providing five or more values (e.g., margin: 1px 2px 3px 4px 5px). The shorthand accepts a maximum of four.
Missing units: Writing a non-zero number without a unit (e.g., margin: 10 instead of margin: 10px). Only 0 is valid without a unit.
Typos or invalid units: Using a misspelled or nonexistent unit like margin: 10xp or margin: 10pixels.
Invalid keywords: Using a keyword that isn’t recognized in the margin context (e.g., margin: none). The only non-global keyword margin accepts is auto.
Missing separators or extra characters: Including commas or other unexpected characters between values (e.g., margin: 10px, 20px). Values should be separated by spaces, not commas.

This matters because browsers may ignore or misinterpret an invalid margin declaration entirely, leading to broken or inconsistent layouts across different browsers. Writing valid CSS ensures predictable rendering and easier maintenance.

How margin shorthand values work

The number of values you provide determines how they are applied:

1 value: Applied to all four sides. margin: 10px → top, right, bottom, and left all get 10px.
2 values: First is top and bottom, second is left and right. margin: 10px 20px → top/bottom 10px, left/right 20px.
3 values: First is top, second is left and right, third is bottom. margin: 10px 20px 30px.
4 values: Applied clockwise — top, right, bottom, left. margin: 10px 20px 30px 40px.

Examples

❌ Too many values

/* Five values — invalid */
.box {
  margin: 10px 20px 30px 40px 50px;
}

❌ Missing unit on a non-zero number

.box {
  margin: 10 20px;
}

❌ Invalid keyword

.box {
  margin: none;
}

❌ Comma-separated values

.box {
  margin: 10px, 20px;
}

✅ Correct: one to four valid values

/* All four sides */
.box {
  margin: 10px;
}

/* Top/bottom and left/right */
.box {
  margin: 10px 20px;
}

/* Top, left/right, bottom */
.box {
  margin: 10px auto 20px;
}

/* Top, right, bottom, left */
.box {
  margin: 10px 20px 30px 40px;
}

✅ Correct: using auto for centering

.container {
  margin: 0 auto;
}

✅ Correct: zero without a unit

.box {
  margin: 0;
}

✅ Correct: using global keywords

.box {
  margin: inherit;
}

If you need to set margins on more than four sides independently (which isn’t possible — elements only have four sides), you likely have a logic error. If you want fine-grained control, use the individual longhand properties (margin-top, margin-right, margin-bottom, margin-left) instead of the shorthand.

CSS: "margin-top": "px" não é um valor válido para "margin-top".

The margin-top property accepts several types of values: lengths (like 10px, 1.5em, 2rem), percentages (like 5%), the keyword auto, or the value 0. When you write margin-top: px, the browser encounters a bare unit with no associated number, which is meaningless — it doesn’t know how many pixels you want. Browsers will ignore the invalid declaration entirely, which means margin-top will fall back to its default or inherited value. This can lead to unexpected layout results that may differ across browsers.

This error commonly happens due to a typo, an accidental deletion of the numeric portion, or a templating/build tool that failed to interpolate a variable (e.g., margin-top: ${value}px where value was empty). It can also occur when editing CSS quickly and removing the number while intending to change it.

Beyond just margin-top, this same principle applies to all CSS properties that accept length values — margin, padding, width, height, font-size, border-width, and many others. A bare unit without a number is never valid.

Note: The value 0 is the only numeric length that does not require a unit. Writing margin-top: 0 is perfectly valid and equivalent to margin-top: 0px.

How to fix it

Add the missing number before the unit. Determine the spacing you need and prepend it to the unit (e.g., 10px, 1.5em).
Use a valid keyword if you don’t need a specific numeric value — auto or inherit, for example.
Check template variables if you use a preprocessor or templating system. Make sure the variable that provides the number is defined and not empty.

Examples

Incorrect: bare unit with no number

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

The validator reports that "px" is not a valid margin-top value because it lacks a numeric component.

Correct: number followed by a unit

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

Correct: using zero without a unit

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

Correct: using a keyword value

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

Incorrect in a stylesheet

<style>
  .box {
    margin-top: px;
  }
</style>
<div class="box">Content</div>

Correct in a stylesheet

<style>
  .box {
    margin-top: 16px;
  }
</style>
<div class="box">Content</div>

Incorrect with CSS preprocessor output

If you use a preprocessor like Sass or a JavaScript framework, an undefined or empty variable can produce this error:

<!-- If the variable was empty, the rendered output becomes: -->

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

Ensure the variable has a valid numeric value so the rendered CSS is complete:

<div style="margin-top: 20px;">Content</div>

CSS: "margin": ""X"" não é um valor "margin".

css
margem

In CSS, property values such as lengths, percentages, and keywords are written without quotation marks. Quotes in CSS are reserved for specific contexts like content property strings, font family names with spaces, and url() paths. When you wrap a margin value (or any similar CSS property value) in double or single quotes, the CSS parser interprets it as a string literal rather than a set of length or keyword values. Since "0 0 1em 0" is a string and not a valid margin value, the declaration is ignored by browsers and flagged by the W3C validator.

This is a problem for several reasons. First, the style will silently fail — browsers discard CSS declarations they can’t parse, so your intended margins won’t be applied, potentially breaking your layout. Second, it indicates a misunderstanding of CSS syntax that could lead to similar errors in other properties. This mistake commonly occurs when developers confuse HTML attribute quoting rules with CSS value syntax, especially when writing inline style attributes where the attribute value itself is already quoted.

The margin property accepts one to four values, each of which can be a length (e.g., 10px, 1em), a percentage, auto, or a global keyword like inherit. None of these require quotes. The fix is straightforward: remove the quotation marks around the CSS value.

Examples

❌ Incorrect: margin value wrapped in quotes

In a <style> block:

<style>
  .card {
    margin: "0 0 1em 0";
  }
</style>

In an inline style:

<p style="margin: '10px auto'">Hello</p>

Both of these produce the validator error because the CSS parser sees a quoted string instead of valid margin values.

✅ Correct: margin value without quotes

In a <style> block:

<style>
  .card {
    margin: 0 0 1em 0;
  }
</style>

In an inline style:

<p style="margin: 10px auto">Hello</p>

Valid margin value formats

For reference, here are the accepted patterns for the margin property — none of which use quotes:

/* All four sides */
margin: 1em;

/* Vertical | Horizontal */
margin: 5% auto;

/* Top | Horizontal | Bottom */
margin: 1em auto 2em;

/* Top | Right | Bottom | Left */
margin: 2px 1em 0 auto;

/* Global keywords */
margin: inherit;
margin: initial;
margin: unset;

Watch out for inline style quoting confusion

A common source of this mistake is confusion about the quotes used for the HTML style attribute versus the CSS values inside it. The outer quotes delimit the attribute value for HTML — the CSS inside should not have its own quotes around property values:

<!-- ❌ Wrong: extra quotes around the CSS value -->

<div style="margin: '1em'"></div>

<!-- ✅ Correct: only the HTML attribute is quoted -->

<div style="margin: 1em"></div>

This same rule applies to other CSS properties like padding, border, font-size, color, and so on. If you see a similar validator error for any CSS property, check whether you’ve accidentally quoted the value.

CSS: "mask": Demasiados valores ou valores não são reconhecidos.

css
máscara

The mask CSS shorthand property allows you to hide parts of an element by masking or clipping it at specific points. It combines several longhand properties into one declaration: mask-image, mask-mode, mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and mask-composite.

Because mask is a shorthand that accepts values for many sub-properties, it’s easy to trigger validation errors. Common causes include:

Too many values: Providing more values than the shorthand grammar allows, or duplicating values for the same sub-property.
Unrecognized values: Using vendor-specific values (like -webkit- prefixed keywords), typos, or values that belong to a different CSS property.
Incorrect value order: The shorthand has a specific grammar. For example, mask-size values must follow mask-position values and be separated by a /, similar to the background shorthand.
Mixing shorthand and longhand concepts: Trying to set values that aren’t part of the mask shorthand grammar.

The formal syntax for a single mask layer is:

<mask-layer> = <mask-reference> || <position> [ / <bg-size> ]? || <repeat-style> ||
               <geometry-box> || [ <geometry-box> | no-clip ] || <compositing-operator> ||
               <masking-mode>

This is a problem for standards compliance because invalid CSS can lead to the entire declaration being ignored by browsers, causing your masking effect to silently fail. It also affects cross-browser compatibility — different browsers have varying levels of support for the mask shorthand, and using individual longhand properties is often more reliable.

To fix this issue:

Check each value in your mask declaration and ensure it’s a valid value for one of the mask sub-properties.
Use longhand properties instead of the shorthand if you only need to set one or two aspects of the mask. This avoids ambiguity and improves readability.
Separate position and size with / if you’re specifying both, e.g., center / contain.
Remove or separate vendor prefixes — use -webkit-mask for WebKit-specific syntax and the standard mask for standards-compliant syntax, but don’t mix prefixed values into the unprefixed property.

Examples

Incorrect: too many or unrecognized values in the shorthand

<style>
  .masked {
    /* Error: too many values / unrecognized combination */
    mask: url(mask.svg) center center no-repeat contain;
  }
</style>
<div class="masked">Content</div>

Here, contain is a mask-size value but it must be separated from the position with a /. Without the slash, the validator sees an extra unrecognized value.

Correct: proper shorthand syntax with position and size

<style>
  .masked {
    mask: url(mask.svg) center / contain no-repeat;
  }
</style>
<div class="masked">Content</div>

The / separates mask-position (center) from mask-size (contain), just like in the background shorthand.

Correct: using longhand properties for clarity and compatibility

<style>
  .masked {
    width: 100px;
    height: 100px;
    background-color: #8cffb0;
    -webkit-mask-image: url(sun.svg);
    mask-image: url(sun.svg);
    mask-repeat: no-repeat;
    mask-position: center;
    mask-size: contain;
  }
</style>
<div class="masked">Content</div>

Using individual longhand properties avoids shorthand parsing issues entirely. Including the -webkit-mask-image prefix alongside the standard mask-image ensures broader browser support.

Incorrect: unrecognized value in the shorthand

<style>
  .masked {
    /* "luminance" is a mask-mode value but may not be recognized in the shorthand by all validators */
    mask: url(mask.png) luminance;
  }
</style>
<div class="masked">Content</div>

Correct: using the longhand for mask mode

<style>
  .masked {
    mask-image: url(mask.png);
    mask-mode: luminance;
  }
</style>
<div class="masked">Content</div>

When in doubt, splitting the mask shorthand into its individual longhand properties is the safest approach. It makes your intent explicit, avoids validation errors, and tends to have better cross-browser support.

CSS: "max-width": "auto" não é um valor de "max-width".

The max-width property sets the maximum width an element can grow to, preventing the computed value of width from exceeding the specified limit. While many CSS sizing properties accept auto as a value (for example, width: auto and margin: auto are perfectly valid), the max-width property does not. This is a common mistake because developers often assume auto is universally accepted across similar properties.

When a browser encounters max-width: auto, it will typically ignore the invalid declaration and fall back to the default value of none. While the page may still render as expected in some browsers, relying on this behavior is unreliable and non-standard. Writing valid CSS ensures consistent rendering across all browsers and makes your stylesheets easier to maintain and debug.

If your intent is to remove a maximum width constraint (effectively making max-width have no effect), use none — this is the default value. If you want the element to size itself based on its content, use max-content, min-content, or fit-content. If you need to reset the property to its initial value, use initial (which resolves to none).

Valid values for max-width

The max-width property accepts the following types of values:

none — No limit on the element’s width (the default).
Length values — Such as 500px, 3.5em, 20rem, 80ch.
Percentage values — Such as 75%, relative to the containing block’s width.
Keyword values — max-content, min-content, fit-content, or fit-content(<length>).
Global values — inherit, initial, revert, unset.

Examples

❌ Incorrect: using auto with max-width

<div style="max-width: auto;">
  This container has an invalid max-width value.
</div>

This triggers the validation error because auto is not a valid max-width value.

✅ Fixed: using none to remove the constraint

If you want no maximum width limit (the most likely intent when writing auto), use none:

<div style="max-width: none;">
  This container has no maximum width constraint.
</div>

✅ Fixed: using a specific length or percentage

If you want to cap the element’s width at a specific size:

<div style="max-width: 600px;">
  This container will not grow beyond 600 pixels.
</div>

<div style="max-width: 80%;">
  This container will not exceed 80% of its parent's width.
</div>

✅ Fixed: using intrinsic sizing keywords

If you want the element’s maximum width to be based on its content:

<div style="max-width: max-content;">
  This container's max width is determined by its content.
</div>

CSS: "min-height": Muitos valores ou valores não reconhecidos.

The min-height property sets the minimum height of an element. Unlike shorthand properties such as margin or padding, min-height accepts only a single value. Providing multiple space-separated values (e.g., min-height: 100px 200px) is invalid and will trigger this error.

This error commonly occurs for several reasons:

Multiple values provided: min-height is not a shorthand and does not accept more than one value.
Invalid units or typos: Using an unrecognized unit (e.g., 100pixels instead of 100px) or a misspelled keyword.
Using unsupported CSS functions or syntax: Some newer CSS features like min-height: fit-content(200px) may not be recognized by the validator or may lack browser support.
Confusing min-height with other properties: Accidentally using syntax meant for properties like grid-template-rows or minmax() expressions.
Missing units on non-zero values: Writing min-height: 100 instead of min-height: 100px. Zero is the only numeric value that doesn’t require a unit.

According to the CSS specification, valid values for min-height include:

Value Type	Examples
Length	0, 100px, 10em, 5rem, 50vh
Percentage	50%, 100%
Keywords	auto, min-content, max-content, none
Functions	fit-content, calc(100vh - 50px)

Fixing this issue ensures your CSS is standards-compliant and behaves predictably across browsers. Invalid min-height values will be ignored by browsers, which means your layout may not render as intended.

Examples

Incorrect: multiple values

<div style="min-height: 100px 200px;">Content</div>

min-height only accepts a single value. This is not a shorthand property.

Incorrect: missing unit

<div style="min-height: 100;">Content</div>

Non-zero numeric values must include a unit.

Incorrect: invalid keyword or typo

<div style="min-height: inheret;">Content</div>

The keyword inherit is misspelled.

Correct: single length value

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

Correct: percentage value

<div style="min-height: 50%;">Content</div>

Correct: using calc() for computed values

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

Correct: using a keyword

<div style="min-height: min-content;">Content</div>

Correct: using auto

<div style="min-height: auto;">Content</div>

If you need to set both a minimum and maximum height on an element, use min-height and max-height as separate properties:

<div style="min-height: 100px; max-height: 400px;">Content</div>

CSS: "mso-X": A propriedade "mso-X" não existe.

These mso- prefixed properties are most commonly introduced when content is copied and pasted from Microsoft Word or other Office applications into an HTML editor. Microsoft Office generates heavily styled HTML with dozens of proprietary CSS properties designed to preserve the document’s formatting when rendered back in Office products. While browsers silently ignore these unknown properties, they clutter your markup, inflate file size, and violate web standards.

This is a problem for several reasons. First, these properties have no effect in any web browser — they are purely artifacts of Microsoft’s internal rendering engine. Second, they significantly bloat your HTML, sometimes doubling or tripling the size of the markup. Third, they make your code harder to read and maintain. Fourth, they can cause issues with automated tools, linters, and content management systems that expect valid CSS. Finally, in the context of HTML email development, while mso- properties are sometimes intentionally used to target Microsoft Outlook’s rendering engine, they should not appear in web pages intended for browsers.

How to Fix

Identify the source. Check if the content was pasted from Microsoft Word or another Office application. This is the most common origin.
Remove all mso- properties. Delete every CSS declaration that starts with mso-. They serve no purpose in a browser context.
Replace with standard CSS if needed. Some mso- properties have standard CSS equivalents. For example, mso-margin-top-alt can be replaced with margin-top, and mso-bidi-font-weight can be replaced with font-weight.
Use a paste-as-plain-text workflow. When copying from Word, paste as plain text first (Ctrl+Shift+V in many editors), then apply formatting using your own CSS.

Examples

❌ Incorrect: HTML with Microsoft Office properties

<p style="mso-spacerun: yes; mso-fareast-font-family: 'Times New Roman'; margin-bottom: .0001pt; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; mso-bidi-font-weight: bold; line-height: normal;">
  This text was pasted from Microsoft Word.
</p>

<style>
  .content {
    mso-fareast-font-family: "Calibri";
    mso-bidi-font-family: "Times New Roman";
    font-family: Arial, sans-serif;
    mso-line-height-rule: exactly;
    line-height: 1.5;
  }
</style>

✅ Correct: Cleaned-up HTML with only standard CSS

<p style="margin-bottom: 0; margin-top: auto; font-weight: bold; line-height: normal;">
  This text was pasted from Microsoft Word.
</p>

<style>
  .content {
    font-family: Arial, sans-serif;
    line-height: 1.5;
  }
</style>

Common mso- properties and their standard replacements

mso- Property	Standard CSS Equivalent
mso-margin-top-alt	margin-top
mso-margin-bottom-alt	margin-bottom
mso-bidi-font-weight	font-weight
mso-bidi-font-style	font-style
mso-bidi-font-size	font-size
mso-fareast-font-family	font-family (use a standard font stack)
mso-line-height-rule	No equivalent needed — remove it
mso-spacerun	No equivalent needed — remove it
mso-tab-count	No equivalent needed — remove it

Many mso- properties (like mso-spacerun and mso-tab-count) control behaviors specific to Microsoft’s rendering engine and have no CSS equivalent at all. These can simply be deleted without any replacement. If your content originally came from Word, it’s often best to strip all formatting and restyle the content from scratch using your own clean CSS.

CSS: "padding-block": "auto" não é um valor para "padding-block".

The padding-block shorthand property sets padding on the block-start and block-end sides of an element. In horizontal writing modes (like English), this corresponds to the top and bottom padding; in vertical writing modes, it maps to left and right. It’s the logical equivalent of combining padding-block-start and padding-block-end.

The reason auto is invalid here is that padding, by definition in the CSS specification, must resolve to a definite size. Margins can be auto because the browser uses that value in layout algorithms to distribute remaining space (e.g., centering a block element with margin-inline: auto). Padding, however, adds space inside an element’s border and has no such auto-distribution behavior defined in the spec. Attempting to use auto will cause the declaration to be ignored by browsers, meaning no padding is applied, which can lead to unexpected layout results.

This validation error often arises when developers confuse padding-block with margin-block, or when they copy centering patterns that work with margins and try to apply them to padding. If your intent was to center content, consider using margin-block: auto instead, or use Flexbox/Grid alignment properties.

How to Fix

Replace auto with a valid value:

Length values: 0, 10px, 1em, 1.5rem, etc.
Percentage values: 5%, 2% 1%, etc. (relative to the inline size of the containing block).
Two values: padding-block: 20px 10px; sets padding-block-start to 20px and padding-block-end to 10px.
CSS-wide keywords: inherit, initial, revert, revert-layer, or unset.

If you used auto to try to eliminate padding, use 0 instead. If you used it to try to center something, switch to margins or a layout method like Flexbox.

Examples

Incorrect: using auto as a padding-block value

<style>
  .box {
    padding-block: auto;
  }
</style>
<div class="box">This box has invalid padding.</div>

The browser will ignore the padding-block: auto declaration entirely, and the W3C validator will flag it as an error.

Correct: using length values

<style>
  .box {
    padding-block: 20px 10px;
  }
</style>
<div class="box">20px padding on block-start, 10px on block-end.</div>

Correct: using a single value for equal padding

<style>
  .box {
    padding-block: 1em;
  }
</style>
<div class="box">1em padding on both block-start and block-end.</div>

Correct: removing padding with zero

<style>
  .box {
    padding-block: 0;
  }
</style>
<div class="box">No block padding.</div>

If you intended to center: use margin-block instead

<style>
  .container {
    display: flex;
    flex-direction: column;
    height: 300px;
  }
  .centered {
    margin-block: auto;
  }
</style>
<div class="container">
  <div class="centered">This element is vertically centered using margin-block: auto.</div>
</div>

The margin-block: auto approach works inside flex or grid containers to distribute space evenly, achieving vertical centering. This is likely what you want if you originally reached for padding-block: auto.

CSS: "padding-bottom": "px" não é um valor válido para "padding-bottom".

The padding-bottom property defines the amount of space between an element’s content and its bottom border. Like all CSS length properties, it expects a length value — a number paired with a unit such as px, em, rem, %, vh, etc. The lone string px is just a unit identifier with no magnitude, so CSS parsers cannot interpret it as a meaningful measurement. This typically happens when a numeric value is accidentally deleted during editing, when a CSS preprocessor or template engine outputs an empty variable before the unit, or when code is manually written with a typo.

When the browser encounters an invalid value like padding-bottom: px, it discards the entire declaration and falls back to the default or inherited value. This can lead to unexpected layout shifts, where the spacing looks correct in one browser but breaks in another depending on how defaults are applied. Fixing these errors ensures consistent rendering across browsers and keeps your stylesheets standards-compliant.

How to fix it

Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
Use 0 without a unit if you want zero padding — writing padding-bottom: 0 is valid and preferred over 0px.
Check template variables — if you’re using a preprocessor like Sass or a templating engine, make sure the variable that generates the number is not empty or undefined.
Remove the declaration entirely if padding-bottom is not needed, rather than leaving a broken value in place.

Examples

Incorrect: unit without a number

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

The value px alone is not valid because there is no number specifying the amount of padding.

Correct: numeric value with a unit

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

Correct: zero padding (no unit needed)

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

Incorrect in an external stylesheet

.card {
  padding-bottom: px;
}

Correct in an external stylesheet

.card {
  padding-bottom: 16px;
}

Common preprocessor pitfall

In Sass or similar tools, this issue often arises from an empty or undefined variable:

$spacing: null;

.card {
  padding-bottom: #{$spacing}px; // Outputs "padding-bottom: px;" if $spacing is empty
}

The fix is to ensure the variable holds a valid number, or provide a fallback:

$spacing: 16;

.card {
  padding-bottom: #{$spacing}px; // Outputs "padding-bottom: 16px;"
}

Even better, include the unit in the variable itself to avoid concatenation issues:

$spacing: 16px;

.card {
  padding-bottom: $spacing;
}

CSS: "padding-left": "px" não é um valor "padding-left".

The padding-left property accepts a valid CSS length value, a percentage, or the keyword 0. A CSS length is always composed of two parts: a number and a unit (e.g., 10px, 2em, 1.5rem). Writing just px with no number is syntactically invalid — it’s a bare unit with no magnitude, so the browser cannot determine what spacing to apply. This commonly occurs due to a typo, a missing variable in a template or preprocessor, or accidentally deleting the numeric portion during editing.

When the validator encounters this in a style attribute, it flags the value as invalid CSS. While most browsers will simply ignore the malformed declaration and fall back to the default padding, relying on this error-recovery behavior leads to unpredictable layouts. Fixing the issue ensures your styles are applied consistently across all browsers and that your markup passes validation.

How to fix it

Add a numeric value before the unit: change px to something like 10px, 1em, or 5%.
If you want zero padding, use 0 — no unit is needed (though 0px is also valid).
Check template variables and preprocessors. If you’re using a system like PHP, JavaScript templating, or a CSS preprocessor (Sass, Less), make sure the variable that should supply the number isn’t empty or undefined. For example, padding-left: <?= $indent ?>px; will produce padding-left: px; if $indent is empty.

Examples

Incorrect: bare unit with no number

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

The value px has no numeric component, so it is not a valid length.

Correct: numeric value before the unit

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

Correct: zero padding (no unit required)

<div style="padding-left: 0;">Content</div>

Incorrect: empty variable producing a bare unit

This is a common source of the bug in templated or dynamically generated HTML:

<!-- If the variable is empty, this renders as "padding-left: px;" -->

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

Correct: ensuring a fallback value

When generating styles dynamically, always provide a sensible default so the output is valid even if the variable is missing:

<div style="padding-left: 16px;">Content</div>

Using an external stylesheet

The same rule applies in external or embedded CSS. The incorrect version:

.sidebar {
  padding-left: px;
}

The corrected version with a proper numeric value:

.sidebar {
  padding-left: 20px;
}

Other valid padding-left values

Any valid CSS length or percentage works:

<div style="padding-left: 2em;">Em-based padding</div>
<div style="padding-left: 1.5rem;">Rem-based padding</div>
<div style="padding-left: 5%;">Percentage-based padding</div>

CSS: "padding": "none" não é um valor de "padding".

The padding shorthand property sets the padding area on all four sides of an element. It accepts one to four values, each of which must be a <length> (e.g., 10px, 1em), a <percentage>, or 0. Unlike some other CSS properties such as border, outline, or max-width, the padding property has no none keyword in its value syntax.

This is a common mistake because several CSS properties do accept none — for example, border: none, text-decoration: none, and display: none. It’s natural to assume padding: none would work the same way, but the CSS specification simply doesn’t define it for padding. When a browser encounters an invalid value, it ignores the declaration entirely, which means your intended styling won’t be applied and the element may retain its default or inherited padding. This can lead to unexpected layout issues that are difficult to debug.

The same rule applies to the margin property — margin: none is also invalid. Use margin: 0 instead.

How to Fix It

Replace none with 0. You don’t need to include a unit when the value is zero, so padding: 0 is perfectly valid and is the idiomatic way to express “no padding.” You can also use 0 for individual padding properties like padding-top, padding-right, padding-bottom, and padding-left.

If you only want to remove padding on specific sides, target those sides individually rather than using the shorthand.

Examples

❌ Incorrect: Using none with padding

.card {
  padding: none;
}

The validator will report: CSS: “padding”: “none” is not a “padding” value. The browser will ignore this declaration.

✅ Correct: Using 0 to remove padding

.card {
  padding: 0;
}

✅ Correct: Removing padding on specific sides

.card {
  padding-top: 0;
  padding-bottom: 0;
}

❌ Incorrect: Using none in inline styles

<div style="padding: none;">Content</div>

✅ Correct: Using 0 in inline styles

<div style="padding: 0;">Content</div>

✅ Correct: Using valid padding values

/* Single value — applies to all four sides */
.card {
  padding: 16px;
}

/* Two values — vertical | horizontal */
.card {
  padding: 10px 20px;
}

/* Four values — top | right | bottom | left */
.card {
  padding: 10px 20px 15px 5px;
}

/* Zero on top/bottom, 1em on left/right */
.card {
  padding: 0 1em;
}

CSS: "padding": "px" não é um valor "padding" válido.

css
padding

The padding property accepts one or more length values, percentages, or the keyword 0. A valid length value always consists of a number immediately followed by a unit identifier, such as 10px, 1.5em, or 2rem. Writing just px without a preceding number is meaningless to the CSS parser — it’s like saying “pixels” without specifying how many. The browser will discard the invalid declaration entirely, which means the element will fall back to its default or inherited padding, potentially breaking your layout in unexpected ways.

This error commonly occurs due to:

Typos or accidental deletion — the numeric part of the value was inadvertently removed during editing.
Templating or build tool issues — a dynamic value (e.g., from a variable or CMS field) resolved to an empty string, leaving only the px suffix behind.
Copy-paste mistakes — copying a snippet and forgetting to update the placeholder value.

Because the W3C validator flags this in inline style attributes, it means invalid CSS is embedded directly in your HTML. Fixing it improves standards compliance and ensures consistent rendering across browsers.

How to Fix

Add a numeric value before the unit: change px to something like 10px, 1em, or 5%.
Use 0 without a unit if you want zero padding — writing padding: 0; is valid and preferred over padding: 0px;.
Check dynamic values — if the number comes from a variable or template expression, make sure it outputs a valid number and isn’t empty.

Examples

Incorrect: Unit Without a Number

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

The validator reports that px is not a valid padding value because no number precedes the unit.

Correct: Numeric Value With Unit

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

Correct: Zero Padding (No Unit Needed)

<div style="padding: 0;">Content</div>

When the value is 0, no unit is required since zero pixels, zero ems, and zero percent are all identical.

Correct: Multiple Padding Values

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

This sets 8px of vertical padding and 16px of horizontal padding — both are valid length values.

Incorrect in External CSS

The same problem can appear in a stylesheet linked from your HTML:

.card {
  padding: px;
}

Fixed in External CSS

.card {
  padding: 12px;
}

Watch for Template-Generated Values

If you use a templating system, double-check that the numeric portion actually renders. For example, a template like this could produce the error if spacing is empty:

<!-- If spacing is empty, this becomes "padding: px;" -->

<div style="padding: {{ spacing }}px;">Content</div>

Make sure the variable always resolves to a valid number, or provide a fallback value.

CSS: "padding-right": "px" não é um valor válido para "padding-right".

The padding-right property defines the amount of space between an element’s content and its right border. Like all CSS length properties, it expects either a valid length value (a number paired with a unit like px, em, rem, %, vw, etc.), the keyword 0 (which needs no unit), or the keyword inherit/initial/unset. A bare unit such as px with no number is meaningless — it doesn’t tell the browser how much padding to apply.

This error typically occurs due to a typo, a templating issue where a variable failed to render, or accidental deletion of the numeric portion of the value. For example, a template like padding-right: {{ value }}px; might produce padding-right: px; if value is empty or undefined.

When the browser encounters an invalid value like px, it discards the entire declaration and falls back to the default or inherited value for padding-right. This can lead to unexpected layout differences across browsers and makes your intentions unclear to other developers. Fixing these validation errors also helps maintain clean, predictable stylesheets.

How to Fix

Add the missing number before the unit: change px to a specific value like 10px.
Use 0 without a unit if you want no padding: padding-right: 0; is valid and preferred over padding-right: 0px;.
Check template variables and dynamic style generation to ensure numeric values are always output correctly.

Examples

Incorrect: bare unit with no number

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

The value px is not valid because it lacks a numeric component.

Correct: numeric value with unit

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

Correct: zero padding (no unit needed)

<div style="padding-right: 0;">Content</div>

Correct: using other valid units

<div style="padding-right: 2em;">Content</div>

<div style="padding-right: 5%;">Content</div>

Incorrect in an external stylesheet

.sidebar {
  padding-right: px;
}

Fixed in an external stylesheet

.sidebar {
  padding-right: 16px;
}

Guarding against empty values in templates

If you generate CSS dynamically, make sure the numeric value is always present. For instance, provide a fallback:

.sidebar {
  padding-right: 16px; /* safe default */
}

Rather than relying on a template that might produce an empty value, consider setting defaults in your CSS and only overriding with inline styles when you’re certain the value is valid.

CSS: "padding-top": "px" não é um valor de "padding-top" válido.

The W3C validator reports this error when it encounters padding-top: px; — a unit with no numeric component. In CSS, length values are composed of two parts: a number and a unit identifier (e.g., px, em, rem, %, vh). The unit alone is meaningless without a number to quantify it. This typically happens due to a typo, a preprocessor variable that resolved to an empty value, or accidentally deleting the number during editing.

This matters for several reasons. Browsers will discard the invalid declaration entirely, meaning padding-top will fall back to its default or inherited value — which may not be what you intended. This can cause unpredictable layout differences across browsers. Additionally, invalid CSS can interfere with parsing of subsequent declarations in the same rule block, potentially causing other styles to be ignored as well.

To fix this issue:

Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
Use 0 without a unit if you want zero padding: padding-top: 0; is valid and preferred over padding-top: 0px;.
Check preprocessor variables (Sass, Less, etc.) to make sure they resolve to complete values, not just units.
Remove the declaration entirely if padding-top doesn’t need to be set.

Examples

Incorrect: unit without a number

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

The value px is not a valid padding-top value because it lacks a numeric component.

Correct: number with a unit

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

Correct: zero padding (no unit needed)

<div style="padding-top: 0;">Content</div>

Incorrect in an external stylesheet

.header {
  padding-top: px;
}

Correct in an external stylesheet

.header {
  padding-top: 16px;
}

Common preprocessor pitfall

If you use a CSS preprocessor like Sass, watch out for variables that might be empty or undefined:

/* If $spacing somehow resolves to empty, this produces "padding-top: px;" */
.card {
  padding-top: $spacing + px;
}

/* Safer approach — define the variable with the full value */
.card {
  padding-top: $spacing;  /* where $spacing: 16px; */
}

Any valid CSS length value will work for padding-top, including px, em, rem, %, vw, vh, ch, and others — as long as a number precedes the unit. The only length value that doesn’t require a unit is 0.

CSS: "padding-top": "-X" valores negativos não são permitidos.

Unlike margin properties, which accept negative values to pull elements closer together or overlap them, all padding properties (padding-top, padding-right, padding-bottom, padding-left, and the padding shorthand) are defined in the CSS specification to only accept zero or positive lengths. This is because padding represents the space inside an element between its content and its border — a negative internal space is not a meaningful concept.

When you use a negative padding value, browsers will typically ignore the declaration entirely, meaning your layout may not look the way you intended. The W3C validator catches this to help you identify code that won’t behave consistently across browsers and doesn’t conform to the CSS specification.

If your goal is to reduce the space between elements, negative margin values are the correct tool. If you’re trying to shift content upward within a container, consider using position: relative with a negative top offset, or adjust the layout with other techniques like transform: translateY().

Examples

❌ Invalid: negative padding value

<div style="padding-top: -20px;">
  This element has invalid negative padding.
</div>

The validator will report: CSS: “padding-top”: “-20” negative values are not allowed.

✅ Fixed: using zero or positive padding

<div style="padding-top: 0;">
  This element has no top padding.
</div>

<div style="padding-top: 10px;">
  This element has valid positive top padding.
</div>

✅ Alternative: using negative margin instead

If you need to reduce the space above an element, use a negative margin-top:

<div style="margin-top: -20px;">
  This element is pulled upward with a negative margin.
</div>

❌ Invalid: negative values in the padding shorthand

The same rule applies to the padding shorthand property. Any negative component value is invalid:

<div style="padding: -10px 20px 15px 20px;">
  Invalid shorthand padding.
</div>

✅ Fixed: all-positive shorthand values

<div style="padding: 0 20px 15px 20px;">
  Valid shorthand padding with zero top padding.
</div>

✅ Alternative: using transform for visual offset

If you need to visually shift an element’s content upward without affecting layout flow, transform is a clean option:

<div style="transform: translateY(-20px);">
  This element appears shifted upward.
</div>

CSS: Erro de análise.

A CSS parse error means the validator’s CSS parser encountered something unexpected and could not make sense of the code from that point forward. Unlike many HTML errors that pinpoint a specific rule violation, a parse error is more general — the parser simply gave up trying to interpret the CSS. This can sometimes cause a cascade of additional errors, since the parser may lose track of context after the initial failure.

This matters because browsers handle broken CSS unpredictably. While most browsers are forgiving and will skip invalid rules, the way they recover varies. Styles may render differently across browsers, or entire rule blocks may be silently ignored. Valid CSS ensures consistent rendering, easier debugging, and better maintainability.

Common causes of CSS parse errors include:

Missing semicolons between declarations
Unclosed curly braces { or extra closing braces }
Unclosed comments (/* without a matching */)
Invalid or empty property values (e.g., color: ;)
Unexpected characters such as stray text, unsupported tokens, or HTML markup inside <style> blocks
Typos in property names or values (e.g., colr: red)
Using CSS syntax that isn’t valid in an attribute context, such as placing selectors inside a style attribute

To fix the error, go to the line indicated by the validator and carefully inspect the CSS around that point. Look for the common issues listed above. Sometimes the actual mistake is on a line before the reported one — for example, a missing semicolon on line 5 might only cause a parse error on line 6.

Examples

Missing semicolon

A missing semicolon causes the parser to misinterpret where one declaration ends and the next begins.

❌ Incorrect:

<p style="color: red font-size: 16px">Hello</p>

✅ Fixed:

<p style="color: red; font-size: 16px">Hello</p>

Unclosed curly brace

A missing closing brace causes the parser to treat subsequent rules as part of the unclosed block.

❌ Incorrect:

<style>
  .container {
    margin: 0 auto;
    padding: 20px;

  .title {
    font-size: 24px;
  }
</style>

✅ Fixed:

<style>
  .container {
    margin: 0 auto;
    padding: 20px;
  }

  .title {
    font-size: 24px;
  }
</style>

Unclosed comment

A comment that is never closed causes everything after it to be consumed by the parser as part of the comment.

❌ Incorrect:

<style>
  /* Set the main color
  body {
    color: #333;
  }
</style>

✅ Fixed:

<style>
  /* Set the main color */
  body {
    color: #333;
  }
</style>

Empty or invalid property value

Declaring a property with no value or a clearly invalid value triggers a parse error.

❌ Incorrect:

<div style="background-color: ;">Content</div>

✅ Fixed:

<div style="background-color: #f0f0f0;">Content</div>

Selectors inside an inline style attribute

The style attribute only accepts declarations (property-value pairs), not selectors or full rule blocks.

❌ Incorrect:

<div style="p { color: blue; }">Content</div>

✅ Fixed:

<div style="color: blue;">Content</div>

Stray characters or typos

Unexpected characters anywhere in CSS will cause parsing to fail.

❌ Incorrect:

<style>
  .box {
    width: 100px;;
    height: 50px
    border: 1px solid #ccc;
  }
</style>

While a double semicolon (;;) is technically harmless in most parsers, a missing semicolon after height: 50px merges it with the next line, producing an invalid value.

✅ Fixed:

<style>
  .box {
    width: 100px;
    height: 50px;
    border: 1px solid #ccc;
  }
</style>

If the validator points to a line but the cause isn’t obvious, try isolating sections of your CSS and validating them separately using the W3C CSS Validation Service. This can help narrow down the exact location of the problem.

CSS: "pointer-events": "normal" não é um valor "pointer-events".

The pointer-events CSS property controls whether an element can be the target of pointer events such as clicks, taps, and hover states. Unlike many other CSS properties that accept normal as a keyword (e.g., white-space, letter-spacing), the pointer-events property does not include normal in its list of valid values. This is a common mistake since normal and auto are often used interchangeably across different CSS properties, but each property defines its own set of accepted keywords.

Using an invalid value like normal means the browser will ignore the entire declaration. In most cases this won’t cause visible breakage because the default behavior already allows pointer interaction, but it can lead to unexpected results if you’re relying on the property to override an inherited pointer-events: none from a parent element. The invalid declaration would simply be discarded, and the inherited none value would remain in effect, making the element unclickable.

For standard HTML elements, the two primary values you’ll use are:

auto — The element behaves as it normally would regarding pointer events. This is the default.
none — The element is never the target of pointer events. Clicks and hovers pass through to whatever is behind it.

Several additional values exist (visiblePainted, visibleFill, visibleStroke, visible, painted, fill, stroke, all) but these only apply to SVG elements. Global CSS keywords like inherit, initial, unset, and revert are also valid.

To fix the issue, replace normal with auto wherever it appears as a pointer-events value. If you’re using pointer-events: normal to restore default interactivity after a parent set pointer-events: none, then auto is exactly what you need.

Examples

Incorrect — using normal

<div style="pointer-events: normal;">
  <a href="/about">About us</a>
</div>

The validator will flag normal as an invalid value for pointer-events.

Correct — using auto

<div style="pointer-events: auto;">
  <a href="/about">About us</a>
</div>

Practical use case: restoring pointer events on a child

A common pattern is disabling pointer events on a parent and re-enabling them on a specific child. Using normal here would silently fail, leaving the button unclickable:

<!-- Incorrect -->

<style>
  .overlay {
    pointer-events: none;
  }
  .overlay .close-btn {
    pointer-events: normal; /* Invalid — button remains unclickable */
  }
</style>

<div class="overlay">
  <button class="close-btn">Close</button>
</div>

<!-- Correct -->

<style>
  .overlay {
    pointer-events: none;
  }
  .overlay .close-btn {
    pointer-events: auto; /* Valid — button is clickable again */
  }
</style>

<div class="overlay">
  <button class="close-btn">Close</button>
</div>

In the incorrect version, the browser discards the invalid pointer-events: normal declaration entirely, so the .close-btn inherits none from the parent and cannot be clicked. Changing it to auto correctly restores interactivity on the button.

CSS: "px" não é um valor de "width"

In CSS, a length value is composed of two parts: a number and a unit. Writing just px provides the unit but omits the number, which makes the declaration invalid. The CSS parser cannot interpret px alone as a meaningful measurement, so the property is ignored entirely. This means your intended layout won’t be applied, potentially causing elements to render at unexpected sizes across different browsers.

This error commonly arises from typos, copy-paste mistakes, or templating issues where a variable that should output a number resolves to an empty string, leaving behind only the unit suffix. It can also happen when a numeric value is accidentally deleted during editing.

Beyond layout breakdowns, invalid CSS can cause inconsistent rendering across browsers. Some browsers may silently discard the invalid declaration, while others might apply unexpected fallback behavior. Keeping your CSS valid ensures predictable, cross-browser results and makes your stylesheets easier to maintain and debug.

How to Fix It

Add the missing numeric value — Pair every unit with a number, e.g., 300px, 1.5em, 50%.
Use 0 without a unit for zero values — The value 0 is valid on its own and doesn’t require a unit.
Use a valid keyword — Properties like width accept keywords such as auto, min-content, max-content, and fit-content.
Check dynamic values — If a preprocessor or template engine generates the value, verify it outputs a complete length (e.g., ${value}px where value is not empty).

Examples

Incorrect: unit without a number

<style>
  .box {
    width: px;
  }
</style>
<div class="box">Content</div>

The declaration width: px is invalid because px alone is not a recognized CSS value. The browser will discard this rule.

Incorrect: number without a unit

<style>
  .box {
    width: 300;
  }
</style>
<div class="box">Content</div>

A unitless number (other than 0) is also invalid for the width property. Browsers will ignore this declaration as well.

Correct: number paired with a unit

<style>
  .box {
    width: 300px;
  }
</style>
<div class="box">Content</div>

Correct: using different valid length units

<style>
  .box-a {
    width: 50%;
  }
  .box-b {
    width: 20em;
  }
  .box-c {
    width: 15rem;
  }
  .box-d {
    width: 80vw;
  }
</style>

Correct: zero value and keywords

<style>
  .collapsed {
    width: 0;
  }
  .flexible {
    width: auto;
  }
  .intrinsic {
    width: fit-content;
  }
</style>

The value 0 is the only number that doesn’t require a unit in CSS. Keywords like auto, min-content, max-content, and fit-content are also valid for width and don’t use numeric lengths at all.

Common CSS Length Units

Unit	Description
px	Pixels (absolute unit)
em	Relative to the element’s font size
rem	Relative to the root element’s font size
%	Percentage of the containing block’s dimension
vw	1% of the viewport width
vh	1% of the viewport height
ch	Width of the “0” character in the element’s font

Always double-check that your CSS length values include both a number and a unit. If you’re generating styles dynamically, add safeguards to ensure the numeric portion is never empty before the unit is appended.

CSS: "stroke-width": valores negativos "-X" não são permitidos.

The stroke-width property controls the thickness of the outline (stroke) drawn around shapes and text, primarily used in SVG but also applicable to HTML elements via CSS. According to both the SVG specification and the CSS standard, stroke-width accepts only non-negative values — that is, zero or any positive number, optionally with a CSS length unit like px, em, or rem. A unitless number is also valid and is interpreted in the current coordinate system’s user units.

Negative values are logically meaningless for stroke width because you cannot draw an outline with negative thickness. Browsers will typically ignore or discard the invalid declaration, meaning the stroke may render with an unexpected default width or not at all. Beyond rendering issues, using invalid CSS values causes W3C validation errors, which can indicate broader quality problems in your code and may lead to unpredictable behavior across different browsers.

A common cause of this error is dynamic value generation — for example, a CSS calc() expression or a preprocessor variable that inadvertently produces a negative result. If your stroke width is computed, make sure to clamp the value so it never goes below 0.

How to fix it

Replace negative values with 0 or a positive number. If you intended no visible stroke, use 0. If you wanted a visible stroke, use the appropriate positive thickness.
Guard computed values. If the value comes from a calc() expression or CSS custom property, use max() to ensure the result is never negative — for example, stroke-width: max(0px, calc(10px - 15px)).
Check inline styles and stylesheets. The error can appear in both inline style attributes and external/internal CSS. Search your codebase for any stroke-width declaration with a negative number.

Examples

❌ Invalid: negative stroke-width on an HTML element

<p style="stroke-width: -1">Some content</p>

This triggers the validator error because -1 is not an allowed value.

✅ Fixed: non-negative stroke-width

<p style="stroke-width: 0">Some content</p>

Using 0 removes the stroke entirely and is valid.

❌ Invalid: negative stroke-width on an SVG element

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="-3" fill="none"/>
</svg>

✅ Fixed: positive stroke-width on an SVG element

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="none"/>
</svg>

✅ Using max() to clamp a computed value

<div style="stroke-width: max(0px, calc(5px - 10px))">Some content</div>

Here, calc(5px - 10px) would produce -5px, but max(0px, ...) ensures the final value is 0px, keeping the CSS valid.

CSS: "text-overflow": X não é um valor de "text-overflow".

The text-overflow CSS property controls how overflowed content that is not displayed is signaled to users. It applies when an element’s overflow is hidden (e.g., overflow: hidden) and the content exceeds the element’s box. The property accepts specific values, and using anything outside the allowed set — such as a misspelled keyword, an unquoted string, or a made-up value — will trigger this validation error.

Accepted values

The text-overflow property accepts the following values:

clip — Truncates the text at the edge of the content area. Characters may be clipped mid-glyph. This is the default.
ellipsis — Displays an ellipsis character (…) to indicate clipped text.
A custom <string> — A quoted string to display at the clipping point (e.g., " [..]"). Note that browser support for custom strings is limited.
Global CSS values — inherit, initial, revert, revert-layer, and unset.

The property can take one or two values. If one value is given, it specifies the overflow behavior for the end of the line (the right end for left-to-right text, the left end for right-to-left text). If two values are given, the first controls the left end of the line and the second controls the right end. Two-value syntax has limited browser support.

Common mistakes that trigger this error include:

Misspelling ellipsis (e.g., elipsis, ellipses).
Using a value from a different property (e.g., hidden, scroll, auto).
Using an unquoted custom string instead of a properly quoted one.
Using a numeric or length value (e.g., 10px), which is not valid for this property.

Why this matters

Invalid CSS values are ignored by browsers, which means the property will fall back to its default (clip) instead of behaving as you intended. This can lead to text being abruptly cut off without any visual indicator, harming readability and user experience. Fixing validation errors also ensures your stylesheets are clean, predictable, and maintainable.

Examples

Incorrect — misspelled keyword

/* "elipsis" is not a valid text-overflow value */
.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: elipsis;
}

Incorrect — value from another property

/* "hidden" is an overflow value, not a text-overflow value */
.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: hidden;
}

Incorrect — unquoted custom string

/* Custom strings must be quoted */
.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: [more];
}

Correct — using ellipsis

.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

Correct — using clip (the default)

.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: clip;
}

Correct — using a quoted custom string

.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: " [..]";
}

Correct — two-value syntax

/* Left end uses ellipsis, right end uses a custom string */
.truncated {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis " [..]";
}

Note that text-overflow on its own does not force overflow to occur. To make text actually truncate, you typically need overflow: hidden (or another non-visible overflow value) and white-space: nowrap on the element. The text-overflow property only controls how the clipped content is signaled visually.

CSS: "text-transform": "X" não é um valor "text-transform".

The text-transform CSS property controls the capitalization of text within an element. It’s commonly used to enforce consistent text casing — for example, making headings appear in all uppercase or ensuring navigation links are lowercase — without changing the actual content in the HTML. When the validator encounters a value it doesn’t recognize for this property, it flags it as invalid.

This error can occur for several reasons:

Typos — writing upppercase instead of uppercase, or Capitalize instead of capitalize (CSS values are case-sensitive in validation contexts).
Incorrect values — using values from other properties, like bold, italic, or center, which don’t apply to text-transform.
Non-standard values — using browser-specific or experimental values that aren’t part of the CSS specification.
Wrong property — confusing text-transform with text-decoration, text-align, or font-variant, and using their values here instead.

Fixing this matters because invalid CSS can lead to unpredictable rendering across browsers. While most browsers will simply ignore an invalid declaration, your intended styling won’t be applied, potentially breaking your design. Keeping your CSS valid also improves maintainability and ensures forward compatibility.

Valid values for text-transform

Value	Effect
none	No capitalization change (default)
capitalize	First letter of each word is uppercased
uppercase	All characters are converted to uppercase
lowercase	All characters are converted to lowercase
full-width	Forces characters into a full-width form (useful for CJK typography)
full-size-kana	Converts small kana characters to full-size equivalents

Examples

Incorrect — invalid value

In this example, bold is not a valid text-transform value. It likely belongs on the font-weight property instead.

<p style="text-transform: bold;">Welcome to our site</p>

Similarly, a simple typo will trigger this error:

<p style="text-transform: uppercse;">Welcome to our site</p>

Correct — using valid values

<p style="text-transform: uppercase;">Welcome to our site</p>

<p style="text-transform: capitalize;">Welcome to our site</p>

Correct — separating concerns with the right properties

If you intended to make text bold and uppercase, use the appropriate property for each effect:

<p style="font-weight: bold; text-transform: uppercase;">Welcome to our site</p>

Correct — using text-transform in a stylesheet

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Text Transform Example</title>
  <style>
    .heading {
      text-transform: uppercase;
    }
    .name {
      text-transform: capitalize;
    }
    .code-snippet {
      text-transform: none;
    }
  </style>
</head>
<body>
  <h1 class="heading">site navigation</h1>
  <p class="name">john doe</p>
  <code class="code-snippet">myVariable</code>
</body>
</html>

If you’re unsure which value you need, uppercase and capitalize are the most commonly used. Use none when you need to override a text-transform rule inherited from a parent element.

Pronto para validar os seus sites?
Comece o seu teste gratuito hoje.

Teste Pro Teste Gratuito