Good idea breaking this out -- it was turning into a threadjack.
<henghist>
Threadjack, THREADJACK, THREADJACK!!!, You're all gonna die... die...</henghist>
DOSGuy wrote:I can see that you're a purist, whereas I try to be practical, which sometimes means breaking the rules. The Strict standard is based on a philosophy that everything to do with style should be handled by CSS. That's great, but what if I don't want to use CSS?
Then you aren't designing in a modern manner for modern browsers using modern techniques, with a mind to graceful degradation to less capable devices by way of progressive enhancement.
Later on you asked about the first of those, I'm going to cover that up front.
Graceful degradation means "how well does the site work as more advanced technologies disappear" -- does the site fall apart if scripting is disabled/unavailable. How does it handle images being turned off while CSS is still on -- how does it handle CSS not being present at all if all presentation is stripped from the markup.
Naturally it's impossible to have it perfect on all of those, but a lack of any technology above the base HTML should NOT get in the way of the user having access to the content.
(for example, this is where AJAX abuse for mimicking frame behaviors is a miserable /FAIL/)
The separation of presentation from content works to this -- you aren't supposed to choose tags based on their
default appearance, but for what they MEAN; since the default appearance is ENTIRELY left up to the user agent (browser).
Let me say that again, the default appearance of ALL HTML TAGS
is left ENTIRELY to the discretion of the user agent and is
NOT actually defined in the specification. There are recommendations and suggestion, but nothing that says ANY user agent "has to display it this way"... it's why the spec is filled to the brim with lots of "may", "can" and "could" -- but not a whole lot of "should" and "must".
NEVER assume the default appearance of a HTML tag is why you should use it!
This goes back to the POINT of HTML, device neutrality -- the ability to write a document that can customize itself to ANY device from the 22x21 display on a VIC-20 to a 132x66 per page daisy wheel print to a 2048x1536 24 bit 32" display. We got away from that in the late 90's with the browser wars -- HTML 3.2 and by extension transitional being bloated nonsense that was slapped together with little care for if it worked right on anything other than 640-1024 wide screen.
With the proliferation of devices ranging from 320x480 handhelds to 800x600 pads to 1920x1200 24" LCD's the 'need' for device neutrality is stronger than ever.
Now, that leaving it up to the user agent is WHY cross-browser coding can be a royal pain -- take INPUT as an example. IE treats it as a 'special' element that has em padding of which you have no control on top of whatever padding/width/height you set, and it ignores height using line-height instead. FF treats it as a 'special' element that has a fixed 4px padding over which you have no control... Opera treats them EXACTLY as if they were inline-block, giving you full control over it's padding and borders... while webkit browsers go nuts tacking all sorts of fancy presentation on them that craps all over trying to style a form with CSS.
... and ALL of them are valid by the specification since the appearance of a INPUT is NOT strictly defined -- this is true of EVERY tag; it's why you can't trust the default line-height, generally end up using resets to null margins and padding on block-level elements for cross-browser consistency, and a dozen other things that separate the "looks like something written for netscape in 1998" from "a professional layout".
Now, I mentioned "progressive enhancement" -- If you build your site with semantic markup so that the defaults for all browsers (including non-visual and search engines) know what things ARE, then slowly add your enhancements by creating the layout with CSS, adding enhancements with scripting (without supplanting functionality) you automatically get "graceful degradation".
It's why my site building approach is to semantically mark up the content first, create the layout with CSS without images, then apply the desired images. At each point I may end up having to add some extra DIV or SPAN sandbags/wrappers for use on applying appearance, but I try to restrict that to 'semantically neutral' tags and only add them as needed so as not to change the meaning of the content.
It's also why the garbage churned out by PSD jockeys are usually a miserable /FAIL/ -- Photoshop and other paint programs should be used at the END of the process, not the start. People visit websites for the content, not the goofy images and gee ain't it neat animated garbage hung around it. (Which in most cases ends up the equivalent of polishing a turd)
DOSGuy wrote:That's why the Transitional standard exists.
Transitional exists for supporting old/outdated/not recommended for use methodologies on old websites, not for creating anything new after 1998... It is there to 'transition' old coders from their old/sloppy habits into the new way of doing things.
<m.cole>
... and I quote:</m.cole>
This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.
... and since about 2004 onward, about when we stopped giving a flying fig about Nyetscape 4 is when it stopped being 'required'.
Even if Gecko is still just Nyetscape's sweetly retarded cousin about a great many things.
"Hello, my name is Firefox. Mozilla Firefox. My momma always said, Life is like a box of open source. You never know what you're gonna get." -- no joke, I consider FF the Forest Gump of web browsers. While IE is Ronald McDonald, Safari is Jessica Simpson, Chrome is a japanese loli idol singer, and Opera is Andy Dick.
DOSGuy wrote:Well, I can only say that I found it somewhere on W3C's site as recently as 2008 or 2009 (and no, it wasn't W3Schools, which I only learned about a few months ago). But even if it's not recommended any more, this is a perfect example of the conflict between purism and practicality. HTML is case insensitive, and using uppercase tag names make it easier for me to find them in my code (since I don't use an HTML editor that would highlight them for me). Who does my code need to satisfy? Browsers don't care either way, and uppercase works best for me, so I'm going to continue to use uppercase!
Invalid markup is invalid markup -- if you used more formatting you wouldn't need it; that and if you REALLY need that sort of behavior, isn't that what color syntax highlighting is for?
NOT that I use color highlighting -- the illegible acid trip drives me nuts and I'm not punctuation blind, but if you need to see the tags, use an editor with syntax highlighting.
DOSGuy wrote:XHTML is one of the languages that HTML 5 officially replaces. I'm surprised to see anyone advocating for XHTML at this point.
I'm still trying to figure out why anyone advocates HTML5 -- it's undoing a decade worth of progress by adding uselessly redundant tags (audio, video), pointless extra wrappers (like header) just to placate the people who place unneccessary div around their head
ing and menus, etc, etc...
I like the combination of XHTML and STRICT because the formatting rules end up a bit like Pascal in one regard... "It won't let you shoot yourself in the foot". Good code formatting habits and proper validation can prevent so many cross-browser mistakes from even cropping up. Too many developers will call such things "arbitrary" or "unneccessary"... or even "a waste of time" when such practices prevent you from spending hours debugging the simplest of mistakes... As Patton said, a ounce of sweat now saves a gallon of blood later.
Hell, even my commenting style is crafted to avoid rendering errors. (That's not a joke, yes, COMMENTS can make IE and FF render elements wrong!)
That's actually one of my issues with the disaster known as HTML 5, it's so loose a specification that any sort of 'validation' ends up meaningless -- it lets people vomit up code any-old-way like the pinnacle of 1998 bloated inefficient lazyness. It's setting itself up to be the C++ of web technologies -- and no that's not a compliment.
Though there's nothing really wrong with HTML 4.01, so long as you're working in HTML 4.01 and not HTML 3.2 with a tranny doctype slapped on it.
DOSGuy wrote:FFA0A0 isn't a color, it's a class!
I realize that, but that's a presentational class name -- and as such needlessly vague as you didn't say what it is or WHY you are assigning it that markup. Net change ZERO from just not bothering to use CSS in the first place and vomiting up HTML 3.2.
ONE of the advantages of separation of presentation from content and using CSS in the first place is being able to total reskin WITHOUT changing the markup. Using classes that say what the appearance is means editing the HTML to change the appearance -- DEFEATING THE POINT of CSS.
DOSGuy wrote:but there's no rule against that!
Just because there's no rule doesn't make it good practice -- when I see classes like "colorRed", "left", "centered" -- I always cringe; you might as well go back to using the deprecated font, center and align values at that point, as it misses the POINT of HTML and CSS. You should be saying WHY it's recieving that styling as in "what is the element".
HTML is for saying what things ARE,
NOT how they are going to appear.
DOSGuy wrote:The "width: 20%" is there because this is the only instance of that class that needs its width defined at 20%. Sure, I could have created a subclass for this special case to avoid using in-line CSS, but it seemed like more work to do it that way. While the difference in coding time is negligible in this case, this is an example of my programming philosophy: I usually won't create more work for myself in order to conform to some philosophical rule. If "the right way" is also "the hard way", is it really the right way?
... and when that 20% is inappropriate for when you make your handheld.css? When you don't want that wasting the users ink when they hit print?
Which reminds me:
<LINK rel="stylesheet" type="text/css" href="style.css">
Where's your media declaration?
DOSGuy wrote:Seriously? %/EM?! Wow. Nope, I don't think I'm going to bother with that crap. PT has been the standard way of defining fonts since... whenever fonts were invented. If a browser can't properly render PT, it's time to get a new browser!
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20081103/C14
Web content accessibility guidelines!
Mind you, on that one you sound EXACTLY like I did six years ago before I embraced strict, separation of presentation from content, etc, etc... Back when I was arguing in favor of pt over %/em it was because it was (and still is) the only font metric that actually obeys the system metric (dpi setting) in Windows... But the accessibility guidelines exist for a reason; where's the harm in following them?
Especially since they are incredibly simple to use and actually work...
DOSGuy wrote:
This was a recent experiment in using JavaScript's ability to preload images to get the genre icons in the user's browser cache before they hover over the link. It's a hack that has been on the chopping block since it was implemented, but I've been busy every weekend since I wrote it. I already know how I'm going to fix it, but I've been too busy with trips and death and related obligations to get to it. That mess will be going away this weekend. You happend to pick the only part of the site that's in a beta stage for your example.
Problem is, MOST of what I said is unrelated to the images... The other menu dropdowns contain 80-90% of the same flaws apart from the inlined effects.
DOSGuy wrote:As for the icons, they serve dual purposes. Not everyone knows what these genre names refer to; and not everyone who visits the site speaks English. These graphical representations are about being inclusive.
Probably why I'd class them, and use something like 16x16 or 24x24 icons next to them instead... Though as with many images you run the risk of "what the *** does that image mean?" -- thankfully you avoid that by keeping the text.
Drives me nuts when things have just icons I can't figure out what they mean... but I'm the guy who'll take a menu over a toolbar any day.
deathshadow wrote:Tables exist for TABULAR data -- like a spreadsheet or database output, not for just 'making columns'. I think a LOT of the problems you may have been having was your not using semantic markup and practicing separation of presentation from content; much less the reliance upon things that have NO PLACE in modern markup like ALIGN, VALIGN, CENTER, FONT, STYLE on EVERY element...
DOSGuy wrote:The LEM was designed to land on the Moon, but the crew of Apollo 13 used it to get home. Tables aren't supposed to be used for layout, but they can be! I don't disagree with you, but the site has an infinite mandate with finite development time. Visitors never stop requesting new games, and their requests are always top priority unless something on the site is broken. Reverting to tables got the job done in the least amount of time, and converting the layout back to CSS hasn't made it back to the top of the priority list in the short time that has passed since I re-introduced the left-side menu. I'll try to fix it this weekend.
It's just not something you should get in the habit of -- though if there are visual effects (like true equal height columns) you want to achieve I'm right there with you on retaining the tables. Unlike many I'm not completely anti-table; there are people who refuse to even use them on obviously tabular data; take a look at the default skin for vBulletin 4 if you want to see the worst tag abuse to avoid using tables ever.
(or better, the forum skin at Digital Point -- I stopped going there because of the 2 megabyte page-loads)
DOSGuy wrote:That's another practical vs. philosophical issue. My recollection is that I didn't want either the blank line above or below the heading when I designed the menu, so I went with the STRONG tag. Of course, I could have overridden the default behavior of the heading tag to remove the blank line that I didn't want, but if you have to override the default behaviour of a tag, are you really using the right tag?
If you are even THINKING about the default appearance of a tag instead of it's semantic meaning, you are using the wrong tags! What does it MEAN, not "what is it's default appearance in my favorite pet browser". That's going to end up meaningless to screen readers, meaningless to search engines, meaningless on less capable browsers like DosLYNX and Arachne...
The appearance of a HTML tag
is not why you should be choosing it!!!
Never was -- the browser wars got us away from that; CSS lets us drag people kicking and screaming back to it improving accessibility and making for better/cleaner sites. It's why TBL invented HTML, so that a hyperlinked document could be marked up to say what things are, allowing the user agent to best determine how to show it in relation to the device's capabilities. We got away from that in the late 90's, but were able to get back on track with CSS, and media types -- and now CSS3 is bringing media queries to further let us customize content.
DOSGuy wrote:Since I don't necessarily want it to be emphasized by a browser for the visually impaired, I probably should have used <B> instead of <STRONG>, but I've gotten out of the habit of using <B> tags. The side menu has undergone a number of revisions since I created it, so maybe a header tag would work now, but it didn't at the time.
Each has it's own meaning, or lack of meaning... Though at least you don't think B and I are deprecated (I still come across people who think that). Neither actually says what the element IS -- it's a heading... it's obviously a heading, so you use the heading tag that implies the proper meaning to the content.
Not everything is media="screen" on a desktop computer. That's HTML 3.2 thinking.
DOSGuy wrote:I had never thought about caching as a benefit of an external style sheet.
That's one of the major reasons for using it -- you can often save bandwidth by using more CSS than it saves you in HTML, the moment your average page-views per user breaks 2 pages. CSS file that's used across multiple pages on a site ends up cached, so you can use less markup and faster page loads.
It also can help pre-cache sub page information... A lot of developers go nuts breaking up 'unique sub-page values' into their own separate external CSS files, when if they spent the *OH NOES* two to four k on putting it in their main stylesheet, their site would 'feel' more responsive to the end user because all that information is already in the cache when they get to that page.
DOSGuy wrote:I taught myself HTML/CSS/Javascript/PHP/SQL, so I've never had a teacher to explain the WHYs of web design to me.
I've been a teacher for many... A LOT of your conclusions show that you've not grasped a number of the concepts... though that's not entirely your fault. There's a lot of web rot and just plain bad/outdated advice out there as many developers never got out of the 90's... Which is oddly enough who HTML 5 seems to be for -- it's certainly not for anyone who 'got it' or wants clean minimalist coding practices with concern for cross-browser and cross-platform support.
DOSGuy wrote:What is graceful degradation
Covered up above, but to recap: The ability for the code of a page to still result in a attractive useful page if certain technologies and/or capabilites go 'missing', are 'blocked' or otherwise unavailable.
DOSGuy wrote:and what the heck is a gilder-levin?
Gilder-Levin image replacement -- a technique for placing a presentational image (which has no business being in the markup; site logo's for example). You use a dummy empty element like SPAN or B and APO (absolute position) it over the text hiding it. Images off, the nicely styled text appears. When CSS3 (or should I say CSS 2.1) becomes real world deployable (I figure sometime around 2020 at the rate things are going) we'll even be able to get rid of the extra span by using :after and generated content instead.
Go to this page of mine:
http://www.ewiusb.com
In either Opera or FF with the web dev toolbar installed and turn off images. Styled text and background-colors roughly approximating the images appear. This is great for people in places like Coos County NH or the Dakota's where 33.6 dialup is a good day, or in places like say... Canada where you are stuck on a metered data plans. Sites that let you disable images and still be useful end up a godsend.
When I'm at the local college doing research or stuffing my face at Panera Bread, it's one of the first things I do in my browser since Wireless at those types of places is always over saturated.
There are many common CSS layout techniques like Gilder-Levin -- Sliding doors, even my own "Eight Corners of the World Under One Roof"
DOSGuy wrote:Of course you're right that an H4 should follow an H1, H2, and H3, but not every page on the site needs headers of those levels. The hierarchical intention of heading tags is a legacy of Word documents that isn't always relevant on the visual web.
Since HTML was created NOT for word documents, that statement makes little or no sense. EVERY page can have sensible logical heading orders... The kicker here though is what you had as a H4 isn't even the start of a new section, it's the page FOOTER/DISCLAIMER.
DOSGuy wrote:There are entire pages on this site (notably the search pages) that have no text other than links.
... and anywhere on the page do you say what those links ARE?
DOSGuy wrote:While the site does have a few articles, it's mostly a delivery system for downloads and online gameplay.
Which can still have headings like what game is being played, what file you want to download, what category the user is looking at...
DOSGuy wrote:The H4 is there because it produced bold text at the size I wanted
Which is part of why it's wrong. You chose it for presentational reasons.
DOSGuy wrote:Still, I dislike doing more work in the name of conformity to mostly arbitrary conventions.
... it's not arbitrary if you think something other than 1024x768 Screen only.
Usually when people think something is 'arbitrary' and complain about 'conformity' it's because somewhere along the way they failed to grasp one of the fundementals used to create said conventions. It's not like they were pulling rabbits out of their backside when they came up with this stuff.
DOSGuy wrote:In this case, I'll justify breaking my programming philosophy with the possibility that it might confuse a browser for the visually impaired, as that's the only reason I can think of for a browser to use heading tags to determine the "hierarchy" of a web page.
^K navigation in webkit, W/S navigation in Opera, handheld header navigation, screen readers, search engines... it's a big long list.
DOSGuy wrote:As far as I'm concerned, the entire concept of a web page having a hierarchy died with Web 1.0. Web 2.0 doesn't require text
Oooph... Here's a tip, taking technical advice from Forbes is like taking financial advice from Popular Electronics... Sorry, the mere USE of the term "web 2.0" goes into "meaningless buzzword" territory. You really should avoid using that terminology as it's been considered something the "ignorant" use to describe the web for the better part of a year after the term was coined. The only people who use that anymore are suits who don't know any better.
The majority of web content IS text -- there's no getting around that. Saying what that text is -- a heading, a list, a paragraph allows you to convey that content more efficiently/effectively to more users.
DOSGuy wrote:so the concept of a hierarchical structure to a text-filled web page is rapidly becoming obsolete.
Wow... just... wow... Like... I lack the words.
DOSGuy wrote:At this point the header tags are a shortcut for combining the <P> and <B> tags, otherwise they should have been deprecated by now.
That statement right there shows you failed to grasp HTML's purpose... You'd REALLY hate HTML 5 with it's new section, header, and nav tags.
DOSGuy wrote:Of course I'm not going to use lists! If I use lists, I'll get bullets unless I use CSS to specify that I don't want them. If you have to overridge a tag's default behavior to change something this fundamental, use a different tag! Lists are for creating bullets. If you don't want bullets, don't make a list.
Lists are for marking up LISTS -- the default appearance has NOTHING to do with that which is why 99.99% of MODERN websties use LISTS for their main menus and why it is the advocated method for building menus by the W3C. Many user agents (handheld, screen reader) can leverage those lists into something easier to manage/navigate.
Semantic markup, say what things ARE. If you have a list of choices, mark them up as a list. If you are thinking about the default appearance of the tags, you are missing the point of HTML!
DOSGuy wrote:And yes, I'm misusing the fieldset tag to create a rounded border around a group of links that aren't part of the form. Jim Lovell misused the LEM to get back to Earth. I could use CSS to recreate the effect that I get from fieldset, but why should I have to? I don't care what the tag was designed to do, I care what it can do! One man's bad form is another man's thinking outside the box.
... and in the process flushing accessibility down the toilet. Again, it's not just about how it appears to "screen".
DOSGuy wrote:That's a very cool formula. I think you'll need to adjust it going forward as the web becomes more visual and less texty. DOS gave way to Windows, and iPhones are taking over the world. People want icons and quick navigation.
Notice I calculate an EXTREMELY generous 200 bytes for IMG/OBJECT tags, anything that isn't a content image belongs in the markup -- either way that stuff IS accounted for in my formula. The most I'd have to do for an adjustment is to say that OBJECT (and probably HTML 5's redundant audio/video tags) gets 400 bytes instead of 200 bytes -- on most websites that shouldn't have a significant impact.
DOSGuy wrote:I've been guilty of hanging onto Web 1.0, but I'm working to make the site more visual and functional lately. Swapping images for text links and static content for tabs that dynamically load content through JavaScript means more code per K of content. But that's not a bad thing!
It is when it destroys functionality -- and you're WAY behind the times as images for text links is SO '00's.
Joking aside, one of the whole reasons developers are so gaga over CSS3 is the ability to STOP using images in layouts for things like buttons, gradients and shadows... and to use things like web-fonts to RETAIN the content being text instead of bloating out the page with unneccessary images. Even the use of images for presentational borders/backgrounds using extra markup elements is on the chopping block thanks to CSS3's border-image. The past six years mainstream developers have been making huge strides and putting endless effort into RETAINING text on the page so that screen readers, handhelds, and less capable devices aren't left out in the cold.
DOSGuy wrote:Less content doesn't equal less substance.
Think about what you just said!!!
Content is the ONLY reason people visit websites in the first place... CONTENT FIRST is supposed to be the rally cry of web developers. (though admittedly the PSD jockeys have been crapping all over that!)
DOSGuy wrote:
This site has over 1000 downloads and hundreds of screenshots. It has little to say, but what little content there is is thoroughly fact-checked (by myself and by the community). If it stops looking like a page you would have visited with Netscape Navigator and starts looking more like the iOS, that will require more code, but it will be a worthwhile investment.
Shouldn't require that much more code... If handled properly. Even when it does, techniques like separation of presentation from content and minimalist semantic markup can result in lower bandwidth use by leveraging browser cache, and improves accessibility for most every access type.
DOSGuy wrote:And yes, I've snooped at enough source code that I can agree that most websites would use 100k of code to do what I've done in 26k. I may not always use the correct tag, but I don't often use multiple tags to accomplish what a single tag could do, and the site certainly isn't full of tags that do nothing (blasted DreamWeaver opens and closes tags around empty spaces!).
BWAHAA.. ok, so we're on the same page in that regard... You'd like something a friend of mine once said:
"The only thing you can learn from Dreamweaver is how not to build a website"
To which I replied "and the only thing you can learn from jQuery is how not to program javascript".
Recently I've expanded the dreamweaver statement to pretty much EVERY Adobe product.
DOSGuy wrote:
You're from an era when every byte and every clock cycle counted, and I respect that. How many people would even try to make a game that would work on an 8088 at this point? As a child of the 80s, I'm also from the era of limited resources (to a lesser extent), so I'm never intentionally wasteful. I pngout and optipng every screenshot and icon on the site. I never add a graphic or function without weighing the impact on bandwidth, even though I have unlimited bandwidth. I can no longer afford to design for dial-up users, but I won't make anyone's experience any slower than I have to.
Which is a GREAT attitude -- I wish more developers had it... though never rule out low bandwidth users; metered connections, bandwidth caps, pay as you go -- it's starting to look like a really bleak future. (you're in Canada, you should be aware of that one -- hell my "usage" that I'm paying $60/mo for here would run me around $500 a month under yer new law!)
DOSGuy wrote:
I'm committed to making the site (and its underlying code) as good as possible, so I'll see what I can do over the weekend. You can put me through the ringer again on Monday.
If you'd like to talk via IM, we could go over what you're doing. As it sits I've got my CSS rewrite/demo template about 80% complete... really it's presentable as it is now, but I want to add some mcSwitchy code to it. (and maybe media selectors, though that's treading into making the markup iPhone/Droid friendly).
DOSGuy wrote:The downside to all of these methods is that I would have to redirect all traffic that doesn't specify "es" or "fr" to the "en" equivalent, and every existing link to my website on the entire internet is no longer correct. For years to come, the vast majority of all traffic will have to be redirected, and search engines may punish me for moving all of my pages.
You could easily handle that from your CMS code by trapping a cookie and redirecting to the appropriate copy. Also, if your CMS builds entirely off of relative links, it shouldn't matter which domain it's on.
Though I know all sorts of sneaky .htaccess and php tricks for doing that sort of thing.
DOSGuy wrote:Since the menu and the welcome blurb are the only things that are ever likely to be translated, I made a decision to keep the site structure as is, and simply use PHP to load the menus from a different include based on the language cookie it finds. For the index page ONLY, instead of confusing things by having three different versions of the main page, I just put all three languages in the same page and I load the one that's needed. It's not an elegant solution, but it fits the scale of the project. How much trouble should I go to for a single page?
Given that PHP server-side would/should be no more difficult than doing it with javascript client-side...
DOSGuy wrote:Eliminating the target attribute is a load of bull that I've opposed ever since I found out that it wasn't allowed in Strict.
Interesting, it's one of the first things I applauded the idea of.
This might sound like a strange question, but are you a Mac user? Usually the only people who take that stance are the ones who lack the ability to right-click or middle-click.
DOSGuy wrote:Who are my site's beta testers? My friends and family. Not one of them knew that you could right-click on a link and specify "open in new window/tab". If I don't use the target attribute to open a new window for my visitors, they're forced to leave my site when they click on an external link. I hate when clicking a link takes me away from the site that I'm on, but at least I'm savvy enough to know that I can choose where the new page loads. Most people aren't.
My question would be do they get confused as to why the back button didn't work when they didn't notice the new window/tab open?
The use of target on non-frameset pages is on pretty much EVERY "bad web design" list you'll find dating back a decade... and
it still crops up on new ones!
DOSGuy wrote:Think about it logically. If your visitor doesn't know about the right-click options, and you aren't using target="_blank", what are they going to do when they get to the new site if they wanted to stay on your site?
Hit "back"?
You're breaking normal browser navigation by doing that -- made worse by what it does on devices... again, other than "desktop screen"
DOSGuy wrote:I just asked my wife, who can be considered a typical internet user. She works for the Parliament of Canada, has been using for the internet for 15 years, and didn't know that you could right-click a link and choose "open link in new tab" until I showed her 6 months ago. I asked her what she would do if clicking a link took her away from a website that she wanted to stay on, and she confirmed the procedure in the paragraph above, except that she would have opened a whole new browser window! So this idea that everyone on the internet knows about right-clicking on links is ridiculous; this noble-sounding justification of "it's the user's decision where the new page opens" is nonsense because nobody knows that they have the option!
Middle-click would really startle her then.
I get the exact opposite complaints from testers -- "why can't I just hit back", "what do you mean it's a new window"
You know, the typical #DDD (aka Carlos Mencia Gray) Windows IE user who's sitting there with 40 IE windows open becuase they never realized new ones opened? Or sit there complaining about "it takes me forever to close IE becuase of all these copies it spawned for not reason"
Of course that said behavior has ALWAYS annoyed me from the first day I encountered it...
Oh, and sorry about the long posts -- I try to be complete, but can also get a bit long winded at times.
It's what I do.
Wow, spent more time on this post than I have on coding the demo CSS
-- I'll have that demo up on my server probably by dawn once I square away my own projects. I've got non-24 sleep/wake syndrome so even though my local time is 1AM, it's actually around 11AM for me right now. (I'm on a 26 hour day)
This isn't 1998.