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.
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.
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
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.
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.
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.
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)
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.
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.
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.
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?
movieclip._x or movieclip._alpha (as in position and alpha blending) were accessed by properties with underscore to denote that you were using accessors (getters/setters).
Internally properties like Object.prototype.__proto__ had two underscores to denote they were private.
In AS2 you had:
class Foo extends Bar implements Xyz {
private foo
public function set x (value : Number) : void { ... }
public function get x () : Number { }
AS2 was based on long forgotten ES4 specification [0].
Under the hood it was still, what we would call today, transpiled to ES3 bytecode, as it run basically on the same VM as AS1.
It's crazy to think it took us 10 years to reinvent the wheel with TypeScript.
None of what you say here that is true moves the needle on what you say that isn't true.
Programmers using underscore to denote identifiers for internal use was well-established and in use long before ActionScript even appeared. To claim that it's a "direct descendant" of ActionScript is arbitrary, anachronistic, and odd.
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.
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_`.
I do it every day, so I see it from your perspective.
I'm willing to bet there are kids who do not though. Given how many crazy colours my IDE shows everything in, I could definitely believe there are people that go, 'Why bother, aren't those private members blue anyway?', or some such similar train of thought.
Of course if your IDE is little more than notepad, then such things are still important. For me, that's the Arduino IDE. I have to admit I really like writing micro controller code in it, it's a bit like writing code 30 years ago (both the good and bad parts).
Making it a dollar sign would cause countless bugs for people who generate HTML using templating languages whose variables are indicated by dollar sign. From time to time, someone would add target="$blank" to a templates, forgetting that the $ must be escaped to be literal.
They might have to resort to predefining a reserved variable called blank, whose value is "$blank". :)
Similar reasoning applies to most other special characters.
Given how HTML gets generated by preprocessors which use special characters in this manner or that, its best not to come up with new schemes within HTML itself involving special characters.
Carving out a reserved space within an existing namespace is safe.
The _ comes from the W3C in 1995 well before JavaScript was commonly used for templating HTML.
Scripting has used $ for variables for a long time: I think the most relevant history line for $variable is PHP comes from Perl comes from shell scripts. I also remember finding $ ugly on Vax.
There were a huge variety of templating syntaxes for server side and HTML generation was virtually all server side in the 1900s.
Server side languages were very rarely JavaScript before Node in 2009.
JavaScript wasn't used much for HTML generation before Ajax. There were soon after many many client side templating syntaxes.
I'm guessing only Brendan Eich could say why $ was accepted for JavaScript variable names.
Timelines are hard because the foundations were compressed within a decade: JavaScript 1995, PHP 1996, DHTML 1997, Ajax early 2000s, jQuery 2006.
Syntaxes tend to be extremely path dependent, and every developer cribs from everything they use.
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.
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.
Probably because it has no specific meaning and being almost whitespace is the easiest to mentally ignore out of the set of valid nickname characters. `-` is another candidate but a programmer used to C-like languages will likely intuitively pick `_` just because it’s valid in identifiers unlike `-`.
>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."
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.
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.
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.
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.
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 "_".
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.
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.
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.
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.
>(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.
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
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.
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.
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.
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.
> 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
I distinctly remember IE 5.x and 6.x on Windows and Mac OS with no tab support while Mozilla then Firefox (which had a much smaller users base) had them, at a period where HTML frames were still big.
> because you could totally have underscores in frame names.
Technically, the underscore was restricted and should not be used for user defined targets/frame names. This isn't something any browser I know of ever enforced.
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
Now the browser needs to define and document some kind of priority to solve those situations.
If you can have only one target anyway why not simply give special targets special values.
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?
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.
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.
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.
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.
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!
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.
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)
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.
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.
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. :)
> 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).
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.
202 comments
[ 3.2 ms ] story [ 283 ms ] threadYou still see _blank for links opening in new windows, but _parent, _self, etc not so much anymore.
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
https://www.collinsdictionary.com/dictionary/english/shower-...
https://www.collinsdictionary.com/dictionary/english/tongue-...
(Not mocking, I just really liked the explanation and it happened to be the same site)
On Firefox I have the "Send Link to Device" context action that allow me to open a link on my Phone or Desktop.
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.
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.
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.
https://www.w3.org/TR/WD-frames-970331
Enjoy! (check the source)
Are you still using the original Claris Home Page software to maintain the website?
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)
http://www.teleportacia.org/war/war2.htm
https://www.w3.org/TR/html401/present/frames.html#h-16.3
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...
But doesn't it all trace back to C conventions anyways?
AS1 was plain ES3.
movieclip._x or movieclip._alpha (as in position and alpha blending) were accessed by properties with underscore to denote that you were using accessors (getters/setters).
Internally properties like Object.prototype.__proto__ had two underscores to denote they were private.
In AS2 you had:
AS2 was based on long forgotten ES4 specification [0]. Under the hood it was still, what we would call today, transpiled to ES3 bytecode, as it run basically on the same VM as AS1.It's crazy to think it took us 10 years to reinvent the wheel with TypeScript.
AS3 was a complete rework, more akin to Java.
[0] https://evertpot.com/ecmascript-4-the-missing-version/
Programmers using underscore to denote identifiers for internal use was well-established and in use long before ActionScript even appeared. To claim that it's a "direct descendant" of ActionScript is arbitrary, anachronistic, and odd.
1. https://developers.google.com/apps-script/guides/html/commun...
So a variable that really ought to be named `class` you name `class_`.
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.
But yeah for every other time most linters will accept _ as "ignore this".
Thanks for teaching me something today.
I'm willing to bet there are kids who do not though. Given how many crazy colours my IDE shows everything in, I could definitely believe there are people that go, 'Why bother, aren't those private members blue anyway?', or some such similar train of thought.
Of course if your IDE is little more than notepad, then such things are still important. For me, that's the Arduino IDE. I have to admit I really like writing micro controller code in it, it's a bit like writing code 30 years ago (both the good and bad parts).
They might have to resort to predefining a reserved variable called blank, whose value is "$blank". :)
Similar reasoning applies to most other special characters.
Given how HTML gets generated by preprocessors which use special characters in this manner or that, its best not to come up with new schemes within HTML itself involving special characters.
Carving out a reserved space within an existing namespace is safe.
The _ comes from the W3C in 1995 well before JavaScript was commonly used for templating HTML.
Scripting has used $ for variables for a long time: I think the most relevant history line for $variable is PHP comes from Perl comes from shell scripts. I also remember finding $ ugly on Vax.
There were a huge variety of templating syntaxes for server side and HTML generation was virtually all server side in the 1900s.
Server side languages were very rarely JavaScript before Node in 2009.
JavaScript wasn't used much for HTML generation before Ajax. There were soon after many many client side templating syntaxes.
I'm guessing only Brendan Eich could say why $ was accepted for JavaScript variable names.
Timelines are hard because the foundations were compressed within a decade: JavaScript 1995, PHP 1996, DHTML 1997, Ajax early 2000s, jQuery 2006.
Syntaxes tend to be extremely path dependent, and every developer cribs from everything they use.
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
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."
https://github.com/whatwg/html/issues/4078 https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
I'd be interested to hear either a citation proving or disproving that guess though.
[1] https://www.w3.org/TR/WD-frames-970331#frame
I got into web dev after HTML5, I've never heard of <frameset>
This all changed in HTML5 when IDs could start with special characters like "_".
This is the actual answer and TFA somehow missed it completely.
For anyone who writes these, please just leave it blank and revisit it later
see also https://en.wikipedia.org/wiki/Goodhart%27s_law
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.
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.
In anglefire and maybe geocities we would serve the document with a .txt extension and it would also skip the ads but browsers, with their liberal acceptance policy, would render normally.
The 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.
> 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.
I now agree that the article doesn’t make a particularly good job in explaining all of this.
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.
Isn't iframe the replacement? iframe is not deprecated.
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.
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.
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.
First, it doesn't say why an underscore does that, because you could totally have underscores in frame names. My guess as others here is that the underscore prefix dates back from reserved names in C and C++. IIRC the reserved names also included "_self" (even if it was the default), "_parent" (to go up a level in the frame hierarchy) and "_top" to replace the whole page.
Second, at the time it was clearly not "open the link in a new tab" but rather in a "new window". IE was the most used browser back then, by a large proportion, and it didn't supports tabs at all.
Internet Explorer barely even existed back then, it certainly wasn’t the most used browser. That came later. No browser had tabs back in those days.
Technically, the underscore was restricted and should not be used for user defined targets/frame names. This isn't something any browser I know of ever enforced.
https://www.w3.org/TR/REC-html40/types.html#h-6.16
Always thought it was a creatively simple solution, but had no idea the pattern had existed (and was used) for so long.
Though... yeah it's pretty unsatisfying of an answer generally.
Edit: In fact, I'm pretty sure Geers' book associated with that site says as much.
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.
But no.
Fret no more:
https://jsfiddle.net/xrkLt2nz/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.
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.
Fair enough.
And good points all around, especially in your linked comment.
iframes are also in a rather locked-down security model, even if they exist on the same domain. (Requires message passing, strict CORS rules, strict cookies rules etc)
https://github.com/alexpetros/triptych
Tell that to the enterprise email scanning software my Fortune 500 company uses
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.
> 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).
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.