RuebenMarley
10-14-2008, 09:54 PM
Does anyone know if I can head directly for XHTML without learning HTML?
Is there a difference?
Is there a difference?
Click to See Complete Forum and Search --> : Is there a difference?
scragar
10-14-2008, 10:43 PM
I wouldn't recommend it, XHTML is like strict HTML, with a few minor differences, XHTML will argue with you about closing all tags, it will want a valid doctype, it demands CDATA tags where they should be used. Over all it's a good idea to learn it(even if you never use it the practice of using it makes a lot of sense), I just don't think it's wise to skip HTML to learn it.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xml:lang="en" lang="en">
<head>
<title>Throw error</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
<p>Some content that throws an error, p element not closed
</body>
</html>
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xml:lang="en" lang="en">
<head>
<title>Throw error</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
<p>Some content that throws an error, p element not closed
</body>
</html>
felgall
10-15-2008, 03:13 AM
IE doesn't even support XHTML so if you are creating web pages you'll need to use HTML (if you write your page in XHTML you'll need to serve it as HTML for IE to be able to display it).
It is still worthwhile including all the optional tags where HTML requires browsers to cope with their not being there - it will make your pages easier to maintain.
It is still worthwhile including all the optional tags where HTML requires browsers to cope with their not being there - it will make your pages easier to maintain.
opifex
10-15-2008, 04:18 AM
IE doesn't even support XHTML
ie7 does actually support the XML conformance tag now.
for ltIE7 you can use server side browser detection or conditional comments to change the Content-Type to "text/html "instead of "application/xhtml+xml" and IE will more or less behave.
ie7 does actually support the XML conformance tag now.
for ltIE7 you can use server side browser detection or conditional comments to change the Content-Type to "text/html "instead of "application/xhtml+xml" and IE will more or less behave.
Kor
10-15-2008, 06:29 AM
Does anyone know if I can head directly for XHTML without learning HTML?
Is there a difference?
XHTML means eXtended HTML. So, how can you learn an extension of a language if you don't first learn the language itself? :rolleyes:
Another definition of XHTML could be: how to press HTML in order to fit the XML coding exigences. Viewed from this angle, it is more obvious that you must learn HTML in able to know what is to be fit within that XML-like code.
What to use: HTML or XHTML? It depends on your needs. If you intend to work directly with XML files (XML islands), you should use XHTML, otherwise HTML strict should be enough.
There is no big difference between HTML strict and XHTML, except the way some tags (so called "empty" tags), such as IMG, INPUT, BR..., must be closed, and some other minor issues (CDATA, required lowercase for tag names and attributes names, a.s.o.) - all these are, in fact, the XML strict way of coding. That is all.
Is there a difference?
XHTML means eXtended HTML. So, how can you learn an extension of a language if you don't first learn the language itself? :rolleyes:
Another definition of XHTML could be: how to press HTML in order to fit the XML coding exigences. Viewed from this angle, it is more obvious that you must learn HTML in able to know what is to be fit within that XML-like code.
What to use: HTML or XHTML? It depends on your needs. If you intend to work directly with XML files (XML islands), you should use XHTML, otherwise HTML strict should be enough.
There is no big difference between HTML strict and XHTML, except the way some tags (so called "empty" tags), such as IMG, INPUT, BR..., must be closed, and some other minor issues (CDATA, required lowercase for tag names and attributes names, a.s.o.) - all these are, in fact, the XML strict way of coding. That is all.
Kor
10-15-2008, 06:36 AM
IE doesn't even support XHTML
What? Are you sure? What do you mean by that?
As far as I know, IE supports XHTML, and IE7 has even a good handling of all the XML exigencies, even better sometimes than Mozilla.
So, what were you thinking about when saying that "IE doesn't even support XHTML"?
What? Are you sure? What do you mean by that?
As far as I know, IE supports XHTML, and IE7 has even a good handling of all the XML exigencies, even better sometimes than Mozilla.
So, what were you thinking about when saying that "IE doesn't even support XHTML"?
felgall
10-15-2008, 02:05 PM
ie7 does actually support the XML conformance tag now.
for ltIE7 you can use server side browser detection or conditional comments to change the Content-Type to "text/html "instead of "application/xhtml+xml" and IE will more or less behave.
That is what I said. IE does not support XHTML - you have to serve it as HTML in order for IE to be able to display it.
The difference between XHTML and HTML IS the Content-Type
"application/xhtml+xml" means the page is XHTML
"text/html" means the page is HTML
what it say it is in the page is irrelevant as the browser uses the Content-Type to work out which it is.
Anyway if you write XHTML using all the permissible constructs then it can't be served as HTML - you need to limit yourself by following the rules in Appendix C if you want to be able to serve it as HTML.
<a id="here"/> is valid XHTML but will not work properly if served as HTML.
One of the easiest ways to tell if you are coding real XHTML or HTML pretending to be XHTML from the code itself is to see if you are leaving a space before the /> in your singleton tags. XHTML doesn't need a space there but HTML does because the / is invalid and not having the space there will invalidate the preceding attribute declaration.
for ltIE7 you can use server side browser detection or conditional comments to change the Content-Type to "text/html "instead of "application/xhtml+xml" and IE will more or less behave.
That is what I said. IE does not support XHTML - you have to serve it as HTML in order for IE to be able to display it.
The difference between XHTML and HTML IS the Content-Type
"application/xhtml+xml" means the page is XHTML
"text/html" means the page is HTML
what it say it is in the page is irrelevant as the browser uses the Content-Type to work out which it is.
Anyway if you write XHTML using all the permissible constructs then it can't be served as HTML - you need to limit yourself by following the rules in Appendix C if you want to be able to serve it as HTML.
<a id="here"/> is valid XHTML but will not work properly if served as HTML.
One of the easiest ways to tell if you are coding real XHTML or HTML pretending to be XHTML from the code itself is to see if you are leaving a space before the /> in your singleton tags. XHTML doesn't need a space there but HTML does because the / is invalid and not having the space there will invalidate the preceding attribute declaration.
scragar
10-15-2008, 02:14 PM
that does annoy me, every browser accepts:
<script type='text/javascript' src='someCode.js'/>
Except IE anyway, even in it's XHTML accepting mode it still demands a seperate closing tag, which is so very wrong(same rule applies to lots of tags that have opening and closing, but not always content, textarea being a big example).
<script type='text/javascript' src='someCode.js'/>
Except IE anyway, even in it's XHTML accepting mode it still demands a seperate closing tag, which is so very wrong(same rule applies to lots of tags that have opening and closing, but not always content, textarea being a big example).
Jeff Mott
10-15-2008, 06:29 PM
Differences in XHTML handling (http://www.webdevout.net/articles/beware-of-xhtml#examples) is a great resource for testing. You can see how real XHTML renders, and you can see how IE handles it.
Jeff Mott
10-15-2008, 06:31 PM
Except IE anyway, even in it's XHTML accepting mode it still demands a seperate closing tag, which is so very wrong(same rule applies to lots of tags that have opening and closing, but not always content, textarea being a big example).That's because the page isn't being parsed as XML. It's still run through the same old HTML engine.
felgall
10-15-2008, 06:37 PM
IE can only handle "XHTML" if it thinks it is HTML or XHM. If you serve it as real XHTML then all IE will do is offer the file for download.
opifex
10-15-2008, 10:16 PM
here are a couple of good discussions about how IE handles and can be urged to handle xhtml... complete with working examples that you can try in your favorite version of IE ...
recently...
http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML
and 4 years ago...
http://annevankesteren.nl/2004/07/ie-xhtml
both use real xhtml examples..... PLEASE try them in ie7, ie6 and ie5.5 before making comments about why they don't work or why they can't work or that they aren't this or that, etc.
recently...
http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML
and 4 years ago...
http://annevankesteren.nl/2004/07/ie-xhtml
both use real xhtml examples..... PLEASE try them in ie7, ie6 and ie5.5 before making comments about why they don't work or why they can't work or that they aren't this or that, etc.
felgall
10-15-2008, 10:38 PM
recently...
http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML
The first thing I noticed in that page was the following line
AddType text/html .xhtml
which is an instruction to the web server to take files with an xhtml suffix and serve them as HTML instead of as XHTML because of the fact that if you serve XHTML to IE as XHTML then IE will offer it for download rather than display it since IE doesn't understand XHTML.
if the type is text/html then the file is HTML. An XHTML file has a type of application/xhtml+xml. What is actually in the file itself doesn't control whether it is HTML or XHTML.
If you follow appendix C you can write XHTML that can be served as HTML where the above command to treat it as HTML will work. If you don't follow appendix C then you can't serve it as text/html because none of the valid XHTML statements that are not able to be translated as HTML will work.
For example <script type="text/javascript" src="myjs.js"/> is completely valid XHTML whereas in HTML you'd need <script type="text/javascript" src="myjs.js"></script> (which just happens to also be valid XHTML). Also
<img alt=alt text" src="myimg.gif"/> is valid XHTML which will not work as HTML (unless you add a space before the / so that only the / is discarded as invalid instead of the entire src=).
As another example the following JavaScript works with HTML but not with XHTML:
document.write()
innerHTML
document.createElement()
The following works in XHTML but not HTML:
document.createElementNS()
http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML
The first thing I noticed in that page was the following line
AddType text/html .xhtml
which is an instruction to the web server to take files with an xhtml suffix and serve them as HTML instead of as XHTML because of the fact that if you serve XHTML to IE as XHTML then IE will offer it for download rather than display it since IE doesn't understand XHTML.
if the type is text/html then the file is HTML. An XHTML file has a type of application/xhtml+xml. What is actually in the file itself doesn't control whether it is HTML or XHTML.
If you follow appendix C you can write XHTML that can be served as HTML where the above command to treat it as HTML will work. If you don't follow appendix C then you can't serve it as text/html because none of the valid XHTML statements that are not able to be translated as HTML will work.
For example <script type="text/javascript" src="myjs.js"/> is completely valid XHTML whereas in HTML you'd need <script type="text/javascript" src="myjs.js"></script> (which just happens to also be valid XHTML). Also
<img alt=alt text" src="myimg.gif"/> is valid XHTML which will not work as HTML (unless you add a space before the / so that only the / is discarded as invalid instead of the entire src=).
As another example the following JavaScript works with HTML but not with XHTML:
document.write()
innerHTML
document.createElement()
The following works in XHTML but not HTML:
document.createElementNS()
drhowarddrfine
10-15-2008, 10:51 PM
Just want to ditto everything Stephen has said. IE has never supported XHTML, IE8 will not support it, and Microsoft has no plans to ever support it. Another example of how IE holds back the web.
opifex
10-15-2008, 10:58 PM
... so, comments before trying the examples as indicated?
or did you actually try them in IE???
or did you actually try them in IE???
opifex
10-15-2008, 11:42 PM
we know the problems with IE - limited support, MS-only support, no support, etc.
the point in issue is what the user sees on his screen. sometimes MS doesn't make that task as convenient as it might be. that's life.
our jobs as developers is to address these problems in sensible manner and deliver a product according to client specs that will render acceptably cross-browser... without whining and without evangelizing.
we make it work... if we don't, we will be looking for new jobs.
... the web designer says, "oh, yes we can do that... and what else do you want to add to the page design?"
... the web programmer says, "yes, maybe we can do that, but....."
... and the web developer says, "here's what you asked for and it works."
we are at webdeveloper.com, right?
the point in issue is what the user sees on his screen. sometimes MS doesn't make that task as convenient as it might be. that's life.
our jobs as developers is to address these problems in sensible manner and deliver a product according to client specs that will render acceptably cross-browser... without whining and without evangelizing.
we make it work... if we don't, we will be looking for new jobs.
... the web designer says, "oh, yes we can do that... and what else do you want to add to the page design?"
... the web programmer says, "yes, maybe we can do that, but....."
... and the web developer says, "here's what you asked for and it works."
we are at webdeveloper.com, right?
Kor
10-16-2008, 12:03 AM
I am still looking at XHTML as an extension of HTML, as its name suggests, not as a different language. And some of you are talking about the relationship between IE and XHTML as if Microsoft was forced to adopt XHTML in their browsers, which is not true. XHTML is nothing but a step in the evolution of HTML, not a language in itself. W3C says it very clear: "XHTML 1.0 is a reformulation of HTML 4.01 in XML, and combines the strength of HTML 4 with the power of XML."
The next HTML generation is already on draft, and it will bear the name HTML 5.0. That means XHTML is not a fracture in the HTML history, it is a simple episode. It is hard to say now which will be the relationship between HTML 5.0 and XHTML2, but this is another discussion. Let's note that within W3C activity, the XHTML2 Working group is part of the HTML Activity.
I don't say that, W3C says that.
http://www.w3.org/TR/html5-diff/
http://www.w3.org/2007/03/XHTML2-WG-charter
Most of the time people here believe in a war between W3C and Microsoft, but forget that W3C is Microsoft and Mozilla and Opera and Apple and Adobe... and about 400 other companies from the Web domain.
http://www.w3.org/Consortium/Member/List
Some says that a syntax like <script /> should be the only one correct in XHTML, but I don't sense the reason. As far as I have studied W3C XHTML recommendations, only the empty HTML tags have to be closed that way. As long as HTML <script> tag is a non empty tag by default, he needs no such an extra facility. Why should be things more intricate than necessarily?
The next HTML generation is already on draft, and it will bear the name HTML 5.0. That means XHTML is not a fracture in the HTML history, it is a simple episode. It is hard to say now which will be the relationship between HTML 5.0 and XHTML2, but this is another discussion. Let's note that within W3C activity, the XHTML2 Working group is part of the HTML Activity.
I don't say that, W3C says that.
http://www.w3.org/TR/html5-diff/
http://www.w3.org/2007/03/XHTML2-WG-charter
Most of the time people here believe in a war between W3C and Microsoft, but forget that W3C is Microsoft and Mozilla and Opera and Apple and Adobe... and about 400 other companies from the Web domain.
http://www.w3.org/Consortium/Member/List
Some says that a syntax like <script /> should be the only one correct in XHTML, but I don't sense the reason. As far as I have studied W3C XHTML recommendations, only the empty HTML tags have to be closed that way. As long as HTML <script> tag is a non empty tag by default, he needs no such an extra facility. Why should be things more intricate than necessarily?
Jeff Mott
10-16-2008, 12:12 AM
My post above was supposed to have a link. I just noticed I must not have included it, and the post doesn't make much sense without it. I edited my post above, and below is also what you should have seen the first time around.
----
Differences in XHTML handling (http://www.webdevout.net/articles/beware-of-xhtml#examples) is a great resource for testing. You can see how real XHTML renders, and you can see how IE handles it.
----
Differences in XHTML handling (http://www.webdevout.net/articles/beware-of-xhtml#examples) is a great resource for testing. You can see how real XHTML renders, and you can see how IE handles it.
Kor
10-16-2008, 12:16 AM
Speaking about the fact that IE does not handle XHTML recommendations? I don't think so. Let's note, for instance, that IE is the only browser which follows strictly the inserting of CDATA islands recommendation in case of javascript embedded codes. Moz is tolerant and runs the code even without CDATA islands, while IE does not.
Kor
10-16-2008, 12:23 AM
My post above was supposed to have a link. I just noticed I must not have included it, and the post doesn't make much sense without it. I edited my post above, and below is also what you should have seen the first time around.
----
Differences in XHTML handling (http://www.webdevout.net/articles/beware-of-xhtml#examples) is a great resource for testing. You can see how real XHTML renders, and you can see how IE handles it.
That article is focused on the formal language, not on the general aim of the language. Now what is the importance of the fact that IE recognize or not the application/xhtml+xml accept header? Why should it do that? From my point of view, IE is right, as it sees no need to treat XHTML as a different language, that is all.
----
Differences in XHTML handling (http://www.webdevout.net/articles/beware-of-xhtml#examples) is a great resource for testing. You can see how real XHTML renders, and you can see how IE handles it.
That article is focused on the formal language, not on the general aim of the language. Now what is the importance of the fact that IE recognize or not the application/xhtml+xml accept header? Why should it do that? From my point of view, IE is right, as it sees no need to treat XHTML as a different language, that is all.
Jeff Mott
10-16-2008, 12:57 AM
Now what is the importance of the fact that IE recognize or not the application/xhtml+xml accept header? Why should it do that?Because otherwise the browsers are not parsing the code as XML. It's still reading the page as if it were SGML. And as you know, all XHTML is, is an XML implementation of HTML. If you cut out XML (which you do by not using application/xhtml+xml), then it isn't XHTML anymore.
opifex
10-16-2008, 01:02 AM
level-headed and to the point as always, Kor!
i do agree that (x)html is NOT a different language, but a step in the evolution of html that "allows" us to expand the envelope of html coding to the limits of the individual browsers while following the consortium guidelines and standards.
a definition of extensibility from whatis.com...
In information technology, extensible describes something, such as a program, programming language, or protocol, that is designed so that users or developers can expand or add to its capabilities. Extensibility can be a primary reason for the system, as in the case of the Extensible Markup Language (XML), or it may be only a minor feature.
Approaches to extensibility include facilities (sometimes called hooks) for allowing users to insert their own program routines, the ability to define new data types, and the ability to define new formatting markup tags.
... not bad.;)
i do agree that (x)html is NOT a different language, but a step in the evolution of html that "allows" us to expand the envelope of html coding to the limits of the individual browsers while following the consortium guidelines and standards.
a definition of extensibility from whatis.com...
In information technology, extensible describes something, such as a program, programming language, or protocol, that is designed so that users or developers can expand or add to its capabilities. Extensibility can be a primary reason for the system, as in the case of the Extensible Markup Language (XML), or it may be only a minor feature.
Approaches to extensibility include facilities (sometimes called hooks) for allowing users to insert their own program routines, the ability to define new data types, and the ability to define new formatting markup tags.
... not bad.;)
Jeff Mott
10-16-2008, 01:09 AM
Kor, look at these two pages in Firefox.
http://www.webdevout.net/articles/beware-of-xhtml-examples/2.html
http://www.webdevout.net/articles/beware-of-xhtml-examples/2.xhtml
The source code of these two are identical, yet one is XHTML and one is not. The only difference is the mime type, because the mime type is how browsers decide what kind of file it is and how to handle it. If the mime type is text/html, then browsers treat it as good-old-fashioned HTML, regardless of what doctype is at the top. If the mime type is application/xhtml+xml, then browsers treat it as XHTML and parse it with an XML parser, which is why we can use MathML.
If you don't use the application/xhtml+xml mime type, then as far as the browser is concerned, it isn't XHTML.
http://www.webdevout.net/articles/beware-of-xhtml-examples/2.html
http://www.webdevout.net/articles/beware-of-xhtml-examples/2.xhtml
The source code of these two are identical, yet one is XHTML and one is not. The only difference is the mime type, because the mime type is how browsers decide what kind of file it is and how to handle it. If the mime type is text/html, then browsers treat it as good-old-fashioned HTML, regardless of what doctype is at the top. If the mime type is application/xhtml+xml, then browsers treat it as XHTML and parse it with an XML parser, which is why we can use MathML.
If you don't use the application/xhtml+xml mime type, then as far as the browser is concerned, it isn't XHTML.
Kor
10-16-2008, 02:23 AM
Because otherwise the browsers are not parsing the code as XML. It's still reading the page as if it were SGML.
I agree. But is that supposes to make me more happy or less happy? :)
I agree. But is that supposes to make me more happy or less happy? :)
Jeff Mott
10-16-2008, 02:28 AM
I agree. But is that supposes to make me more happy or less happy? :)
No. It's supposed to make you realize that there are differences between HTML and XHTML, and that IE does not support XHTML.
No. It's supposed to make you realize that there are differences between HTML and XHTML, and that IE does not support XHTML.
Kor
10-16-2008, 02:44 AM
Hey, you might believe that I am a Microsoft advocate, which definitely I am not. I still consider the IE6 the worst still-in-use browser possible ever, IE7 as a seventh level browser in a world of eight leveled browsers and IE8 as a deplorable new version of the much better and decent IE7. I just wanted to emphasize that XHTML should not be treated as a different language from HTML.
And even some of us believe that XHTML should be HTML included in XML while the others think contrary, that changes nothing regarding to the genuine topic of this thread. Remember:
Does anyone know if I can head directly for XHTML without learning HTML?
Is there a difference?
Again. My answer is: RuebenMarley, your question has no meaning. XHTML is HTML written in an XML way. XHTML is HTML, thus you can not "learn XHTML without learning HTML" same as you can not learn American English without learning English. When you learn XHTML you learn in fact HTML as well.
And even some of us believe that XHTML should be HTML included in XML while the others think contrary, that changes nothing regarding to the genuine topic of this thread. Remember:
Does anyone know if I can head directly for XHTML without learning HTML?
Is there a difference?
Again. My answer is: RuebenMarley, your question has no meaning. XHTML is HTML written in an XML way. XHTML is HTML, thus you can not "learn XHTML without learning HTML" same as you can not learn American English without learning English. When you learn XHTML you learn in fact HTML as well.
Jeff Mott
10-16-2008, 02:55 AM
Hey, you might believe that I am a Microsoft advocate, which definitely I am not.Makes no difference if you are or aren't.
Again. My answer is: ... XHTML is HTML written in an XML way
No one disputed your original answer. Your first post in this thread was just fine. All felgall, drhowarddrfine and I were clarifying for you is that IE does not support XHTML. That's all.
Again. My answer is: ... XHTML is HTML written in an XML way
No one disputed your original answer. Your first post in this thread was just fine. All felgall, drhowarddrfine and I were clarifying for you is that IE does not support XHTML. That's all.
Kor
10-16-2008, 03:20 AM
All felgall, drhowarddrfine and I were clarifying for you is that IE does not support XHTML. That's all.
OK. It looks like we only have a different understanding about what "support" means, that is all. I am used to judge the basis of facts, not the subtle philosophical nuances. When I say "Firefox does not support ActiveX" I understand simply that ActiveX can not run (so far) on Gecko engine. I know that IE interprets XHTML codes in a SGML way, not in an XML way and I agree that IE will not interpret some of the possible XHTML coding gadgets (like <script /> and other useless or non-important shortcuts), but that does not mean that "IE does not support XHTML", as long as I write documents in XHTML and IE is able to run them. I might agree that IE has an incomplete support, or a different support (based on SGML) for XHTML, but not a lack of support.
OK. It looks like we only have a different understanding about what "support" means, that is all. I am used to judge the basis of facts, not the subtle philosophical nuances. When I say "Firefox does not support ActiveX" I understand simply that ActiveX can not run (so far) on Gecko engine. I know that IE interprets XHTML codes in a SGML way, not in an XML way and I agree that IE will not interpret some of the possible XHTML coding gadgets (like <script /> and other useless or non-important shortcuts), but that does not mean that "IE does not support XHTML", as long as I write documents in XHTML and IE is able to run them. I might agree that IE has an incomplete support, or a different support (based on SGML) for XHTML, but not a lack of support.
felgall
10-16-2008, 03:20 AM
No one disputed your original answer. Your first post in this thread was just fine. All felgall, drhowarddrfine and I were clarifying for you is that IE does not support XHTML. That's all.
Exactly.
There are two things that make a page XHTML rather than HTML and this simple PHP script is the simplest way I could come up with to illustrate it. The parts that make it XHTML are in bold. If either of those is missing it isn't XHTML. I chose PHP for this example because one of the two things is an HTTP header that can't be set from the (X)HTML file.
<?php
header("Content-Type: application/xhtml+xml; charset=utf-8");
echo '<'.'?xml version="1.0" encoding="UTF-8"?','>';
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Real XHTML</title>
</head><body>
<p>This page is real XHTML. If your browser displays this as a web page then it supports XHTML. If instead the file was offered for download then your browser doesn't support XHTML.</p>
</body></html>
And http://www.felgall.com/realxhtml.php is a link to a page that contains that exact code. Jeff's earlier link contains lots of additional examples.
There is little point in serving pages to IE as HTML and to everything else as XHTML because the JavaScript that interacts with the page would need to be different for each as well and even though testing server side to decide whether the browser will accept XHTML or not is easy, setting up the JavaScript so that it will work both ways is a lot more complex.
Does any of the JavaScript experts here know of a way of testing when to use document.createElement(tag) and when to use document.createElementNS(tag,namespace) etc without assuming that the browser is IE when XHTML isn't supported?
Exactly.
There are two things that make a page XHTML rather than HTML and this simple PHP script is the simplest way I could come up with to illustrate it. The parts that make it XHTML are in bold. If either of those is missing it isn't XHTML. I chose PHP for this example because one of the two things is an HTTP header that can't be set from the (X)HTML file.
<?php
header("Content-Type: application/xhtml+xml; charset=utf-8");
echo '<'.'?xml version="1.0" encoding="UTF-8"?','>';
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Real XHTML</title>
</head><body>
<p>This page is real XHTML. If your browser displays this as a web page then it supports XHTML. If instead the file was offered for download then your browser doesn't support XHTML.</p>
</body></html>
And http://www.felgall.com/realxhtml.php is a link to a page that contains that exact code. Jeff's earlier link contains lots of additional examples.
There is little point in serving pages to IE as HTML and to everything else as XHTML because the JavaScript that interacts with the page would need to be different for each as well and even though testing server side to decide whether the browser will accept XHTML or not is easy, setting up the JavaScript so that it will work both ways is a lot more complex.
Does any of the JavaScript experts here know of a way of testing when to use document.createElement(tag) and when to use document.createElementNS(tag,namespace) etc without assuming that the browser is IE when XHTML isn't supported?
Jeff Mott
10-16-2008, 03:40 AM
I am used to judge the basis of facts, not the subtle philosophical nuances.
It's borderline insulting when you imply that the rest of us don't judge by facts, especially when the facts are against you, Kor.
It's really quite simple. http://www.webdevout.net/articles/beware-of-xhtml-examples/2.xhtml: In Firefox, works; in IE, doesn't work.
I know that IE interprets XHTML codes in a SGML way, not in an XMLHTML as XML is exactly what makes XHTML XHTML. HTML as SGML is just traditional HTML.
I'm not sure if you're really so caught up on the details or if you just can't ever admit being wrong. We're all wrong from time to time. Recently felgall showed I was wrong in another topic. It isn't a big deal unless you make it a big deal.
It's borderline insulting when you imply that the rest of us don't judge by facts, especially when the facts are against you, Kor.
It's really quite simple. http://www.webdevout.net/articles/beware-of-xhtml-examples/2.xhtml: In Firefox, works; in IE, doesn't work.
I know that IE interprets XHTML codes in a SGML way, not in an XMLHTML as XML is exactly what makes XHTML XHTML. HTML as SGML is just traditional HTML.
I'm not sure if you're really so caught up on the details or if you just can't ever admit being wrong. We're all wrong from time to time. Recently felgall showed I was wrong in another topic. It isn't a big deal unless you make it a big deal.
Kor
10-16-2008, 04:50 AM
Does any of the JavaScript experts here know of a way of testing when to use document.createElement(tag) and when to use document.createElementNS(tag,namespace) etc without assuming that the browser is IE when XHTML isn't supported?
HTML DOM and XML DOM are different models, I agree. I agree also that this dual DOM interpretation looks like a mess and something must be done to stabilize both the HyperText Markup Language and DOM model. This is probably the starting point of general misunderstanding. IE treats XHTML as "XML like" HTML, while Mozilla considers XHTML as "HTML like" XML. I am not sure whose position is better. As I said, from this point of view, IE treats XHTML different from other browsers, we may say that IE has his own XHTML variant, without running counter to the general W3C definition of XHTML. If this is what you meant, I agree.
HTML DOM and XML DOM are different models, I agree. I agree also that this dual DOM interpretation looks like a mess and something must be done to stabilize both the HyperText Markup Language and DOM model. This is probably the starting point of general misunderstanding. IE treats XHTML as "XML like" HTML, while Mozilla considers XHTML as "HTML like" XML. I am not sure whose position is better. As I said, from this point of view, IE treats XHTML different from other browsers, we may say that IE has his own XHTML variant, without running counter to the general W3C definition of XHTML. If this is what you meant, I agree.
Kor
10-16-2008, 04:57 AM
It's borderline insulting when you imply that the rest of us don't judge by facts, especially when the facts are against you, Kor.
You start again to become aggressive. I have not insulting anyone. I feel constrained to remind you that you should respect the others positions, no matter if you agree them or not. I can understand your arguments, thus all I want is to understand mine.
You start again to become aggressive. I have not insulting anyone. I feel constrained to remind you that you should respect the others positions, no matter if you agree them or not. I can understand your arguments, thus all I want is to understand mine.
Jeff Mott
10-16-2008, 12:49 PM
You start again to become aggressive.
That wasn't aggressive. But what I did say, I said because you were condescending.
That wasn't aggressive. But what I did say, I said because you were condescending.
felgall
10-16-2008, 03:38 PM
Let's not have any off topic arguments start over this. One of the great things about this forum is that there are a number of knowledgable people here who all come from slightly different backgrounds and therefore have slightly different viewpoints. While we may not always agree on everything we can at least respect each other's opinions and sometimes learn something new as well.
RuebenMarley
10-17-2008, 08:33 AM
I did some research on it, as a beginner it's better to learn html first, 'cause xhtml is based on html, stands for EXtensible HyperText Markup Language, but I dont know about the ie's support of xhtml issue, hehe, but quite enjoy you guys argue.
webdeveloper.com
Copyright Internet.com Inc., All Rights Reserved.
Copyright Internet.com Inc., All Rights Reserved.