I can't find any discussion about the choice of character. My guess is that discussion was internal to Netscape as they shipped _then_ specced link target names.
There probably was no discussion about it. Back then you didn't have tens of managers looking to add their input to a project, so if you came up with something, you could just demo it, and unless someone had a very specific reason to reject it, nobody would.
I'm not saying this is the answer, but it very well could be that whoever wrote the function that handles this decided on an underscore and nobody ever even questioned it.
and really this should be the path: define a new convention, then standardized after - if it's needed (spoiler: probably not going to need it). This is definitely not perfect; it's incredibly painful to retrofit standards, but I'm not convinced it's less work than creating a bunch of standards no one needs.
Years ago I discovered that Yahoo Fantasy Football would open links to each player profile in its own window/tab, even if I clicked on the same player over and over. I dug in and found that they were using target="playername-idnum".
I've used it everywhere ever since when most people would just use _blank. If you're like me and ever go down and article, clicking all of the links to open in new tabs to look at later then you're welcome...I saved you a few wasted tabs when you clicked on the same link more than once.
I was expecting this post to explain why it's an underscore specifically, as opposed to a dollar sign, an asterisk, a caret, a tilde or some other special character.
I can only assume it's a holdover of languages like C where the standard library has some reserved names that start with an underscore.
As another borrowed convention, JS developers of yore (and likely some today still) used an _ prefix to denote “private” function/methods. Quotes as it’s just a convention - today JS supports # for actual private members in class syntax.
Another weird case: In Google's server-side JS environment Apps Script, function names that end with _ are treated as private functions that cannot be called directly by the user or enumerated.
I do it every day, so I see it from your perspective.
I'm willing to bet there are kids who do not though. Given how many crazy colours my IDE shows everything in, I could definitely believe there are people that go, 'Why bother, aren't those private members blue anyway?', or some such similar train of thought.
Of course if your IDE is little more than notepad, then such things are still important. For me, that's the Arduino IDE. I have to admit I really like writing micro controller code in it, it's a bit like writing code 30 years ago (both the good and bad parts).
Making it a dollar sign would cause countless bugs for people who generate HTML using templating languages whose variables are indicated by dollar sign. From time to time, someone would add target="$blank" to a templates, forgetting that the $ must be escaped to be literal.
They might have to resort to predefining a reserved variable called blank, whose value is "$blank". :)
Similar reasoning applies to most other special characters.
Given how HTML gets generated by preprocessors which use special characters in this manner or that, its best not to come up with new schemes within HTML itself involving special characters.
Carving out a reserved space within an existing namespace is safe.
The _ comes from the W3C in 1995 well before JavaScript was commonly used for templating HTML.
Scripting has used $ for variables for a long time: I think the most relevant history line for $variable is PHP comes from Perl comes from shell scripts. I also remember finding $ ugly on Vax.
There were a huge variety of templating syntaxes for server side and HTML generation was virtually all server side in the 1900s.
Server side languages were very rarely JavaScript before Node in 2009.
JavaScript wasn't used much for HTML generation before Ajax. There were soon after many many client side templating syntaxes.
I'm guessing only Brendan Eich could say why $ was accepted for JavaScript variable names.
Timelines are hard because the foundations were compressed within a decade: JavaScript 1995, PHP 1996, DHTML 1997, Ajax early 2000s, jQuery 2006.
Syntaxes tend to be extremely path dependent, and every developer cribs from everything they use.
So basically It’s an “_blank” because it is.. Author’s description is, “because if it wasn’t _blank.. it wouldn’t open a new tab.” Reminds me of some university professors I had.
When I built "webapps" in the 90s, they were a collection of frames. You could just do everything as one page, but there were some neat things you could do by dividing the page up into frames + internet connections were not very good so if you had something you needed to update a lot, it was easier to make it it's own .html and server it in an iframe.
Because you could "NameAFrameAnyThingYouWanTED" they made some magic targets, _blank window to open a blank window (we have tabs, then we did not), _self to open in the same frame or window, _parent to open in the parent frame, _top to break out of frames entirely (this is how you would bypass the ad some free .coms would inject into your site)
When I read the html spec in the 90s all it says was you can name a frame anything except don't use _ as _ is reserved for special frame types.
>(this is how you would bypass the ad some free .coms would inject into your site)
In anglefire and maybe geocities we would serve the document with a .txt extension and it would also skip the ads but browsers, with their liberal acceptance policy, would render normally.
Not quite. Any name would open a new window unless a frame with that name already exists. This includes the case of the name “blank”. In other words, the first time clicking on a link targeting a name would open a new frame (window) with that name, but the second time would load the content into the existing frame, replacing the previous content. In that scheme, there is no way to open an additional new frame each time. The reserved name “_blank” was then defined to have that semantics.
Maybe the article didn’t make it clear enough, but having special targets begin with an underscore has the purpose of avoiding name collisions with normal targets.
The primary thing the article does is explain that there are normal targets in the first place, which is probably the main aspect people might otherwise be missing.
It would open in a new tab (or specifically, window) if there was no object named "blank" for it to target. The problem with that is subsequent links with the target "blank" would use this same new window. Links with the target "_blank" would each open in individual windows
The general trend in search engine results seems to be optimising towards these superficial and unsatisfying answers too... and part of it is no doubt due to sites like this.
It is what it is because it's that. You can tell, you just have to look at how it is. If it's like that, then it is what it is. If it isn't what it is it would be something that it isn't but still be what it is. Luckily for us it's what it is, not what it isn't.
I was more thinking of javadoc, or other languages where people can automatically generate documentation from the code comments they wrote and 97 out of 100 comments is the function name written as a sentence ("reserveItem(): reserves an item")
For anyone who writes these, please just leave it blank and revisit it later
In other answer they link to the original specification [1], and it says that names must start with a letter, so anything preceded by "_" cannot be a frame name.
To me (and I’m of the era they’re describing so I used it a lot) it’s simply that _blank is a reserved keyword that means open the link in a new, unnamed window.
Other reserved keywords for “target” are _self (default value), _parent, and _top.
Also worth noting that "_new" is NOT a reserved keyword, but it is sometimes mistakenly used instead of "_blank". Which can lead to funny behavior if you are visiting 2 or more sites making this mistake, as the links could then start opening in windows that were initially opened by the other site. Or least that's how it was back in the days of popup windows, before tabs and popup blockers became the norm.
I'm guessing it was possible before the window-opening behaviour came in (unless it was always there from the genesis of frameset), but it was assumed that the underscore prefixed version would be less likely to conflict with existing code than without.
I'd be interested to hear either a citation proving or disproving that guess though.
Tangential, but I would really like frames to come back for incremental document updates, like LiveView/Hotwire/HTMX. You can just start working like that today with one of those libraries, but it would be so neat to have a common standard for describing an update to a targeted frame.
HTML has a bunch of good stuff in it that'd replace the need for so much heavy and slow and non-native-feeling javascript if that'd just been improved. Lots of it's now rarely used because it sucks, but there's no good reason it has to suck. It's like whole sections of the spec just got abandoned around 2005, but the need is still there.
The <blink> tag needs to make a comeback; I'm so tired of having to write my own JavaScript to get annoying flashy text.
In all seriousness, I'm not entirely sure why so many features in HTML are eschewed in favor of a slow JS mess. It doesn't feel like bolting on an entire relatively-slow programming language is going to make your code more organized than a relatively easy to use tag.
The main problem with frames is that you need to use JS to get it to be responsively sized. If they would fix that, frames would be perfect. They actually do what people just think Web Components do. I.E. they are actually isolated from the styles of the host page and have an actual security boundary preventing malicious execution.
I consider frames to be an example of MFE, actually. I believe I remember reading that Spotify (long ago) used frames in their app so each team could be self-contained.
Edit: In fact, I'm pretty sure Geers' book associated with that site says as much.
The targeting for updates. Something like hotwire/turbo frames allows you to push a form's response to any turbo-frame. You can also push updates to multiple frames at once. They're matched by frame ID, much like target="", but in the case of iframes, the iframe is the only thing that can update the interior HTML. (other than just changing the URL from the parent application)
iframes are also in a rather locked-down security model, even if they exist on the same domain. (Requires message passing, strict CORS rules, strict cookies rules etc)
Why did we move away from this model of web development? If I remember back that far, it seems like fairly soon after this was when the meta starting telling us that frames were bad, and using <table> was bad, etc.
It all honestly seemed a lot easier than what has come after.
The direct answer to your question is that the idea of "responsive" web design gradually took over when smartphones became popular. People liked the idea of not needing to create a separate mobile version of their frontend, and instead simply adjusting the styling and structure of the page in response to the size of the viewport. Tables were bad at this because you couldn't use CSS to arbitrarily move around the way a table is structured.
(The funny thing is that, in modern browsers this is no longer true - you actually can use CSS to restructure table layouts now. But, the world has already moved on.)
Though there's a broader answer, which is that generally as web design has modernized, so too have ideas of "semantic" markup. Semantically, table is supposed to be used to display data. HTML which is used for its proper semantic purpose is easier for screen readers, improving accessibility, and easier for search crawlers to make sense of the content, improving SEO. So a lot of old HTML tricks fell out of use when HTML5 started becoming popular.
> The direct answer to your question is that the idea of "responsive" web design gradually took over when smartphones became popular. People liked the idea of not needing to create a separate mobile version of their frontend, and instead simply adjusting the styling and structure of the page in response to the size of the viewport.
Table-based layout was already falling out of favour before this happened. Even when you had fixed sites that were predominantly desktop, divs and spans (coupled with CSS) made life a lot easier to put things where you wanted them and lay out a site faster. It was also cleaner when reading the markup.
From what I remember, the move away from tables happened around the same time external CSS took off and you could partition your site with reusable styling instead of framesets or tables.
Responsive design then sped up the process a few years later.
I have to use, still, a set of documentation that is formatted using an old-style two-frame layout—contents/search on the left, article on the right. It sucks, because unless I’m willing to lose the left frame, I can’t open articles in new tabs, I can’t bookmark them, I can’t copy their addresses. The back button kind of works, but the menu items are useless (they all contain the title of the frameset). And so on.
The layouts people were trying to create with frames weren’t bad, but browser behaviour around framesets isn’t good. I didn’t really have a good enough Internet connection at the time, but looking at them now I do agree that frames break linking too hard and shouldn’t be used.
We moved away from it because frames are quite limited in what UI's they can express. I don't know that it's true that what we have now is much more complicated, because it's pretty simple to build a multi-pane layout with CSS grid or flexbox.
I think frames are an artifact of the time when people thought of HTML as a desktop publishing markup language. It has evolved into a generalized UI description language.
It wasn't easier, but it was simpler. Fewer moving parts.
The reason we moved away from it was that after a point, the amount of legwork to implement relatively simple behaviours became astronomical. Whether or not the current state of matters is "better", who's to say. But things are certainly much easier now.
Besides, you still can use those old modes if you want to :)
> developers needed a way to explicitly tell the browser to open the link in a new tab, free of frame semantics
First, it doesn't say why an underscore does that, because you could totally have underscores in frame names. My guess as others here is that the underscore prefix dates back from reserved names in C and C++. IIRC the reserved names also included "_self" (even if it was the default), "_parent" (to go up a level in the frame hierarchy) and "_top" to replace the whole page.
Second, at the time it was clearly not "open the link in a new tab" but rather in a "new window". IE was the most used browser back then, by a large proportion, and it didn't supports tabs at all.
I distinctly remember IE 5.x and 6.x on Windows and Mac OS with no tab support while Mozilla then Firefox (which had a much smaller users base) had them, at a period where HTML frames were still big.
> because you could totally have underscores in frame names.
Technically, the underscore was restricted and should not be used for user defined targets/frame names. This isn't something any browser I know of ever enforced.
Probably the most likely explanation, given so many things do inherit idiosyncrasies from C. I'd always assumed it was from Perl, given its heavy use in CGI back then -- like $_ being the default var. But that would probably also eventually inherit from C :P
Minor nitpick: browsers used _blank as a special directive to open the link in a new “window”, not a tab. Browsers didn’t have tabs back then, well other than Opera 4.x which was a paid software which never cracked 3% marketshare.
Readit News
- 1995 Sept https://web.archive.org/web/19990202141025/http://home.mcom.... Netscape Navigator 2.0a2 release notes including rollout of TARGET.
- 1995 Sept https://lists.w3.org/Archives/Public/www-html/1995Sep/0034.h... First definition of them; spec text provided by "the Netscape Navigator marketing guy".
- 1997 Jan https://www.w3.org/TR/2018/SPSD-html32-20180315/ HTML 3.2 published without frame target names specced.
- 1997 Aug https://lists.w3.org/Archives/Public/www-html/1997Aug/0010.h... Roles of these target names clarified
- 1997 Dec https://www.w3.org/TR/html401/types.html#h-6.16 HTML 4.0 published with target names.
I can't find any discussion about the choice of character. My guess is that discussion was internal to Netscape as they shipped _then_ specced link target names.
I'm not saying this is the answer, but it very well could be that whoever wrote the function that handles this decided on an underscore and nobody ever even questioned it.
I've used it everywhere ever since when most people would just use _blank. If you're like me and ever go down and article, clicking all of the links to open in new tabs to look at later then you're welcome...I saved you a few wasted tabs when you clicked on the same link more than once.
I can only assume it's a holdover of languages like C where the standard library has some reserved names that start with an underscore.
https://devblogs.microsoft.com/oldnewthing/20230109-00/?p=10...
1. https://developers.google.com/apps-script/guides/html/commun...
Deleted Comment
I'm willing to bet there are kids who do not though. Given how many crazy colours my IDE shows everything in, I could definitely believe there are people that go, 'Why bother, aren't those private members blue anyway?', or some such similar train of thought.
Of course if your IDE is little more than notepad, then such things are still important. For me, that's the Arduino IDE. I have to admit I really like writing micro controller code in it, it's a bit like writing code 30 years ago (both the good and bad parts).
They might have to resort to predefining a reserved variable called blank, whose value is "$blank". :)
Similar reasoning applies to most other special characters.
Given how HTML gets generated by preprocessors which use special characters in this manner or that, its best not to come up with new schemes within HTML itself involving special characters.
Carving out a reserved space within an existing namespace is safe.
The _ comes from the W3C in 1995 well before JavaScript was commonly used for templating HTML.
Scripting has used $ for variables for a long time: I think the most relevant history line for $variable is PHP comes from Perl comes from shell scripts. I also remember finding $ ugly on Vax.
There were a huge variety of templating syntaxes for server side and HTML generation was virtually all server side in the 1900s.
Server side languages were very rarely JavaScript before Node in 2009.
JavaScript wasn't used much for HTML generation before Ajax. There were soon after many many client side templating syntaxes.
I'm guessing only Brendan Eich could say why $ was accepted for JavaScript variable names.
Timelines are hard because the foundations were compressed within a decade: JavaScript 1995, PHP 1996, DHTML 1997, Ajax early 2000s, jQuery 2006.
Syntaxes tend to be extremely path dependent, and every developer cribs from everything they use.
Deleted Comment
Deleted Comment
Because you could "NameAFrameAnyThingYouWanTED" they made some magic targets, _blank window to open a blank window (we have tabs, then we did not), _self to open in the same frame or window, _parent to open in the parent frame, _top to break out of frames entirely (this is how you would bypass the ad some free .coms would inject into your site)
When I read the html spec in the 90s all it says was you can name a frame anything except don't use _ as _ is reserved for special frame types.
In anglefire and maybe geocities we would serve the document with a .txt extension and it would also skip the ads but browsers, with their liberal acceptance policy, would render normally.
> The (reserved) name “_blank” was then defined to have that semantic.
I guess I was hoping for some interesting quirk with older browsers or something.
The primary thing the article does is explain that there are normal targets in the first place, which is probably the main aspect people might otherwise be missing.
For anyone who writes these, please just leave it blank and revisit it later
[1] https://www.w3.org/TR/WD-frames-970331#frame
To me (and I’m of the era they’re describing so I used it a lot) it’s simply that _blank is a reserved keyword that means open the link in a new, unnamed window.
Other reserved keywords for “target” are _self (default value), _parent, and _top.
https://www.w3schools.com/TAgs/att_a_target.asp
I'd be interested to hear either a citation proving or disproving that guess though.
In all seriousness, I'm not entirely sure why so many features in HTML are eschewed in favor of a slow JS mess. It doesn't feel like bolting on an entire relatively-slow programming language is going to make your code more organized than a relatively easy to use tag.
Edit: In fact, I'm pretty sure Geers' book associated with that site says as much.
iframes are also in a rather locked-down security model, even if they exist on the same domain. (Requires message passing, strict CORS rules, strict cookies rules etc)
https://github.com/alexpetros/triptych
It all honestly seemed a lot easier than what has come after.
(The funny thing is that, in modern browsers this is no longer true - you actually can use CSS to restructure table layouts now. But, the world has already moved on.)
Though there's a broader answer, which is that generally as web design has modernized, so too have ideas of "semantic" markup. Semantically, table is supposed to be used to display data. HTML which is used for its proper semantic purpose is easier for screen readers, improving accessibility, and easier for search crawlers to make sense of the content, improving SEO. So a lot of old HTML tricks fell out of use when HTML5 started becoming popular.
Table-based layout was already falling out of favour before this happened. Even when you had fixed sites that were predominantly desktop, divs and spans (coupled with CSS) made life a lot easier to put things where you wanted them and lay out a site faster. It was also cleaner when reading the markup.
From what I remember, the move away from tables happened around the same time external CSS took off and you could partition your site with reusable styling instead of framesets or tables.
Responsive design then sped up the process a few years later.
Deleted Comment
The layouts people were trying to create with frames weren’t bad, but browser behaviour around framesets isn’t good. I didn’t really have a good enough Internet connection at the time, but looking at them now I do agree that frames break linking too hard and shouldn’t be used.
I think frames are an artifact of the time when people thought of HTML as a desktop publishing markup language. It has evolved into a generalized UI description language.
Ironically people moved to divs and spans, which when combined with the old box model issues, made the problem even worse.
The semantic web elements in HTML5 was an attempt to fix those issues.
The reason we moved away from it was that after a point, the amount of legwork to implement relatively simple behaviours became astronomical. Whether or not the current state of matters is "better", who's to say. But things are certainly much easier now.
Besides, you still can use those old modes if you want to :)
First, it doesn't say why an underscore does that, because you could totally have underscores in frame names. My guess as others here is that the underscore prefix dates back from reserved names in C and C++. IIRC the reserved names also included "_self" (even if it was the default), "_parent" (to go up a level in the frame hierarchy) and "_top" to replace the whole page.
Second, at the time it was clearly not "open the link in a new tab" but rather in a "new window". IE was the most used browser back then, by a large proportion, and it didn't supports tabs at all.
Internet Explorer barely even existed back then, it certainly wasn’t the most used browser. That came later. No browser had tabs back in those days.
Technically, the underscore was restricted and should not be used for user defined targets/frame names. This isn't something any browser I know of ever enforced.
https://www.w3.org/TR/REC-html40/types.html#h-6.16
https://www.w3.org/TR/html401/present/frames.html#h-16.3