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 article details the frustrating experiences of individuals named "Null," whose names cause software glitches due to its interpretation as a null value or lack of input. From online forms rejecting their names to databases corrupting their records, people named Null face constant challenges in a digitally-driven world. They've developed workarounds, like using middle names or initialized first names, but the underlying problem highlights the inflexibility of many systems and the lack of consideration for edge cases in software development. The article emphasizes the importance of comprehensive data validation and the need for developers to anticipate diverse and unusual names to avoid inadvertently excluding or inconveniencing real people.
HN commenters largely discuss their own experiences with problematic names and data entry systems. Several share anecdotes about names with apostrophes, spaces, or titles causing issues. Some point out the irony of the article's author having a relatively common surname (Null) while claiming digital invisibility. Others discuss the technical reasons behind such issues, mentioning database design, character encoding, and validation practices. A few commenters note that the problem isn't new and express frustration with the persistent nature of these bugs. One highly upvoted comment suggests that the real issue lies with programmers who fail to properly sanitize inputs, rather than with the names themselves. There's a brief discussion of legal names versus preferred names and the challenges this presents for systems.
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".