Hacker News new | ask | show | jobs
by n_plus_1_acc 484 days ago
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.
4 comments

In other answer they link to the original specification [1], and it says that names must start with a letter, so anything preceded by "_" cannot be a frame name.

[1] https://www.w3.org/TR/WD-frames-970331#frame

This one sentence is better than the original article.
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>

Thanks
Yeah it’s not a great explanation.

To me (and I’m of the era they’re describing so I used it a lot) it’s simply that _blank is a reserved keyword that means open the link in a new, unnamed window.

Other reserved keywords for “target” are _self (default value), _parent, and _top.

https://www.w3schools.com/TAgs/att_a_target.asp

Also worth noting that "_new" is NOT a reserved keyword, but it is sometimes mistakenly used instead of "_blank". Which can lead to funny behavior if you are visiting 2 or more sites making this mistake, as the links could then start opening in windows that were initially opened by the other site. Or least that's how it was back in the days of popup windows, before tabs and popup blockers became the norm.
Not just weird behavior, but possible security issues. Browsers now automatically add a rel="noopener" to links that target _blank to prevent the opened site from gaining full access to your javascript object. Targeting _new does not do this unless you explicity add the rel="noopener" yourself.

https://github.com/whatwg/html/issues/4078 https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

Nobody gets "full access" to your "javascript object"—whatever that even means; pages from different origins will still run into exceptions when trying to diddle the opener. There is a small, well-known set of (safe) properties that are excluded from the restrictions—like location. But the noopener behavior, by making opener null, does stop other pages from setting even opener.location, which could ordinarily be used to programmatically send the user to another page.
But why was _name the naming syntax for reserved keywords, specifically?
I suspect, when the specification was created, "_" was already popular for private/reserved members in many programming languages. In C++, for instance, you can only start an identifier with a letter or an underscore. So it seems like a natural, intuitive choice. Whether anyone can find any corroborating evidence would be interesting.
Probably inspired by C and C++ which reserve names starting with an underscore for the implementation (more precisely, they reserve names starting with `_[_A-Z]` everywhere, and all other names starting with `_` in the global scope only).
I nice factoid: in Erlang, `_` if functional. It means "I don't care about this variable". When pattern matching you can put `_` to not bind value in function or pattern to anything or prepend a variable with `_` to tell compiler that you won't be using it, but it's there for "documentation" purposes. For example `[A|_]=List` will extract first element of list into A and ignore rest of list. Underscore has some other uses too.
Yes, many languages use `_` as a placeholder name, and at least in Rust any name starting with `_` is considered intentionally unused.
Aside: many IRC clients would auto-append _ when registering a nick if the desired nick was already registered. Why _? Who knows.
>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."

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.
I'm guessing it was possible before the window-opening behaviour came in (unless it was always there from the genesis of frameset), but it was assumed that the underscore prefixed version would be less likely to conflict with existing code than without.

I'd be interested to hear either a citation proving or disproving that guess though.

Frame names must start with an alphanumerical character.