What is the issue with the HTML Standard?
The processing of http-equiv meta tags is currently done in the insertion steps (see this usage and this usage), meaning it happens synchronously upon insertion, before the post-insertion steps (which all browsers seem to have some form of) run.
But implementations don't seem to do this. See this test: https://wpt.fyi/results/dom/nodes/insertion-removing-steps/Node-appendChild-script-and-default-style-meta-from-fragment.tentative.html?label=experimental&label=master&aligned. All browsers currently fail it (except for Edge, mysteriously), because Blink, WebKit, and Gecko (though I can't find the exact source code for this) all process http-equiv in the post-insertion steps.
Once whatwg/dom#1261 lands (🤞), we should update the spec to use the post-insertion steps for this kind of meta tag, to match implementations. In the meantime, I will update the test expectations.
There's an open question about what we should do with name/content meta elements. Both Chromium and WebKit also process these kinds of meta tags in the post-insertion steps, so I suppose we should update the following instances:
... to use the post-insertion steps too, to at least match 2/3 browser implementations. See https://wpt.fyi/results/dom/nodes/insertion-removing-steps/Node-append-meta-referrer-and-script-from-fragment.tentative.html?label=experimental&label=master&aligned. Given this, Gecko would be the odd one out and we'd file a bug against Gecko to start processing these kinds of meta elements in the post-insertion steps.
If anyone disagrees with this analysis and my recommendations above, let me know! I'll prepare spec PRs once the post-insertion steps primitive is a thing.
What is the issue with the HTML Standard?
The processing of
http-equivmeta tags is currently done in the insertion steps (see this usage and this usage), meaning it happens synchronously upon insertion, before the post-insertion steps (which all browsers seem to have some form of) run.But implementations don't seem to do this. See this test: https://wpt.fyi/results/dom/nodes/insertion-removing-steps/Node-appendChild-script-and-default-style-meta-from-fragment.tentative.html?label=experimental&label=master&aligned. All browsers currently fail it (except for Edge, mysteriously), because Blink, WebKit, and Gecko (though I can't find the exact source code for this) all process
http-equivin the post-insertion steps.Once whatwg/dom#1261 lands (🤞), we should update the spec to use the post-insertion steps for this kind of meta tag, to match implementations. In the meantime, I will update the test expectations.
There's an open question about what we should do with
name/contentmeta elements. Both Chromium and WebKit also process these kinds of meta tags in the post-insertion steps, so I suppose we should update the following instances:... to use the post-insertion steps too, to at least match 2/3 browser implementations. See https://wpt.fyi/results/dom/nodes/insertion-removing-steps/Node-append-meta-referrer-and-script-from-fragment.tentative.html?label=experimental&label=master&aligned. Given this, Gecko would be the odd one out and we'd file a bug against Gecko to start processing these kinds of meta elements in the post-insertion steps.
If anyone disagrees with this analysis and my recommendations above, let me know! I'll prepare spec PRs once the post-insertion steps primitive is a thing.