[HN Gopher] Why does target="_blank" have an underscore in front...
___________________________________________________________________
Why does target="_blank" have an underscore in front? (2024)
Author : OuterVale
Score : 228 points
Date : 2025-02-21 14:07 UTC (3 days ago)
(HTM) web link (kyrylo.org)
(TXT) w3m dump (kyrylo.org)
| stop50 wrote:
| Because its an remnant from the browser wars.
| mattl wrote:
| 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.
| gpmcadam wrote:
| The title of the post isn't asking HN users a question
| batch12 wrote:
| Looks like a question to me. Even has a little curly
| punctuation mark at the end.
| oneeyedpigeon wrote:
| > The title of the post isn't asking *HN users* a question
| batch12 wrote:
| So everyone else then? Sounds like someone is just grumpy
| today.
| oneeyedpigeon wrote:
| The headline of the article is a rhetorical question, one
| that the article itself then answers in detail. It's a
| very common device.
| batch12 wrote:
| 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.
| arrowsmith wrote:
| 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.
| mattl wrote:
| OK.
| icedchai wrote:
| Because back in the mid 90's, there was Netscape...
| lifthrasiir wrote:
| 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.
| niek_pas wrote:
| [flagged]
| sangeeth96 wrote:
| Who doesn't?
| AndrewOMartin wrote:
| By only reading HN in the shower I limit the time wasted on
| browsing HN to a couple of hours a day.
| culi wrote:
| 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
| thih9 wrote:
| > SHOWER THOUGHT definition: a sudden idea that occurs to a
| person during an unconnected mundane activity
|
| https://www.collinsdictionary.com/dictionary/english/shower-.
| ..
| ramon156 wrote:
| Its a tongue-in-cheek comment
|
| https://www.collinsdictionary.com/dictionary/english/tongue
| -...
|
| (Not mocking, I just really liked the explanation and it
| happened to be the same site)
| shreddit wrote:
| That IP rating for my phone got be be useful for something
| staz wrote:
| 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.
| tossandthrow wrote:
| 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.
| Asmod4n wrote:
| 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.
| woodpanel wrote:
| Sounds like a new product idea for services a la "login via
| apple-id/windows/google/...". Name it something like "send
| session to..."
| tossandthrow wrote:
| 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.
| graemep wrote:
| KDE Connect does that on Linux and Android across browsers.
| berkes wrote:
| 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.
| 6510 wrote:
| <a target="_car"></a> <a target="_shower"></a> <a
| target="_doorbel"></a>
| SahAssar wrote:
| 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.
| d--b wrote:
| FWIW, I never heard of the frameset tag, while I did use frames
| back then.
| barotalomey wrote:
| Same... We used <iframe>.
| mxfh wrote:
| _frameset_ was already there in 1997, when _iframe_ was just a
| proposal
|
| https://www.w3.org/TR/WD-frames-970331
| tobyhinloopen wrote:
| http://hinloopen.nl/be499.html
|
| Enjoy! (check the source)
| jeroenhd wrote:
| A true modern blast from the past!
|
| Are you still using the original Claris Home Page software to
| maintain the website?
| tobyhinloopen wrote:
| 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)
| california-og wrote:
| Olia Lialinas "My boyfriend came back from the war" is a
| classic piece of netart that uses frameset in a unique way.
| It's still online:
|
| http://www.teleportacia.org/war/war2.htm
| werdnapk wrote:
| <frameset> replaces the <body> tag. TIL
| Cthulhu_ wrote:
| My first "web app" used frames, it was good times. Some time
| later I used backbone.js, and while it was still good times, it
| did get a lot more complicated (e.g. having to manually
| disconnect and reconnect 'child' elements when the main element
| re-rendered so that they would retain their event handlers).
| 101008 wrote:
| Ouffff, I haven't heard of backbone.js for a long time. Yeah,
| my first web also used frames and framesets, then I discovered
| iframes and it was a whole new world! I didn't need PHP to do
| includes. And when with JS I could adjust the size of the
| iframes dinamically, that was like magic.
| reflectiv wrote:
| my current job still uses it deep in some abstraction created
| ages ago...
| aryonoco wrote:
| Minor nitpick: browsers used _blank as a special directive to
| open the link in a new "window", not a tab. Browsers didn't have
| tabs back then, well other than Opera 4.x which was a paid
| software which never cracked 3% marketshare.
| kyrylo wrote:
| Author here -- thank you! You're absolutely right, and I've
| corrected it!
| currysausage wrote:
| Another nitpick: the attribute was called _name,_ not _id._
|
| https://www.w3.org/TR/html401/present/frames.html#h-16.3
| kyrylo wrote:
| Thanks, fixed!
| ldjb wrote:
| I was expecting this post to explain why it's an underscore
| specifically, as opposed to a dollar sign, an asterisk, a caret,
| a tilde or some other special character.
|
| I can only assume it's a holdover of languages like C where the
| standard library has some reserved names that start with an
| underscore.
|
| https://devblogs.microsoft.com/oldnewthing/20230109-00/?p=10...
| lelandfe wrote:
| As another borrowed convention, JS developers of yore (and
| likely some today still) used an _ prefix to denote "private"
| function/methods. Quotes as it's just a convention - today JS
| supports # for actual private members in class syntax.
| zeroq wrote:
| This is a direct descendant of ActionScript. It introduced
| the convention of Instance._getter and Instance.__private.
| DidYaWipe wrote:
| What about Lingo?
| magicalist wrote:
| 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?
| xd1936 wrote:
| 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...
| phist_mcgee wrote:
| I use underscore to prevent shadowing of variables names. Not
| sure where I picked up that habit though.
| lelandfe wrote:
| 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.
| fennecbutt wrote:
| 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".
| phist_mcgee wrote:
| I had no idea that was a thing!
|
| Thanks for teaching me something today.
| lelandfe wrote:
| Oh yeah, I always forget about that.
| layer8 wrote:
| I wouldn't say it's a "holdover", it continues to be a common
| convention for marking internal or reserved use.
| paradox460 wrote:
| Some modern languages even turn _ flagged
| variables/parameters into black holes
| anoldperson wrote:
| I do it every day, so I see it from your perspective.
|
| I'm willing to bet there are kids who do not though. Given
| how many crazy colours my IDE shows everything in, I could
| definitely believe there are people that go, 'Why bother,
| aren't those private members blue anyway?', or some such
| similar train of thought.
|
| Of course if your IDE is little more than notepad, then such
| things are still important. For me, that's the Arduino IDE. I
| have to admit I really like writing micro controller code in
| it, it's a bit like writing code 30 years ago (both the good
| and bad parts).
| kazinator wrote:
| Making it a dollar sign would cause countless bugs for people
| who generate HTML using templating languages whose variables
| are indicated by dollar sign. From time to time, someone would
| add target="$blank" to a templates, forgetting that the $ must
| be escaped to be literal.
|
| They might have to resort to predefining a reserved variable
| called blank, whose value is "$blank". :)
|
| Similar reasoning applies to most other special characters.
|
| Given how HTML gets generated by preprocessors which use
| special characters in this manner or that, its best not to come
| up with new schemes within HTML itself involving special
| characters.
|
| Carving out a reserved space within an existing namespace is
| safe.
| robocat wrote:
| 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.
| n_plus_1_acc wrote:
| 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.
| tomhoward wrote:
| Yeah it's not a great explanation.
|
| To me (and I'm of the era they're describing so I used it a
| lot) it's simply that _blank is a _reserved keyword_ that means
| open the link in a new, unnamed window.
|
| Other reserved keywords for "target" are _self (default value),
| _parent, and _top.
|
| https://www.w3schools.com/TAgs/att_a_target.asp
| stickynotememo wrote:
| But why was _name the naming syntax for reserved keywords,
| specifically?
| beejiu wrote:
| I suspect, when the specification was created, "_" was
| already popular for private/reserved members in many
| programming languages. In C++, for instance, you can only
| start an identifier with a letter or an underscore. So it
| seems like a natural, intuitive choice. Whether anyone can
| find any corroborating evidence would be interesting.
| Sharlin wrote:
| 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).
| yetihehe wrote:
| 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.
| Sharlin wrote:
| Yes, many languages use `_` as a placeholder name, and at
| least in Rust any name starting with `_` is considered
| intentionally unused.
| hunter2_ wrote:
| Aside: many IRC clients would auto-append _ when
| registering a nick if the desired nick was already
| registered. Why _? Who knows.
| ramesh31 wrote:
| >But why was _name the naming syntax for reserved keywords,
| specifically?
|
| As with so many things in software engineering, the answer
| comes down to "some programmer in the 70s working on a UNIX
| system had to make an arbitrary decision about something,
| and no one ever had a good reason to change it again."
| lazide wrote:
| 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.
| 0x0 wrote:
| Also worth noting that "_new" is NOT a reserved keyword, but
| it is sometimes mistakenly used instead of "_blank". Which
| can lead to funny behavior if you are visiting 2 or more
| sites making this mistake, as the links could then start
| opening in windows that were initially opened by the other
| site. Or least that's how it was back in the days of popup
| windows, before tabs and popup blockers became the norm.
| shkkmo wrote:
| 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...
| dcminter wrote:
| 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.
| Maken wrote:
| In other answer they link to the original specification [1],
| and it says that names must start with a letter, so anything
| preceded by "_" cannot be a frame name.
|
| [1] https://www.w3.org/TR/WD-frames-970331#frame
| stickfigure wrote:
| This one sentence is better than the original article.
| hbn wrote:
| 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>
| bazoom42 wrote:
| Frame names must start with an alphanumerical character.
| oneeyedpigeon wrote:
| Because making "blank" a reserved word would've been so much
| harder than making "_blank" one... /s
| Someone1234 wrote:
| 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 "_".
| moralestapia wrote:
| Not sure about the /s.
|
| This is the actual answer and TFA somehow missed it completely.
| bilekas wrote:
| 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.
| systems_glitch wrote:
| "I dunno...is _magic_ " (engineering Calculus II GTA, Virginia
| Tech, 2006)
| rendaw wrote:
| And a lot of SO answers.
| Aachen wrote:
| 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
| russfink wrote:
| I second your motion.
| mdaniel wrote:
| My experience with this is it is almost always caused by
| some heavy-handed linter rule, e.g. "fail CI if methods
| don't have javadoc". Most of those "dumb" linters also
| almost never catch when a parameter has been renamed but
| its "@param" was left intact. Drives me crazy.
|
| see also https://en.wikipedia.org/wiki/Goodhart%27s_law
| userbinator wrote:
| 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.
| neom wrote:
| When I built "webapps" in the 90s, they were a collection of
| frames. You could just do everything as one page, but there
| were some neat things you could do by dividing the page up into
| frames + internet connections were not very good so if you had
| something you needed to update a lot, it was easier to make it
| it's own .html and server it in an iframe.
|
| Because you could "NameAFrameAnyThingYouWanTED" they made some
| magic targets, _blank window to open a blank window (we have
| tabs, then we did not), _self to open in the same frame or
| window, _parent to open in the parent frame, _top to break out
| of frames entirely (this is how you would bypass the ad some
| free .coms would inject into your site)
|
| When I read the html spec in the 90s all it says was you can
| name a frame anything except don't use _ as _ is reserved for
| special frame types.
| sokols wrote:
| This is exactly what I understood from the article. Your
| explanation didn't add anything extra.
| lazide wrote:
| 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.
| tredre3 wrote:
| 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!
| layer8 wrote:
| Maybe the article didn't make it clear enough, but having
| special targets begin with an underscore has the purpose of
| avoiding name collisions with normal targets.
|
| The primary thing the article does is explain that there are
| normal targets in the first place, which is probably the main
| aspect people might otherwise be missing.
| mixmastamyk wrote:
| Yes, whenever you see such a convention it's about expanding
| the namespace. i.e. avoiding the main namespace.
| mikeyinternews wrote:
| 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
| layer8 wrote:
| Not quite. _Any_ name would open a new window unless a frame
| with that name already exists. This includes the case of the
| name "blank". In other words, the first time clicking on a link
| targeting a name would open a new frame (window) with that
| name, but the second time would load the content into the
| existing frame, replacing the previous content. In that scheme,
| there is no way to open an additional new frame each time. The
| reserved name "_blank" was then defined to have that semantics.
| bilekas wrote:
| So again as I understand, it's simply because a standard was
| decided ?
|
| > The (reserved) name "_blank" was then defined to have that
| semantic.
|
| I guess I was hoping for some interesting quirk with older
| browsers or something.
| layer8 wrote:
| 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.
| reverendsteveii wrote:
| 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.
| nubinetwork wrote:
| I think it's funny that Mozilla says not to use frames anymore,
| they work just fine on modern browsers...
| oneeyedpigeon wrote:
| 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.
| pjerem wrote:
| 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.
| zaxomi wrote:
| >> It's a shame they were deprecated without a modern
| replacement.
|
| Isn't iframe the replacement? iframe is not deprecated.
| JimDabell wrote:
| > 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.
| dylan604 wrote:
| 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.
| tredre3 wrote:
| 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.
| dylan604 wrote:
| > 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.
| p4bl0 wrote:
| > 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.
| systems_glitch wrote:
| 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
| JimDabell wrote:
| > 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.
| shkkmo wrote:
| > 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
| advincze wrote:
| It's crappy design. Instead of using a separate property for
| different functionality like target-new-window=true or sth. They
| wanted to be clever. I think this is misinterpreting Simplicuty
| by thinking that an additional property is complicating things
| Calzifer wrote:
| 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 ...
|
| 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.
| bicsi wrote:
| Wait, so frameset is basically htmx?
| jmg_ wrote:
| 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.
| tredre3 wrote:
| 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.
| hbn wrote:
| Hey, we may be spinning in circles, but at least the websites
| consistently get slower over the years
| recursivedoubts wrote:
| always has been (hx-target was taken directly from the target
| attribute on anchors, innerHTML as the default swap taken from
| how iframes behave)
| dugmartin wrote:
| 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?
| that_guy_iain wrote:
| 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.
| taco_emoji wrote:
| Yeah it's a magic value. No shit? Was anyone really confused by
| this?
| graypegg wrote:
| 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.
| graypegg wrote:
| 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.
| snarkyturtle wrote:
| Isn't that the use-case for Micro Frontend Architecture? I've
| always viewed it as a second-coming of Frames. https://micro-
| frontends.org/
| lelandfe wrote:
| 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.
| alabastervlog wrote:
| HTML has a bunch of good stuff in it that'd replace the need
| for so much heavy and slow and non-native-feeling javascript if
| that'd just been improved. Lots of it's now rarely used because
| it sucks, but there's no good reason it has to suck. It's like
| whole sections of the spec just got abandoned around 2005, but
| the _need_ is still there.
| tombert wrote:
| The <blink> tag needs to make a comeback; I'm so tired of
| having to write my own JavaScript to get annoying flashy
| text.
|
| In all seriousness, I'm not entirely sure _why_ so many
| features in HTML are eschewed in favor of a slow JS mess. It
| doesn 't feel like bolting on an entire relatively-slow
| programming language is going to make your code _more_
| organized than a relatively easy to use tag.
| alabastervlog wrote:
| We could have datasource-backed tables and list elements.
| Built-in. Sorting for most purposes, "for free", and more
| with simple and light JS hooks for sort functions. Frames
| that actually work as useful UI elements. "Basic auth"
| screens that look and function well enough for lots of
| purposes. Something like "Apple Pay" or other external
| payment systems but built into the browser, replacing
| _stupid_ amounts of time spent writing yet another payment
| form (and usually fucking it up in several ways)
|
| But no.
| lelandfe wrote:
| > 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>
|
| https://jsfiddle.net/xrkLt2nz/
| tombert wrote:
| 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!
| lelandfe wrote:
| Definitely. Much less the many several users who yet lack
| CSS support in their preferred browser.
| tombert wrote:
| The good news is that <marquee> still works in the latest
| Firefox. No need for any new-fangled animation libraries
| for me.
| Sohcahtoa82 wrote:
| If front-end devs would stop reinventing things using JS
| that can be done in CSS, I'd be so happy.
| wruza wrote:
| Why?
| thesuitonym wrote:
| Not the GP, but my two cents: because JS sucks and CSS
| can already do it.
| jonathanhefner wrote:
| Agreed! There is a proposal for something like that in the
| WHATWG repo: https://github.com/whatwg/html/issues/8538
| jodydonetti wrote:
| What are you missing by using iframes (still standard,
| supported, working) + css for layouting that old school frames
| would give you?
| graypegg wrote:
| 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)
| evantbyrne wrote:
| 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
| earthboundkid wrote:
| 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.
| recursivedoubts wrote:
| Alex and (to a much lesser extent) I are trying to get a
| modernized version into the HTML spec:
|
| https://github.com/alexpetros/triptych
| notpushkin wrote:
| You can use target with iframes: https://jsfiddle.net/7szje2a9/
| muglug wrote:
| > P.S. Don't use <frameset>. It's deprecated in HTML5
|
| Tell that to the enterprise email scanning software my Fortune
| 500 company uses
| wicket wrote:
| 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. :)
| cubefox wrote:
| The last browser that did that was the infamous Internet
| Explorer 6.
| btown wrote:
| 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).
| cubefox wrote:
| 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.
| ZoomStop wrote:
| Site is giving me a 403, here is an Archive mirror:
| https://archive.ph/aDqv3
| paulirish wrote:
| 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.
| thesuitonym wrote:
| 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.
| rco8786 wrote:
| 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.
| cartoffal wrote:
| 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 :)
| mananaysiempre wrote:
| 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.
| wavemode wrote:
| The direct answer to your question is that the idea of
| "responsive" web design gradually took over when smartphones
| became popular. People liked the idea of not needing to create
| a separate mobile version of their frontend, and instead simply
| adjusting the styling and structure of the page in response to
| the size of the viewport. Tables were bad at this because you
| couldn't use CSS to arbitrarily move around the way a table is
| structured.
|
| (The funny thing is that, in modern browsers this is no longer
| true - you actually can use CSS to restructure table layouts
| now. But, the world has already moved on.)
|
| Though there's a broader answer, which is that generally as web
| design has modernized, so too have ideas of "semantic" markup.
| Semantically, table is supposed to be used to display data.
| HTML which is used for its proper semantic purpose is easier
| for screen readers, improving accessibility, and easier for
| search crawlers to make sense of the content, improving SEO. So
| a lot of old HTML tricks fell out of use when HTML5 started
| becoming popular.
| jayflux wrote:
| > The direct answer to your question is that the idea of
| "responsive" web design gradually took over when smartphones
| became popular. People liked the idea of not needing to
| create a separate mobile version of their frontend, and
| instead simply adjusting the styling and structure of the
| page in response to the size of the viewport.
|
| Table-based layout was already falling out of favour before
| this happened. Even when you had fixed sites that were
| predominantly desktop, divs and spans (coupled with CSS) made
| life a lot easier to put things where you wanted them and lay
| out a site faster. It was also cleaner when reading the
| markup.
|
| From what I remember, the move away from tables happened
| around the same time external CSS took off and you could
| partition your site with reusable styling instead of
| framesets or tables.
|
| Responsive design then sped up the process a few years later.
| wavemode wrote:
| "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.
| acjohnson55 wrote:
| 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.
| bazoom42 wrote:
| Framesets were a bad idea because they didn't work well with
| links, bookmarks, and search engines. Tables are fine when used
| correctly though.
| jwsteigerwalt wrote:
| Love this. Just when you thought you knew all the reserved words,
| you learn another one.
| mannyv wrote:
| name collisions.
| knorker wrote:
| 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.
| hollerith wrote:
| 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.
| encom wrote:
| 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.
| kilna wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-24 23:00 UTC)