|
|
i was working hard to convert my pages to XHTML. there were 52 error at first and now i managed to bring it to 02 error only(local files) but whats the use of it when i found yahoo.com has 200+ error in it! millions of people use that page and they found no problem with it. so is tere really any difference if one uses XHTML? whats wrong with HTML 4.01 ? if one use HTML 4.01 and uses css for style and formatting then it shall fit in all resulation? anyone has to say anythnig about it?
Xhtml is actually just a big hype. You normally don't need it. W3C is still recommanding to use html 4.01 and I see no reason why not to do it, at least for most websites.
Thats it! i needed this advice from the expert. moving back to HTML 4.01 with ear to ear face. YAY!
Although it may not make such a difference, it's a good thing to know that your page is XHTML compliant, isn't it? And honestly, was it a hard job to correct your pages?
I think XHTML may be the way to cross-browser compatibility - unless a company comes up again with their own standards, just to make people pay...
xhtml is for computer more update of html more easy to clone and hader to hack
| sub-zero wrote: | | xhtml is for computer more update of html more easy to clone and hader to hack |
Harder to hack? It doesn't make sense.. XHTML (eXtensible Hypertext Markup Language) is just a stricter set of rules that define how HTML tags must be coded.
For example:
1. XHTML tags have to be properly nested.
<b><u>Frihost</u></b> <- This is fine.
<b><u>Frihost</b></u> <- This is not fine for XHTML, but for HTML, it is fine.
2. XHTML tags have to be in lower-case. HTML do not.
<b>Frihost</b> <- This is fine.
<B>Frihost</b> <- This is not fine for XHTML, but for HTML, it is fine.
On the whole, XHTML is a set of rules that forces your code to be "cleaner", neater and easier to read.. Need it or not? Well, most modern browsers are able to render codings correctly even though there may be errors in your HTML code, such as missing <html> tags, not properly nested tags, etc etc. My opinion is that it doesn't really matter.
You tend to find that programmers who code HTML automatically follow most xhtml rules, simply because languages (ones that have to compile etc) do not tolerate ambiguity and have exact syntax.
The other side of the rules is to separate content from how it is displayed, which if you are using CSS should be occurring anyway.
There are also a few rules which are just odd, like the fact that elements are not allowed to be defined with any capitals. I fail to see why case sensitivity is important here.
As thiamshui said, xhtml is basically a tightening of the rules. Yahoo is clearly a mixmatch of different developers using different HTML standards. Fortunately they all still work though.
xhtml is better to use just because it makes your code cleaner and easier to manage. Also, you should use CSS even with html 4.01.
Here is a very nice article about it html vs xhtml:
http://www.sitepoint.com/forums/showthread.php?t=393445
Normally you should be sending the xhtml file as an application (mime type) and then the browser will only display it if there are no errors at all. Otherwise you'll get an empty page. However, IE doesn't even support it.
| Quote: | | In reality, the latest W3C recommendation with widespread support is HTML 4.01. Unless you actually need any of the features that XHTML offers over HTML, there is no technical reason to use XHTML. |
If you read the DTD's for HTML 4.01 and XHTML 1.0 (Transitional) you will see there are not many differences. There are some major ones though....for example in HTML 4.01 you can still use standalone tags (many are being depreciated though) such as:
in HTML one has no closing tag and the other really doesn't require one, but in XHTML all tags must be closed:
| Code: | | <p> would require the closing </p> tag, and <br> would become <br /> |
For the most part I have to agree with Bondings....XHTML is more hype than anything else...I'll stick with HTML4.01, unless a customer requests XHTML that is....then they have to pay extra 
Im coding in XHTML ... why? Because its not to hard to code in it  I don't care of target=blank or div-align center, and i like to have clean code (no capital letters) but I don't think that this is necessery - It is just for satisfaction
I would recommend you to use HTML.
I only use XHTML because I learned it that way, but HTML is rendered better in most browsers.
I was really close to move my site from HTML to xHTML, but at the end I told myself "meh, It's not something I need".
at the end, every variations on the web are useful, but that doesn't mean you have to put javascript, php, css, html and flash on a site just because they are useful, you only have to use what you need.
I use XHTML, it forces me to make cleaner code so its easer to edit in the future.
HTML is good for beginners cause it allows for mistakes.
XHTML is stricter (not by much).
In the end, it comes down which you prefer.
whatever it is, i dont really see any difference between HTML 4.01 and xHTML.
however, i use Frontpage 2002 and in the "code" view when i apply XML formatting it becomes somewhat xHTML
simply, i'm HTML 4.01 agent 
its like [No girl no pain]=No xHTML no pain!!
| Quote: | Is XHTML supported by all browsers?
No. Only a few mainstream browsers support XHTML, like Opera, Firefox and Safari.
Most importantly, Internet Explorer does not support XHTML at all.
If you follow certain guidelines you can serve XHTML documents as text/html (see below). That means the document will be seen as HTML, which all browsers can handle. Virtually all browsers have a parser bug that ignores the slash in self-closing tags. |
No frontpage = no pain ...
H8 frontpage ... it makes TRASH from HTML code ... only MS WORD sucks more but ... this is my opinion I use Notepad++
| b4r4t wrote: | No frontpage = no pain ...
H8 frontpage ... it makes TRASH from HTML code ... only MS WORD sucks more but ... this is my opinion I use Notepad++ |
never tried Frontpage's code paste into Dreamweaver? then do a code check and refine it. yeah when coding alone i too preffer notepad
| Stubru Freak wrote: | | but HTML is rendered better in most browsers. |
Ummm, show me ANY example where a html 4.01 page renders better than the same page that is xhtml compliant. Maybe if you send it as a *.xhtml file it won't work, but sending it as *.html, it is just cleaner code.
| snowboardalliance wrote: | | Stubru Freak wrote: | | but HTML is rendered better in most browsers. |
Ummm, show me ANY example where a html 4.01 page renders better than the same page that is xhtml compliant. Maybe if you send it as a *.xhtml file it won't work, but sending it as *.html, it is just cleaner code. |
I'm too lazy to do it myself again, but I did it a while ago. Try doing this:
Get Amaya.
Open some random HTML sites, and some random sites claiming to be XHTML.
Most HTML pages will be displayed somewhat right, a lot of XHTML pages will fail.
At least with the pages I tried (might be coincidence, who knows).
Well, maybe Amaya isn't a good example of "most browsers".
But, if you're sending XHTML as text/html (which you probably are), the browser will parse it as HTML (as it should). (Both the Gecko engine (Firefox) and the Trident engine (IE) will parse it as HTML. Mozilla and Microsoft have confirmed this. No idea for other browsers.) That means, when sending the browser valid XHTML, it parses as invalid HTML. If you send it HTML, it parses as valid HTML. Now what will logically be parsed best? The valid HTML.
If you send it as application/xhtml+xml, it doesn't work in Internet Explorer. If you send it as text/html to IE, application/xhtml+xml to others, you will have a really hard time fixing browser differences, as you also have to fix language differences. That's like trying to write code that compiles as both C and C++. (Well, maybe that would be a little harder.  )
Oh, I'm talking about valid HTML 4.01 Strict. That will produce code as clean as XHTML. If you use it with some common sense. And XHTML is far from "just cleaner code". It's another language. E.g. some elements SHOULD be closed in XHTML, and SHOULD NOT be closed in HTML. So they're not compatible. Unless you're not going to use <br />'s and <img />'s in your document. But I don't think you'll do that.
| snowboardalliance wrote: | | Stubru Freak wrote: | | but HTML is rendered better in most browsers. |
Ummm, show me ANY example where a html 4.01 page renders better than the same page that is xhtml compliant. Maybe if you send it as a *.xhtml file it won't work, but sending it as *.html, it is just cleaner code. |
For Understanding the matter..
http://www.sitepoint.com/forums/showthread.php?t=393445
For anyone really interested in the differences between HTML 4.01 and XHTML 1.0 [Recomendations], I have the W3C Specifications for both online at:
http://kenshi.net/html401
and
http://kenshi.net/xhtml10
HTML versions of the actual DTD's are incuded, as well as the DTD's themselves in .dtd format, but this format is not viewable in your web browser. If anyone is really that interested in having a copy of all the related DTD's for both just PM me and I will make a zipped copy available that can be viewed in a text editor.
Browsers display XHTML faster than HTML, because they use a XML parser instead of a slow SGML parser.
And XHTML files, being valid XML, are easier to parse by other softwares.
| Ranfaroth wrote: | | Browsers display XHTML faster than HTML, because they use a XML parser instead of a slow SGML parser. |
Wrong. They SHOULD use an XML parser. But really doing so would break a lot of sites claiming to be XHTML.
So for the moment, no mainstream browser that I know of really uses an XML parser for XHTML (not Opera, Firefox or IE) sent as text/html.
So XHTML sent as text/html is in fact HTML tag soup, so it will probably render slower then valid HTML.
If you send XHTML as application/xhtml+xml, some browers (at least Firefox) will render it as XML. IE will not render it at all and offer to download it.
But Mozilla explicitly states that their current SGML parser is better, and that web authors are encouraged to send XHTML as text/html if they have no good reason not to. For example, the Mozilla XML parser doesn't support incremental loading.
Not sure, but I think the same applies for Opera.
So, no matter how you sent your XHTML, it will render slower in at least Firefox and IE.
| Stubru Freak wrote: | | Wrong. They SHOULD use an XML parser. |
They do. | Quote: | | So for the moment, no mainstream browser that I know of really uses an XML parser for XHTML (not Opera, Firefox or IE) sent as text/html. |
text/hml isn't XML, so there isn't any reason for them to use an XML parser. but I wasn't talking about text/html, but about XHTML... | Quote: | | So XHTML sent as text/html is in fact HTML tag soup |
Everybody already knows that, an this has nothing to do with my post.. | Quote: | | If you send XHTML as application/xhtml+xml, some browers (at least Firefox) will render it as XML. |
Not only Firefox, but every modern browsersYou should read carefuly your link : they never say that here.
They only talk about incremental display which isn't really important in small pages (and usually, good pages are small : the scripts and the style sheet are external).
But if you were a bit aware of gecko development, you'll see that there XML parser is faster. And it's easy to understand :
First : XML is a subset of SGML, so a XML parser will have less check to do compared to a SGML parser.
Second, XML is more strict, so once again, less verifications (for instance, you end a <p> when you find the closing tag. With SGML, you have to chech each opening tag to see if this sgnificate the end of the <p> element...)
And also, the SGML parser supports deprecated features, whereas the XML doesn't. So once again, the XML parser will be faster.
| Quote: | | So, no matter how you sent your XHTML, it will render slower in at least Firefox |
Wrong.
If you send it as HTML, it's HTML. Period
If you send it as XHTML, gecko engine will use XML parser, which will be faster.
| Ranfaroth wrote: | | Stubru Freak wrote: | | Wrong. They SHOULD use an XML parser. |
They do. | Quote: | | So for the moment, no mainstream browser that I know of really uses an XML parser for XHTML (not Opera, Firefox or IE) sent as text/html. |
text/hml isn't XML, so there isn't any reason for them to use an XML parser. but I wasn't talking about text/html, but about XHTML... | Quote: | | So XHTML sent as text/html is in fact HTML tag soup |
Everybody already knows that, an this has nothing to do with my post.. | Quote: | | If you send XHTML as application/xhtml+xml, some browers (at least Firefox) will render it as XML. |
Not only Firefox, but every modern browsersYou should read carefuly your link : they never say that here.
They only talk about incremental display which isn't really important in small pages (and usually, good pages are small : the scripts and the style sheet are external).
But if you were a bit aware of gecko development, you'll see that there XML parser is faster. And it's easy to understand :
First : XML is a subset of SGML, so a XML parser will have less check to do compared to a SGML parser.
Second, XML is more strict, so once again, less verifications (for instance, you end a <p> when you find the closing tag. With SGML, you have to chech each opening tag to see if this sgnificate the end of the <p> element...)
And also, the SGML parser supports deprecated features, whereas the XML doesn't. So once again, the XML parser will be faster.
| Quote: | | So, no matter how you sent your XHTML, it will render slower in at least Firefox |
Wrong.
If you send it as HTML, it's HTML. Period
If you send it as XHTML, gecko engine will use XML parser, which will be faster. |
Sorry to treat text/html as XML, but I didn't know you knew so much, and I didn't want to get a reaction "Well don't send it as application/xhtml+xml then".
I still think that for a lot of people with slow internet connections the incremental loading (on a normal page) will be more useful then the speed gained in parsing. Are there any statistics on that?
Also IE doesn't support XHTML. So you have to do content negotiation which isn't a good idea in general. (A markup document being both XHTML and HTML doesn't exist.)
You should check ANY change in both IE and an XHTML-compatible browser. And even if you do that, there will always be people copying your code, not knowing about HTML vs XHTML, who will almost certainly break something in one of the browsers by doing so.
| Stubru Freak wrote: | | I still think that for a lot of people with slow internet connections the incremental loading (on a normal page) will be more useful then the speed gained in parsing. |
I don't know it this incremental problem also occures in other browsers engine (Opera's presto, KHTML), but for Gecko, it's a bug which will be corrected some day 
| Quote: | | Also IE doesn't support XHTML. So you have to do content negotiation which isn't a good idea in general. (A markup document being both XHTML and HTML doesn't exist.) |
They're are scripts (especially in PHP) to transform XHTML documents in HTML documents server-side.
But as you know, XHTML as been designed to degrade graefully in HTML-only browsers (like IE), so it's still possible to serve the same document, only changing the media type (very easy)
| Ranfaroth wrote: | | Stubru Freak wrote: | | I still think that for a lot of people with slow internet connections the incremental loading (on a normal page) will be more useful then the speed gained in parsing. |
I don't know it this incremental problem also occures in other browsers engine (Opera's presto, KHTML), but for Gecko, it's a bug which will be corrected some day |
I know, I'm waiting for that.
| Quote: | | Quote: | | Also IE doesn't support XHTML. So you have to do content negotiation which isn't a good idea in general. (A markup document being both XHTML and HTML doesn't exist.) |
They're are scripts (especially in PHP) to transform XHTML documents in HTML documents server-side.
But as you know, XHTML as been designed to degrade graefully in HTML-only browsers (like IE), so it's still possible to serve the same document, only changing the media type (very easy) |
It still is risky. Expecially those who use IE to test their website will break other browsers a lot this way.
But I agree, if you understand it enough, go ahead and use XHTML
Just because other sites have lots of errors in them, why shouldn't you make your site neat and tidy and compatible with more than 1 or 2 standard browsers on 1 standard platform? Many browsers today forgive many html-errors, but will the browsers of tomorrow do the same? Or the mobile phones? TV-browsers? Browsers for blind people etc...
I don't say you should jump right to the latest xhtml-version, but xhtml 1.0 is tidy and compatible, and you are allowed to run the pages as text/html for those outdated browsers like (if you have not heard of it, ask your parents): Microsoft Internet Explorer.
Put this on the top of your webpage (if you use php) to check if the browser supports xhtml+xml and apply the right content-type:
| Code: | <?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml"))
{ header("Content-Type: application/xhtml+xml; charset=iso-8859-1"); }
else
{ header("Content-Type: text/html; charset=iso-8859-1"); }
?> |
PS: in my code example, I use iso-8859-1 as charset. If your charset is something else, you must of course change/remove that.
| cavey wrote: | Just because other sites have lots of errors in them, why shouldn't you make your site neat and tidy and compatible with more than 1 or 2 standard browsers on 1 standard platform? Many browsers today forgive many html-errors, but will the browsers of tomorrow do the same? Or the mobile phones? TV-browsers? Browsers for blind people etc...
I don't say you should jump right to the latest xhtml-version, but xhtml 1.0 is tidy and compatible, and you are allowed to run the pages as text/html for those outdated browsers like (if you have not heard of it, ask your parents): Microsoft Internet Explorer.
Put this on the top of your webpage (if you use php) to check if the browser supports xhtml+xml and apply the right content-type:
| Code: | <?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml"))
{ header("Content-Type: application/xhtml+xml; charset=iso-8859-1"); }
else
{ header("Content-Type: text/html; charset=iso-8859-1"); }
?> |
PS: in my code example, I use iso-8859-1 as charset. If your charset is something else, you must of course change/remove that. |
Shouldn't XHTML be sent as UTF-8?
| Stubru Freak wrote: | | Shouldn't XHTML be sent as UTF-8? |
Not that I know of. But if you use UTF-8, you just replace what I wrote in my previous post.
| cavey wrote: | | Stubru Freak wrote: | | Shouldn't XHTML be sent as UTF-8? |
Not that I know of. But if you use UTF-8, you just replace what I wrote in my previous post. |
Sorry I'm wrong.
You should place an xml prolog when the encoding is different from UTF-8 or UTF-16
The thing I like about XHTML is it needs be proper, forcing big name sites to clean up their 200+ errors. Good formed sites is really needed on the internet and will help all sites to be rendered the same no matter what browser is being used. All good things, I use it at the Novis Design site.
Thanks
GS - ND
| Ranfaroth wrote: | Browsers display XHTML faster than HTML, because they use a XML parser instead of a slow SGML parser.
And XHTML files, being valid XML, are easier to parse by other softwares. |
this is unfortunately not totally correct as most xhtml pages are sent as html since IE cant read application/xhtml+xml. If it wasnt for IE, we wouldnt even have this thread and everyone could happily use xhtml, but thats not the case.
One technique i used is sending the correct xml header to browsers that can read it using php (everything except IE) and sending html 4 to IE. The problem is if you arent using php on your site, it will probably slow down the load time to add it, and could slow it down a little even if you already do.
One last thing to note is that if you really are sending your pages as xhtml, the normal way of commenting script and styles wont work. You have to do it like this:
<script type="text/javascript">
<!--//--><![CDATA[//><!--
....
//--><!]]>
</script>
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
....
/*]]>*/-->
</style>
And to the best of my knowledge regarding the charset, it actually should be omitted as XML is a self-describing language and that info should be in the xml version.
XHTML still has some issuse true, but it is trying to undo years of browser compition and the stupidity of Microsoft, that takes some time, for now I think that we should make sure our documents are well formed at least, XHML is still buggy and demanding but HTML is not going to develop any farther so some evoltion some were on the web in common Language is need and that what XHTML is but its still a child give it a break!
| <BananasAreForMonkeys wrote: | | this is unfortunately not totally correct as most xhtml pages are sent as html since IE cant read application/xhtml+xml. |
As I said above, XHTML sent has text/html is no more XHTML. | Quote: | | One last thing to note is that if you really are sending your pages as xhtml, the normal way of commenting script and styles wont work. |
Your code sample are useless.
First : you never need to put your scripts in comments (nether in XHTML nor in HTML).
Second : In XHTML, if you have a script which contains special entities (example "&"), you have to escape your code, puting it in a CDATA section (which is very easy : <![CDATA[ your code ]]>)
|
