HTML Guides for serializable

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

<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:serif="http://www.serif.com/"
  viewBox="0 0 100 100"
  width="100"
  height="100">
  <g serif:id="Layer 1">
    <circle cx="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

<svg xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 100 100"
  width="100"
  height="100">
  <g>
    <circle cx="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 -->

<svg xmlns="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">
  <rect x="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 -->

<svg xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 200 200">
  <rect x="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.

When the W3C HTML Validator reports that an attribute is “not serializable as XML 1.0,” it means the attribute name contains characters that fall outside the allowed range defined by the XML 1.0 specification. HTML5 documents can be serialized as either HTML or XML (XHTML), and the validator checks that your markup is compatible with both serialization formats. Attribute names in XML 1.0 must start with a letter or underscore and can only contain letters, digits, hyphens, underscores, periods, and certain Unicode characters — they cannot include characters like {, }, @, $, or other symbols commonly found in templating languages.

This issue most frequently appears when a server-side or client-side templating engine (such as Mustache, Handlebars, Angular, Jinja2, or Blade) fails to fully process its expressions before the HTML reaches the browser. Instead of the template placeholder being replaced with a proper value, the raw template syntax ends up in the HTML as a malformed attribute. For example, {{class}} might appear as an attribute name rather than being resolved to its intended value.

Why this matters

• Standards compliance: HTML that isn’t serializable as XML 1.0 cannot be reliably converted to XHTML, which limits interoperability.
• Browser inconsistency: Browsers may handle invalid attribute names unpredictably, potentially ignoring the attribute entirely or misinterpreting surrounding markup.
• Accessibility: Malformed attributes can break ARIA attributes or other accessibility-related markup, making content inaccessible to assistive technologies.
• Tooling and parsing: XML-based tools, RSS feeds, and content syndication systems that consume your HTML will choke on attributes that violate XML naming rules.

How to fix it

1. Check for unresolved template expressions. Inspect the rendered HTML (not your source templates) for leftover placeholders like {{...}}, <%= ... %>, @{...}, or similar patterns.
2. Ensure proper server-side rendering. Make sure your templating engine is correctly processing all expressions before the HTML is sent to the client.
3. Remove invalid characters from attribute names. If you’re using custom attributes, stick to valid data-* attributes with names consisting only of lowercase letters, digits, and hyphens (after the data- prefix).
4. Check for typos. A missing = sign, quote, or space can cause a value to be interpreted as an attribute name.

Examples

Unresolved template placeholder in an attribute

This occurs when a template expression isn’t processed and appears literally in the output:

<!-- ❌ Bad: template syntax rendered as attribute name -->

<div {{classBinding}} id="main">
  <p>Hello, world!</p>
</div>

The fix is to ensure the template engine resolves the expression. The rendered output should look like this:

<!-- ✅ Good: attribute properly resolved -->

<div class="container" id="main">
  <p>Hello, world!</p>
</div>

Typo causing a value to be parsed as an attribute name

A missing equals sign or quotation mark can cause part of a value to become an attribute name with invalid characters:

<!-- ❌ Bad: missing = sign causes "bold}" to be treated as an attribute -->

<p style"font-weight:bold}" class="intro">Welcome</p>

<!-- ✅ Good: proper attribute syntax -->

<p style="font-weight:bold" class="intro">Welcome</p>

Special characters in custom attribute names

Using invalid characters directly in attribute names will trigger this error:

<!-- ❌ Bad: @ and $ are not valid in attribute names -->

<input @change="update" $value="test">

If you need custom attributes, use the standard data-* pattern:

<!-- ✅ Good: valid data attributes -->

<input data-change="update" data-value="test">

Angular-style bindings in static HTML

Frameworks like Angular use special attribute syntax (e.g., [property] or (event)) that is only valid within the framework’s context and will fail validation if rendered directly:

<!-- ❌ Bad: framework-specific syntax in raw HTML -->

<img [src]="imageUrl" (load)="onLoad()">

If you’re generating static HTML, use standard attributes instead:

<!-- ✅ Good: standard HTML attribute -->

<img src="photo.jpg" alt="A photo">