|
in reply to Re: Deprecate target attribute in <a> tag
in thread Deprecate target attribute in <a> tag
Howdy!
The specific motivation was its use in a node this morning. The
node was considered and janitored, removing the target attributes.
My personal take is that any link that is meant to forcibly open
a new window is b0rken, in that it's for *me* to decide if I want
that link to open in a new window or not. Similarly, links that
don't work when they are forcibly opened into a new tab/window
are equally b0rken.
One can fairly ask what constructive purpose that attribute serves.
|
Re^3: Deprecate target attribute in <a> tag
by tye (Sage) on Sep 16, 2005 at 19:23 UTC
|
The node was considered and janitored, removing the target attributes.
And it seemed a bit abusive, outside of the scope of the janitorial mandate. I don't think janitors should be mucking with such trivialities of other people's compositions. Janitorial intervention should require something at least a little more dire.
A better choice would have been to /msg the author, IMO.
| [reply] |
|
|
Howdy!
I did /msg the author, but I considered it after being encouraged to do
so in conversation in the ChatterBox. I certainly did not just jump in
with a consideration, and this discussion is an outcome of conversation
with marto as well. The author was not averse to editing, and probably
would have done what the janitors did had I not considered it.
| [reply] |
|
|
Just FYI, I wasn't blaming you; I saw the conversation, though not while it was taking place. I'm glad the author didn't mind the update (and, had they minded, they would have just changed it back -- which is part of why this isn't an appropriate action for janitors, IMO).
| [reply] |
Re^3: Deprecate target attribute in <a> tag
by sauoq (Abbot) on Sep 16, 2005 at 22:11 UTC
|
My personal take is that any link that is meant to forcibly open a new window is b0rken, in that it's for *me* to decide if I want that link to open in a new window or not.
The link isn't b0rked, your browser is. HTML can't "forcibly" open a new window on your desktop. Your consent must be given. If you choose to use a browser that doesn't allow you to control that, then you are implicitly giving your consent.
I'm going to take a wild guess and assume that you surf sites other than Perl Monks. Are you going to petition all of them to remove the "target" attribute from their links?
The fact is that the target attribute is useful. And it isn't going anywhere. If you don't like it, you can avoid its effects... but that's an itch you have to scratch yourself.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
Howdy!
I didn't say "broken"; I said "b0rked". It is unfortunate that
browser-level control of this behavior is not widespread or standard.
The choice of a browser involves tradeoffs. You cannot infer acceptance
of the consequences of abusive web coding from the choice of browsers.
At the very least, you don't get to tell me it's all my fault and that
I shouldn't complain.
Now, I have been known to make my displeasure known to other web sites
at their use of target=_blank on links. This case was the first time I
recall running into that usage on PM, and it was not a site function,
but a user created link.
I have yet to see a cogent argument why the target attribute is useful
on PM. I have seen discussion of how it can be useful in a framed page,
but that is not relevant here, nor to those discussions speak to setting
it to _blank. I really dislike web sites that think they should control
my browser by opening windows when I click links. It's popups all over
again. I do have my browser configured to give me a visual cue that a
link will try to open a new window, but that does not excuse the abuse
of that feature.
My request was confined to its use here on PM.
| [reply] |
|
|
I didn't say "broken"; I said "b0rked".
Actually, you said, "b0rken." Twice. And I said, "b0rked." Not that this is particularly relevant...
It is unfortunate that browser-level control of this behavior is not widespread or standard.
I wholeheartedly agree.
The choice of a browser involves tradeoffs. You cannot infer acceptance of the consequences of abusive web coding from the choice of browsers.
It isn't "abusive web coding." There arguably is no such thing so long as the code you write adheres to the standard. The onus is on the browser to provide acceptable behavior. In the case of target="_blank" the HTML 4.01 spec states only that the browser "should load the designated document in a new, unnamed window."¹ It is not a requirement that the browser do so to maintain compliance. So, yes, when you can choose between more than one compliant browsers, some which behave as you wish and some which don't, then your is choice is at fault.
But, all of that said, I'm not inferring your acceptance at all. I'm only suggesting that you are barking up the wrong tree. In other words, go complain to your friendly neighborhood browser developers. Or write a browser yourself that behaves the way you want. Or join the W3C and work to get the standard changed. Complaining because PM is allowing perfectly acceptable HTML is just misplaced irritation.
I really dislike web sites that think they should control my browser by opening windows when I click links.
Well, you can dislike a site for whatever reasons you choose. I dislike animated gifs. If I were to say that your way, I'd complain, "I really dislike web sites that think they should control my browser by displaying crappy animations when I open a page." But, the point continues to be that, if the website is controlling our browsers, it's because our browsers have let themselves be controlled. In reality, websites can't really do more than provide hints.
Fortunately for me, extensions for FireFox, my favored browser, allow me to turn off image animations as well as handle target="_blank" the way I want to handle it. So, I've got no complaints. Well... that's not true. I have other complaints now. For instance, it drives me batty that FireFox makes a separate request when I want to view source. That's a real pain when debugging issues on pages generated from POST requests.
1. The use of the word "should" here is as defined in RFC2119 Key words for use in RFCs to Indicate Requirement Levels.3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
-sauoq
"My two cents aren't worth a dime.";
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
|
|
|
