Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

_new considered harmful

by jZed (Prior)
on Oct 01, 2006 at 17:38 UTC ( [id://575798]=monkdiscuss: print w/replies, xml ) Need Help??

Most modern browsers allow you to do some combination of mouse clicks to open a link in either the current window, a new window, or a new tab. When you set up a page for yourself, you have a fourth option to send links to a frame in the current window. However, links that force a _new or _blank target prevent you from opening in the current window or in a same-page frame. In our beloved fullpage chat, the feeds for privatemessages, showotherusers, and showchatmessages all hard code a base target of "_new". The feed for just_search OTOH allows you to specify the base target with a formtarget parameter.

Why do I care? Well, I'm modifying tye's version of fullpage chat to work like my old Zedulator. You can grab the new Zedulator here. I have the search form go to a frame under the chat frame so I can do searches onsite or using google:// etc. and see the result pages in the same window/tab as the chat. I also have small but expandable frames for private messages and other users. What I'd like to do is be able to have the chat, private messages, and other user links open in the same bottom frame that the search results do. That way I can visit a link someone suggests in the cb without leaving the cb.

What would it take to fix this (if you agree it needs fixing)?

  1. The easiest would be to hardcode a window/frame name like "pm_display". If the base target were that instead of "_new", then users of fullpage chat would get the same behaviour as now - it would open in a new tab/window depending on mouse click; while users of Zedulator and other fullpage chat derivatives could create a frame called "pm_display" and the links would then redirect there.
  2. A more complete but more labor intensive approach would be to make privatemessages, showotherusers, and showchatmessages behave the way just_search does and accept a target parameter.

So, which do you prefer: 1) hardcode a specific frame/window name or 2) add parameters to the existing feeds or 3) nah, leave it like it is.

I'm pretty sure I could implement #1 myself and could probably do #2 with some hints.

Replies are listed 'Best First'.
Re: _new considered harmful
by ikegami (Patriarch) on Oct 01, 2006 at 17:50 UTC

    If the base target were [something like "pm_display"] instead of "_new", then users of fullpage chat would get the same behaviour as now

    No, it wouldn't. If pm_planet was used for target, the first followed link will open a new window as if _new had been used, but the second followed would overwrite the window opened by the first link (if it's still open) instead of opening a new window.

    For example, if you click on each of the following without closing newly opened windows, you'll end up with 3 windows instead of the desired 4.
    <a href="?node_id=67275" target="_new"> (jZed's home node)
    <a href="?node_id=381608" target="_new"> (my home node)
    <a href="?node_id=67275" target="pm_display">
    <a href="?node_id=381608" target="pm_display">

    I *hate* windows overwritting each other. I've lost much this way.

    Update: By the way, _new is non-standard. _blank is the standard target to specify that "the user agent should load the designated document in a new, unnamed window."

      Yes, you're right, hardcoding "pm_display" would behave like _blank, not like _new. However if I (debian FF) middle-click on any of the four links you provided, they each open in separate new tabs, or if I control-click on any of the four of them, they each open in a separate new windows so that with the _new I can open anywhere except in the current window or in a frame while with pm_display I can open anywhere except the current window (and even there if the current window is in a frame name pm_display).

        I know there are ways around it. My point was that it's a dangerous default to overwrite a window one doesn't realize has been overwritten. ( If the current window gets overwritten, I'd just press back and middle-click the link. Overwritting another window, one that might (and likely, in my case) have been open for days, is bad. ) I vote against #1.

        By the way, you *can* open a targetted link in the current window. Just drag the link to the address bar.

Re: _new considered harmful
by jonadab (Parson) on Oct 02, 2006 at 11:49 UTC

    If your browser doesn't have an option to just plain ignore the target attribute, it should. (Firefox requires you to install an extension for this, but then again it requires that for a lot of important things, so if you use it you rapidly become accustomed to installing a lot of extensions.) IMO the target attribute shouldn't even exist in modern markup, only in legacy HTML Frameset stuff that hopefully nobody is still using for new pages at this point. The whole point of the target attribute was to let the page creator make decisions that would normally be up to the user, so like toolbar=no and its ilk, it should hopefully go entirely the way of the dodo as browsers start to mature a bit and treat the user, rather than the web page author, as their primary target (ha) audience.

    Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.

      I agree with most of what you say except for the idea that frames should be relegated to the garbage heap of history. Sure they were horribly misused and before browsers learned to make "back" work correctly in frames they were a nightmare. Frames still do two things that can not be accomplished as well with other browser features and which happen to be critical for the kind of modification of fullpage chat I am working on: tiling and transclusion.

      I am a big fan of a combined tabbed-tiling approach, I use pekwm window manager and my desktop is a mixture of tabs, tiling, and restricted but occasional floating windows. Tiling provides the ability to have a large number of things available in a window while maintainng the ability to flexibly adjust the space alloted for each thing. CSS can do some things similar to tiling but until CSS matures, frames do tiling better.

      As for transclusion: AJAX, the hero of ancient Greece and modern buzzwordists, can do translusion of *local* content but for security reasons can not transclude *remote* content which is critical for apps like fullpage chat and Zedulator. I tried making Zedulator using CSS and iFrames rather than frames and it was moderately successful, but nowhere near as easily maintaniable or usable as the frames version.

      Take Zedulator for a spin and I think you'll see what it accomplishes with frames: Hide and display the private messages and other users as needed; split the main screen between chat and browsing or, when needed make the screen all chat or all browsing; drag a link from the chat to the search and see it appear in the browse area ...

        I didn't mean to imply that browsers shouldn't have frames. Implemented correctly, I would view browser frames as either an alternative to or a complement to browser tabs and/or multiple browser windows. I'm not against frames in general, and indeed use them extensively in Emacs (though there they are called "windows", and windows are called "frames"). I have also used a window manager that allowed the screen to be divided up in this fashion, and although it's not my cup of tea, it does have some advantages. I might have liked it better if dialog boxes were handled differently somehow, and if I'd had Gimp 2 with the dialogs all docked under the toolbox, rather than the Gimp 1.x that I had at the time. But I still would probably have ended up back with a more traditional window manager, because I like to let the bottom edges of certain windows (e.g., log tailers or download progress bars) show behind/under what I'm currently doing, so that I can notice if there are significant changes at the bottom. Still, as I said, the principle of split windows is sound, and I use it very extensively in Emacs.

        However, I don't think it is the webmaster's business which window, tab, frame, or other UI element I choose to use to view any given web page. Fundamentally that should ALWAYS be up to the user, not the content creator. There's no legitimate reason for document markup to specify that, ever. I could *maybe* live with allowing stylesheets to _suggest_ a particular arrangement, but only if the user can set his browser to ignore such suggestions, which I would promptly do.

        This is, incidentally, a more hardline position than I used to take on frames. I once believed that frames were merely overused, and that there might be some things for which frames might actually be needed. But after a decade or so I've yet to see a website that actually needs to specify frame layouts to work correctly. Every time someone tries to point one out to me, I can't help but see ways in which the user might like to arrange things differently, and ways in which fundamentally the same thing (or the important part, at any rate) could be accomplished without frames.

        The way that the fullpage chat uses frames has always annoyed me. Not only is it unnecessary, but the lack of reload (of the comments) on submit causes a very annoying lag between typing something and seeing it appear. And between times, when you're just sitting there reading, it reloads the existing information every few seconds, interrupting the reading process, which in these days of DOM manipulation and asynchronous retrieval is needless, because the new stuff could just be appended to what is already there. In fact, I'd say it's a perfect example of unwarranted frame (ab)use.

        Websites should not be specifying frame layouts. It was a bad idea when Netscape first came up with it, and it hasn't improved with age. The sooner web browsers stop supporting it, the better. I realize this is in some ways a narrow-minded opinion, but that doesn't keep it from being right.

        Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.
Re: _new considered harmful
by wazoox (Prior) on Oct 02, 2006 at 19:54 UTC

    _blank is certainly harmful, it's not even valid XHTML after all. I personnaly hate _blank : I'm perfectly able to open a link in a new tab or window if that's what I want. And actually, I hardly ever want to open a new window anyway.

      Update: Oh! I think you meant "_new is certainly harmful", instead of "_blank is certainly harmful". Ignore the rest of this post if so.

      Why do you say it's not valid XHTML? According to the XHTML DTD, the value of target is a NMTOKEN. _blank is a valid NMTOKEN.

      Nmtoken ::= (NameChar)+ NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | +Extender

      Futhermore, it's not list as a difference with HTML 4, and HTML 4 explicitely lists _blank as a valid frame target name. (_new, on the other hand, is not listed.)

        Check with the w3c validator : any xhtml page containing
        <a href="foo" target="_blank">
        will be dubbed as non valid XHTML strict. Well, actually that's the "target" attribute that's invalid, not "_blank".

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://575798]
Approved by ikegami
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (2)
As of 2024-07-14 02:28 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.