Skip to content

Conversation

RobertBoes
Copy link
Contributor

@RobertBoes RobertBoes commented Jul 15, 2025

Inertia now uses the inertia attribute on all the head elements. However, this is invalid HTML in many cases. For example the <title> element only allows for global attributes. These attributes consist of existing HTML attributes, not non-existing attributes. This means using data-* attributes is only allowed for the <title> element. Currently Inertia apps would thus fail HTML validation.

@RobertBoes
Copy link
Contributor Author

To be clear, this is probably a breaking change. If one has <title inertia>My title</title> in their backend template then Inertia wouldn't update that value on the frontend.

Not sure if Inertia is willing to introduce a breaking change there, or refactor the code to also account for the legacy use-case.

@HichemTab-tech
Copy link
Contributor

Can't we leave the attribute inertia for backward compatibility? With a warning or something that tells that it's recommended to use data-inertia from now on.

@RobertBoes
Copy link
Contributor Author

The problem is, leaving it as just inertia results in invalid HTML, as inertia is not an allowed attribute. So yeah, if a backwards-compatible way is wanted, then it would mean checking for both inertia, data-inertia and keeping that in sync with the keys that are being set on those attributes

@RobertBoes
Copy link
Contributor Author

To give a few examples:
https://validator.w3.org/nu/?doc=https%3A%2F%2Fcodecourse.com%2F
https://validator.w3.org/nu/?doc=https%3A%2F%2Fcfcasts.com%2F
Taken from https://builtwithinertia.com/.

Both sites use Inertia and have <title inertia> in their server-rendered HTML, among other tags. This results in errors like Error: Attribute inertia not allowed on element [meta] at this point. and Error: Attribute inertia not allowed on element [title] at this point.

@pascalbaljet
Copy link
Member

I think it's a good change to move to data-inertia and be compliant with the specs. I haven't looked into the code changes in detail, but could we support both? There's probably a very small chance people depend on the inertia attribute, but since we already have to change our own tests, I still think we should consider it a breaking change. It would be nice if existing apps keep working as-is, and that we update the starter kits to data-inertia for new projects.

@Ookma-Kyi
Copy link

I had trouble getting my app to pass HTML validation to comply with Section 508(a) and WCAG AAA accessibility guidelines. As far as breaking changes go, if a backwards-compatible solution is preferred, I wouldn't mind. To fix it, just add data- to the existing inertia attribute on the title tag. Let me know if I'm wrong.

@pascalbaljet
Copy link
Member

I've updated the PR so that it supports both the inertia and data-inertia attributes. It still defaults to inertia to avoid breaking changes, but now when you use data-inertia in your template, it'll use that.

@RobertBoes
Copy link
Contributor Author

It still defaults to inertia to avoid breaking changes, but now when you use data-inertia in your template, it'll use that.

My idea was it would default to using data-*, that way it would default to following the spec. Could be with a fallback to inertia, so when you use <title inertia></title> in your blade template it would pick that up properly. And whenever you're using just the <Head> element it would create those elements with data-inertia. Or is that the case now? Haven't looked thoroughly at the changes yet

@stausmar
Copy link

I'm facing the same issue, especially in combination with SEO tools such as e.g. ahrefs. Their site audits look specifically for <title></title> tags. If there's no <title> tag included, the page will always get a bad health score. Also, not sure, if the <title inertia> tags might have any negative effects on SEO.

I really hope this will be fixed / merged soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants