Add `<meta name="responsive-embedded-sizing">` by kojiishi · Pull Request #12444 · whatwg/html

kojiishi · 2026-05-13T08:54:08Z

This adds <meta name="responsive-embedded-sizing"> as an immutable standardized name.

This is used by the CSS responsive embedded sizing flag.

At least two implementers are interested (and none opposed):
- Chromium: https://chromestatus.com/feature/5108373464547328
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/css/css-sizing/responsive-iframe?label=master&label=experimental&aligned
Implementation bugs are filed:
- Chromium: https://crbug.com/418397278
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2039202
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=314714
Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
MDN issue is filed: In Chromium Documentation Tracker https://issuetracker.google.com/issues/511947520
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/dom.html ( diff )
/semantics.html ( diff )

kojiishi · 2026-05-13T09:37:20Z

@chrishtr @bfgeek @annevk @zcorpan

mtrootyy · 2026-05-13T17:07:14Z

If either name, http-equiv, or itemprop is specified in meta element, then the content attribute must also be specified.
If "responsive-embedded-sizing" is specified to value of name attribute of mata element, what is specfied to value of content attribute of this meta element?

miketaylr · 2026-05-18T01:38:56Z

https://html.spec.whatwg.org/#the-meta-element

If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified. Otherwise, it must be omitted.

But just below:

If a meta element has a name attribute, it sets document metadata.... If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

So meta with name and without content is allowed (but, imho it's a bit confusing for HTML to use must in "this must be specified, otherwise it must not be specified" instead of may?)

mtrootyy · 2026-05-18T09:26:19Z

If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

The above specifications are for user agents, not for authors.
Regardless of how the user agent processes it, author must comply with the following specifications.

If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified.

annevk · 2026-05-18T10:53:56Z

+    the user agent must run the following algorithm:</p>
+
+    <ol>
+     <li><p>If <var>element</var> is not inserted by the parser, then return.</p></li>


This doesn't seem like a good idea. This will just encourage people to use document.write() instead of tree manipulation.

Suggesting an alternative where once the body element is seen this cannot be modified.

That's also not a primitive that exists?

It is, eg for render blocking.

A similar approach is to cement it at the beginning of the first render

@noamr

This is different, I mean that you can't apply it once the body is seen, even if it's inserted to the head

Can you expand a bit more? It looks to me that if it's valid only in <head>, and only by the parser, then you can't insert to the head once the body is seen, so we're talking about the same thing. Did I miss anything?

For b and c, The best way to spec this I think is to have this as a tri state of sorts (true, false, uninitialized) and set it to false on some conditions (eg body insertion). Not sure if parser-inserted is that important given the other conditions or what the best way to spec it given document.write().

I was worried "hey, it's alredy defined there, use existing definition" feedback, so I'm fine with your suggestion if that is preferred.

Two questions before I update this PR. I couldn't read whether you and @annevk want to allow tree manipulation or not, and whether to allow document.write(), when the script is in <head>. Could you clarify which you want?

@annevk previously requested this to be immutable, so I'm trying to respond to the request. My understanding of the "immutable" is not allowing tree manipulation nor document.write() even in <head>, but I'm happy to be corrected if that was wrong.

Three questions actually, sorry. Custom elements could inject a <meta> element asynchronously. Do we want to allow that?

@noamr

This is different, I mean that you can't apply it once the body is seen, even if it's inserted to the head

Can you expand a bit more? It looks to me that if it's valid only in <head>, and only by the parser, then you can't insert to the head once the body is seen, so we're talking about the same thing. Did I miss anything?

It's almost the same but not exactly. What I am suggesting still allows inserting it dynamically in a parser blocking script included in the head. It's a more established concept than "only by the parser" and I think it might do in terms of security etc. it's equivalent behavior to the blocking attribute - which can make some sense given that they both impact rendering behavior.

For b and c, The best way to spec this I think is to have this as a tri state of sorts (true, false, uninitialized) and set it to false on some conditions (eg body insertion). Not sure if parser-inserted is that important given the other conditions or what the best way to spec it given document.write().

I was worried "hey, it's alredy defined there, use existing definition" feedback, so I'm fine with your suggestion if that is preferred.

Two questions before I update this PR. I couldn't read whether you and @annevk want to allow tree manipulation or not, and whether to allow document.write(), when the script is in <head>. Could you clarify which you want?

@annevk previously requested this to be immutable, so I'm trying to respond to the request. My understanding of the "immutable" is not allowing tree manipulation nor document.write() even in <head>, but I'm happy to be corrected if that was wrong.

Thanks a lot for the clarification @noamr. So you want to allow tree manipulations, document.write(), and async custom elements injections, as long as they're done before <body> starts. /cc @tabatkins @bfgeek

@annevk can you confirm if you agree this achieves "immutable"?

Thanks a lot for the clarification @noamr. So you want to allow tree manipulations, document.write(), and async custom elements injections, as long as they're done before <body> starts. /cc @tabatkins @bfgeek

Yes but only for the first time (when uninitialized)
So you can document.write or append the meta, but only if it wasn't already there and only if the body didn't start yet.

kojiishi · 2026-05-25T07:20:07Z

@annevk can you help whether the content attribute is required or not? It looks to me that omitting is allowed from what @miketaylr quoted, but I'm not sure.

@mtrootyy wrote:

If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

The above specifications are for user agents, not for authors. Regardless of how the user agent processes it, author must comply with the following specifications.

If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified.

noamr · 2026-05-28T16:55:17Z

+  <p>Each <code>Document</code> has a boolean
+  <dfn data-x="concept-document-responsive-embedded-sizing">responsive embedded sizing</dfn>,
+  initially false.</p>
+


@kojiishi this is what I mean by "move things around"
The note below this ("as the name indicates") relates to the paragraph about "navigation ID or webdriver Bidi", and the new paragraph splits them in the middle.

I got it, thanks for the explanation and thanks for catching this. Done.

This adds `<meta name="responsive-embedded-sizing">` as an immutable standardized name. This is used by the CSS [responsive embedded sizing flag]. [responsive embedded sizing flag]: https://drafts.csswg.org/css-sizing-4/#document-responsive-embedded-sizing-flag

noamr

(Unofficial as I'm not an approver and we need multi implementer support)
I think this PR does the right thing in a way that's concise and consistent enough.
Editorially I can't say about maintaining the outdated wording style of existing meta tag or moving forward.

noamr · 2026-05-28T19:01:42Z

+    <div algorithm>
+    <p>If a <code>meta</code> element is
+    <span data-x="node is inserted into a document">inserted into the document</span>,
+    the user agent must run the following algorithm:</p>


I think this wording style is outdated but will leave to @annevk whether this needs to be consistent with what's around it or with new style.

kojiishi force-pushed the responsive-embedded-sizing branch from 4f63023 to 5d63e86 Compare May 13, 2026 09:09

kojiishi mentioned this pull request May 13, 2026

Responsively-sized iframes mozilla/standards-positions#1394

Open

annevk reviewed May 18, 2026

View reviewed changes

kojiishi force-pushed the responsive-embedded-sizing branch from 5d63e86 to ad98ae3 Compare May 28, 2026 08:51

noamr reviewed May 28, 2026

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch from ad98ae3 to 49c5445 Compare May 28, 2026 16:22

noamr reviewed May 28, 2026

View reviewed changes

kojiishi force-pushed the responsive-embedded-sizing branch from 49c5445 to fe4fc74 Compare May 28, 2026 16:56

kojiishi force-pushed the responsive-embedded-sizing branch from fe4fc74 to 615fb1c Compare May 28, 2026 17:34

noamr approved these changes May 28, 2026

View reviewed changes

Conversation

kojiishi commented May 13, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kojiishi commented May 13, 2026

Uh oh!

mtrootyy commented May 13, 2026

Uh oh!

miketaylr commented May 18, 2026

Uh oh!

mtrootyy commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kojiishi commented May 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

noamr left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

kojiishi commented May 13, 2026 •

edited by pr-preview Bot

Loading

mtrootyy commented May 18, 2026 •

edited

Loading

noamr left a comment •

edited

Loading