Forum Moderators: not2easy
Xhtml is more strict then html. You need to focus more on your tags being closed correctly.
And If I am correct, xhtml is what is before usage of xml. So if you are planing on one day going to xml, its good to get used to the xhtml.
I"m going by what I have been reading on my learning journey, so I hope that if I am wrong on anything here someone will come along and correct me. ;)
Why XHTML over HTML.
I'm learning to use XHTML simply because the HTML is simpler. None of those ugly tags to worry about, just do everything in the stylesheet. Keeps things simple...
Though still in the learning mode myself, I find it easier to use the xhtml and the style sheets.
Its just difficult when it comes to positioning with css. And getting all the browsers to cooperate.
But, I love a challenge, so its interesting, and keeps me interested in the learning. When I do accomplish something, its like a giant viola! And not only is it interesting and challenging, but its a ton of fun. (I still dont' understand how web design is considered work yet. ;) )
I think that its important to stay on top of what the new methods of design are. And if xhtml and css are what is going to be the future of designing web pages, then I think that its very important to learn all of this.
As to whether XHTML or HTML is better; that's been done to death:
[webmasterworld.com ]
[webmasterworld.com ]
[webmasterworld.com ]
[webmasterworld.com ]
Surprisingly, there are valid arguments for both options.
If this is the case, isn't it better to learn the xhtml and css? Also if xml is going to be the future of coding, isn't it better to take the steps as they come along and learn how to do things the proper way?
I see no problem in following standards. I mean, arent standards there for a reason?
drbrain
It doesn't really matter. The two standards are orthogonal provided your document conforms to the the strict document types.
If your document conforms to the strict document types, then, you are acutally following standards.
Provided you aren't using the presentational attributes of either HTML4 or XHTML, it won't make a difference which of the two you choose. They both give you the same layout when used with CSS. (In fact, even if you use presentational attributes from the Transitional doctype (also standards-compliant) you'll get the same layout.)
You're better off choosing between the two based on the use of XML in your backend, MIME type handling in your user-agents, etc.
If your document conforms to the strict document types, then, you are acutally following standards.
Yes, this is true. I believe what drbrain was saying is that if your HTML or XHTML is written correctly, both are standards compliant. You seem to be under the impression that XHTML is somehow 'more standards compliant' than HTML, and this isn't the case. They're just a different standards!
Edit: Damn, that drbrain types fast :)
You seem to be under the impression that XHTML is somehow 'more standards compliant' than HTML
Or, maybe that it is more strict then html?
Also, it was my understanding that css works better with xhtml. Also, that xhtml strict is much better then html or xhtml transitional.
remember, I am self teaching, so am bound to get some of this incorrect, any guidance is greatly greatly appreciated ;)
If you forsee the back-end items drbrain mentioned coming into play on your sites, then obviously, learn the XHTML (is it really all that different than html401strict? not really) or, if you really forsee the need, XML.
But html401 is, and is supposed to be, perfectly, wonderfully and magically fused with CSS. CSS1 was designed YEARS ago ('98? 99'?) for use with html, before XHTML was even a twinkle.
What you are probably getting hung up on is the fact that html 401 is the last of it's kind, in other words, that all future developments will be in XHTML and so, if you're forward thinking, it's probably best to go that route.
I personally use a 401strict dtd in all my pages and validate to that standard, although I try to follow all the little 'hang ups' that XHTML has (self-closing tags, closing all opened tags, etc) simply because they are the practice of a good boy who always listened to his mother.
So learning about css and xhtml seemed to fit into overcoming that frustration. If I am making any sense with this that is.
So I guess I am forward thinking in wanting to learn xhtml and css. I just want to make sure I learn it the correct way.
I guess I also don't understand, if CSS was created so long ago, why more people aren't using it in their designs?
(btw, its great to hear that you were a good boy who always listened to your mom! As the mom of 5 children, I would have to say that I am sure your mom is proud of you! ;) )
I guess I also don't understand, if CSS was created so long ago, why more people aren't using it in their designs?
This is an easy one. Check out any article on A List Apart, Position Is Everything, or any other CSS design site. They generally run about four or five paragraphs to explain the concept (ie, how it works in Mozilla and Firefox), then two or three times that amount to detail all the hacks necessary to get it working cross-browser(esp. in IE).
Bottom line: its IE's fault.
Bottom line: its IE's fault
I have found that the IE conditional statement works pretty good, so far that is. I just have not found anything out there that really teaches the other hacks and how they are used. I see them in other peoples code, but don't understand how they are used. I think there needs to be more advanced CSS tutorials out there.
On the brighter side, I have finally found a reason to use xhtml, it took me a while:
If you are going to convert your content pages to xml files running through an xslt processor eventually, it's a little bit easier to do that if your pages are done in xhtml, but you still have to make absolutely sure that no errors had crept in, like those pesky ms word magic quotes (illegal character), long dashes, ... characters, etc. However it's unlikely many people are ever going to do that, but there it is, an actual reason to use xhtml, weak as it is, but note the use of xhtml itself is meaningless in this process unless youi are going to do that kind of xml type processing.
However, no matter what you have to go in and validate your new xml, since one error will stop parsing instantly.
Note however that this is not a standard situation, usually from what I understand xml is being produced elsewhere then being transformed into html, what type is irrelevant completely, it's just output, it's the xml that matters, not the html.
Other than that I have to agree completely with Mattur's position in the threads. By far the funniest claims are that xhtml will somehow speed up rendering, as if the browser could magically determine beforehand that the document it has received is in fact error free, then go ahead and render it as xml. Which of course they can't do. But I guess it's fun to pretend or something.
By far the funniest claims are that xhtml will somehow speed up rendering, as if the browser could magically determine beforehand that the document it has received is in fact error free, then go ahead and render it as xml. Which of course they can't do. But I guess it's fun to pretend or something.
This is actually possible for XML user agents handling XML documents. An XML parser does not have to carry around all the cruft of an HTML parser to support things like overlapping start and end tags, improperly closed elements and all that other stuff that allows broken documents to render just fine. This makes the code path through the XML parser shorter than one through an HTML parser . (In order to trigger the XML parser you must return an XML mime type like application/xhtml+xml instead of text/html.)
Will your users notice the difference in speed? No.
The differences are too small to notice for typical page sizes. Latency, not parse time, is the worst enemy of speedy page loading. The parser is so fast that you have to drop back many CPU generations before the parser consumes a noticeable amount of wall clock time.
CSS1 was designed YEARS ago ('98? 99'?)
It became an official W3C recommendation in 1996 (!), which means it was designed even earlier than that ;)
However, no matter what you have to go in and validate your new xml, since one error will stop parsing instantly.
If you start with XML, and transform it with XML tools, what you get out should be guarenteed to be XML. If it isn't well-formed to begin with, your XML processing tools will reject it. If they don't, they're not XML processing tools. If it isn't well-formed, it isn't XML either.
Of course, being well-formed XML doesn't mean it will be valid XHTML.
The benefits of XHTML are only there if you serve it with an XML mime-type (preferably application/xhtml+xml). But this doesn't work for IE. XHTML 1.0 may be served as text/html (if it meets restrictions such as <br /> instead of <br/>). HTML compatible XHTML 1.1 doesn't exist and shouldn't ever be serverd as text/html.
If you're using XSLT to produce XHTML from XML documents, note that XSLT processors have a HTML output option.
[w3.org...]
The best way to do things is to serve XHTML to user-agents that support it (as application/xhtml+xml), and HTML 4.01 to user-agents that don't (IE). This way applications that support XHTML get the benefits of using a simpler parser (the mime-type tells them it is well-formed. If it turns out not to be well-formed, they just throw an error and stop.)
Microsoft apparently have no interest whatsoever in supporting XHTML in IE, by the way.
