-
☆ A M B ☆
- 24,524 Posts
Well, links in the forums here open in a new window. But links from the top menu don’t.
-
MODX Staff
- 2,502 Posts
The thing about target="_blank" is that at the time when it was most used in the late 90s it was to "solve" the apparent issue of clients being told to have interesting links on their site crossed with the Marketing departments’s false logic of how to make sites sticky or creating dead ends for eyeballs.
In an era of dominant fullscreen browsing in browsers that didn’t have tabs, spawning new windows didn’t look like a new window or tab was spawned but the link went to the new page but now the backbutton was disabled and user testing showed that users got frustrated with apparently broken sites that didn’t let them go back to where they were and then would close the entire application instead of the foreground window when done. This defeated the purpose of spawning the new window entirely since only those who knew what was going on would end up back on the originating site.
Today where we have large monitors and tabbed browsers and better content using things like target="_blank" have likely a diminished negative impact on the user experience. Users are more sophisticated and site builders are also past the idea that you can’t let users leave their site.
I’ve been on the dogmatic side of webstandards and moved into a more pragmatic mindset. I build sites and pages with webstandards but break rules when it makes sense for the user or application. 100% validity in HTML and CSS doesn’t make better UX or better browser compatibility because browsers are inconsistent with implementation or interpretation of the specs or the spec has limitations or holes for use cases. Beyond that knowing what will make for better sales results for clients is equally important so when I heard a client say, "I want to put a bunch of links to other sites but I want them to open in a new window because I don’t want them to leave my site." I would tell discuss in depth about how to make their site better, be valuable to the people they want as customers and limit unnecessary exits from the site. Content strategy and site goals are married to the implementation of our markup doing one well and ignoring the others just doesn’t work.
Author of zero books. Formerly of many strange things. Pairs well with meats. Conversations are magical experiences. He's dangerous around code but a markup
magician.
Blog ✦
Twitter ✦
LinkedIn ✦
GitHub
Good stuff Jay.
As you touched on earlier I think wysiwyg programs like the older Drreamweaver and GoLive had a big role in making that practice popular. It was a feature that could be easily programmed into these software titles via pulldown menus. (on a side note I wonder how many MODXers use Dreamweaver these days? I own it but all the menus and whatnot put me off completely.)
The other thing is screen size. On larger displays having an extra page pop up is OK. On smaller screens like laptops having extra open pages can be annoying: sometimes users don’t even know they were there or there is frustration with having to hide the top page just to see the lower pages on your display. These days most people are comfortable with browser tabs and right clicking to open fresh pages if they so desire.
On the doctype front it seems like we were using Strict XHTML to ensure we had "tight, lean, valid code" that would give us a better chance of having consistent rendering across more browsers and devices. Or at least that is what some of the hype led us to believe. With the new html5 and whatnot things seem more looser now? Certainly the longed for <video> tag is proving to be a confusing mess with the major players going in different directions with different self serving motives. Do we want Flash technology any more? Do we want one codec that plays on everything? Or do we want a codec that presents video content with the highest quality available? Do we still want to force users to download plugins? Its all confusing. Time will tell how well Apple, Adobe, Google and others will play together on this.
If the document is served with a text/html MIME type, it is treated as HTML. If it is served as application/xhtml+xml or text/xml, it gets treated as XHTML. So if you use doctype XHTML and MIME type is text/html it is actually parsed by the html-parser. XHTML as text/html is html4-strict minus some (depricated) elements. A disadvantage of XML so also XHTML is draconian error handling. Malformed XML is error. This is partly why html5 is here. Html5 also defines how errors should be handled by the browser.
UI /UX designer + bit of Front-End Developer. Getting around with MODx Revolution