homepage Welcome to WebmasterWorld Guest from 23.23.12.202
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 75 message thread spans 3 pages: 75 ( [1] 2 3 > >     
Why most of us should NOT use XHTML
DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 7:39 pm on Apr 1, 2006 (gmt 0)

Ian Hickson, a member of the Mozilla.org Browser Standards Compliance QA team and an invited expert in the W3C CSS Working Group, explains why XHTML should not be sent as text/html: [hixie.ch...]

 

tedster

WebmasterWorld Senior Member tedster us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 10:06 pm on Apr 1, 2006 (gmt 0)

Great link, Dr. Doc

Abstract
--------

A number of problems resulting from the use of the text/html MIME type
in conjunction with XHTML content are discussed. It is suggested that
XHTML delivered as text/html is broken and XHTML delivered as text/xml
is risky, so
authors intending their work for public consumption
should stick to HTML 4.01
, and authors who wish to use XHTML should
deliver their markup as application/xhtml+xml.

[emphasis added]

We've been trying to shout this from the rooftops -- but no rooftop is tall enough to get through to all those developers who feel that xhtml is what they "should" be writing in order to be on the cutting edge.

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 12:00 am on Apr 2, 2006 (gmt 0)

That "article" is a great read and truly an eye opener when read objectively! I must admit that I was once tempted by the XHTML bandwagon myself, only to revert back to HTML 4.01 after reading that article what now seems so long ago. I never use XHTML without sending it as application/xhtml+xml and with the XML prolog included as well.

I especially like the section about The Myth of "HTML-compatible XHTML 1.0 documents".

The article is so good it is worth reading and pondering at least twice if you are still new to XHTML.

When sending XHTML as text/html ... :
The "/>" empty tag syntax actually has totally different meaning in
HTML4. (It's the SHORTTAG minimisation feature known as NET, if I
recall the name correctly.) Specifically, the XHTML

<p> Hello <br /> World </p>

...is, if interpreted as HTML4, exactly equivalent to:

<p> Hello <br>&gt; World </p>

...and should really be rendered as:

Hello
> World


Wlauzon

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 12026 posted 9:00 am on Apr 2, 2006 (gmt 0)

Ian Hickson, a member of the Mozilla.org Browser Standards Compliance QA team and an invited expert in the W3C CSS Working Group, explains why XHTML should not be sent as text/html: [hixie.ch...]

Hmm.. interesting.

So it appears that even though the XHTML "standards" are dated 2000, that it still might be best to stick with HTML 4.01 for now.

Lucky for us, the DOCTYPE is an include file, so won't take but a few minutes to change it, at least for now.

We have not seen any problems yet with the pages that we used the XHTML DOCTYPE on, but it looks like there are enough potential problems that it is safer for now to stick with 4.01.

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 3:31 pm on Apr 2, 2006 (gmt 0)

You can get away with XHTML-style trailing slashes because there is no user agent which actually implements SHORTTAG minimisation - HTML is based on SGML and the minimisation aspect comes from there. XHTML is XML-based, where such minimisation is not permitted.

A document is always parsed in relation to the MIME type not the doctype, so if you serve XHTML as text/html then the user agent will treat it as ordinary HTML. The trailing slashes are ignored because SHORTTAG minimisation is not implemented, so they are treated as unknown attributes in the same way as any other non-existent or erroneous attribute.

Is XHTML syntax served as text/html "harmful"? Only partially. Using XHTML syntax in HTML documents will function correctly in just about every known user agent in existence, so it can be considered safe. However is is harmful in terms of perception: most would consider a valid XHTML page as being "forwards-compatible", however in very many cases, simple validation isn't enough to guard against problems in converting or parsing such documents as true XHTML later on.

XHTML may well just be a dead-end technology anyway. The browser companies (Mozilla, Opera, KDE, Apple) are not interested in pursuing XHTML and have put their efforts towards WHAT-WG [whatwg.org] and its plans for "HTML 5". Microsoft is not interested in XHTML either, prefering XAML/Avalon (its proprietary solution).

Mozilla's Web Author FAQ [mozilla.org] offers a clear recommendation for those undecided between HTML 4.01 and XHTML:

Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

HTML 4.01 Strict is the clear winner, at least until WHAT-WG's HTML 5 is finalized.

Note: Ian Hickson, who wrote the original article referenced in the first post of this thread, used to work for Mozilla, and subsequently worked for Opera Software and now Google inc. He is the spokesman for WHAT-WG who are developing the HTML 5 specifications.

[edited by: encyclo at 3:46 pm (utc) on April 2, 2006]

tedster

WebmasterWorld Senior Member tedster us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 3:45 pm on Apr 2, 2006 (gmt 0)

I noticed that several issues come up around scripts:

A DOM-based script written for an HTML4 document has subtly
different semantics in an XHTML context (e.g. element names are
case insensitive and returned in uppercase in HTML4, case sensitive
and always lowercase in XHTML; you have to use the namespace-aware
methods in XHTML, but not in HTML4). BUT, if you send your
documents as text/html, then they will use the HTML4 semantics
DESPITE being XHTML! Thus, scripts are highly likely to break when
the document is parsed as XHTML.

...and

Scripts that use document.write() will not work in XHTML contexts.
(You have to use DOM Core methods.)

[edited by: tedster at 3:50 pm (utc) on April 2, 2006]

buckworks

WebmasterWorld Administrator buckworks us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 3:45 pm on Apr 2, 2006 (gmt 0)

Ironically, the article referenced in the opening post is totally broken and unreadable in Safari.

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 3:49 pm on Apr 2, 2006 (gmt 0)

Ironically, the article referenced in the opening post is totally broken and unreadable in Safari.

No, Safari is totally broken, as it does what is called "MIME-type sniffing", ignoring the explicitly-declared text/plain MIME and overriding it due to the presence of markup.

This is actually an excellent example of the dangers explained by the article. What would happen if a user agent "did a Safari" and decided to parse all documents with an XHTML doctype as application/xhtml+xml? The vast majority would break, even the "valid" ones. Of course, any error in a document served as application/xhtml+xml is a fatal error, making the document totally inaccessible.

[edited by: encyclo at 3:50 pm (utc) on April 2, 2006]

longen

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 12026 posted 3:50 pm on Apr 2, 2006 (gmt 0)

If you send XHTML as application/xhtml+xml, and the code validates to W3C, does anyone know if that will display ok in legacy UA's?

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 3:52 pm on Apr 2, 2006 (gmt 0)

If you send XHTML as application/xhtml+xml, and the code validates to W3C, does anyone know if that will display ok in legacy UA's?

No, if you serve a document as application/xhtml+xml then IE6 (or even IE7) is unable to parse the file, and you will get a download prompt. Same goes for search engine spiders such as Googlebot which do not handle application/xhtml+xml - use it and the page cannot be indexed by any major search engine.

walrus

10+ Year Member



 
Msg#: 12026 posted 6:19 pm on Apr 2, 2006 (gmt 0)

This is an amazing thread. Just wanted to say how great it is to be able to find advice like this.
Last week I spent a lot of time reading up on the pros and cons of xhtml for a client, decided to aim for 4.1 strict as much as possible.

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 6:38 pm on Apr 2, 2006 (gmt 0)

One thing that I have a really hard time understanding is why people say that it is ok to use XHTML with a text/html mime type. Sending XHTML with text/html forces it to be parsed as HTML 4 ... thus losing any advantages XHTML had in the first place. So, if you want your code to be parsed as HTML 4, why not just use the HTML 4.01 doctype, as it will accomplish just that, but without any of the drawbacks!

To go back to the SHORTTAG minimization in HTML 4 ... Saying that "it's ok to send XHTML as HTML 4.01" simply because no browsers have implemented shorttag minimization is dangerous. You are now relying on a browser bug to get your documents to render correctly. I, for one, hope that the Gecko engine will fix this problem and implement shorttag minimization properly, in order to be more fully HTML 4 compliant.

Finally, on to a very important point... We all know by now that XHTML served as text/html is truly "HTML 4.01 in quirksmode". Unfortunately, when using the W3 validator to validate a document (with XHTML doctype specified) it should truly force a doctype override. Thus, if you have specified XHTML Strict, the validator should validate against HTML 4.01 Strict when the document is sent as text/html as this is what browsers will treat it as anyway. Further, as XHTML documents sent as text/html are not really XHTML to begin with, all the XHTML requirements (such as wellformedness, closing all tags [including empty ones like "<br />"]) are no longer in effect, wherefore you can safely write plain ol' HTML 4.01 compliant markup, throw in the XHTML doctype ... as long as you serve the document as text/html. If that doesn't sound messed up, I don't know what does.

Web Quirksmode 2.0

pageoneresults

WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 7:35 pm on Apr 2, 2006 (gmt 0)

The XHTML family is the next step in the evolution of the Internet. By migrating to XHTML today, content developers can enter the XML world with all of its attendant benefits, while still remaining confident in their content's backward and future compatibility.

[w3.org...]

Does that mean that the suggestions from the W3 are to be questioned?

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 7:42 pm on Apr 2, 2006 (gmt 0)

Pageone, just remember that W3's statement is said in the light of using the XML prolog and application/xhtml+xml mime type. Without the two, there is no "entering the world of XML with its benefits" whatsoever. XHTML without the two is not XHTML. It is HTML 4 in quirksmode.

WITH the two, however ... yes, the there are certainly benefits to be had!

XHTML family document types are XML based

henry0

WebmasterWorld Senior Member henry0 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 8:42 pm on Apr 2, 2006 (gmt 0)

I might have to read it a few more times
But I would like understanding why
My pages using
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml 1-transitional.dtd">
Validate OK, (well pure “XHTML” does not my PHP pages!) should I go back to HTML 4…?
Plus a few years ago I went back to U and took a course mostly dedicated to web architecture.
XHTML was becoming real big and we were told to use a XHTML DTD

So I would like to understand better what’s happening

Robert Lofthouse

5+ Year Member



 
Msg#: 12026 posted 9:26 pm on Apr 2, 2006 (gmt 0)

Unfortunately, I believe that everyone just ran to XHTML without thinking about the consequences. It was the latest thing, all the standards gurus were going on about it, but nobody really took the time out to see how this new markup language worked, and what affect it had on other technologies.

I used to praise up XHTML, but I believe that until it is fully supported (i.e. we have the ability to send it with the correct mime type and prolog), we should use HTML 4.01 strict instead.

Obviously if you are developing a site for an intranet, where you know everyone in your company is using firefox, then feel free to use XHTML with the correct prolog and mime type, but if you're developing a public site then I see no point in using it just yet.

Elijah

10+ Year Member



 
Msg#: 12026 posted 11:58 pm on Apr 2, 2006 (gmt 0)

Unfortunately, I believe that everyone just ran to XHTML without thinking about the consequences. It was the latest thing, all the standards gurus were going on about it, but nobody really took the time out to see how this new markup language worked, and what affect it had on other technologies.

That pretty much describes me. After reading "Sending XHTML as text/html Considered Harmful ", I plan to change my documents from being XHTML 1.0 served as text/html to being HTML 4.01 Strict.

Thanks to DrDoc for posting the link.

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 1:38 am on Apr 3, 2006 (gmt 0)

DrDoc:
XHTML served as text/html is truly "HTML 4.01 in quirksmode"

Well, to be fair, a document with an XHTML doctype is parsed in standards-compliance mode rather than quirks mode (except in IE6 when preceeded by an XML prolog), but it is true to say it is parsed as "HTML with errors" (the undefined attributes which constitute the trailing slashes).

The validator won't complain about XHTML served as text/html for two reasons, firstly that the file is merely being checked for conformity to a published DTD rather than whether it is being correctly served, and secondly that at least for XHTML 1.0 (not 1.1), text/html is explicitly permitted as an acceptable MIME type for legacy use.

DrDoc:
Saying that "it's ok to send XHTML as HTML 4.01" simply because no browsers have implemented shorttag minimization is dangerous. You are now relying on a browser bug to get your documents to render correctly. I, for one, hope that the Gecko engine will fix this problem and implement shorttag minimization properly, in order to be more fully HTML 4 compliant.

They will never do it, simply because it will break legacy XHTML 1.0/text/html support (which is specifically permitted by the XHTML specification). The SHORTTAG problem is a non-issue because user agents have never been SGML-compliant agents, and because a significant number of XHTML 1.0 documents exist whereas no HTML documents which use SHORTTAG notation exist precisely because there has never been an user agent support.

Robert Lofthouse:
Unfortunately, I believe that everyone just ran to XHTML without thinking about the consequences. It was the latest thing, all the standards gurus were going on about it, but nobody really took the time out to see how this new markup language worked, and what affect it had on other technologies.

Firstly, welcome to WebmasterWorld Robert, and thank you for your input! I think there has been a shift in the message carried by what we can generally call "standards evangelists" over the last couple of years for serveral reasons. When the XHTML specifications were published, they were seen as a great leap forward from the prevalent "tag soup" HTML. There was an assumption that the tools and browser support would rapidly follow, and that XHTML would push HTML into obsolescence.

I count myself in this group, and I was already producing XHTML documents served as application/xhtml+xml back in 2001/2002 which functioned in early Mozilla pre-release builds. But the tools and browser support never followed, IE7 still will have no support for XHTML. We misread the future.

The second failure of XHTML was with the implementation - the specification itself is flawed-to-broken. In almost every case of even very experienced developers putting in place a "true" XHTML solution for a public (not test) website, the difficulties and disadvantages of using application/xhtml+xml far out-weighed the supposed advantages. Most if not all early adopters walked away.

The message from standards evangelists is much more mitigated than in the early days. There was a great deal of "HTML is eeeeviiiil" and "tables are eeeeviiiil", and a certain utopian feel to the refrains. But I think it is now a mistake to suddenly switch to a "XHTML is eeeeviiiil" discourse which is equally uncompromising. The idea is not (as in the early days) to assume that HTML is going to disappear rapidly from the scene and be replaced by XML variants. Rather it is more important to to consider "now-compatibility" rather than "forwards-compatibility". We messed up predicting the future so let's talk about what you should be doing here and now to produce robust, well-built, compatible websites.

If you are building a site today, HTML 4.01 Strict is the best choice, as it has the best user agent support, has the advantage of legacy support too, is easiest to parse and render by the widest variety of browsers and search-engine spiders today.

XHTML 1.0 served as text/html is overall a safe choice too. The HTML mime type ensures legacy support, the trailing slash problem is far less serious than the vast majority of real tag soup invalidity, many tools now produce XHTML-compatible syntax by default, and the doctype ensures standards-compliace rendering mode in modern browsers. It is also an easier standard to understand than HTML 4.01 as it is based on the simple constructs of XML syntax rather than the arcane rules of SGML.

Is XHTML ideal? No, but then using tables for layout isn't either, but surely we should pull back from standards extremism and suggest a more pragmatic approach to standards compliance?

A useful reference guide to XHTML from the W3C is: HTML and XHTML Frequently Answered Questions [w3.org].

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 2:10 am on Apr 3, 2006 (gmt 0)

Let me just say something I was hoping to avoid having to say in the first place ...

First, let me preface my statement by saying that I am not completely anti-XHTML. As someone cleverly pointed out to me in a sticky, I use XHTML myself (I was wondering how long it would take for anyone to point that out). ;)

What I am against, however, is uneducated and misinformed implementations of XHTML without fully understanding the implications. Way too often have I seen XHTML implementations which were so carelessly carried out as to completely missing the target. XHTML can, and perhaps should be, a viable alternative for public consumption if, and only if, it is implemented 100% correctly.

What this means is that you should not use XHTML unless:

  1. you are willing to take the time to educate yourself with regards to what XHTML is, and how it differs from regular HTML
  2. you are willing to make the effort of implementing XHTML properly
  3. you have the technical understanding and ability to do both of the above

The education can best be carried out in two ways: first, careful reading and pondering of Ian Hickson's article; second, careful reading and pondering of W3C's XHTML documentation. Read until you understand.

Once you have gained the needful knowledge about XHTML through the two aforementioned documents you can move to implement your newfound knowledge. Doing so requires more than mere markup. Reading between the lines in both Ian's article and W3C's documentation, one more change is necessary. You should ensure that your server does the following, whether directly in your server's settings, or through explicit header output through server side scripting.

To avoid throwing IE into quirksmode we really want to avoid including the XML prolog on our pages. In order to do so, the W3C documentation declares that character set must be specified by a "higher protocol". To you, that means it must be sent by the server. Again, this can be done directly in the server configuration, or by properly outputting the appropriate "content-type" header.

Now, in all honesty it should be said that sending XHTML as text/html is not going to cause severe problems in IE. But, doing so across the board is also not going to justify using XHTML over HTML 4.01, as "text/html" effectively nullifies use of XHTML to begin with, and removes any of the benefits for choosing XHTML in the first place. You therefore want to check whether the browser sends the HTTP_ACCEPT header.

If HTTP_ACCEPT is being sent and contains application/xhtml+xml, use this content-type header:
Content-Type: application/xhtml+xml;charset=ISO-8859-1
If
HTTP_ACCEPT is being sent, but does not contain application/xhtml+xml, use this content-type header:
Content-Type: text/html;charset=ISO-8859-1
If
HTTP_ACCEPT is not being sent at all, use this content-type header:
Content-Type: application/xhtml+xml;charset=ISO-8859-1

In PHP, that is accomplished as follows:
<?php 
if((
isset($_SERVER["HTTP_ACCEPT"])
AND stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml")
) ¦¦ (
!isset($_SERVER["HTTP_ACCEPT"])
)) {
header("Content-Type: application/xhtml+xml;charset=ISO-8859-1");
}
else {
header("Content-Type: text/html;charset=ISO-8859-1");
}
header("Content-Style-Type: text/css");
header("Content-Script-Type: text/javascript");
?>

Adjust charset as appropriate. I put the content-style-type and content-script-type headers in there for good measure as well.

Now, by doing that you are not only sending XHTML according to the W3C recommendations, you are truly making your site both forward and backward compatible while doing what XHTML was designed to do -- taking the web one step closer to being able to fully utilize the power of XML.

If you are incapable of the above implementation, or simply lack the ability to do so, stick with HTML 4.01 as it is the better tool for the job at this point.

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 2:33 am on Apr 3, 2006 (gmt 0)

Firstly, the PHP script above is incomplete in that it doesn't take into account the weighting (quotient) for each MIME type. For example, a standard Firefox
HTTP_ACCEPT would be:

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Your code will serve the document as application/xhtml+xml, which would be correct. However if my HTTP_ACCEPT was:

text/html,application/xhtml+xml;q=0.9,application/xhtml+xml;q=0.8,text/plain;q=0.7,image/png,*/*;q=0.5

Then your code will still serve application/xhtml+xml despite the stated preference for text/html.

I also use XHTML for one large (30K+ pages) site. I serve it as text/html, I have no XML prolog, it uses transitional markup with tables for layout, and the majority of the pages (which are user-generated) do not validate and are not well-formed. I use XHTML because the script I use produces XHTML-compatible syntax, and I prefer consistency.

Should I try to serve this content as application/xhtml+xml in order to do better follow the standard? I won't do it. Real-world requirements mean that application/xhtml+xml is the wrong solution, because the variables involved with processing third-party input make the risk of well-formedness errors too great, and whereas with text/html the page still displays, with application/xhtml+xml the page will break. XHTML can't reliably be generated from current tools.

The "MIME-type switching" idea is flawed too, because it actively penalizes conformant browsers when an error inevitably occurs. the document becomes fragile in application/xhtml+xml-aware environments, but remains robust in legacy user agents. Of course, the draconian error-handling is already being circumvented by user agents - visit an ill-formed application/xhtml+xml document in recent versions of Opera, and you are given the possibility of viewing the document anyway as text/html.

Finally, using XHTML and application/xhtml+xml is not necessarily "forwards-compatible", because it is far from certain that furure user agents will support what is a very marginal standard. If Microsoft never supports it at all and the browser companies head towards WHAT-WGs HTML 5, XHTML served as application/xhtml+xml may well be just a minor early 21st-century fad.

For reference, a semi-related article (which discusses mostly syndication formats, but the same issues exist for XHTML): XML on the Web Has Failed [xml.com].

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 2:42 am on Apr 3, 2006 (gmt 0)

Tadaa! I just discovered something by reading the XHTML FAQ again: Does Microsoft Internet Explorer accept the media type application/xhtml+xml? [w3.org]

Although IE cannot handle application/xhtml+xml there is a trick which allows you to send XHTML as [b]application/xml[/b]! Although the preferred mime type for XHTML is application/xhtml+xml, you can send XHTML to IE in a way which forces it to parse the document as XML (which is what we want) while at the same time displaying it as regular HTML (which is exactly what XHTML is supposed to do)!

So, the PHP header thingy now looks as follows:
<?php 
if((
isset($_SERVER["HTTP_ACCEPT"])
AND stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml")
) ¦¦ (
!isset($_SERVER["HTTP_ACCEPT"])
)) {
header("Content-Type: application/xhtml+xml;charset=ISO-8859-1");
}
elseif(isset($_SERVER["HTTP_ACCEPT"]) AND stristr($_SERVER["HTTP_USER_AGENT"], "MSIE 6.0")) {
header("Content-Type: application/xml;charset=ISO-8859-1");
}
else {
header("Content-Type: text/html;charset=ISO-8859-1");
}
header("Content-Style-Type: text/css");
header("Content-Script-Type: text/javascript");
header("Content-Language: $lang");
echo "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>
<?xml-stylesheet type=\"text/xsl\" href=\"/copy.xsl\"?>
";
?>

My copy.xsl file contains:
<stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"> 
<template match="/">
<copy-of select="."/>
</template>
</stylesheet>

And it works! I tried sending a non-wellformed XHTML document to IE, and it complains like it should!

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 2:46 am on Apr 3, 2006 (gmt 0)

Then, encyclo ... HTML 4.01 is truly for you, not XHTML ;)

Yes, XHTML might break. Thus, you are not capable of using it in your environment. If you use tools which are incapable of producing correct markup, or are unable to fix the output yourself, then there is no need for you to use XHTML at all. You might as well throw the HTML 4.01 doctype in there, as your pages wouldn't validate anyway, and there wouldn't be any drawbacks.

I also use XHTML for one large (30K+ pages) site

No, you're not, regardless of what your doctype says. :)


You are, however, right that the HTTP_ACCEPT check is flawed in that it does not consider weighting. Then again, it is no more flawed than explicitly sending something as text/html. The page is only available in one format. It just differs depending on whether you can handle it or not.

ccity

10+ Year Member



 
Msg#: 12026 posted 3:59 am on Apr 3, 2006 (gmt 0)

Source code from w3.org:

<?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" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Hmmm... The W3C uses XHTML Strict with content="text/html".

Sounds fishy.

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 4:05 am on Apr 3, 2006 (gmt 0)

... as they are free to do.

As does msn.com.
Google uses no doctype and font tags.

[edited by: DrDoc at 4:12 am (utc) on April 3, 2006]

JAB Creations

WebmasterWorld Senior Member jab_creations us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 4:11 am on Apr 3, 2006 (gmt 0)

It was only a matter of time until I found this thread! ;)

You can use XHTML 1.0 Strict with text/html.

The text/html and application/xhtml+xml mimes will render exactly the same if you code correctly in both Gecko and Presto based browsers.

My site uses XHTML 1.1 with application/xhtml+xml. When you change the DTD or Mime (accessible via the personal toolbar) the rendering does not change. I've worked very hard to ensure it meets all the standards but keep in mind we all have different methods of coding.

So in that case has anyone noticed differences in rendering when changing their site (but not CSS) between HTML 4 and XHTML. I ask this question with one string attached, removing the trailing slashes when testing with HTML 4 that are required by XHTML.

While I have yet to do this specifically myself sites served as XHTML 1.1 with application/xhtml+xml should detect bots and serve the XHTML 1.0 Strict DocType as text/html. I am not aware of what bots support application/xhtml+xml and which do not but I currently do not run that chance. I simply serve bots XHTML 1.1 as text/html (until I have a chance to further address this in the future). The main point is that they are still able to read the pages and no harm (to my current understanding) is being done.

It's more of a bragging right to get on the edge but support legacy programs (such as IE6/7) and bots that do not recognize application/xhtml+xml.

I look at it this way, if they update a law in 2000 that says application/xhtml+xml is the legal HTML limit then that is what we should currently be doing. So in essence everyone using HTML 4 is breaking the law. But of course that is just an analogy and there are no such laws, just standards. Still I take standards seriously (sometimes more then that law ha-HA!)

There are downsides to XHTML. For example I am not a (good or well versed) web programmer. That means my forums and mail (are built by others until I know how to build my own and...) are currently XHTML 1.1 but served as text/html which is a no no of course. So it's important to keep working on it. If you are in the same position I simply suggest using XHTML 1.0 Strict as you are still allowed to use text/html and once you have updated your templates to change your DocType to XHTML 1.1.

DrDoc - Good point on IE's ability to handle application/xml. I'll have to look in to that myself. While I know everything I forgot most of it. ;) (JK of course)

John

PS - What is the difference between application/xml and application/xhtml+xml?

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 4:34 am on Apr 3, 2006 (gmt 0)

More excellent reading on the topic from XML.com:

[xml.com...]

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 12026 posted 4:58 am on Apr 3, 2006 (gmt 0)

What is the difference between application/xml and application/xhtml+xml?

application/xhtml+xml [w3.org]
application/xml [w3.org]

Wlauzon

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 12026 posted 8:39 am on Apr 3, 2006 (gmt 0)

Source code from w3.org:
<?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" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Hmmm... The W3C uses XHTML Strict with content="text/html".

Sounds fishy.

Fishy, yes, buggy yes.

Since this thread started, I have been checking a little deeper into the issue, especially vs IE6.

And I found a very interesting thing.

This line "<?xml version="1.0" encoding="utf-8"?>" causes IE6 to go into "weird quirks" mode with CSS, especially lists.

What was happening was that I had a small nav list that totally refused to go flush left no matter what I did - worked fine in other browsers. It had a left margin of around 10% - and I spent about 3 hours trying to find some odd inheritance or unclosed tag someplace. Then just by chance I tried a different DOCTYPE, and left that line out.

Lo and behold - that fixed the problem with that table lining up like it was supposed to.

So even though I came in here as a non-believer, I have seen the light, and have now changed all our pages over to the standard 4.01 strict DOCTYPE.

I also found out that using UTF-8 can cause some odd behaviour - so far have seen nothing serious, but I might end up replacing that also with the standard ISO.

<bows down to Doc's infinite wisdom>

knighty

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 12026 posted 9:08 am on Apr 3, 2006 (gmt 0)


OK I can accept that IE isnt properly understanding XHTML but practiacally is this really a big deal?

I mean the leap to XHTML will happen at some time and there are no issues in regards to rendering so does it really matter?

All the pages coded in XHTML look great in all browsers - no problem here!

Allan Rasmussen

5+ Year Member



 
Msg#: 12026 posted 9:49 am on Apr 3, 2006 (gmt 0)

So in that case has anyone noticed differences in rendering when changing their site (but not CSS) between HTML 4 and XHTML.

There can be changes in the DOM, yes. Certain elements are not implied, for instance tbody and tfoot (and head & body, but those are required to be there explicitly in XHTML documents).

XHTML is hardly going to be a dead technology, as the W3C supports it, unlike what they do with HTML. And Chris Wilson, "the group program manager for the web platform and security in Internet Explorer", has publicly stated that he is a big supporter and/or fan of XHTML (I don't remember the exact wording, search for it on the IEBlog if you must know), and the IE-team have implied that its support is planned for a future version of IE.

Hmmm... The W3C uses XHTML Strict with content="text/html".

Sounds fishy.


Why? First of all, if you visit w3.org the page will be sent as application/xhtml+xml if your UA supports it. Secondly, far from every high profile web developer seems to agree with Ian Hickson that 'XHTML sent as text/html is considered harmful', just look at the homepages of David Baron and Tantek Celik, to mention the first two that pops into my mind...

Update: Just searching for a similar topic, I stumbled upon [times.usefulinc.com...] where Edd Dumbill also outlines that it's not a fact that sending XHTML as text/html is considered harmful (and critizises the objectivity of the Google Web Authoring statistics, incidentally one day before I did [blog.skalske.dk], but that's probably another discussion...). And btw., the two IBM developerWorks articles he's linking to is surely worth reading, if you haven't already!

[edited by: Allan_Rasmussen at 10:04 am (utc) on April 3, 2006]

This 75 message thread spans 3 pages: 75 ( [1] 2 3 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved