The underscore in target="_blank" is a relic of older HTML versions where custom target names were conventionally prefixed with an underscore to distinguish them from predefined targets like _top, _self, _parent, and _blank. While underscores are no longer technically required for custom target names in modern HTML, the convention persists, especially with _blank, due to its widespread historical use. Essentially, the underscore was originally a way to signal a developer-defined target, separating it from the reserved target names built into the HTML specification.
The blog post by Kyrylo Yermak elucidates the historical reasoning behind the presence of an underscore in the target="_blank" attribute used in HTML anchor tags. This attribute dictates that when a user clicks on a hyperlink, the linked resource should open in a new browsing context, typically a new tab or window. The underscore prefix, seemingly arbitrary at first glance, is a remnant of a naming convention established in the nascent days of HTML. Specifically, this convention harks back to the era of framesets, a now-obsolete HTML element used to divide a browser window into multiple frames, each displaying a distinct HTML document.
In the context of framesets, the target attribute would specify the name of the frame within which the linked content should load. These target names were often descriptive, employing alphanumeric characters and, significantly, the underscore character. For instance, a frameset might have frames named "content", "navigation", or "footer". These names served as identifiers for individual frames within the overall frameset structure.
The special keyword "_blank" emerged as a designation for opening the link in a new, unnamed browsing context, as opposed to a specific, pre-defined frame. To maintain consistency with the existing naming convention that allowed underscores in frame names, the underscore was incorporated into the "_blank" keyword. This ensured that "_blank" adhered to the same syntactical rules as other valid target names, even though it functioned differently by creating a new browsing context rather than targeting an existing frame.
Therefore, although framesets have largely fallen out of favor in modern web development, the underscore in target="_blank" persists as a legacy of this older practice. It serves as a historical artifact, reminding us of the evolution of HTML and the conventions that shaped its development. While functionally unnecessary in the current context, its presence ensures backward compatibility and avoids breaking legacy code that might still rely on older frame-based designs.
Summary of Comments ( 121 )
https://news.ycombinator.com/item?id=43127577
Hacker News users discussed the historical context of the underscore in
target="_blank", attributing it to the legacy of SGML and HTML's early evolution. Some pointed out that the underscore was used as an escape character for non-standard attributes, allowing developers to introduce custom attributes without breaking the existing parser. This was especially important during the transition from SGML to HTML, as browsers were still evolving. The underscore acted as a signal that this was an extension, potentially browser-specific, and not part of the official standard at the time. Others questioned the current necessity of the underscore and whether modern HTML specifications still require it, suggesting it's primarily a historical artifact. A few comments also touched upon the security implications oftarget="_blank"withoutrel="noopener", a common topic often paired with discussions about this attribute.The Hacker News post "Why does target=\"_blank\" have an underscore in front?" has generated several comments discussing the historical context and technical reasons behind the underscore in HTML's
target="_blank"attribute.Several commenters point out that the underscore prefix convention stems from older versions of HTML, specifically HTML 3.2, where it was used to signify special target names. These special names, like
_blank,_self,_parent, and_top, had predefined behaviors related to how links opened in different browser windows or frames. The underscore served as a visual cue to differentiate these reserved keywords from user-defined target names, which were permitted without the underscore.One commenter clarifies that the underscore is not strictly required in modern HTML, but its continued usage is largely due to convention and backwards compatibility. While you could technically use
target="blank"without the underscore, it's considered best practice to include it for consistency and to avoid potential conflicts with future HTML specifications.The discussion also delves into the security implications of
target="_blank", specifically the vulnerability related to thewindow.openerproperty. Commenters explain that when a link opens in a new tab or window usingtarget="_blank", the new window can access and potentially manipulate the original window throughwindow.opener. This can pose a security risk, as malicious websites could exploit this access to perform actions on the user's behalf on the originating page. The recommended solution to mitigate this risk, mentioned by multiple commenters, is to include therel="noopener"attribute alongsidetarget="_blank". This prevents the new window from accessing the original window viawindow.opener, effectively isolating the two and enhancing security.One commenter offers additional context regarding the
noopenerattribute, explaining that it not only enhances security but also improves performance. By severing the link between the opened window and the opener, the browser can optimize resource allocation and prevent potential performance bottlenecks.In summary, the comments on the Hacker News post provide a comprehensive overview of the historical reasons behind the underscore in
target="_blank", its optional nature in modern HTML, and the crucial security and performance implications associated with its usage, especially in conjunction withrel="noopener".