Why does target="_blank" have an underscore in front? (2024)
202 comments
·February 21, 2025paulirish
thesuitonym
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.
janalsncm
There was a recent post about asking for “no”, in other words defaulting to yes unless there’s an objection before a deadline. I like that model.
smallnix
I am making extensive use of deadlined passive approval for decision I consider non-contentious. For everything else I set up meetings. I don't believe in async review of contentious decisions.
dowager_dan99
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.
IgorPartola
Please don’t. In theory this works for some things. But when you have multiple implementations of the browser doing different things given the same code it is a nightmare. A solid well defined spec is necessary in that case.
brightball
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.
ldjb
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.
https://devblogs.microsoft.com/oldnewthing/20230109-00/?p=10...
lelandfe
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.
zeroq
This is a direct descendant of ActionScript. It introduced the convention of Instance._getter and Instance.__private.
magicalist
That looks like ActionScript 2, so the javascript convention was actually well in place by then. I can't speak confidently about the late 90s, but I wouldn't be surprised if it predated Actionscript 1 as well.
But doesn't it all trace back to C conventions anyways?
DidYaWipe
What about Lingo?
xd1936
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.
1. https://developers.google.com/apps-script/guides/html/commun...
BurningFrog
In the Python world I was in, trailing underscores is used to work around the ban on reserved words. The language grabs some of the best names for itself!
So a variable that really ought to be named `class` you name `class_`.
null
phist_mcgee
I use underscore to prevent shadowing of variables names. Not sure where I picked up that habit though.
lelandfe
I've seen that before.
A related conventional use of underscores in JS variable names is when "discarding" values in positional settings, like destructuring arrays.
E.g. `const [_, a, b] = triple`
In general, underscores in JS seem to be used to help call out what to ignore or what is less important.
layer8
I wouldn’t say it’s a “holdover”, it continues to be a common convention for marking internal or reserved use.
paradox460
Some modern languages even turn _ flagged variables/parameters into black holes
anoldperson
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).
kazinator
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.
robocat
Your reason is unlikely to be a cause.
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.
kazinator
Shell script here documents can generate HTML:
cat <<!
<div>
...
<a href="$url" target="_blank" ...
...
!
null
null
bilekas
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.
neom
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.
sokols
This is exactly what I understood from the article. Your explanation didn't add anything extra.
lazide
I actually used the 1.0 version of Netscape Navigator, and did some web development on it back in the day.
Originally, _blank, _new, etc. weren’t special. A target ref to a name which wasn’t used would open a new window. If it was already used, it would take you to that open window.
People started using _whatever because just ‘blank’ would almost always cause a collision. Eventually it got standardized that it would always open a new blank window.
pests
>(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.
layer8
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.
bilekas
So again as I understand, it's simply because a standard was decided ?
> 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.
layer8
It was to avoid the situation of someone naming a frame “blank” without being aware of it having special semantics, or (I’m not completely clear on the history) avoiding breaking compatibility with existing use. That’s much more unlikely with a name like “_blank”. It’s common practice to separate out names with special semantics from general-use names in a syntactic way like that. There’s also “_self”, “_parent”, and “_top”. It’s an extensible scheme where HTML can add further names with special semantics in that reserved name space.
I now agree that the article doesn’t make a particularly good job in explaining all of this.
layer8
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.
mixmastamyk
Yes, whenever you see such a convention it’s about expanding the namespace. i.e. avoiding the main namespace.
mikeyinternews
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
userbinator
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.
reverendsteveii
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.
systems_glitch
"I dunno...is magic" (engineering Calculus II GTA, Virginia Tech, 2006)
rendaw
And a lot of SO answers.
Aachen
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
mdaniel
My experience with this is it is almost always caused by some heavy-handed linter rule, e.g. "fail CI if methods don't have javadoc". Most of those "dumb" linters also almost never catch when a parameter has been renamed but its "@param" was left intact. Drives me crazy.
russfink
I second your motion.
n_plus_1_acc
The answer is a little unsatisfying to me. It says that "blank" ca be a frame name, but doesn't say why "_blank" can't be.
Maken
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.
stickfigure
This one sentence is better than the original article.
hbn
That sentence wouldn't have made sense to me before I read the original article.
I got into web dev after HTML5, I've never heard of <frameset>
n_plus_1_acc
Thanks
tomhoward
Yeah it’s not a great explanation.
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.
0x0
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.
shkkmo
Not just weird behavior, but possible security issues. Browsers now automatically add a rel="noopener" to links that target _blank to prevent the opened site from gaining full access to your javascript object. Targeting _new does not do this unless you explicity add the rel="noopener" yourself.
https://github.com/whatwg/html/issues/4078 https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
stickynotememo
But why was _name the naming syntax for reserved keywords, specifically?
beejiu
I suspect, when the specification was created, "_" was already popular for private/reserved members in many programming languages. In C++, for instance, you can only start an identifier with a letter or an underscore. So it seems like a natural, intuitive choice. Whether anyone can find any corroborating evidence would be interesting.
Sharlin
Probably inspired by C and C++ which reserve names starting with an underscore for the implementation (more precisely, they reserve names starting with `_[_A-Z]` everywhere, and all other names starting with `_` in the global scope only).
ramesh31
>But why was _name the naming syntax for reserved keywords, specifically?
As with so many things in software engineering, the answer comes down to "some programmer in the 70s working on a UNIX system had to make an arbitrary decision about something, and no one ever had a good reason to change it again."
lazide
Most other characters you would use aren’t valid HTML, and originally you could say things like target=foo (no quotes) and it would work.
dcminter
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.
bazoom42
Frame names must start with an alphanumerical character.
graypegg
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.
alabastervlog
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.
tombert
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.
alabastervlog
We could have datasource-backed tables and list elements. Built-in. Sorting for most purposes, "for free", and more with simple and light JS hooks for sort functions. Frames that actually work as useful UI elements. "Basic auth" screens that look and function well enough for lots of purposes. Something like "Apple Pay" or other external payment systems but built into the browser, replacing stupid amounts of time spent writing yet another payment form (and usually fucking it up in several ways)
But no.
lelandfe
> I'm so tired of having to write my own JavaScript to get annoying flashy text
Fret no more:
<style>
.blink { animation: blink 1s steps(2, start) infinite; }
@keyframes blink { 50% { visibility: hidden; } }
</style>
<p class="blink">Lorem ipsum</p>
earthboundkid
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.
snarkyturtle
Isn't that the use-case for Micro Frontend Architecture? I've always viewed it as a second-coming of Frames. https://micro-frontends.org/
lelandfe
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.
evantbyrne
I'm just happy we can find DOM elements by CSS selectors now. Full browser support for calc was almost too much excitement for me
jodydonetti
What are you missing by using iframes (still standard, supported, working) + css for layouting that old school frames would give you?
graypegg
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)
jonathanhefner
Agreed! There is a proposal for something like that in the WHATWG repo: https://github.com/whatwg/html/issues/8538
recursivedoubts
Alex and (to a much lesser extent) I are trying to get a modernized version into the HTML spec:
rco8786
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.
wavemode
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.
jayflux
> 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.
wavemode
"Made life a lot easier" wasn't my experience. I always found early CSS much more fiddly than tables, and less capable in many ways.
It's funny looking back at this SO question from 2009, and its answers: https://stackoverflow.com/questions/426253/why-use-tables-to...
There was definitely an ongoing culture war between people who felt like using tables was not "proper", and people who just wanted their site layout to work consistently in IE6.
null
null
mananaysiempre
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.
acjohnson55
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.
junto
Tables didn’t work very well with screen readers if memory serves me right. That and it produced a tag soup.
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.
cartoffal
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 :)
bazoom42
Framesets were a bad idea because they didn’t work well with links, bookmarks, and search engines. Tables are fine when used correctly though.
p4bl0
> 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.
JimDabell
> 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.
p4bl0
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.
shkkmo
> 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.
systems_glitch
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
aryonoco
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.
kyrylo
Author here — thank you! You're absolutely right, and I've corrected it!
lifthrasiir
Shower thought: `<a href="..." target="_mobile">` should transfer a link in a desktop into my phone. Same goes for `target="_desktop"` but in the opposite direction.
staz
Should it really be up to the Website designer to decide?
On Firefox I have the "Send Link to Device" context action that allow me to open a link on my Phone or Desktop.
berkes
I would imagine that it'd be best done with the "share" API that already exists.
A website designer then might say "share this url on click" and the browser takes over and/or defers to the OS.
Now, the share() [https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...] falls short in passing along context for login (e.g. cookies) so I'd imagine that this would either be part of the browser, or something the share() api could extend on, though I'd be unconfortable about the security implications of the latter.
The share() also falls short on desktop in my experience. AFAIK, firefox (on linux?) doesn't even have the share() API available.
The browser now already registers itself as a target to share web urls. It does this already (on my mobile devices at least) as "Open URL in Firefox" for example.
It should and could also add a target to share web urls, but call it "Send to device". Firefox for Android used to have this and it was awesome. But mozilla somehow dropped it. (There was a long thread on a bug report about exactly this, but I cannot find it).
Also, when I choose that option, it'd not just send the url along, but could also send any cookies or even localstorage and other data along. That way I'd be logged in.
That last part would be part of the "send to " feature, in Firefox called "firefox sync" and possibly be configurable from there to opt out of sending session or other data along.
Point is: there's no need for extra "target=" hackery, we already have all the tech in place to send links to devices. Instead, we'd have to convince browser builders to improve this tech and the UX of it.
tossandthrow
In my product we have a photo app and for normal people it is just easier to have the transferred to the phone than to use a desktop computer (without a camera) to grab a picture.
We use QR codes to transfer the user - a solution would need to be as simple as that (Ie. not requiring the user to be logged in on the same browser or other shenanigans).
The current solution is a hasle, but works well - I can't envision how a target="_mobile" should solve this? Especially since you need to transfer authentication also.
woodpanel
Sounds like a new product idea for services a la "login via apple-id/windows/google/...". Name it something like "send session to..."
Asmod4n
On windows you can “link” your phone to your windows account, or log into your Microsoft account in edge on mobile. That could solve the login part somehow.
graemep
KDE Connect does that on Linux and Android across browsers.
6510
<a target="_car"></a> <a target="_shower"></a> <a target="_doorbel"></a>
SahAssar
Yay, that would be awesome for cross-device tracking! Also don't forget about _tablet, _phablet, _tv, _laptop, _watch, _work_laptop, _smart_speaker, _ereader, etc.
niek_pas
[flagged]
thih9
> SHOWER THOUGHT definition: a sudden idea that occurs to a person during an unconnected mundane activity
https://www.collinsdictionary.com/dictionary/english/shower-...
ramon156
Its a tongue-in-cheek comment
https://www.collinsdictionary.com/dictionary/english/tongue-...
(Not mocking, I just really liked the explanation and it happened to be the same site)
shreddit
That IP rating for my phone got be be useful for something
sangeeth96
Who doesn't?
culi
Seems awfully wasteful. In many (most?) parts of the the middle east you pay for water in a shower and you get 10 minutes. It's usually extremely cheap, but the added realization of water being a limited resources promotes people to be more waterwise.
I wish this was common in the US too but consumption by the American consumer is the most sacrosanct thing in the current world order. As Bush said "The American lifestyle is non-negotiable". Even while the world burns
AndrewOMartin
By only reading HN in the shower I limit the time wasted on browsing HN to a couple of hours a day.
advincze
It's crappy design. Instead of using a separate property for different functionality like target-new-window=true or sth. They wanted to be clever. I think this is misinterpreting Simplicuty by thinking that an additional property is complicating things
Calzifer
That just opens the door for invalid combinations. As others said there is not only "_blank" but other special values like "_top".
<a target-new-window=true target-top-frame=true target-self=true ...
btown
The 1995 Frameset proposal from Netscape that started it all: https://lists.w3.org/Archives/Public/www-html/1995Sep/0034.h...
> Hi. I'm the Netscape Navigator marketing guy. Please forgive the temerity with which we submit this new proposal from Netscape to the W3 and IETF for enhancements to HTML 3.0. It pertains to functionality called Frames.
...
> The NAME attribute is used to assign a name to a frame so it can be targeted by links in other documents (These are usually from other frames in the same document.) The NAME attribute is optional; by default all windows are unnamed.
> Names must begin with an alphanumeric character. However, several reserved names have been defined, which start with an underscore. These are currently: _blank Always load this link into a new, unnamed window. _self Always load this link over yourself. _parent Always load this link over your parent. (becomes self if you have no parent). _top Always load this link at the top level. (becomes self if you are at the top).
Cthulhu_
My first "web app" used frames, it was good times. Some time later I used backbone.js, and while it was still good times, it did get a lot more complicated (e.g. having to manually disconnect and reconnect 'child' elements when the main element re-rendered so that they would retain their event handlers).
101008
Ouffff, I haven't heard of backbone.js for a long time. Yeah, my first web also used frames and framesets, then I discovered iframes and it was a whole new world! I didn't need PHP to do includes. And when with JS I could adjust the size of the iframes dinamically, that was like magic.
reflectiv
my current job still uses it deep in some abstraction created ages ago...
I went digging in W3C archives to find relevant discussions. There are 4 reserved target names: _blank, _parent, _self, _top.
- 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.