You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I add a <meta name="viewport" content="viewport-fit=cover" /> tag to a custom _document.js (because I don't intend for that viewport value to ever change in my app), next/head still adds the default <meta name="viewport" content="width=device-width"> to my HTML and sends a warning to the console linking to an error message, which reads "Adding <meta name="viewport" ...> in pages/_document.js will lead to unexpected results since it cannot be deduped."
But that isn't true. Next.js could deduplicate these viewport meta tags, if next/head consulted a list of document/head children in its filtering process. All it rightly can't do is remove children from document/head, since _document.js is only rendered once, in the server. But nothing needs to be removed from document/head in this case—the tag that's causing the problem and needs to be removed is the default meta tag in next/head.
Expected Behavior
Next.js should pass a read-only list of document/head children to next/head's filter, and next/head should let document/head win all conflicts. And Next.js should then only warn users when they create <head> tag conflicts themselves. The process would look like this:
document/head adds any elements defined within it to the initial HTML, without concerning itself about defaults or anything. No warnings necessary.
The list of elements that document/head added gets passed to next/head's filter somehow.
next/head filters out all elements that conflict with document/head children.
If a conflict filtered out was part of defaultHead, that's good.
If a conflict filtered out was a manually defined next/head child, then generate a warning, because the user goofed by defining conflicting tags in multiple places themselves.
next/head injects the results into the page.
According to @lfades's definitions of _document.js and _app.js in #13408 (comment), _document.js is a better place for a static viewport meta tag than _app.js because it's "something that you know only needs to be added once and has to be always there". There's no reason to keep injecting it over and over with next/head if the developer knows what they want. The only situation that should generate a warning is if the developer put their own viewport meta tags in both document/head and in next/head, because then they've actually created a conflict.
This would make the purposes of document/head and next/head much clearer, turning it into
document/head is for things that should never ever ever change throughout your entire app.
next/head is for things that you might want to change sometimes.
This is in contrast to the current document/head policy, which is essentially "document/head is for things that should never ever ever change except for the things that could conflict with next/headif you do something wrong." See #9794, #13230, #13408, #26534, #27142, and #30068 for more expressions of confusion over the current document/head policy.
To Reproduce
Create a custom Document with a viewport meta tag like this:
This discussion was converted from issue #30745 on December 08, 2021 01:18.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
What version of Next.js are you using?
12.0.2-canary.14
What version of Node.js are you using?
14.8.1
What browser are you using?
Firefox 93.0 (64-bit)
What operating system are you using?
macOS 11.6 (20G165)
How are you deploying your application?
next devDescribe the Bug
When I add a
<meta name="viewport" content="viewport-fit=cover" />tag to a custom_document.js(because I don't intend for thatviewportvalue to ever change in my app),next/headstill adds the default<meta name="viewport" content="width=device-width">to my HTML and sends a warning to the console linking to an error message, which reads "Adding<meta name="viewport" ...>inpages/_document.jswill lead to unexpected results since it cannot be deduped."But that isn't true. Next.js could deduplicate these viewport
metatags, ifnext/headconsulted a list ofdocument/headchildren in its filtering process. All it rightly can't do is remove children fromdocument/head, since_document.jsis only rendered once, in the server. But nothing needs to be removed fromdocument/headin this case—the tag that's causing the problem and needs to be removed is the defaultmetatag innext/head.Expected Behavior
Next.js should pass a read-only list of
document/headchildren tonext/head's filter, andnext/headshould letdocument/headwin all conflicts. And Next.js should then only warn users when they create<head>tag conflicts themselves. The process would look like this:document/headadds any elements defined within it to the initial HTML, without concerning itself about defaults or anything. No warnings necessary.document/headadded gets passed tonext/head's filter somehow.next/headfilters out all elements that conflict withdocument/headchildren.defaultHead, that's good.next/headchild, then generate a warning, because the user goofed by defining conflicting tags in multiple places themselves.next/headinjects the results into the page.According to @lfades's definitions of
_document.jsand_app.jsin #13408 (comment),_document.jsis a better place for a static viewportmetatag than_app.jsbecause it's "something that you know only needs to be added once and has to be always there". There's no reason to keep injecting it over and over withnext/headif the developer knows what they want. The only situation that should generate a warning is if the developer put their own viewportmetatags in bothdocument/headand innext/head, because then they've actually created a conflict.This would make the purposes of
document/headandnext/headmuch clearer, turning it intodocument/headis for things that should never ever ever change throughout your entire app.next/headis for things that you might want to change sometimes.This is in contrast to the current
document/headpolicy, which is essentially "document/headis for things that should never ever ever change except for the things that could conflict withnext/headif you do something wrong." See #9794, #13230, #13408, #26534, #27142, and #30068 for more expressions of confusion over the currentdocument/headpolicy.To Reproduce
Create a custom
Documentwith a viewportmetatag like this:Or clone https://github.com/TyMick/nextjs-document-meta-tag. Then run
yarn dev, watch your terminal for the console warning, and use your browser's HTML inspector to see the conflicting viewportmetatags.Beta Was this translation helpful? Give feedback.
All reactions