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 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.
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.
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.
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.
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.
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.
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
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.
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 arbitrary 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.
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.
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 :)
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.
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)
This is certainly better than nothing, but it should just be a tag! I shouldn't need this fancy new-fangled "CSS" fad to bail me out of the problems that W3C created by removing it in the first place!
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)
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.
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.
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).
I nice factoid: in Erlang, `_` if functional. It means "I don't care about this variable". When pattern matching you can put `_` to not bind value in function or pattern to anything or prepend a variable with `_` to tell compiler that you won't be using it, but it's there for "documentation" purposes. For example `[A|_]=List` will extract first element of list into A and ignore rest of list. Underscore has some other uses too.
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.
>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."
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.
> 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).
> 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.
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
> 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.
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.
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.
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.
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.
The issue, as also described in the comment, is that it is a hard no-go to assume that the user is logged in on the same device.
It is a shame that the family computer does not exists anymore - a place where you can't just assume that the same account is logged in on related devices.
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.
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
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
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).
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.
I'm guessing it is because the developer at Netscape that added frame support thought about it for 5 seconds and came up with the name. Maybe if Lou Montulli sees this he would know?
I haven't done much with HTML for years so I had no idea that modern browsers use "_blank" to open a page in a new tab instead of a new window. This genuinely surprised me, seems like unexpected behaviour or a regression/bug. :)
You mean [the mdn docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...)? Looks like classic deprecation to me: they'll still 'work', you just shouldn't use them. In the same way that tables-for-layout still 'works', but you shouldn't actually do that.
Actually, frames were ugly, limited and not really ergonomic but they weren’t a wrong pattern.
They solved a real problem of having parts of the page that changes and other parts that didn’t. It’s a shame they were deprecated without a modern replacement.
An "include" mechanism (like what html provides) should have been proposed to replace this use case.
The deprecation of frames forced dynamic websites (wether it is client or server side) on everyone and i feel like it is in part responsible of why people stopped to handcraft websites.
> Actually, frames were ugly, limited and not really ergonomic but they weren’t a wrong pattern.
I used frames to do holy grail lite layout with static header/footer with the main body being the part that continued to update. The footer remaining the same was the only way I could get our early "radio station" to continue playing with the user navigated the site so that the music wasn't interrupted. This was so old, it was using an embedded Real Player. As for ugly, there were no borders from the frameset.
> Actually, frames were ugly, limited and not really ergonomic but they weren’t a wrong pattern.
They were. The most fundamental part of the WWW architecture is the URL. URLs are more important than even HTML or HTTP. Without addressability, the web doesn’t work.
Frames break URLs because you can visit a site that uses frames, navigate around the site, and the URL won’t change. You can’t link to the place you arrive at. Frames break addressability and this makes them go completely against the grain of the WWW. Flash and Java applets were fundamentally at odds with the WWW architecture as well for the same reason.
There were workarounds to load a direct link to a frame so that it loaded properly in the frameset. If you visited a site that did not do that, then they were just not trying as hard.
This is true, but back then we didn't have the JS History API so navigating throughout a frame-based website would never update the URL in the address bar to reflect where the user is.
Whether or not you see it as a big deal is up to you, but I personally have vivid memories of receiving links from users who were trying to share or show me a particular page, only to realize that they had copied the address bar's content of a framed website.
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.
Are there still legitimate uses for the target attribute, other than _blank?
Framesets are obviously out of date, but the target attribute can also be used to always open some links in the same tab with that target name, i.e. not to open a new one when it already exists. Not sure whether this has much of a modern use case.
This to me was always obvious. They wanted a way to define special targets that had specific behaviour but didn't want people to get confused when they tried to call something "blank" and then it created a new window. Having a special character at the start of your name by default is extremely uncommon so you're very safe if you add a special character at the start of the name for special purposes it won't conflict with someone's actual desires. "_blank" isn't the only one. "_parent", "_top", etc also exist.
True, but most people will have clicked through to the HN comments without reading the actual article. So I suppose it's helpful for the comments to give a succinct answer to the question for the people who don't know.
Yes, it is a common clickbait tactic. Also, rhetorical questions, by definition, don't get answered. If it's rhetorical then the article content is pointless? I don't see why this bothers you all. Saved me a click so I appreciate the comment.
To be fair, a lot of people they might assume that the target attribute can ONLY take a few discrete magic values if they haven't worked with multiple frames on one document, so it's an obvious question to ask why it HAS to start with an underscore. (_blank has the same uniqueness as blank, if you assume the ONLY options are _blank and _self, the only commonly used values in modern web development.)
Though... yeah it's pretty unsatisfying of an answer generally.
My father is, yes. I think he still uses his old Powerbook G4 with the old 30" cinema display for that website. He also has an ancient version of photoshop on there, hah.
He also has a bunch of wordpress websites. He's scared to change his "main" website because it might break SEO or bookmarks or incoming links.
He has 2 laptops on his desks; one modern M-based macbook and that ancient powerbook. He also has a black apple laptop that I think is a G3, and it still worked (a few years ago, last time it came up)
Defaulting to kindness, curiosity, and respect will help you get heard. I read the code included version of this comment and it seemed you had some potentially interesting contributions to add to the conversation.
In HTML 4.01 and XHTML "_blank" was an illegal ID, so a frame could not use it. Therefore, there was no chance of breaking existing code. "blank" however, could be in use when they introduced this feature and break existing pages.
This all changed in HTML5 when IDs could start with special characters like "_".
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.
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...
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.
This is a direct descendant of ActionScript. It introduced the convention of Instance._getter and Instance.__private.
What about Lingo?
I wouldn’t say it’s a “holdover”, it continues to be a common convention for marking internal or reserved 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 exactly what I understood from the article. Your explanation didn't add anything extra.
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.
If what you say is accurate then it should have been in the article. Because, as is, GP is correct that it doesn't answer the question!
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.
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.
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.
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.
Yes, whenever you see such a convention it’s about expanding the namespace. i.e. avoiding the main namespace.
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.
And a lot of SO answers.
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
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.
see also https://en.wikipedia.org/wiki/Goodhart%27s_law
I second your motion.
"I dunno...is magic" (engineering Calculus II GTA, Virginia Tech, 2006)
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 arbitrary 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.
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.
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 :)
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.
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.
> I'm so tired of having to write my own JavaScript to get annoying flashy text
Fret no more:
https://jsfiddle.net/xrkLt2nz/This is certainly better than nothing, but it should just be a tag! I shouldn't need this fancy new-fangled "CSS" fad to bail me out of the problems that W3C created by removing it in the first place!
Definitely. Much less the many several users who yet lack CSS support in their preferred browser.
The good news is that <marquee> still works in the latest Firefox. No need for any new-fangled animation libraries for me.
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.
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/
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.
What are you missing by using iframes (still standard, supported, working) + css for layouting that old school frames would give you?
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)
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
Agreed! There is a proposal for something like that in the WHATWG repo: https://github.com/whatwg/html/issues/8538
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.
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.
[1] https://www.w3.org/TR/WD-frames-970331#frame
This one sentence is better than the original article.
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.
https://www.w3schools.com/TAgs/att_a_target.asp
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.
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...
But why was _name the naming syntax for reserved keywords, specifically?
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).
I nice factoid: in Erlang, `_` if functional. It means "I don't care about this variable". When pattern matching you can put `_` to not bind value in function or pattern to anything or prepend a variable with `_` to tell compiler that you won't be using it, but it's there for "documentation" purposes. For example `[A|_]=List` will extract first element of list into A and ignore rest of list. Underscore has some other uses too.
Yes, many languages use `_` as a placeholder name, and at least in Rust any name starting with `_` is considered intentionally unused.
Aside: many IRC clients would auto-append _ when registering a nick if the desired nick was already registered. Why _? Who knows.
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.
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.
>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."
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.
Frame names must start with an alphanumerical character.
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).
> 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.
> 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.
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
> 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.
https://www.w3.org/TR/REC-html40/types.html#h-6.16
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.
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.
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.
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.
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.
Sounds like a new product idea for services a la "login via apple-id/windows/google/...". Name it something like "send session to..."
The issue, as also described in the comment, is that it is a hard no-go to assume that the user is logged in on the same device.
It is a shame that the family computer does not exists anymore - a place where you can't just assume that the same account is logged in on related devices.
KDE Connect does that on Linux and Android across browsers.
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.
<a target="_car"></a> <a target="_shower"></a> <a target="_doorbel"></a>
[flagged]
> SHOWER THOUGHT definition: a sudden idea that occurs to a person during an unconnected mundane activity
https://www.collinsdictionary.com/dictionary/english/shower-...
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)
That IP rating for my phone got be be useful for something
Who doesn't?
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
By only reading HN in the shower I limit the time wasted on browsing HN to a couple of hours a day.
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
Site is giving me a 403, here is an Archive mirror: https://archive.ph/aDqv3
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).
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.
I'm guessing it is because the developer at Netscape that added frame support thought about it for 5 seconds and came up with the name. Maybe if Lou Montulli sees this he would know?
I haven't done much with HTML for years so I had no idea that modern browsers use "_blank" to open a page in a new tab instead of a new window. This genuinely surprised me, seems like unexpected behaviour or a regression/bug. :)
The last browser that did that was the infamous Internet Explorer 6.
You can use target with iframes: https://jsfiddle.net/7szje2a9/
I think it's funny that Mozilla says not to use frames anymore, they work just fine on modern browsers...
You mean [the mdn docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...)? Looks like classic deprecation to me: they'll still 'work', you just shouldn't use them. In the same way that tables-for-layout still 'works', but you shouldn't actually do that.
Actually, frames were ugly, limited and not really ergonomic but they weren’t a wrong pattern.
They solved a real problem of having parts of the page that changes and other parts that didn’t. It’s a shame they were deprecated without a modern replacement.
An "include" mechanism (like what html provides) should have been proposed to replace this use case.
The deprecation of frames forced dynamic websites (wether it is client or server side) on everyone and i feel like it is in part responsible of why people stopped to handcraft websites.
> Actually, frames were ugly, limited and not really ergonomic but they weren’t a wrong pattern.
I used frames to do holy grail lite layout with static header/footer with the main body being the part that continued to update. The footer remaining the same was the only way I could get our early "radio station" to continue playing with the user navigated the site so that the music wasn't interrupted. This was so old, it was using an embedded Real Player. As for ugly, there were no borders from the frameset.
> Actually, frames were ugly, limited and not really ergonomic but they weren’t a wrong pattern.
They were. The most fundamental part of the WWW architecture is the URL. URLs are more important than even HTML or HTTP. Without addressability, the web doesn’t work.
Frames break URLs because you can visit a site that uses frames, navigate around the site, and the URL won’t change. You can’t link to the place you arrive at. Frames break addressability and this makes them go completely against the grain of the WWW. Flash and Java applets were fundamentally at odds with the WWW architecture as well for the same reason.
There were workarounds to load a direct link to a frame so that it loaded properly in the frameset. If you visited a site that did not do that, then they were just not trying as hard.
This is true, but back then we didn't have the JS History API so navigating throughout a frame-based website would never update the URL in the address bar to reflect where the user is.
Whether or not you see it as a big deal is up to you, but I personally have vivid memories of receiving links from users who were trying to share or show me a particular page, only to realize that they had copied the address bar's content of a framed website.
>> It’s a shame they were deprecated without a modern replacement.
Isn't iframe the replacement? iframe is not deprecated.
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.
Author here — thank you! You're absolutely right, and I've corrected it!
Another nitpick: the attribute was called name, not id.
https://www.w3.org/TR/html401/present/frames.html#h-16.3
Thanks, fixed!
name collisions.
> P.S. Don’t use <frameset>. It’s deprecated in HTML5
Tell that to the enterprise email scanning software my Fortune 500 company uses
Love this. Just when you thought you knew all the reserved words, you learn another one.
Wait, so frameset is basically htmx?
I've been doing web development on and off for 30 years and in no other programming field have I seen this perpetual habit of rediscovering the wheel.
I’m having the same realization regarding Turbo.
Always thought it was a creatively simple solution, but had no idea the pattern had existed (and was used) for so long.
Are there still legitimate uses for the target attribute, other than _blank?
Framesets are obviously out of date, but the target attribute can also be used to always open some links in the same tab with that target name, i.e. not to open a new one when it already exists. Not sure whether this has much of a modern use case.
This to me was always obvious. They wanted a way to define special targets that had specific behaviour but didn't want people to get confused when they tried to call something "blank" and then it created a new window. Having a special character at the start of your name by default is extremely uncommon so you're very safe if you add a special character at the start of the name for special purposes it won't conflict with someone's actual desires. "_blank" isn't the only one. "_parent", "_top", etc also exist.
Because back in the mid 90's, there was Netscape...
Because “blank” can be a real frame name if you want to make your codebase a little harder on purpose.
You still see _blank for links opening in new windows, but _parent, _self, etc not so much anymore.
The title of the post isn't asking HN users a question
True, but most people will have clicked through to the HN comments without reading the actual article. So I suppose it's helpful for the comments to give a succinct answer to the question for the people who don't know.
Looks like a question to me. Even has a little curly punctuation mark at the end.
> The title of the post isn't asking *HN users* a question
So everyone else then? Sounds like someone is just grumpy today.
The headline of the article is a rhetorical question, one that the article itself then answers in detail. It's a very common device.
Yes, it is a common clickbait tactic. Also, rhetorical questions, by definition, don't get answered. If it's rhetorical then the article content is pointless? I don't see why this bothers you all. Saved me a click so I appreciate the comment.
OK.
Yeah it's a magic value. No shit? Was anyone really confused by this?
To be fair, a lot of people they might assume that the target attribute can ONLY take a few discrete magic values if they haven't worked with multiple frames on one document, so it's an obvious question to ask why it HAS to start with an underscore. (_blank has the same uniqueness as blank, if you assume the ONLY options are _blank and _self, the only commonly used values in modern web development.)
Though... yeah it's pretty unsatisfying of an answer generally.
FWIW, I never heard of the frameset tag, while I did use frames back then.
frameset was already there in 1997, when iframe was just a proposal
https://www.w3.org/TR/WD-frames-970331
Olia Lialinas "My boyfriend came back from the war" is a classic piece of netart that uses frameset in a unique way. It's still online:
http://www.teleportacia.org/war/war2.htm
http://hinloopen.nl/be499.html
Enjoy! (check the source)
A true modern blast from the past!
Are you still using the original Claris Home Page software to maintain the website?
My father is, yes. I think he still uses his old Powerbook G4 with the old 30" cinema display for that website. He also has an ancient version of photoshop on there, hah.
He also has a bunch of wordpress websites. He's scared to change his "main" website because it might break SEO or bookmarks or incoming links.
He has 2 laptops on his desks; one modern M-based macbook and that ancient powerbook. He also has a black apple laptop that I think is a G3, and it still worked (a few years ago, last time it came up)
<frameset> replaces the <body> tag. TIL
Same... We used <iframe>.
fartheads eat farts
Thanks for the source. The other comment where you call HN users dumb for not checking themselves was uncalled for.
Welcome to Hacker News.
Defaulting to kindness, curiosity, and respect will help you get heard. I read the code included version of this comment and it seemed you had some potentially interesting contributions to add to the conversation.
Because making "blank" a reserved word would've been so much harder than making "_blank" one... /s
In HTML 4.01 and XHTML "_blank" was an illegal ID, so a frame could not use it. Therefore, there was no chance of breaking existing code. "blank" however, could be in use when they introduced this feature and break existing pages.
This all changed in HTML5 when IDs could start with special characters like "_".
Not sure about the /s.
This is the actual answer and TFA somehow missed it completely.
[dead]
Because its an remnant from the browser wars.