Live data from Hacker News

Why does target="_blank" have an underscore in front? (2024)

kyrylo.org

101–110 of 203 posts

Re: Why does target="_blank" have an underscore in front? (2024)

#101
post #44

> 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 l…

> because you could totally have underscores in frame names.

Technically, the underscore was restricted and should not be used for user defined targets/frame names. This isn't something any browser I know of ever enforced.

https://www.w3.org/TR/REC-html40/types.html#h-6.16

Re: Why does target="_blank" have an underscore in front? (2024)

#102
post #53

Earlier quoted context omitted.

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…

> 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…

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.

Re: Why does target="_blank" have an underscore in front? (2024)

#104
post #90

Earlier quoted context omitted.

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 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.

Re: Why does target="_blank" have an underscore in front? (2024)

#105
post #18

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.

Re: Why does target="_blank" have an underscore in front? (2024)

#106
post #93
post #41

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.

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.

Re: Why does target="_blank" have an underscore in front? (2024)

#109
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).

Re: Why does target="_blank" have an underscore in front? (2024)

#110

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'm just happy we can find DOM elements by CSS selectors now. Full browser support for calc was almost too much excitement for me
Post reply on HN