So if we kept frameset in HTML5, we would not have had to do all these JS shenanigans?!?!?! SPA out of the box? :)
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.
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.
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.
In which case, the need for the spec should be obvious from the onset. Nobody though that html would be used the way it was used today. But we now know the same things as they knew back then, meaning that we do not know nothing, we don't know what will be used and need interoperability. Also, specs means nothing if each implementation can and will do whatever they want (ie. Chrome vs Firefox vs Edge)
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.
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.
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.
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.
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?
What about Lingo?
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...
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_`.
In java usually clazz
I use underscore to prevent shadowing of variables names. Not sure where I picked up that habit though.
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.
You've been able to `const [, a, b] = tuple;` for a wee while now FYI.
But yeah for every other time most linters will accept _ as "ignore this".
I had no idea that was a thing!
Thanks for teaching me something today.
Oh yeah, I always forget about that.
I wouldn’t say it’s a “holdover”, it continues to be a common convention for marking internal or reserved use.
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).
Some modern languages even turn _ flagged variables/parameters into black holes
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.
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.
Shell script here documents can generate HTML:
cat <<!
<div>
...
<a href="$url" target="_blank" ...
...
!
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.
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.
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 dunno...is magic" (engineering Calculus II GTA, Virginia Tech, 2006)
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.
I second your motion.
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.
This one sentence is better than the original article.
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>
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.
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...
Nobody gets "full access" to your "javascript object"—whatever that even means; pages from different origins will still run into exceptions when trying to diddle the opener. There is a small, well-known set of (safe) properties that are excluded from the restrictions—like location. But the noopener behavior, by making opener null, does stop other pages from setting even opener.location, which could ordinarily be used to programmatically send the user to another page.
But why was _name the naming syntax for reserved keywords, specifically?
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.
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.
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.
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:
<style>
.blink { animation: blink 1s steps(2, start) infinite; }
@keyframes blink { 50% { visibility: hidden; } }
</style>
<p class="blink">Lorem ipsum</p>
If front-end devs would stop reinventing things using JS that can be done in CSS, I'd be so happy.
Why?
Because the JS version will likely take more resources and probably end up being done wrong anyways.
I just don't get why front-end devs feel the need to reinvent everything.
I mean, for fuck's sake, front-end devs for some reason have a fascination with reinventing fucking SCROLLING. And 100% of the time, it either doesn't work, has less functionality than what was built-in, or is annoying for the simple fact that it changes an expected behavior.
If I click my scroll wheel once, and the page keeps scrolling and the scrolling slowly comes to a stop as if it had momentum, that's a bug, not a feature. Stop wasting time deliberately writing bugs.
Scrolling is sort of a strawman here, so I’ll focus on blinking and css features and the need to reinvent these.
First, not all css features are consistent enough from the side you usually tend to approach things, due to various backgrounds and thinking modes. Css is notoriously overcomplicated, nuanced and ad-hoc applicable, and tendency to neglect it is its own self-imposed problem.
Second, there’s no law that dictated some true way to do things. People use instruments they know, and if these work, there’s no need to go and find true ways.
Overall, there’s no difference if you do something in js that css can do, apart from hurting someone’s feelings. All the difference you see is in multi-megabyte tracking scripts, not in js-dom chain per se. The difference betwen css and js ways is barely measurable when you start actually testing it. But js is more powerful in expression and familiar to a developer (except for 60fps+ animations and such).
I say this as a non-frontend dev who makes dashboards and other report/control pages for myself, so opinions may vary. But I’ve never seen a higher resource consumption from avoiding css. To my understanding, literally all sites I ever visited can be implemented in a straightforward way in js and will never “take more resources” and will work as fast as just html. Because it’s literally how any non-C GUI app works on desktops. An interpreted jit-able language controlling some widgets. It’s nothing new or unusual or bizarre. In fact, css is also a language, even if declarative, and keyframes structures and other calc()s also get interpreted many times per second, even if not using a full-blown vm.
In my opinion, people’s web bloat ideas are all over the place and miss the basics comletely, e.g. https://news.ycombinator.com/item?id=42990724 , and tend to blame wrong parts.
Not the GP, but my two cents: because JS sucks and CSS can already do it.
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.
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
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)
Agreed! There is a proposal for something like that in the WHATWG repo: https://github.com/whatwg/html/issues/8538
Alex and (to a much lesser extent) I are trying to get a modernized version into the HTML spec:
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.
"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.
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.
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.
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 :)
Framesets were a bad idea because they didn’t work well with links, bookmarks, and search engines. Tables are fine when used correctly though.
> 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.
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).
Perhaps for the same reason "World wide web inventor admits forward slashes 'a mistake'" [0]I wonder what the cumulative years / time wasted writing '://' or the amount of energy which could have been saved computing it would be?
[0] https://economictimes.indiatimes.com/tech/internet/world-wid...
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
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 ...
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.
my current job still uses it deep in some abstraction created ages ago...
Underscore prefix in a label has conferred a meaning of private or reserved in the C programming language since at least Unix Version 6 in 1975, which had underscores to denote system level functions and variables. MUMPS in 1966 reserved a % prefix to indicate system variables and routines, so a convention of using a non-alphanumeric character to distinguish scope has been around about as long as ASCII has been the dominant standard for text.
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.
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.
Thanks, fixed!
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.
Of note: <frameset> is marked obsolete, not deprecated, in the current HTML standard (aka HTML5): https://html.spec.whatwg.org/dev/obsolete.html#non-conformin...
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.
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.
> 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.
>> It’s a shame they were deprecated without a modern replacement.
Isn't iframe the replacement? iframe is not deprecated.
Site is giving me a 403, here is an Archive mirror: https://archive.ph/aDqv3
You can use target with iframes: https://jsfiddle.net/7szje2a9/
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.
Hey, we may be spinning in circles, but at least the websites consistently get slower over the years
always has been (hx-target was taken directly from the target attribute on anchors, innerHTML as the default swap taken from how iframes behave)
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.
On this topic: Please NEVER use target=_blank. If the user wants a new window or tab, then they can open a new window or tab. There are so many websites where navigating around for a bit makes you end up with 5-6 tabs open, all with broken history, thanks to this mis-feature.
_blank is evil and user hostile. Don't be evil and user hostile.
It's too bad that you have to resort to pleading with the 10s of 1000s of web-site owners because the place where this problem is most easily addressed is with the 4 major browser owners (Apple, Google, Microsoft and Mozilla). I.e., they have the power to remove the _blank functionality from the browsers.
I hate this so much. There are a few extensions that try to limit the damage, but none of them work super well. There's no reason for target=_blank to exist.
> P.S. Don’t use <frameset>. It’s deprecated in HTML5
Tell that to the enterprise email scanning software my Fortune 500 company uses
Of note: <frameset> is marked obsolete, not deprecated, in the current HTML standard (aka HTML5): https://html.spec.whatwg.org/dev/obsolete.html#non-conformin...
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
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.
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.
OK.
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.
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.
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.
name collisions.
Love this. Just when you thought you knew all the reserved words, you learn another one.
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
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://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>.
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.
Because its an remnant from the browser wars.