Forum Moderators: open
There are a couple of good threads on this:
HTML vs. XHTML :: What are the advantages of one or the other?
[webmasterworld.com...]
HTML or XHTML? :: Which to code in?
[webmasterworld.com...]
XHTML or HTML wth css :: is it better to use XHTML with css
[webmasterworld.com...]
As tedster says in the first link above:
Here's where I see a crucial differentiation, and one that is very seldom discussed -- the difference between using a transitional DTD and using strict DTD. That is very important, no matter whether you are writing xhtml or HTML. Learning to write strict code is the big deal.
XHTML takes a big step towards the seperation of style and content and trying to add more semantics to a page (this is a major heading, this is a <cite>ation, an <abbr>evation etc.) and in doing so many tags are completely deprecated and using them will cause validation failure.
Depending on your knowledge and patience, many people find the learning curve quite painful.
HTH
Why both Transitional? Well, it wouldn't be but for the fact that it's a consistent paradigm in my site architecture that external links use target="_blank" while internal links load into the same window. That's the only thing that makes it transitional. (I look forward to CSS 3!)
Why not write the rest of the site in XHTML 1.0 if the homepage employs it? Mostly because I agree with the notion that whether a doctype is strict or transitional is probably a much more important question than whether it is in XHTML or HTML. Also because, as far as I understand it, XHTML 2 doesn't have much more in common with XHTML 1.0 and 1.1 than it does with HTML 4.01 [w3.org]... so when I next update my site (come on browsers!) I'm intending to leapfrog XHTML 1.0.
Why is your home page written in XHTML, rather than HTML, as per the rest of your site? Do you think it gives some advantage?
I've started using js instead of target="_blank" to avoid this pitfall.
Something like <a href="http://www.example.com" onclick="go(this); return false;"> passes strict validation. (I know it's cheating a little but it does achieve the desired result).
Krapulator> Yes, you're absolutely right. I've considered something similar with JS, but I haven't implemented it. I'm hoping that Opera and Firefox will introduce support for CSS 3 as soon as possible, so I can get rid of all the target="_blank" references and just define link behaviour in my stylesheet.
I'm sticking with validated HTML 4.01 until server and browser technology has evolved a lot more.
I'm sticking with validated HTML 4.01 until server and browser technology has evolved a lot more.
On websites that need to cater for everyone on any platform and any browser I'm sticking with html 4.01.
On my own personal websites I feel free to use xhtml 1.x. They are my personal pet projects and I'll do whatever I damned please with them :)
for my reasons for disregarding xhtml 1.x for websites for the general public see the url's in my postings in the related / cited threads.
Target and name attributes? What the heck are those? ;)
Also, would the addition of js not defeat the purpose of having nice clean (x)html?
I find the best thing is only to open new windows rarely, not even for off site links. I think it's a very '90s approach to holding on to traffic, and it usually ticks me off when a site does it to me. Even newbies know where the Back Button is and most newbies also remember how they found your site in the first place.
Build a good site and you don't need to corral your traffic, you can give them credit for having at least half a brain.
And back to the topic, I so far have no reason to use XHTML. But I can see lots of reason to move to strict mark-up rather than transitional - and that's what I think is the main direction forward right now.
If you want to open a new window, then that's not a function that the W3C wants in the HTML - going forward at least. So scripting IS the right way.
I think the people working on CSS 3 might have other ideas apart from scripting:
[w3.org ]
The 'target-new' property determines what new target destination (if any) is created.
window: The target is displayed in a new window.
tab: The target is displayed in a new tab of an existing window.
none: No new destination is created. The target is not displayed.
Next up, this old chestnut.
I think it's a very '90s approach to holding on to traffic...
I don't disagree and it won't work anyway if a user is trying to employ the technique to "hold on" to traffic.
But in lots of situations where the reader needs to compare and contrast, it's a useful technique. eg. a recipe collection site that says: "here are three more simple recipes for making a birthday cake". It's more practical for each of the external hyperlinks to come up in a new window by default so that the necessary ingredients, cooking time etc. may be quickly compared side-by-side.
And it usually ticks me off when a site does it to me.
Sure. But it ticks me off when sites don't do this... and I then have to press the back button and then manually open a new window. Which is why (I maintain) that the behaviour of external links should have a manual override in the browser's Options menu.
I'd be happy to switch to XHTML properly as soon as browsers start supporting CSS 3... does anyone have any idea when they might be?
I'd be happy to switch to XHTML properly as soon as browsers start supporting CSS 3... does anyone have any idea when they might be?
And none of the browsers fully implement css2.1 yet, so for the moment I'll settle for a consistent implementation of css2.1 across all browsers. Let them get css2.1 implemented first before we bithc about lacking css3 support
Huh? I open nearly every link that I click on as open in new tab.
Spawning new windows on the user is a no-no these days. Many users are fearful of new windows opening due to popups, popunders, spyware, etc.
Now, back to the topic. Anyone out there using XHMTL 1.1 (or 1.0) and having any problems?
I agree 100%, but unfortunately it is not always the web developers decision.
would the addition of js not defeat the purpose of having nice clean (x)html
JS adds functionality to a page, which interacts with, but is not the same as, structure (html, xhtml) or appearance (css). So I don't think adding JS has any effect on the 'cleanliness' of a site, and it certainly has nothing to do with validation.
As for adding JS to achieve validation: absolutely, when you consider in the case above that JS is being used to replace a (soon to be) deprecated html property.
A single error on your page, for example forgetting to escape & or something, causes a full page parse error on Mozilla, on newer Opera's the page tries to render until the error.
and as noted there is zero support for xhtml on IE, so if you try serving it xhtml it asks you were you want to download the unknown file type. only mimetype xml will display as xml on IE.
But that's not the real problem, the problem if you are using javascript that uses any document.write in it. XHTML is not supposed to support that, although the new Operas will do this, Gecko won't, not sure about Konqueror/Safari.
Look up the replacement for that document write, it's a bad dream.
the reason for document.write not being allowed when serving as application/xhmtl+xml is given here:
[ln.hixie.ch...]
It's small wonder commercial sites avoid true xhtml, mimetype xhtml, when the stuff won't support any existing standard javascripts that use document.write. yet another brilliant move on the part of the w3c to make adoption of xhmtl rewarding and straightforward for web developers.
The especially odd thing is that despite this, Opera decided to support document.write in 7.5 and xhtml. Which again leaves a brand new development fork between even supposedly compliant browsers. Is anyone ever going to learn from past mistakes, looks like no....
by the way encyclo, another great post on this subject..
