Basically what coven said: No target attribute is a feature. If I want your link to open in a new window (which is never) or tab (which is often), I will do it my goshdarn self, thank you very much.
Seems like new window links are really a behavior issue and donât necessarily need to be markup elements anywayâuse Javascript for that.
The target attribute is so much a better way to open anything in a new window than doing it with JavaScript⌠At least the browser (Safari does it) can tell the user this link will open a new tab/window. This is way more accessible and user respectful.
I hate it when I click on a link and it opens a new window (because my Safari is set to open target=_blank in new tabs).
And, as a developer, I continue to use target=_blank for external links.
I think target attribute is forbidden on strict html/xhtml because it breaks history, can do weird things if the user doesnât notice the new window, etc. But doing STRICT and doing the exact same thing with JS is just stupid (even MORE stupid if they say weâre xhtml strict valid).
My initial reaction to the removal of target was negative. I thought it was stupid. Then I thought some more and figured out the theory behind it. XHMTL is trying to do the MVC pattern with the markup being the model. Actions, like opening in a different browser are in the controller, which is browser and if you want to do custom browser behavior, you use JavaScript. So it make sense from the theory perspective. But my final conclusion rest in change and that people only like change that makes things better. This makes things harder and more bug prone, especially for non-developers. So I agree with you that XHTML strict is likely to be a developer only markup.
Just you wait to you see XFORMS, XHTML has nothing on them.
I would say validation should be important to developers. As HTML and CSS continues to evolve and become more advanced browsers will have no choice but to begin being more and more strict and when they do the broken HTML will be truly broken. One must also wonder what kind of impact these loose interpretations have on the performance of browsers since they have to spend a lot of time fixing stuff that should be done properly in the first place.
Rather than looking at the short term as everyone usually does, perhaps if everyone moved to valid HTML/XHTML we would have higher visual consistency in different browsers over time. Itâs a lot easier to code a display engine if everyone is following the same rules.
+1, for the removal of the target attribute.
Oh, how I hate those sites that thing theyâre so important that they can take over my browser experience.
XHTML has no advantage over HTML as of now, since IE doesnât support true xml. They wonât in the future either.
http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx
Itâs fairly easy to make a HTML-Transitional page fully validate though.
Itâs also worth noting that valid (X)HTML is MUCH easier for screen readers to parse. They arenât (always) as forgiving as your standard web browser.
Nor are the cut-down browsers in mobile devices, or in browsers that support older systems (ever try to surf using Lynx? THATâS masochism)
Valid (X)HTML isnât just a nicety, itâs the ramp outside the store, right next to the handicapped space. Just because YOU are sighted, not color blind, and can read 8-pt font comfortably doesnât mean everyone can.
Itâs also worth noting that if you use the web for a business and your website isnât accessible to screen readers, you may run afoul of some local laws.
It is very sad to read this post. I seriously doubt that the W3C standards were created just for the fun of it! I think the root of the problems lies in the forgiving nature of the EARLY browsers, newer browsers would then have to be forgiving as well, otherwise nobody would use them since they might not display your favorite site correctly (or at all).
BUT why not make things better? Iâll wager that if browsers only displayed valid (X)HTML everyone would create valid (X)HTML. So Iâm soooo glad XHTML Strict are really anal about validation!
If everyone then again had valid HTML, Iâd bet a lot of things would be easier, e.g. parse XHTML via XML DOMâŚ
Regarding JavaScript, if the JS engine only allowed valid changes to the DOM then there would be no problem.
Of course JS should be valid ecmascript (or whatever itâs called this week) and the same really applies to CSS.
The attitude: its hard to implement and it works anyway, then I canât really be bothered (IMHO) effectively prevents unleashing the full power of HTML/the web.
Few points:
-
target=_blank breaks (to some degree) the consistency of the web. If people want a new window, they can right-click-open in new window. If they want to replace your site with the new one, theyâll just click. If they want it in a new tab, theyâll middle-click. target=_blank breaks all of that good standard Web stuff. Even if you insist on your nonstandard behaviour, chuck it where it belongs: not in the document structure (probably in the Javascript).
-
td width=80
br/
⌠versus this way?
td style=width:80px
br
- both of these are wrong. 1st one has terrible hard-to-correct in-page styling (chuck it in a stylesheet!) and the 2nd is worse: in-page styling AND a malformed line break element (which even when written correctly is rarely/never necessary if you have decent mark-up. But itâs legal, so fair enough).
- Why build away from standards? XHTML Strict isnât that hard (apart from if you want to keep the web-distorting _blankness). Get it right now. Doing mark-up quickly while doing it well is only zero-sum if you arenât very good at it, in which case: pay someone to do it.
I generally like your posts but I am disappointed to see a prominent blog like yours advocating invalid markup and I feel sorry for those who follow your bad advice on this post.
Sloppy code, everyone is doing it and it works well enough so why bother to do it right, no one notices the code seems to be your message. Anyone who calls themselves a web developer ought to care enough to do it right or get out of the way and let someone who does care do it.
You are right to call out the popular sites that are not valid, they should be shamed into doing better, you are wrong to endorse bad practices just because there is so much successful crap out there.
Maybe its difficult to validate a site once youâve waited until its all developed and in production, but with modern tools and awareness it is not difficult to build valid XHTML Transitional ASP.NET applications.
Joe Audette
Founder of mojoPortal an Open Source CMS that does produce valid Xhtml.
I have not looked at the sites listed, but do they say they apply to HTML 4.01 strict? Or have you validated with strict anyway? If you say your site is transitional or frameset it should be validated for that.
Maybe because I am a programmer I prefer strict. And I would probably use XHTML if the browsers really would support that. Firefox at least tell it likes XHTML. IE does only do / as accepted data. I hate that. Now it was probably over a year since I last tried what browsers really accepted XHTML, so it probably lot better today. But with the world still being owned by IE6 I stick to HTML 4.01 strict.
Iâm a bit disappointed that you donât get why target=_blank is bad. Here are some links:
http://www.useit.com/alertbox/990530.html
http://www.snyderconsulting.net/article_7tricks.htm#7
Validation is pretty much at the very, very, very, bottom of priorities in any site I make. And even if by some miracle I ever actually got to this proverbial bottom, I wouldnât do it just because I think itâs such a waste of time.
a perfectly harmless attribute for links that you want to open in a different browser tab/window
Therein be part of the problem - actions that you as developer want to happen to the userâs machine, regardless of the userâs wishes. For accessibility and usability reasons the user/user agent should remain in control of behaviour. Using JS is a better fit to separate behaviour from content but arguably this particular practice is undesirable anyway.
XHTML is just as easy to handcode as HTML once you are used to either one of them. Is this the same question as âwhy does PHP need semi-colons at the end of each line when Python doesnât?â, or âwhy do I need a closing brace as well as an opening brace?â As noted though, sending XHTML is normally utterly pointless unless sent as application/xhtml+xml.
Youâre right that nobody cares if your code is valid except you, but itâs akin to writing a statistical report where, because of rounding, the percentages donât add up to 100%. It doesnât really matter at the end of the day, but itâs lazy and could confuse/give extra work to the reader (browser).
I agree with you completely. Validating your HTML is very useful since it exposes some obvious problems that could turn into real headaches. But, things like the target attribute are ridiculous. I actually ran into that recently.
So, I tossed the idea of completely validating my code right out the window. I used the validation check to see what needed to be fixed, but I did not fix it all. Fixing it all would lead to more problems. Instead, I just focused on what could actually cause complications down the line. All the rest, that have no effect on user experience, were left alone.
An example is when I set up a form with an empty action, and assign an event using MooTools. The event then directs an ajax submission when the user submits the form. But, when validating the HTML it comes up as an error that the form does not have an action assigned to it. Who cares? Nobody. It works.
Validating to 100% should only really matter if your site is running completely on HTML, with little to no JavaScript or other languages.
You can feed web browsers almost any sort of HTML markup or JavaScript code and theyâll gamely try to make sense of what youâve provided, and render it the best they can.
Having seen web-developers near-enough tear their hair out over cross-browser rendering issues, one finds it difficult to conclude that the above statement is a positive one.
In comparison, most programming languages are almost cruelly unforgiving.
This is a good thing, and this is the same standard that webpages should adhere to. If this were the case, it would be far easier to implement web browsers that could confidently apply standards-based layouts to pages, and would render cross-browser design issues a thing of the past. Web Developers that dig their heels in the ground and proclaim (about the lax attitude towards mark-up) It has always been this way; why should we change? are digging their own.
Coding Horror 
59 Errors, 63 warning(s)
Not just 508 but W3C accessibility guidelines, of which Priority 2 is the accepted (although not legal) minimum standard in the UK states that to achieve Priority 2 you must âCreate documents that validate to published formal grammarsâ.
I like having valid HTML, it helps when the browser rendering engines change so frequently, itâs good to know you have a solid and correct foundation to buid from.
And as someone else said it helps with Search Engine Rankings, MSN even more so (although the site Iâm basing that on we also did it to pass accessibility guidelines too) I was amazed!
The other thing is if you built a building and it didnât pass building regulations youâd get sued by the clientâŚ