My company is looking to replace all websites in the group with a new CMS-based system and similar designs/styling, with E-Commerce functionality being added in a future phase. It's too big a job for me to do in a reasonable time-frame, so we are going to be inviting tenders from agencies.
I'm currently in the process of defining the technical requirements, and I'm intending to dictate that the selected system must have a Strict DOCTYPE and must trigger Standards mode (or Almost Standards Mode) in common browsers, or something to that effect [We have to allow Almost Standards Mode to cater for IE, obviously].
I've done a bit of homework an all of this - I don't want the spec to be limited by my ignorance, after all - but it won't surprise you all that I've found that 'current opinion' is completely divided on what is good practice.
There are plenty of people who advocate HTML4.01 Strict (fair enough), plenty of people who recommend XHTML1.0 Strict served as text/html (I'm OK with this too), some who recommend HTML5 but restricted to HTML4.01 tags (erm... still not sure if this is a good idea or not, but I see the principle), but also a not-inconsiderable number (including people on other SO threads) who recommend XHTML1.0 Transitional.
I just don't understand the reasoning for this... OK, you may happen to want to temporarily use something that been deprecated, and thus Transitional seems sensible, but some people recommend XHTML Transitional for new build.
After checking out other companies' sites for design inspiration, I've notice that many sites (if they have any DOCTYPE specified at all) will refer to a Transitional DTD. OK, we all know there is plenty of crap on the web, so perhaps I shouldn't draw too many conclusions. But checking out Web Design Agencies that we've come across, there are an amazing proportion of them (the vast majority of them, I would say) are using XHTML 1.0 Transitional.
Fine, so you don't necessarily have to be an expert to call yourself a Web Designer, but the sheer volume of Transitional layouts makes me wonder... Most of the sites seem to be otherwise reasonably designed (CSS layout, validating, accessible etc).
So, having finally got to the point(!), is there some reason why such a large proportion of these agencies are opting for Transitional DOCTYPEs? Am I missing something, something that I need to consider for my new sites?
Edit: Yeah, I realise the purpose of the Transitional DTD - I was just suspicious that so many otherwise-competent web developers are clinging on to deprecated markup. I wonder if you guys are correct and the answer is simply that they are a) are too lazy to get their own website to validate, or b) sticking with the default DTD of their preferred IDE.
The key re-assurance for me is that (according to your responses so far) I don't seem to be missing out on some key reason to use a Transitional DTD.
Edit 2: Regarding our CMS project - all the short-listed agencies thankfully seem to have their heads screwed on - Strict, valid and accessible.
I'm going to take a hard-nosed approach and say that Transitional doctypes are popular because some people are lazy or just don't care. Somebody told them they should validate their code, and transitional is the easiest to validate because it allows deprecated markup.
I agree with those who answered this previously and said that transitional doctypes are for transitioning to strict. Those are the only situations where I've used them.
Any new development should definitely be with a strict doctype. The choice of Strict vs. Transitional is more important than XHTML vs. HTML4. I would strongly recommend to you that in your technical requirements you require Strict.
Simply put, XHTML Transitional allows developers to more easily migrate a legacy HTML codebase over to that doctype. The Transitional doctype is more forgiving than Strict, but is meant as a stepping stone toward Strict.
Here's a good article talking about Transitional vs Strict: http://24ways.org/2005/transitional-vs-strict-markup
The default of DOCTYPE of MS Visual Studio is XHTML 1.0 Transitional.
XHTML 1.0 Transitional is more forgiving than its Strict counterpart and is the easiest to transition to.
For example in Strict DTD, you would need to write JS to open linked pages in a new window... and target="_blank" would flag an error (eg. from Designing with Web Standards...)
Strict is definitely the way to move forward, but transitional is the best choice for, Transitioning.
I think many people use XHTML 1.0 Transitional because it seems advanced, up-to-date or even beyond (XHTML is the future, dude!) on the one hand but on the other hand still does allow this “nasty stuff” like center, font, align, border, target etc.
Most of the web doesn't validate, as either transitional or strict. Transitional is generally easier to work with, but I think a more telling reason it's used more frequently is that it's also the default for editors like Dreamweaver and many CMS's use it as their default doctype.
Most web authors don't validate their pages, in which case, there's very little to choose between the DOCTYPEs and no good reason to change from the IDE default. The only practical difference to browsers between Strict and Transitional is that strict triggers Standards mode and Transitional triggers Almost Standards mode in gecko, presto, webkit, etc. Pages that actually require Standards mode behaviour are very few and far between and certainly won't affect the overall proportions that you see on the web.
It's worth noting that HTML 5 is being written without a Strict/Transitional distinction, largely because the authors of that recognise that the Transitional DOCTYPEs of XHTML and HTML4 are widely misused.
In XHTML 1.0 Transitional you have <center> <font> and <strike> which is not allowed within the strict version.
The reason is mostly portability between other templates. A nice article about that is here.
Good luck bludgeoning your pages into validating if you're using user input in a CMS. XHTML Strict doesn't like really common things like target="_blank" (we can have a debate about that, but people still use it). Additionally, if anyone adds the default youtube embed html, it won't validate.
Related
Is there any reason to consider XHTML related details for web development for someone who works with HTML4 and plans to work with HTML5?
Or was XHTML a "side" development in web technology which is not related to the current mainstream of web development (which I guess is HTML5)?
Rationale for asking
The reason I'm asking is that a StackOverflow answer I previously posted was recently commented on to the effect that "You should NOT use upper case HTML tags". When I asked "why" the commenter pointed me to a couple of articles, both of which gave the reasoning for lowercase-only tag names as "Upper case tag names are not allowed in XHTML" as the main reason.
Since I don't currently do web development in XHTML (pure HTML4.0) and only plan to use HTML5 as the next step, I'm interested in whether XHTML should be a factor in assorted decisions I make as far as web development
Please note that this question is NOT asking whether one should use upper or lower case tag names in pure HTML - merely whether the upper-case-tag prohibition in XHTML should be a factor in my decision making, or I should ignore XHTML related rules.
Most of the info you will find on XHTML fails to mention that the whole purpose of XHTML is to be used by both humans and computers for data exchange. XHTML was created so that computers could talk to each other, but in the same time remain readable by humans.
The most crazy thing is that various code monks became obsessed with XHTML compliance, without any intend of using the XHTML for data exchange and without understanding what XHTML actually is.
Edit:
A good example of XHTML use is an airline company publishing its flights. The company can utilize XHTML to produce a single list of flights that will be both consumable be humans visiting online and by services that will read the data for their needs.
On the other hand if you own a hair-salon, there is no need for your site to validate against XHTML standards.
Directly, there's no reason to take into account XHTML rules when marking up documents for the HTML serialization of HTML5.¹ However, it seems to be the modern practice to use lower case for tags, and that has been partly influenced by XML and XHTML. So if you find yourself working in a large team of developers, it is quite likely that the coding guidelines for the team will mandate lower case just for consistency's sake. So, it might be worth getting into the habit of doing so.
¹ Note that there's also the possibility of using the XHTML serialization of HTML5, in which case it would matter of course, but I don't think that's what you are asking about.
As far as I can tell, XHTML was intended to be a kind of combination between the features of HTML and the strictness of XML. For example, in HTML you can write <b><i>test</b></i> and the browser won't care, it knows what you meant. Whereas in XHTML that would cause an error and block the entire page from showing.
However most browsers just tolerated errors in XHTML as well, so it became kind of pointless.
Personally, the only reason I can give for choosing to use lowercase tag names rather than uppercase is because I'm too lazy to hold the Shift key and I remapped my CapsLock key to something more useful.
From what I've personally observed about XHTML, the only "benefit" of it is the versatility—for example, it is my understanding that with relative ease, one can create a custom tag/element or attribute and still validate with XHTML.
I see no need for custom tags, since if there isn't one that doesn't fit semantically (though the cases are minimal due to HTML5's improvements in semantic markup), you can just use a div or span and use a class or id to make it "fit." And HTML5 does allow custom attributes anyways.
So I see no direct relationship—or at least, I don't think there should be one—between HTML5 and XHTML (and anyways, XHTML 1.0 is meant to be a combination of HTML 4 and XML). The spec doesn't recommend one over the other, it just notes the fact that in HTML5, they are case-insensitive.
I personally use lowercase tag names for two reasons:
It's a nuisance to hold shift every time (though one could argue that you hold shift to get the angular brackets, but whatever).
It's a style preference—I truly think it looks much cleaner with lowercase tag names as well as a lowercase doctype (<!doctype html>). Uppercase tag names are really old-fashioned, and you don't really see them anymore. It may just be a thing with newer generation programmers such as myself.
And either way, you should pay no mind to rules that apply to a doctype you're not even working with.
From what I have read, it appears that HTML5 removes the distinction between strict and transitional (always strict now). I have not been able to find it specifically mentioned anywhere, only implied. Is this the case?
This is the (only) DOCTYPE for HTML5:
<!DOCTYPE html>
That's it. So yes, there's no difference between "strict" and "transitional".
Yes, it does. Transitional and Strict only apply to XHTML 1.0 and HTML 4.01.
From what I have gathered so far html5 has some sloppy allowances, for instance, you can tag upper or lower case. It will not necessarily flag certain fudging as xhtml 1.1 will. I suspect this can lead into problems down the line for the casual/sloppy coder.
I code in xhtml strict. I would advise anyone learning html to learn strict coding practices - it will teach you how to code consistently and accurately, and how to problem solve succinctly, and to be better prepared as xml standards open up for more and more practical use.
I cannot stress how glad I am I started coding strict.
If you search on "is html5 strict" (the truth is out there) you will find tones of what I am saying reflected/shared in the more educated circles (imho), so I think my remarks are fairly sound. You will also find good advice on maintaining your tried and true xhtml coding while stretching your legs with (x)html5. (If you don't know why I added the (x) there, then you are not done searching ;^) Try searching html5 + xml ;^)
HTH, Cheers.
This is stated on this page http://www.veiled-chameleon.com/xhtml11.html
XHTML 1.1 allows for the easy creation
of different display formats, such as
a page format for printing, for
wireless devices and PDAs, and
television based browsers, simply by
writing a new CSS (cascading style
sheet) for the new document.
Update:
And this is stated on http://www.w3schools.com/w3c/w3c_xhtml.asp
XHTML 1.1 (Modular XHTML)
Small devices cannot support all XHTML
functions, therefore XHTML 1.1 divides
the specification into modules with
limited functionality.
Small browsers can reduce their
complexity by supporting only selected
modules
Can anyone explain to me what authors are saying in this statement, and can't this be done by XHTML 1.0 stric or HTML 4.01 Strict?
The author of that quote is just wrong. It’s CSS that allows such things, not HTML or XHTML.
The media attribute for STYLE and LINK was introduced with HTML 4 and the CSS media types with CSS 2.
The purpose of xhtml1.1 is to divide the spec up into smaller modules that devices can choose to use to fit their purpose rather than having each device required to support the entire spec. No one doctype is "better" than the other but you choose the doctype based on your need. HTML4.01 is HTML. XHTML1.1 is strictly XML.
And as far as strict vs transitional is concerned, no one has any need for transitional in newly created web pages.
The first author appears to be full of brown substance.
XHTML 1.1 is kind of dead in the water, now that the XHTML2 WG has been dismantled. Also, if you look at the iPhone/Nexus One/Blackberry/..., you'll notice that "Small devices cannot support all XHTML functions" isn't really true (at least not anymore).
Actually, if there's any distinction it's between Transitional and Strict. Transitional allows you to do all kinds of wacky things in both HTML and XHTML. It's possible to abuse or misuse nearly any standard.
The hype behind using XML was because in theory, any XML document can be easily transformed to another. so you would have a single web app code, but multiple XSLTs transforming your pages just before consumption for any presentation.
Of course, there are other, far easier to use, templating systems that work equally well on HTML
First of all let's emphasize that syntax rules don't work alone, but they need the correct Content-type header to be fully interpreted by the clients. Currently web pages cannot be served with the correct XHTML header because Internet Explorer doesn't understand that.
The first advantage usually mentioned is that XHTML requires pages to be well-formed: true, but when browsers treat them as (malformed) HTML nothing enforces this rule, so it's up to you being a disciplined developer -- but you can be as disciplined writing good well-formed HTML too.
Another point often mentioned is that XHTML promotes the separation between content and presentation, but even in this case it doesn't really offer anything that can't be done with HTML -- it still depends on the developer since nothing is enforced, and no exclusive tools are offered.
So why do so many developer (including those of famous CMS/blogging softwares) still use XHTML syntax instead of directly writing what those pages will become anyway (i.e. plain HTML)?
Related fact: Stackoverflow uses HTML strict.
http://en.wikipedia.org/wiki/XHTML
From the wiki:
"The only essential difference between XHTML and HTML is that XHTML must be well-formed XML, while HTML need not be."
It's up to you which one you choose. There is no real difference in terms of what the user sees. Whichever you choose, please try to make it well-formed and make sure that your HTML/XHTML validates and follows the standards.
This probably isn't the actual reason, but it makes them parsable using a regular XML parser.
Sadly, XHTML syntax isn't as widely used as the XHTML doctype. You'd think people would be conscious about it, but a lot of the time (at least a few years ago), an XHTML doctype was used mostly because HTML 4 was being "dissed". That hasn't stopped people from continuing to use HTML syntax though. Open ended <li> and <p> tags, non-terminated <br> and <img> tags, tag attributes not enclosed in quotes, and more hypocritical nonsense.
Currently web pages cannot be served with the correct XHTML header because Internet Explorer doesn't understand that.
Sure they can, provided you're prepared to use content negotiation to serve a application/xhtml+xml content type to those user-agents that say they accept it.
There a number of reasons both good and bad why xhtml is so widely used. Jay Askren has a point about people who use XML in other contexts, (I'm one of them), but I doubt if that accounts for much use. If there is a good reason why XHTML is popular, it's most likely that the orthogonality of XML is a very seductive idea. It's simply easier remembering "Always close every tag, always quote the attribute values" than trying to remember all the rules about when you can safely omit tags and leave attributes unquoted etc., even though it results in a more verbose document.
There are other reasons like the fact that it's easier to indent your code if every opening tag has a matching closing one, and if you do, you've got a pretty accurate picture of the DOM laid out in the source code, which can aid with scripting. But I doubt that this is a primary reason.
Using XHTML states an intent, don’t underestimate that (but don’t overestimate this either). Web standards are politics: if nobody cares, nothing is gonna change. Using XHTML (or HTML5) signals “yes, we are in fact interested in the continued development of the standards.
Furthermore, while clients certainly don’t enforce XHTML rules with a text/html content type, design tools still can do this. XHTML is much easier to support for editors than real HTML (with “real” I mean the whole ugly SGML package). There are good XHTML validators that do much more than HTML validators can (e.g. Schneegans’ XML schema validator).
All in all, many arguments against XHTML are in fact straw-men that aim at some of the poorly-formulated arguments for XHTML. For instance, Microsoft is responsible of publishing long lists of purported XHTML advantages (such as semantic web design). Attacking those arguments is like reductio ad absurdum. But there are good arguments for XHTML.
I suspect a major reason xhtml is so popular is cultural and historical more than anything. XML became quite popular some time ago and it is still used quite heavily. It is good for for defining a data model that can be sent over the wire using webservices. There are lots of tools/technologies that work with it such as xslt and many others. It is natural for a developer to use html which is structured like xml, even if there is no real advantage just because they use xml in other contexts.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When developing a new web based application which version of html should you aim for?
EDIT:
cool I was just attempting to get a feel from others I tend to use XHTML 1.0 Strict in my own work and Transitional when others are involved in the content creation.
I marked the first XHTML 1.0 Transitional post as the 'correct answer' but believe strongly that all the answers given at that point where equally valid.
HTML 4.01. There is absolutely no reason to use XHTML for anything but experimental or academic problems that you only want to run on the 'obscure' web browsers.
XHTML Transitional is completely pointless even to those browsers, so I'm not sure why anyone would aim for that. It's actually pretty alarming that a number of people would recommend that.
I'd say aiming for HTML 4.01 is the most predictable, but Teifion is right really, "anything that renders your page will do".
in response to Michael Stum:
XHTML is XML based, so it allows easier parsing and you can also use the XML Components of most IDEs to programatically query and insert stuff.
This is certainly not true. A lot of XHTML on the web (if not most) does not conform to XML validity (and it needn't - it's not being sent as XML). Trying to treat this like XML when dealing with it is just going to earn you a lot of headaches. This page on Stack Overflow, for instance, will generate errors with many unforgiving XML tools for having invalid mark-up.
I'd shoot for XHTML Transitional 1.0. There are still a few nuances out there that don't like XHTML strict, and most editors I've seen now will give you the proper nudges to make sure that things are done right.
Transitional flavors of XHTML and HTML are deprecated. They were intended only for old user-agents that don't support CSS. See explanation in the DTD.
W3C advises that you should use Strict whenever possible, and these days it's certainly possible.
Transitional version has already been removed in XHTML/1.1 and HTML5.
XHTML/1.0 has exactly the same elements and attributes (semantics) as HTML4. The XHTML/1.0 specification doesn't even specify any elements! For anything else than syntax, it refers to HTML4.
Additionally, you'll be unable to use any feature of XHTML that is not available in HTML (namespaces, XML DOM) if you send documents as text/html, and unfrortunately that is required for compatibility with IE and other HTML-only browsers.
In 2008 the correct choice would be HTML4 Strict:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
but as of 2016, there's only one version of HTML that matters.
<!DOCTYPE html>
Dillie-O is right on with his answer of XHTML 1.0 Transitional but I would suggest shooting for XHTML 1.0 Strict and only falling back on Transitional if there's some piece of functionality you absolutely need that Strict is not allowing.
#Mike:
While I agree that validity is not needed to make a page render (after all, we have to keep IE6 compatibility in...), creating valid XHTML that IS compatible AND valid is not a problem. The problems start when people are used to HTML 4 and using the depreciated tags and attributes.
Just because the Web is a pile of crap does not mean that every new page needs to be a pile of crap as well. Most Validation errors on SO are so trivial, it shouldn't take too long to fix, like missing quotes on attributes.
But it may still be kind of pointless, given the fact that the W3C does not have any idea where they want to be going anyway (see HTML 5) and a certain big Browser company that also makes operating systems does not care as well, so a site could as well send out it's doctype as HTML 1337 Sucks and browsers will still try to render it.
There are some compelling warnings about the usage of XHTML, primarily centering around the fact that the mime-type for such a document should be sent as:
Content-type: application/xhtml+xml
Yet IE 6 and 7 don't support this, and then websites must send it as:
Content-type: text/html
Unfortunately that method is considered harmful.
Some also bemoan the fact that although the intent of XHTML is to make web pages parsable by an XML parser, it has in practice failed due to incorrect usage on existing websites.
I still prefer to write documents in XHTML 1.0 Strict, mostly because of the challenge, and the cleanliness and error-checking that a validator gives. I enjoy the syntax a bit better, because it forces me to be very explicit in when tags end, etc. It's more for me a personal choice than purely technical.
Anything that renders your page is will do so regardless of which popular standard you use. XHTML is stricter and probably "better" but I can't see what advantages you will get with one standard over another.
Personally, I prefer XHTML 1.0 Transitional.
XHTML is XML based, so it allows easier parsing and you can also use the XML Components of most IDEs to programatically query and insert stuff.
Transitional is not as strict as strict, which makes it relatively easy to work with, compared to strict which can often be a PITA. Comparison between Transistional and Strict
1.0 is "more compatible" than 1.1 and 1.1 seems to be still under some sort of development.
I aim for XHTML 1.0 Trans. It's better to conform so when bugs are fixed in the browsers you won't suddenly be working against the clock trying to figure out what actually needs changing.
In my opinion 1.1 is borked and 2.0 has been smashed to smithereens: Do I really need/want a header/footer tag?
I'm all for XHTML Strict every time. I strongly believe that HTML should be more like XML. It's not hard to validate it if you know XML and the W3's validator ipoints you on the right track anyway.
XHTML 2.0 is heading toward what the W3 have been aiming for for a long time - the semantic web. The best benefit of XHTML 2.0 for me is that every conformant page on the web will be understandable as content, or an article (for that's what pages are - documents) becuase they all apply to the same standard. You would then be able to construct intepreters (i.e. browsers) that present the content in a completely different manner - there's literally thousands of ideas waiting here.
If you want to use XHTML 1.0 in an HTML-compatible way, that's fine. However, do note that the W3C validator and the XHTML DTDs know nothing about mime types and how browsers behave differently (like <map> name/id matching) between them. The DTDs know nothing about how well browsers support certain elements (like <embed> for example) either.
What this means is that the XHTML DTDs and the validator don't reflect reality and trying to conform to them is pointless.
If you want to use XHTML just so you can close certain elements with /> (where html-compatible), just use HTML5 markup (so the browser is in full standards mode). HTML5 allows the use of /> in an HTML-compatible way (the same HTML-compatible way you have to do it when using XHTML 1.0 markup with text/html). Then, just stick to what works (you know better than some DTD) in browsers.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<title></title>
</head>
<body>
<p>Line1<br/>Line2</p>
<p><img src="" alt="blank"/></p>
<p><input type="text"/></p>
<p><embed type="application/x-something" src=""/></p>
</body>
</html>
Then, use http://validator.nu/ to make sure it's well formed at least.
If you have tools to generate your XHTML like any other XML document, then go with XHTML. But when you just use plain text templates, text concatenation, etc. you are OK with good old HTML 4.01.
Browsers now start to support this 10 year old standard.
Important: Avoid being called a bozo when producing XML
I don't think it actually matters whether you use XHTML or plain HTML. The end goal here is to have low maintenance and quick development through a predictable rendering. You can get this from using xhtml or html, as long as you have validating code. I've even heard arguments that it's best to target quirks mode, because new versions of browsers don't change quirks mode, so maintenance is easy.
In the end, it all becomes tag soup, for good reason, because getting web app developers to write error-free html means asking them to write bug-free code. Validators are no help, because they only validate the initial page view. This is also why I've never seen the point in xhtml served as xml for anything beyond static sites. The level of arrogance a web apps developer would need to have to serve up their web app as xml is staggering.
HTML 4.0 Strict, or ISO HTML.