HTML Guides

HTML has a defined set of global attributes (like class, id, title, lang, etc.) and element-specific attributes that are permitted by the specification. Any attribute that falls outside this set — such as st_url, st_title, or displayText — will trigger a validation error because the browser and the validator don't recognize it as part of the HTML standard.

The st_url attribute, along with related attributes like st_title, st_via, and displayText, originated from early versions of the ShareThis social sharing library. These were proprietary attributes that the ShareThis JavaScript would read from the DOM to configure sharing behavior. While browsers generally ignore attributes they don't understand (so the page may still appear to work), using non-standard attributes violates the HTML specification and can cause several problems:

• Standards compliance: Invalid HTML can lead to unpredictable behavior across different browsers and future browser versions.
• Accessibility: Screen readers and other assistive technologies may not handle non-standard attributes correctly, potentially causing confusion.
• Maintainability: Non-standard markup is harder for other developers to understand and maintain.
• SEO: Search engine crawlers may penalize or misinterpret pages with significant validation errors.

HTML5 introduced data-* attributes specifically to solve this problem. Any custom data you need to attach to an element can use this pattern — for example, data-st-url instead of st_url. The ShareThis library itself updated its integration to use data-* attributes in later versions, so modern implementations should already follow this pattern.

How to Fix

1. Replace proprietary attributes with data-* equivalents: Convert st_url to data-st-url, st_title to data-st-title, displayText to data-display-text, and so on.
2. Update your ShareThis integration: If you're using an outdated version of ShareThis (or an outdated CMS module/plugin like an old Drupal integration), update to the latest version, which uses valid HTML5 attributes.
3. Check your CMS templates: If the invalid attributes are hardcoded in a theme template or a content block, update them manually.

Examples

Invalid: Proprietary attributes on a <span>

<spanclass="st_facebook_large"displayText="Facebook"st_url="https://example.com"st_title="My Page Title"></span>

<spanclass="st_twitter_large"displayText="Twitter"st_url="https://example.com"st_title="My Page Title"></span>

This markup uses st_url, st_title, and displayText, none of which are valid HTML attributes.

Valid: Using data-* attributes instead

<spanclass="st_facebook_large"data-display-text="Facebook"data-st-url="https://example.com"data-st-title="My Page Title"></span>

<spanclass="st_twitter_large"data-display-text="Twitter"data-st-url="https://example.com"data-st-title="My Page Title"></span>

By prefixing each custom attribute with data-, the markup becomes valid HTML5. Note that you may also need to update the associated JavaScript to read from these new attribute names (e.g., using element.dataset.stUrl instead of element.getAttribute('st_url')).

Valid: Modern ShareThis integration

If you're updating your ShareThis integration entirely, the modern approach uses a different markup pattern:

<divclass="sharethis-inline-share-buttons"data-url="https://example.com"data-title="My Page Title"></div>

Modern versions of the ShareThis library expect data-* attributes by default, so upgrading the library and its associated markup is the cleanest solution. Check the ShareThis documentation for the latest recommended integration approach for your platform.

HTML has a defined set of global attributes (such as id, class, lang, and title) and element-specific attributes. Any attribute that isn't part of these recognized sets will trigger a validation error. The st_title attribute is a proprietary, non-standard attribute that was used by older versions of the ShareThis sharing widget to pass metadata — specifically, the title of the content being shared.

The HTML5 specification introduced data-* attributes as the standard mechanism for embedding custom data on elements. These attributes allow developers to store arbitrary information without conflicting with the HTML spec. Newer versions of ShareThis and similar services have adopted this convention, but legacy code — especially in CMS themes, plugins, or modules — may still use the old non-standard format.

Using invalid attributes causes several problems:

• Standards compliance: The document fails W3C validation, which can indicate deeper markup quality issues.
• Future compatibility: Browsers are not required to handle non-standard attributes in any predictable way. Future browser updates could ignore or strip them.
• Maintainability: Non-standard attributes make code harder for other developers to understand and maintain.
• Accessibility tools: Screen readers and other assistive technologies rely on well-formed HTML. Invalid attributes can cause unexpected behavior in these tools.

To fix this, replace all proprietary ShareThis attributes with their data-* equivalents. For example, st_title becomes data-st-title, st_url becomes data-st-url, and displayText becomes data-st-displaytext. You should also update the ShareThis JavaScript library to a version that recognizes the new attribute format.

Examples

❌ Invalid: Using proprietary attributes

<spanclass="st_sharethis"st_title="My Article"st_url="https://example.com/article"displayText="ShareThis">

Share

</span>

This triggers validation errors for st_title, st_url, and displayText because none of these are valid HTML attributes.

✅ Valid: Using data-* attributes

<spanclass="st_sharethis"data-st-title="My Article"data-st-url="https://example.com/article"data-st-displaytext="ShareThis">

Share

</span>

All custom data is now stored in properly namespaced data-* attributes, which are fully compliant with the HTML5 specification.

✅ Valid: Using a button element with data-* attributes

If the element is interactive (e.g., it triggers a share action on click), consider using a <button> instead of a <span> for better accessibility:

<buttontype="button"class="st_sharethis"data-st-title="My Article"data-st-url="https://example.com/article">

Share this article

</button>

Fixing this in a CMS

If you're using Drupal, WordPress, or another CMS with a ShareThis module or plugin:

1. Update the plugin/module to the latest version — most have already migrated to data-* attributes.
2. Check your theme templates for hardcoded ShareThis markup that may still use the old attribute format.
3. Search your codebase for st_title, st_url, and displayText and replace them with data-st-title, data-st-url, and data-st-displaytext respectively.
4. Update the ShareThis JavaScript to a version compatible with the new attribute names, and verify that sharing functionality still works after the change.

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

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

HTML Example With the Issue

<divstyle="display: flex;flex-wrap: no-wrap;">

<p>Item 1</p>

<p>Item 2</p>

</div>

Fixed HTML Example

<divstyle="display: flex;flex-wrap: nowrap;">

<p>Item 1</p>

<p>Item 2</p>

</div>

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:

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

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

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

Incorrect: missing unit

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

Non-zero numeric values must include a unit.

Incorrect: invalid keyword or typo

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

The keyword inherit is misspelled.

Correct: single length value

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

Correct: percentage value

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

Correct: using calc() for computed values

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

Correct: using a keyword

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

Correct: using auto

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

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

HTML documents must use UTF-8 as their character encoding. The legacy encoding iso-8859-15 is no longer allowed in modern HTML.

The HTML living standard requires all documents to be encoded in UTF-8. Older encodings like iso-8859-15 (also known as Latin-9) were common in the past, especially for Western European languages, but they are now considered legacy. UTF-8 supports virtually all characters from every writing system, making it the universal standard for the web.

To fix this, you need to do two things. First, update the <meta> charset declaration in your HTML to specify UTF-8. Second — and this is the important part — you must actually save or convert the file itself to UTF-8 encoding. Simply changing the meta tag without re-encoding the file can cause characters like é, ñ, or € to display incorrectly.

Most modern code editors (VS Code, Sublime Text, Notepad++) let you change the file encoding. In VS Code, click the encoding label in the bottom status bar and choose "Save with Encoding" → "UTF-8".

If your server is sending an iso-8859-15 charset in the HTTP Content-Type header, you'll also need to update that. The HTTP header takes precedence over the meta tag.

HTML Examples

❌ Incorrect: legacy encoding

<!DOCTYPE html>

<htmllang="fr">

<head>

<metacharset="iso-8859-15">

<title>Mon site</title>

</head>

<body>

<p>Bienvenue sur mon site € 2025</p>

</body>

</html>

✅ Correct: UTF-8 encoding

<!DOCTYPE html>

<htmllang="fr">

<head>

<metacharset="utf-8">

<title>Mon site</title>

</head>

<body>

<p>Bienvenue sur mon site € 2025</p>

</body>

</html>

If you're using an Apache server, update your .htaccess or server config:

AddDefaultCharset UTF-8

For Nginx, update the server block:

charset utf-8;

The async attribute tells the browser to download and execute a script without blocking HTML parsing. For external scripts (those with a src attribute), this means the browser can continue parsing the page while fetching the file, then execute the script as soon as it's available. For inline module scripts (type="module"), async changes how the module's dependency graph is handled — the module and its imports execute as soon as they're all ready, rather than waiting for HTML parsing to complete.

For a classic inline script (no src, no type="module"), there is nothing to download asynchronously. The browser encounters the code directly in the HTML and executes it immediately. Applying async in this context is meaningless and contradicts the HTML specification, which is why the W3C validator flags it as an error.

Beyond standards compliance, using async incorrectly can signal a misunderstanding of script loading behavior, which may lead to bugs. For example, a developer might mistakenly believe that async on an inline script will defer its execution, when in reality it has no effect and the script still runs synchronously during parsing.

How to Fix

You have several options depending on your intent:

1. If the script should be external, move the code to a separate file and reference it with the src attribute alongside async.
2. If the script should be an inline module, add type="module" to the <script> tag. Note that module scripts are deferred by default, and async makes them execute as soon as their dependencies are resolved rather than waiting for parsing to finish.
3. If the script is a plain inline script, simply remove the async attribute — it has no practical effect anyway.

Examples

❌ Invalid: async on a classic inline script

<scriptasync>

console.log("Hello, world!");

</script>

This triggers the validator error because there is no src attribute and the type is not "module".

✅ Fixed: Remove async from the inline script

<script>

console.log("Hello, world!");

</script>

✅ Fixed: Use async with an external script

<scriptasyncsrc="app.js"></script>

The async attribute is valid here because the browser needs to fetch app.js from the server, and async controls when that downloaded script executes relative to parsing.

✅ Fixed: Use async with an inline module

<scriptasynctype="module">

import{greet}from"./utils.js";

greet();

</script>

This is valid because module scripts have a dependency resolution phase that can happen asynchronously. The async attribute tells the browser to execute the module as soon as all its imports are resolved, without waiting for the document to finish parsing.

❌ Invalid: async with type="text/javascript" (not a module)

<scriptasynctype="text/javascript">

console.log("This is still invalid.");

</script>

Even though type is specified, only type="module" satisfies the requirement. The value "text/javascript" is the default classic script type and does not make async valid on an inline script.

The http-equiv attribute on a <meta> element simulates an HTTP response header, allowing you to define document-level metadata that would otherwise require server configuration. Because this metadata applies to the entire document and must be processed before the page content is rendered, the HTML specification requires that <meta http-equiv> elements appear within the <head> element. Placing them in the <body> is invalid and may cause browsers to ignore them entirely, leading to unexpected behavior like incorrect character encoding, broken content security policies, or missing refresh directives.

This error commonly occurs when:

• A <meta http-equiv> tag is accidentally placed inside <body>.
• Content is copy-pasted from one document into the body of another, bringing along <meta> tags.
• A templating system or CMS injects <meta> tags in the wrong location.

Common http-equiv values

The http-equiv attribute supports several standard values:

• content-type — Declares the document's MIME type and character encoding. In HTML5, the shorthand <meta charset="UTF-8"> is preferred instead.
• refresh — Instructs the browser to reload the page or redirect after a specified number of seconds. Note that automatic refreshing is discouraged for accessibility reasons: it can disorient users, move focus back to the top of the page, and disrupt assistive technology. Avoid it unless absolutely necessary.
• content-security-policy — Defines a Content Security Policy for the document, helping prevent cross-site scripting (XSS) and other code injection attacks.
• default-style — Specifies the preferred stylesheet from a set of alternative stylesheets.

How to fix it

Find every <meta http-equiv> element in your document and ensure it is placed inside the <head> element, before any content in <body>. If the tag is duplicated or unnecessary, remove it.

Examples

❌ Incorrect: http-equiv inside <body>

<!DOCTYPE html>

<htmllang="en">

<head>

<title>My Page</title>

</head>

<body>

<metahttp-equiv="content-type"content="text/html; charset=UTF-8">

<p>Hello, world!</p>

</body>

</html>

The <meta http-equiv> tag is inside <body>, which triggers the validation error.

✅ Correct: http-equiv inside <head>

<!DOCTYPE html>

<htmllang="en">

<head>

<metahttp-equiv="content-type"content="text/html; charset=UTF-8">

<title>My Page</title>

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

✅ Correct: using the HTML5 charset shorthand

In HTML5, you can replace <meta http-equiv="content-type" content="text/html; charset=UTF-8"> with the simpler charset attribute:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="UTF-8">

<title>My Page</title>

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

✅ Correct: Content Security Policy in <head>

<head>

<metacharset="UTF-8">

<metahttp-equiv="content-security-policy"content="default-src 'self'">

<title>Secure Page</title>

</head>

The content-security-policy value is particularly placement-sensitive — browsers will ignore it if it appears outside <head>, leaving your page without the intended security protections.

The autocomplete attribute tells the browser whether it can assist the user in filling out a form field, and if so, what type of data is expected. The generic values "on" and "off" control whether the browser should offer autofill suggestions to the user. Since type="hidden" inputs are never displayed and never receive direct user input, these values don't apply — there's no user interaction to assist with.

According to the HTML specification, hidden inputs can have an autocomplete attribute, but only with specific named autofill detail tokens (like "transaction-id" or "cc-number"). These tokens serve a programmatic purpose by providing hints about the semantic meaning of the hidden value, which can be useful for form processing. The generic "on" and "off" values, however, are explicitly disallowed because they only relate to the user-facing autofill behavior.

This validation error matters for standards compliance and can indicate a logical mistake in your markup. If you added autocomplete="off" to a hidden input hoping to prevent the browser from caching or modifying the value, it won't have that effect. Hidden input values are controlled entirely by the server or by JavaScript, not by browser autofill.

How to fix it

1. Remove the autocomplete attribute if it's not needed — this is the most common fix.
2. Use a specific autofill token if you need to convey semantic meaning about the hidden value (e.g., autocomplete="transaction-id").
3. Reconsider the input type — if the field genuinely needs autofill behavior controlled, it probably shouldn't be type="hidden".

Examples

Incorrect: using autocomplete="off" on a hidden input

<formaction="/submit"method="post">

<inputtype="hidden"name="token"value="abc123"autocomplete="off">

<buttontype="submit">Submit</button>

</form>

Incorrect: using autocomplete="on" on a hidden input

<formaction="/submit"method="post">

<inputtype="hidden"name="session-id"value="xyz789"autocomplete="on">

<buttontype="submit">Submit</button>

</form>

Correct: removing the autocomplete attribute

<formaction="/submit"method="post">

<inputtype="hidden"name="token"value="abc123">

<buttontype="submit">Submit</button>

</form>

Correct: using a specific autofill token

If the hidden input carries a value with a well-defined autofill semantic, you can use a named token:

<formaction="/checkout"method="post">

<inputtype="hidden"name="txn"value="TXN-001"autocomplete="transaction-id">

<buttontype="submit">Complete Purchase</button>

</form>

This is valid because "transaction-id" is a specific autofill detail token recognized by the specification, unlike the generic "on" or "off" values.

The xmlns:sodipodi attribute is a namespace declaration left over from the Inkscape SVG editor and is not valid in HTML5 documents.

When you embed an SVG directly in HTML, the HTML5 parser only recognizes a limited set of namespace declarations. The xmlns:sodipodi namespace (along with others like xmlns:inkscape) is specific to Inkscape's internal SVG format and serves no purpose in the browser. The W3C validator flags it because it cannot be serialized as XML 1.0 within the HTML5 context.

Inkscape adds several custom namespaces and attributes to SVG files for its own editing purposes. These include sodipodi:* and inkscape:* namespaces, along with their associated attributes and elements. Browsers simply ignore them, so removing them has no effect on how the SVG renders.

The fix is straightforward: remove the xmlns:sodipodi declaration from the <svg> tag, and also remove any sodipodi:* attributes or <sodipodi:*> elements throughout the SVG.

HTML Examples

❌ Invalid: SVG with Inkscape namespaces

<svgxmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

viewBox="0 0 100 100"

sodipodi:docname="icon.svg">

<sodipodi:namedviewpagecolor="#ffffff"/>

<circlecx="50"cy="50"r="40"fill="blue"

inkscape:label="Main Circle"/>

</svg>

✅ Valid: Cleaned SVG without editor-specific namespaces

<svgviewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

If you frequently export SVGs from Inkscape, consider using the "Plain SVG" export option (File → Save As → Plain SVG) instead of the default "Inkscape SVG" format. You can also use tools like SVGO or SVG Cleaner to automatically strip editor metadata before embedding.

HTML5 uses a specific serialization format that is distinct from XML. While XML allows you to declare arbitrary namespace prefixes using xmlns:prefix attributes, the HTML parser does not recognize or process these declarations. The HTML specification only supports a small set of predefined namespaces — the default HTML namespace, SVG (http://www.w3.org/2000/svg), MathML (http://www.w3.org/1998/Math/MathML), XLink, XML, and XMLNS — and these are handled implicitly through the appropriate embedding elements (<svg>, <math>), not through explicit xmlns: declarations.

The phrase "not serializable as XML 1.0" in the validator message means that this attribute cannot be round-tripped between the HTML parser and an XML serializer. The HTML parser treats xmlns:w as an opaque attribute name containing a colon, rather than as a namespace declaration. If you were to serialize this DOM back to XML, the result would be invalid because xmlns:w would be interpreted as a namespace declaration for a prefix that may conflict with actual element usage.

This issue almost always originates from content exported or pasted from Microsoft Word, Excel, or other Office applications. These tools generate markup laden with proprietary namespace declarations like xmlns:w, xmlns:o (Office), xmlns:v (VML), and xmlns:x (Excel). Along with these declarations come Office-specific elements and attributes (e.g., <w:WordDocument>, <o:OfficeDocumentSettings>) that have no meaning in a web browser and bloat your HTML.

Beyond being a validation error, leaving this markup in place creates several problems. It adds significant unnecessary weight to your pages, makes the source code harder to read and maintain, and signals that the HTML was auto-generated without cleanup — which can affect long-term maintainability. Browsers silently ignore these attributes and elements, so they provide no functional benefit.

How to fix it

1. Remove all xmlns: prefixed attributes from your HTML elements, including xmlns:w, xmlns:o, xmlns:v, xmlns:x, and any others.
2. Remove any Office-specific elements that use those namespace prefixes, such as <o:p>, <w:WordDocument>, or <v:shapetype>. These elements are meaningless in HTML5.
3. Clean up associated conditional comments like <!--[if gte mso 9]> that often wrap Office-specific blocks.
4. Consider using a paste-cleanup tool if you regularly paste content from Word into your HTML. Many CMS platforms and text editors offer "paste as plain text" or "clean HTML" options.

If you genuinely need to work with Office Open XML namespaces, use an appropriate XML-based format (XHTML served as application/xhtml+xml, or OOXML documents) rather than standard HTML5.

Examples

Incorrect — Office namespace declarations in HTML

This markup is typical of content saved or exported from Microsoft Word:

<htmlxmlns:w="urn:schemas-microsoft-com:office:word"

xmlns:o="urn:schemas-microsoft-com:office:office"

xmlns:v="urn:schemas-microsoft-com:vml">

<head>

<title>Report</title>

<!--[if gte mso 9]> <w:WordDocument> <w:View>Normal</w:View> </w:WordDocument> <![endif]-->

<w:WordDocument>

<w:View>Normal</w:View>

</w:WordDocument>

<![endif]-->

</head>

<body>

<pclass="MsoNormal">Hello world<o:p></o:p></p>

</body>

</html>

Correct — Clean HTML without Office markup

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Report</title>

</head>

<body>

<p>Hello world</p>

</body>

</html>

Incorrect — Single namespace on the <html> element

Even a single custom namespace declaration triggers the error:

<htmlxmlns:w="urn:schemas-microsoft-com:office:word">

<head>

<title>My Page</title>

</head>

<body>

<p>Content here.</p>

</body>

</html>

Correct — Remove the attribute entirely

<!DOCTYPE html>

<htmllang="en">

<head>

<title>My Page</title>

</head>

<body>

<p>Content here.</p>

</body>

</html>

Note that the default xmlns="http://www.w3.org/1999/xhtml" attribute on the <html> element is permitted (though unnecessary in HTML5), but any prefixed namespace declaration like xmlns:w is not.

When graphic design tools like Affinity Designer (formerly Serif) export SVG files, they often embed custom namespace declarations such as xmlns:serif="http://www.serif.com/". These namespaces allow the editor to store its own metadata — like layer names, grouping information, or application-specific settings — inside the SVG file. While this metadata is useful if you re-open the file in the original editor, it has no meaning in a web browser.

The HTML5 specification defines a specific set of namespace attributes that are allowed in SVG elements (such as xmlns, xmlns:xlink, and xmlns:xml). Any namespace prefix not in this predefined list — like xmlns:serif, xmlns:inkscape, or xmlns:sodipodi — triggers this validation error because the HTML parser cannot serialize these attributes back into well-formed XML 1.0. This isn't just a theoretical concern: non-serializable attributes can cause issues when the DOM is manipulated via JavaScript or when the markup is processed by XML-based tools.

Beyond the xmlns:serif declaration itself, you'll likely find attributes in the SVG that use this namespace prefix, such as serif:id="layer1". These should also be removed since they reference a namespace the browser doesn't understand.

How to Fix It

1. Remove the xmlns:serif attribute from the <svg> element.
2. Remove any attributes prefixed with serif: (e.g., serif:id) from child elements within the SVG.
3. If you re-export the SVG, check your editor's export settings — some tools offer a "clean" or "optimized" export option that strips proprietary metadata.
4. Consider using an SVG optimization tool like SVGO to automatically clean up unnecessary attributes.

Examples

❌ Invalid: SVG with xmlns:serif attribute

<svgxmlns="http://www.w3.org/2000/svg"

xmlns:serif="http://www.serif.com/"

viewBox="0 0 100 100"

width="100"

height="100">

<gserif:id="Layer 1">

<circlecx="50"cy="50"r="40"fill="blue"/>

</g>

</svg>

This triggers the error because xmlns:serif is not a recognized namespace in HTML5, and serif:id references that unsupported namespace.

✅ Valid: SVG with proprietary attributes removed

<svgxmlns="http://www.w3.org/2000/svg"

viewBox="0 0 100 100"

width="100"

height="100">

<g>

<circlecx="50"cy="50"r="40"fill="blue"/>

</g>

</svg>

Both xmlns:serif and serif:id have been removed. The SVG renders identically in the browser since those attributes were only meaningful to the editing application.

Handling Multiple Proprietary Namespaces

Exported SVGs sometimes contain several non-standard namespaces at once. Remove all of them:

<!-- ❌ Invalid: multiple proprietary namespaces -->

<svgxmlns="http://www.w3.org/2000/svg"

xmlns:serif="http://www.serif.com/"

xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

viewBox="0 0 200 200">

<rectx="10"y="10"width="180"height="180"fill="red"

serif:id="background"

inkscape:label="bg-rect"/>

</svg>

<!-- ✅ Valid: all proprietary namespaces and prefixed attributes removed -->

<svgxmlns="http://www.w3.org/2000/svg"

viewBox="0 0 200 200">

<rectx="10"y="10"width="180"height="180"fill="red"/>

</svg>

If you frequently work with SVGs from design tools, integrating an SVG optimizer into your build process can save time and ensure these non-standard attributes never reach production.

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

Common causes of this error include:

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

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

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

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

Examples

Incorrect — invalid values

<style>

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

.grid-a{

display: grid;

grid-template-rows: full auto;

}

/* ERROR: space between number and unit */

.grid-b{

display: grid;

grid-template-rows:100 px 200 px;

}

/* ERROR: bare number without a unit */

.grid-c{

display: grid;

grid-template-rows:100200;

}

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

.grid-d{

display: grid;

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

}

</style>

Correct — valid track sizes

<style>

/* Fixed pixel heights */

.grid-a{

display: grid;

grid-template-rows:100px auto;

}

/* Flexible units */

.grid-b{

display: grid;

grid-template-rows:1fr2fr;

}

/* Repeat function with correct syntax */

.grid-c{

display: grid;

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

}

/* Minmax with auto */

.grid-d{

display: grid;

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

}

</style>

Full working example

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Grid template rows example</title>

<style>

.grid-container{

display: grid;

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

gap:8px;

height:400px;

}

.grid-container>div{

background:#e0e0e0;

padding:16px;

}

</style>

</head>

<body>

<divclass="grid-container">

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

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

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

</div>

</body>

</html>

Using fit-content() and named lines

<style>

.grid{

display: grid;

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

}

</style>

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

The <area> element defines a clickable region within an image map (<map>). The coords attribute works together with the shape attribute to describe the geometry of that region. When the coordinates don't conform to the rules for the given shape, the browser may ignore the area entirely or interpret it unpredictably, making the clickable region inaccessible to users.

Each shape type has strict requirements:

• Rectangle (shape="rect"): Requires exactly four integers in the format x1,y1,x2,y2, where x1,y1 is the top-left corner and x2,y2 is the bottom-right corner. Because 0,0 is the top-left of the image, x1 must be less than x2 and y1 must be less than y2.
• Circle (shape="circle"): Requires exactly three integers in the format x,y,r, where x,y is the center of the circle and r is the radius. The radius must be a positive integer, and the first coordinate (the x-center) must be less than the third value (the radius) is not required—but the validator message mentions this constraint to flag cases where values appear swapped or malformed.
• Polygon (shape="poly"): Requires at least six integers (three x,y coordinate pairs), forming a polygon with at least three vertices (a triangle). The format is x1,y1,x2,y2,...,xn,yn, and the number of integers must be even since they represent pairs.

Getting these formats wrong is a standards compliance issue. Assistive technologies such as screen readers rely on valid <area> definitions to convey interactive regions to users. Invalid coordinates can also cause the clickable area to silently fail in some browsers.

Examples

Invalid: Rectangle with swapped coordinates

The top-left corner values are larger than the bottom-right corner values:

<mapname="nav">

<areashape="rect"coords="200,150,50,10"href="/home"alt="Home">

</map>

Fixed: Rectangle with correct coordinate order

<mapname="nav">

<areashape="rect"coords="50,10,200,150"href="/home"alt="Home">

</map>

Invalid: Circle with wrong number of values

Four values are provided instead of the required three:

<mapname="nav">

<areashape="circle"coords="100,75,50,25"href="/info"alt="Info">

</map>

Fixed: Circle with three values

<mapname="nav">

<areashape="circle"coords="100,75,50"href="/info"alt="Info">

</map>

Invalid: Polygon with too few coordinates

Only four integers (two coordinate pairs) are provided, but a polygon needs at least three pairs:

<mapname="nav">

<areashape="poly"coords="10,20,30,40"href="/about"alt="About">

</map>

Fixed: Polygon with at least three coordinate pairs

<mapname="nav">

<areashape="poly"coords="10,20,30,40,20,60"href="/about"alt="About">

</map>

Invalid: Non-integer or malformed values

Decimal numbers and spaces in the wrong places will also trigger this error:

<mapname="nav">

<areashape="rect"coords="10.5, 20, 100, 200"href="/page"alt="Page">

</map>

Fixed: Using only comma-separated integers

<mapname="nav">

<areashape="rect"coords="10,20,100,200"href="/page"alt="Page">

</map>

Complete valid image map example

<imgsrc="floorplan.png"alt="Office floor plan"usemap="#office">

<mapname="office">

<areashape="rect"coords="0,0,150,100"href="/lobby"alt="Lobby">

<areashape="circle"coords="200,150,40"href="/meeting-room"alt="Meeting room">

<areashape="poly"coords="300,50,400,50,400,150,350,200,300,150"href="/lounge"alt="Lounge">

</map>

When debugging coordinate issues, double-check that the shape attribute matches the number of coordinates you've provided, that all values are non-negative integers separated by commas with no extra spaces, and that rectangle corners are specified in the correct top-left to bottom-right order.

Custom namespace declarations like xmlns:rdf are not serializable as XML 1.0 when used inside HTML5 documents.

In HTML5 (the text/html serialization), the xmlns attribute is only supported in a very limited way. You can use xmlns to declare the default namespace on the <html> or <svg> element, but you cannot declare additional namespace prefixes like xmlns:rdf, xmlns:dc, or xmlns:cc. These prefixed namespace declarations are a feature of XML and XHTML, and the HTML5 parser simply treats them as regular attributes — which then fail XML 1.0 serialization rules.

This commonly happens when SVG files are exported from tools like Inkscape, which embed RDF metadata with namespace declarations. When you paste or include such SVGs directly in an HTML5 document, the validator flags these attributes.

The fix is straightforward: remove the unsupported namespace declarations and any elements that depend on them. If the SVG contains <rdf:RDF>, <cc:Work>, or <dc:title> blocks, those can be safely removed without affecting the visual rendering of the SVG.

HTML Examples

❌ Invalid: SVG with unsupported namespace declarations

<svgxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:cc="http://creativecommons.org/ns#"

viewBox="0 0 100 100">

<metadata>

<rdf:RDF>

<cc:Workrdf:about="">

<dc:title>My Icon</dc:title>

</cc:Work>

</rdf:RDF>

</metadata>

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

✅ Valid: SVG with namespace declarations and metadata removed

<svgviewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

If you need to preserve metadata, consider adding it outside the SVG using standard HTML elements like <meta> tags or structured data formats such as JSON-LD.

The <link> element defines a relationship between the current document and an external resource — most commonly stylesheets, icons, preloaded assets, or canonical URLs. According to the HTML specification, the element must include at least one of the href or imagesrcset attributes so the browser knows what resource is being linked. A <link> element without either attribute is essentially an empty declaration: it tells the browser about a relationship type (via rel) but provides no actual resource to fetch or reference.

This validation error commonly occurs in a few scenarios:

• Templating or CMS issues: A dynamic template generates a <link> tag but the URL variable is empty or undefined, resulting in a bare element with no href.
• Incomplete code: A developer adds a <link> with a rel attribute intending to fill in the href later but forgets to do so.
• Copy-paste mistakes: Attributes are accidentally removed during editing or refactoring.

Fixing this is important for several reasons. Browsers may ignore the element entirely or behave unpredictably when encountering a <link> with no resource URL. Unnecessary elements without purpose add bloat to the document and can confuse other developers reading the code. Additionally, tools that parse HTML — such as search engine crawlers and assistive technologies — rely on well-formed markup to correctly understand document relationships.

To resolve the issue, add an href attribute pointing to the target resource, use an imagesrcset attribute when providing responsive image sources, or include both when appropriate.

Examples

Invalid: missing both href and imagesrcset

This <link> declares a stylesheet relationship but doesn't specify where the stylesheet is located:

<linkrel="stylesheet">

This preload link has an as attribute but no resource to fetch:

<linkrel="preload"as="image"type="image/png">

Fixed: using href

The most common fix is adding an href attribute with a valid URL:

<linkrel="stylesheet"href="styles.css">

<linkrel="icon"href="favicon.ico">

<linkrel="canonical"href="https://example.com/page">

Fixed: using imagesrcset

For responsive image preloading, the imagesrcset attribute specifies multiple image sources at different resolutions. This is valid without href:

<linkrel="preload"as="image"type="image/png"imagesrcset="icon-1x.png 1x, icon-2x.png 2x">

Fixed: using both href and imagesrcset

You can combine both attributes. The href serves as a fallback resource while imagesrcset provides responsive alternatives:

<linkrel="preload"as="image"href="icon-1x.png"imagesrcset="icon-1x.png 1x, icon-2x.png 2x">

Handling dynamic templates

If your <link> elements are generated dynamically, make sure the element is only rendered when a valid URL is available. For example, in a template, wrap the output in a conditional check rather than outputting an empty <link>:

<!-- Bad: outputs a link even when the URL is empty -->

<linkrel="stylesheet"href="">

<!-- Good: only include the element when there's a real URL -->

<linkrel="stylesheet"href="styles.css">

Note that href="" resolves to the current page URL and is technically valid syntax (it won't trigger this specific error), but it's almost certainly not what you intend. Always ensure the href value points to the correct resource.

The HTML specification requires the src attribute of an <img> element to be a valid, non-empty URL. When you set src="", the browser has no resource to fetch, but many browsers will still attempt to make a request — often resolving the empty string relative to the current page URL. This means the browser may re-request the current HTML document as if it were an image, wasting bandwidth and potentially causing unexpected server-side behavior.

Beyond the technical waste, an empty src is problematic for accessibility. Screen readers rely on the <img> element to convey meaningful content. An image with no source provides no value and can confuse assistive technology users. Search engine crawlers may also flag this as a broken resource, negatively affecting SEO.

This issue commonly arises in a few scenarios:

• Placeholder images — developers leave src empty intending to set it later via JavaScript.
• Template rendering — a server-side template or frontend framework outputs an <img> tag before the image URL is available.
• Lazy loading implementations — the real source is stored in a data-src attribute while src is left empty.

How to fix it

The simplest fix is to provide a valid image URL in the src attribute. If the image source isn't available yet, consider these alternatives:

1. Don't render the <img> element at all until a valid source is available.
2. Use a small placeholder image (such as a transparent 1×1 pixel GIF or a lightweight SVG) as a temporary src.
3. Use native lazy loading with loading="lazy" and a real src, letting the browser handle deferred loading instead of relying on an empty src.

Examples

❌ Bad: empty src attribute

<imgsrc=""alt="Profile photo">

This triggers the validation error because the src value is an empty string.

❌ Bad: src with only whitespace

<imgsrc=""alt="Profile photo">

Whitespace-only values are also considered invalid and will produce a similar error.

✅ Good: valid image path

<imgsrc="photo.jpg"alt="Profile photo">

✅ Good: placeholder image for lazy loading

If you're implementing lazy loading and need a lightweight placeholder, use a small inline data URI or a real placeholder file:

<img

src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"

data-src="photo.jpg"

alt="Profile photo">

✅ Good: native lazy loading with a real src

Modern browsers support the loading attribute, eliminating the need for an empty src workaround:

<imgsrc="photo.jpg"alt="Profile photo"loading="lazy">

✅ Good: conditionally render the element

If the image URL might not be available, avoid rendering the <img> tag entirely. For example, in a template:

<!-- Only include the img element when a source exists -->

<imgsrc="photo.jpg"alt="Profile photo">

In frameworks like React, Vue, or server-side templating engines, use conditional logic to skip the <img> element when the URL is empty rather than outputting a tag with an empty src.

The <source> element is used inside <video>, <audio>, and <picture> elements to specify one or more media resources for the browser to choose from. Its src attribute is defined as a valid non-empty URL, meaning it must resolve to an actual file path or web address. An empty string does not satisfy this requirement and violates the HTML specification.

Why this is a problem

Standards compliance: The WHATWG HTML living standard explicitly requires the src attribute on <source> to be a non-empty, valid URL. An empty value makes the document invalid HTML.

Unexpected browser behavior: When a browser encounters an empty src, it may attempt to resolve it relative to the current page URL. This can trigger an unnecessary HTTP request back to the current page, resulting in wasted bandwidth, unexpected server load, or confusing errors in your network logs.

Broken media playback: An empty src means the browser has no media file to load. If the <source> element is the only one provided, the media element will fail to play entirely — often without a clear indication to the user of what went wrong.

Accessibility concerns: Screen readers and assistive technologies rely on well-formed HTML. Invalid markup can lead to unpredictable behavior or missed content announcements for users who depend on these tools.

How to fix it

1. Provide a valid URL — Set the src attribute to the correct path or URL of your media file.
2. Remove the element — If the media source is not yet available or is being set dynamically via JavaScript, remove the <source> element from the HTML entirely and add it later through script when the URL is known.
3. Check for template or CMS issues — This error often appears when a CMS or templating engine outputs a <source> tag with an empty variable. Ensure your template conditionally renders the element only when a valid URL exists.

Examples

Incorrect: empty src on <source> in a video

<videocontrols>

<sourcesrc=""type="video/mp4">

Your browser does not support the video tag.

</video>

Correct: valid URL in src

<videocontrols>

<sourcesrc="movie.mp4"type="video/mp4">

Your browser does not support the video tag.

</video>

Incorrect: empty src on <source> in a picture element

<picture>

<sourcesrc=""type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

Note that <source> inside <picture> uses srcset, not src. This example is doubly wrong — the attribute is both empty and incorrect. Here is the fix:

Correct: using srcset with a valid URL in a picture element

<picture>

<sourcesrcset="photo.webp"type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

Incorrect: multiple sources with one empty src

<audiocontrols>

<sourcesrc="song.ogg"type="audio/ogg">

<sourcesrc=""type="audio/mpeg">

</audio>

Correct: remove the source if no file is available

<audiocontrols>

<sourcesrc="song.ogg"type="audio/ogg">

<sourcesrc="song.mp3"type="audio/mpeg">

</audio>

Correct: conditionally add sources with JavaScript

If the URL is determined at runtime, avoid placing an empty <source> in your markup. Instead, add it dynamically:

<videoid="player"controls>

Your browser does not support the video tag.

</video>

<script>

constvideoUrl=getVideoUrl();// your logic here

if(videoUrl){

constsource=document.createElement("source");

source.src=videoUrl;

source.type="video/mp4";

document.getElementById("player").appendChild(source);

}

</script>

This approach keeps your HTML valid at all times and only inserts a <source> element when a real URL is available.

Namespace declarations like xmlns:dc on an <svg> element are not serializable as XML 1.0 when used in an HTML5 document.

In HTML5 (the text/html serialization), namespace declarations using the xmlns: prefix syntax are not valid attributes. The HTML parser does not treat these as actual XML namespace declarations — it sees them as regular attributes with a colon in the name, which cannot be serialized back to well-formed XML 1.0. This commonly happens when SVG code is exported from graphic editors like Inkscape or Adobe Illustrator, which include Dublin Core (dc), RDF, and other XML namespace declarations that are unnecessary for rendering.

The SVG will render perfectly fine in browsers without these namespace prefixes. If the <svg> element doesn't actually use any elements or attributes from those namespaces (like <dc:title>), you can safely remove them. If it does contain such elements, those elements are also typically unused by browsers and can be removed as well.

Invalid Example

<svgxmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

viewBox="0 0 100 100">

<metadata>

<rdf:RDF>

<rdf:Descriptionrdf:about="">

<dc:title>My Icon</dc:title>

</rdf:Description>

</rdf:RDF>

</metadata>

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

Valid Example

Remove the namespace declarations and any associated metadata elements:

<svgviewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

If you still want to provide a title for accessibility, use the standard SVG <title> element instead:

<svgviewBox="0 0 100 100"role="img">

<title>My Icon</title>

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

Namespaced attributes like xmlns:inkscape are not valid in HTML5 documents and should be removed from inline SVGs.

When you copy an SVG directly from editors like Inkscape or Adobe Illustrator, the markup often includes custom namespace declarations such as xmlns:inkscape or xmlns:sodipodi. These namespaces are used internally by the editor to store metadata like layer names, version info, and other tool-specific data.

In an HTML5 document, the HTML parser only recognizes a limited set of namespaces — specifically xmlns, xmlns:xlink, and the default SVG namespace. Any other namespaced attributes are not serializable as XML 1.0, which triggers this validation error.

The fix is straightforward: remove the editor-specific namespace declarations and any attributes that use those prefixes (e.g., inkscape:version, sodipodi:docname). These attributes serve no purpose in the browser and are safe to delete.

HTML Examples

❌ Invalid: editor-specific namespaces in inline SVG

<svgxmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.0.dtd"

inkscape:version="1.3"

sodipodi:docname="icon.svg"

width="100"height="100"viewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

✅ Valid: clean inline SVG without editor namespaces

<svgxmlns="http://www.w3.org/2000/svg"

width="100"height="100"viewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

Most SVG optimization tools like SVGO or Jake Archibald's SVGOMG will automatically strip these editor-specific namespaces and attributes for you.

The <link> element is used to define relationships between the current document and external resources — most commonly stylesheets, icons, and preloaded assets. The href attribute specifies the URL of that external resource, and it is the core purpose of the element. An empty href attribute makes the <link> element meaningless because there is no resource to fetch or reference.

Why This Is a Problem

Standards compliance: The HTML specification requires the href attribute on <link> to be a valid, non-empty URL. An empty string does not qualify as a valid URL, so the validator flags it as an error.

Unexpected browser behavior: When a browser encounters an empty href, it may resolve it relative to the current document's URL. This means the browser could end up making an unnecessary HTTP request for the current page itself, interpreting the HTML response as a stylesheet or other resource. This wastes bandwidth, can slow down page loading, and may trigger unexpected rendering issues.

Accessibility and semantics: An empty href provides no useful information to browsers, screen readers, or other user agents about the relationship between the document and an external resource. It adds noise to the DOM without contributing anything functional.

How to Fix It

1. Provide a valid URL: If the <link> element is meant to reference a resource, set href to the correct URL of that resource.
2. Remove the element: If no resource is needed, remove the entire <link> element rather than leaving it with an empty href.
3. Check dynamic rendering: This issue often occurs when a templating engine or CMS outputs a <link> element with a variable that resolves to an empty string. Add a conditional check so the element is only rendered when a valid URL is available.

Examples

❌ Incorrect: Empty href attribute

<linkrel="stylesheet"href="">

This triggers the validation error because href is empty.

❌ Incorrect: Empty href from a template

<!-- A template variable resolved to an empty string -->

<linkrel="icon"type="image/png"href="">

✅ Correct: Valid href pointing to a resource

<linkrel="stylesheet"href="/css/main.css">

✅ Correct: Valid href for a favicon

<linkrel="icon"type="image/png"href="/images/favicon.png">

✅ Correct: Remove the element if no resource is needed

<!-- Simply omit the <link> element entirely -->

✅ Correct: Conditional rendering in a template

If you're using a templating language, wrap the <link> in a conditional so it only renders when a URL is available. For example, in a Jinja2-style template:

{% if stylesheet_url %}

<linkrel="stylesheet"href="{{ stylesheet_url }}">

{% endif %}

This ensures the <link> element is never output with an empty href.

In XML-based formats like XHTML 1.0 or other XML vocabularies, namespace declarations such as xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" were used to associate element or attribute prefixes with specific namespace URIs. This allowed different XML vocabularies to coexist in a single document without naming conflicts. The xmlns:dt namespace in particular was commonly associated with Microsoft's XML data types, often seen in legacy ASP or older Microsoft-generated HTML.

HTML5, however, does not use the XML namespace mechanism. The HTML parser treats the document as HTML, not XML, and does not recognize or process custom namespace prefixes. The only xmlns-related attributes permitted in HTML5 are:

• xmlns on the <html> element, but only with the value http://www.w3.org/1999/xhtml (for compatibility with XHTML-serving scenarios).
• Implicit namespace handling for embedded <svg> and <math> elements, which the HTML parser manages automatically.

Any other xmlns:* attribute — such as xmlns:dt, xmlns:o, xmlns:v, or xmlns:st1 — is invalid in HTML5 and will trigger the W3C validator error: "Attribute with the local name 'xmlns:dt' is not serializable as XML 1.0."

Why this is a problem

• Standards compliance: Custom XML namespace attributes violate the HTML5 specification. The HTML parser does not process them, so they serve no functional purpose.
• Serialization issues: If the document is ever round-tripped through an XML serializer (for example, when converting HTML to XHTML), these attributes cannot be properly serialized under XML 1.0 rules, potentially causing parsing failures.
• Legacy baggage: These attributes typically appear in documents generated by older tools (such as Microsoft Word's "Save as HTML" feature) and carry over data-type or Office-specific namespace declarations that are meaningless in a modern web context.
• Document bloat: Keeping unused namespace declarations adds unnecessary bytes to your document without any benefit.

How to fix it

1. Search your HTML for any attributes starting with xmlns: on the <html> element or elsewhere in the document.
2. Remove them entirely. If your code relied on XML data types or Office-specific features tied to these namespaces, you'll need to refactor that logic using standard HTML5 attributes (such as data-* attributes) or JavaScript.
3. Ensure your document uses a standard HTML5 <!DOCTYPE html> declaration and a clean <html> tag.

If you're working with content pasted from Microsoft Word or similar tools, consider running it through an HTML cleaner to strip out all Office-specific markup.

Examples

Incorrect — custom xmlns:dt attribute

This triggers the validation error because xmlns:dt is not a valid attribute in HTML5:

<htmlxmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">

<head>

<title>My Page</title>

</head>

<body>

<p>Hello world</p>

</body>

</html>

Incorrect — multiple custom namespace declarations

Documents exported from older tools often include several invalid namespace attributes at once:

<htmlxmlns:o="urn:schemas-microsoft-com:office:office"

xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"

xmlns:v="urn:schemas-microsoft-com:vml">

<head>

<title>My Page</title>

</head>

<body>

<p>Hello world</p>

</body>

</html>

Correct — clean HTML5 document

Remove all custom xmlns:* attributes and use a standard HTML5 structure:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<title>My Page</title>

</head>

<body>

<p>Hello world</p>

</body>

</html>

Correct — using data attributes as a replacement

If you previously relied on namespace-prefixed attributes to store custom data on elements, use data-* attributes instead:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<title>My Page</title>

</head>

<body>

<pdata-type="datetime">2024-01-15</p>

</body>

</html>

The xmlns attribute defines the XML namespace for an element. For SVG, the correct namespace is http://www.w3.org/2000/svg, declared with xmlns="http://www.w3.org/2000/svg". The xmlns:svg attribute attempts to declare an additional prefixed namespace binding — essentially mapping the prefix svg: to the same namespace URI. This is redundant because the default (unprefixed) namespace already covers all SVG elements.

In HTML5, the parser handles namespaces internally. The HTML specification only permits a small set of namespace attributes: xmlns on certain elements (like <svg> and <math>) and xmlns:xlink for legacy compatibility. Arbitrary prefixed namespace declarations like xmlns:svg are not part of the HTML serialization format. The W3C validator raises this error because attributes containing colons in their local names (other than the specifically allowed ones) cannot be round-tripped through the HTML parser and serializer — they are "not serializable as XML 1.0."

Why this matters

• Standards compliance: HTML5 has strict rules about which namespace declarations are permitted. Using xmlns:svg violates these rules.
• Serialization issues: If a browser parses the HTML and then re-serializes it (e.g., via innerHTML), the xmlns:svg attribute may be lost, altered, or cause unexpected behavior because it falls outside the serializable attribute set.
• Redundancy: Even in pure XML/SVG documents, declaring xmlns:svg="http://www.w3.org/2000/svg" alongside xmlns="http://www.w3.org/2000/svg" is unnecessary. The default namespace already applies to the <svg> element and all its unprefixed descendants.

How to fix it

1. Locate the <svg> element (or any element) that contains the xmlns:svg attribute.
2. Remove xmlns:svg="http://www.w3.org/2000/svg" entirely.
3. Ensure the standard xmlns="http://www.w3.org/2000/svg" attribute remains if needed (note that when embedding SVG inline in an HTML5 document, even xmlns is optional since the HTML parser infers the namespace automatically).

Examples

Incorrect: redundant prefixed namespace declaration

<svgxmlns="http://www.w3.org/2000/svg"xmlns:svg="http://www.w3.org/2000/svg"viewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

The xmlns:svg attribute triggers the validation error because it is not serializable in HTML.

Correct: standard namespace only

<svgxmlns="http://www.w3.org/2000/svg"viewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

Correct: inline SVG in HTML5 without any namespace attribute

When SVG is embedded directly in an HTML5 document, the HTML parser automatically assigns the correct namespace, so you can omit xmlns altogether:

<svgviewBox="0 0 100 100">

<circlecx="50"cy="50"r="40"fill="blue"/>

</svg>

This is perfectly valid and is the most common pattern for inline SVG in modern HTML. The xmlns attribute is only strictly necessary when the SVG is served as a standalone XML file (with a .svg extension or an image/svg+xml content type).

The W3C HTML Validator raises this error when it encounters a namespaced attribute such as xmlns:m, xmlns:o, xmlns:v, or any other xmlns:* declaration in an HTML document. These prefixed namespace bindings are an XML concept defined in the XML Namespaces specification. In the HTML syntax (documents served with the text/html MIME type), the HTML parser does not treat these as namespace declarations — it treats them as regular attributes with a colon in the name. Because such attribute names are not serializable in XML 1.0, the validator reports the error.

This issue is extremely common with content exported from Microsoft Office (Word, Excel, PowerPoint). When you save or copy Office content as HTML, the generated markup often includes namespace declarations like xmlns:m (Office Math Markup Language), xmlns:o (Office namespace), xmlns:v (VML), and xmlns:w (Word-specific markup). These declarations were designed for older, XML-based HTML rendering and serve no purpose in modern HTML5 documents.

Why This Is a Problem

• Standards compliance: The HTML5 specification only permits the xmlns attribute (without a prefix) on the <html> element, and only with the value http://www.w3.org/1999/xhtml. Prefixed forms like xmlns:m are not allowed.
• Serialization: If a tool attempts to serialize the DOM as XML (for example, XMLSerializer), attributes with colons that aren't properly bound namespaces can cause failures or unexpected output.
• No functional benefit: In an HTML document, the browser's HTML parser ignores these namespace bindings. They don't enable any special behavior — they're dead weight in your markup.
• Maintainability: Leaving Office-generated namespace clutter in your HTML makes the code harder to read and maintain.

How to Fix It

1. Remove the xmlns:* attribute from your HTML element (or whichever element it appears on). In most cases, this is all you need to do — the namespaced content from Office isn't rendered by browsers anyway.
2. Clean up Office-generated HTML by stripping out all proprietary namespaces, conditional comments, and Office-specific elements. Tools like HTML Tidy or your editor's "paste as plain text" feature can help.
3. Use native HTML5 equivalents where possible. HTML5 natively supports MathML and SVG without requiring explicit namespace declarations.
4. Switch to XHTML only if you have a genuine need for XML namespaces. This means serving the document with the application/xhtml+xml MIME type and using well-formed XML syntax throughout.

Examples

Incorrect: Office-generated namespace declarations

This markup, typical of content exported from Microsoft Word, triggers the validation error:

<!DOCTYPE html>

<htmlxmlns:m="http://schemas.microsoft.com/office/2004/12/omml"

xmlns:o="urn:schemas-microsoft-com:office:office"

xmlns:v="urn:schemas-microsoft-com:vml">

<head>

<title>Office Export</title>

</head>

<body>

<p>Content from Word</p>

</body>

</html>

Correct: Clean HTML5 without namespace declarations

Remove all xmlns:* attributes and any associated Office-specific markup:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<title>Office Export</title>

</head>

<body>

<p>Content from Word</p>

</body>

</html>

Incorrect: Single namespace on a non-html element

The error can also appear on other elements if a tool inserts namespace attributes:

<divxmlns:custom="http://example.com/ns">

<p>Some content</p>

</div>

Correct: Remove the namespace attribute

<div>

<p>Some content</p>

</div>

Using MathML natively in HTML5

If the xmlns:m attribute was added to support math content, note that HTML5 supports MathML directly without any namespace declaration:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<title>MathML in HTML5</title>

</head>

<body>

<p>The quadratic formula:</p>

<math>

<mi>x</mi>

<mo>=</mo>

<mfrac>

<mrow>

<mo>-</mo>

<mi>b</mi>

<mo>±</mo>

<msqrt>

<msup><mi>b</mi><mn>2</mn></msup>

<mo>-</mo>

<mn>4</mn><mi>a</mi><mi>c</mi>

</msqrt>

</mrow>

<mrow>

<mn>2</mn><mi>a</mi>

</mrow>

</mfrac>

</math>

</body>

</html>

No xmlns:m attribute is needed — the browser recognizes <math> as MathML automatically.

The src attribute on an <iframe> tells the browser which document to load and display within the embedded frame. When you leave this attribute empty (src=""), the W3C HTML Validator reports an error because the HTML specification requires the value to be a valid, non-empty URL. An empty string doesn't resolve to a meaningful resource.

This is more than a cosmetic validation issue. When a browser encounters src="", it typically interprets the empty string as a relative URL pointing to the current page, which causes the browser to re-fetch and embed the current document inside itself. This leads to unnecessary network requests, potential performance degradation, and unexpected rendering behavior. In some cases it can even cause infinite nesting loops or break page functionality.

From an accessibility standpoint, an empty <iframe> with no valid source provides no meaningful content to assistive technologies. Screen readers may announce the frame without being able to describe its purpose, creating a confusing experience for users.

How to fix it

• Provide a valid URL: Set the src attribute to the actual URL of the content you want to embed.
• Use about:blank for intentionally empty frames: If you need an <iframe> in the DOM but don't have content to load yet (e.g., you plan to populate it later via JavaScript), use src="about:blank". This is a valid URL that loads a blank page without triggering extra requests.
• Remove the element: If the <iframe> isn't needed, remove it from the markup entirely. You can dynamically create and insert it with JavaScript when you have content to load.
• Use srcdoc instead: If you want to embed inline HTML rather than loading an external URL, use the srcdoc attribute, which accepts an HTML string directly.

Examples

❌ Empty src attribute

<iframesrc=""></iframe>

This triggers the validation error because the src value is an empty string.

❌ src attribute with only whitespace

<iframesrc=""></iframe>

Whitespace-only values are also invalid URLs and will produce the same error.

✅ Valid URL in src

<iframesrc="https://example.com/map.html"title="Location map"></iframe>

A fully qualified URL is the most straightforward fix. Note the title attribute, which is recommended for accessibility so that assistive technologies can describe the frame's purpose.

✅ Using about:blank for a placeholder frame

<iframesrc="about:blank"title="Dynamic content area"></iframe>

This is a valid approach when you need the <iframe> in the DOM but plan to set its content later with JavaScript using contentDocument.write() or by updating the src attribute dynamically.

✅ Using srcdoc for inline content

<iframesrcdoc="<p>Hello, embedded world!</p>"title="Inline content"></iframe>

The srcdoc attribute lets you embed HTML directly without needing an external URL. When srcdoc is present, it takes priority over src.

✅ Dynamically creating the iframe with JavaScript

<divid="video-container"></div>

<script>

constiframe=document.createElement("iframe");

iframe.src="https://example.com/video.html";

iframe.title="Video player";

document.getElementById("video-container").appendChild(iframe);

</script>

If the source URL isn't available at page load, creating the <iframe> dynamically avoids having an empty src in your HTML altogether.

The background-blend-mode property controls how an element's background layers — including background images and background colors — blend with each other. Each value must be a valid blend mode keyword as defined in the CSS Compositing and Blending specification. The W3C validator flags this error when it encounters a value that doesn't match any recognized keyword, which can happen due to typos, made-up values, or confusion with similar properties like mix-blend-mode.

While browsers typically ignore unrecognized CSS values and fall back to the default (normal), relying on this behavior is risky. It means the blending effect you intended simply won't appear, and the silent failure can be hard to debug. Fixing validation errors ensures your styles work as intended across all browsers.

The complete list of valid values for background-blend-mode is:

• normal (default)
• multiply
• screen
• overlay
• darken
• lighten
• color-dodge
• color-burn
• hard-light
• soft-light
• difference
• exclusion
• hue
• saturation
• color
• luminosity

You can also specify multiple comma-separated values when an element has multiple background layers. Each value corresponds to a background layer in the same order.

Examples

Invalid values

These examples will trigger the validation error:

/* Typo: "multipley" is not a valid keyword */

.hero{

background-blend-mode: multipley;

}

/* "blend" is not a recognized value */

.banner{

background-blend-mode: blend;

}

/* Numeric values are not accepted */

.card{

background-blend-mode:50%;

}

Corrected values

/* Fixed: correct spelling */

.hero{

background-blend-mode: multiply;

}

/* Fixed: use a valid blend mode keyword */

.banner{

background-blend-mode: overlay;

}

/* Fixed: use a keyword instead of a numeric value */

.card{

background-blend-mode: soft-light;

}

Multiple background layers

When you have multiple background images, provide a comma-separated list of valid blend modes:

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Background Blend Mode Example</title>

<style>

.blended{

width:300px;

height:200px;

background-color: teal;

background-image:url("pattern.png"),url("photo.jpg");

background-blend-mode: screen, multiply;

}

</style>

</head>

<body>

<divclass="blended">Blended background layers</div>

</body>

</html>

In this example, screen applies to the first background image layer and multiply applies to the second. Both are valid keywords, so no validation error is produced.