XHTML or HTML 4 ?

M

Marc

Which doctype should we be writing to now? What are the advantages /
disadvantages? I usually write to XHTML1 Strict, but someone in here
said they don't recommend using XHTML at all... why?

Marc
 
S

saz

Which doctype should we be writing to now? What are the advantages /
disadvantages? I usually write to XHTML1 Strict, but someone in here
said they don't recommend using XHTML at all... why?

Marc

HTML can be read by any browser currently in use, which is not true of
XHTML. I can't find any compelling reason to use XHTML at this time
(okay, start flaming me)
 
?

=?ISO-8859-1?Q?G=E9rard_Talbot?=

Marc wrote :
Which doctype should we be writing to now? What are the advantages /
disadvantages? I usually write to XHTML1 Strict, but someone in here
said they don't recommend using XHTML at all... why?

Marc

The most important thing is to write with a strict DTD. Strict DTD will
bring all modern browsers (they all do support rendering mode based on
doctype declaration) into web standards compliant rendering mode. In
case of MSIE 6, this is very important to do since MSIE 6 in standards
compliant rendering mode will implement correctly the CSS box model.

Overall, strict DTD disregards elements and attributes used for
presentational/style purposes: your markup code makes better (or more
correct) use of the HTML code in its original intent, in its best
intended purpose. Usage of elements like <font>, <center>, etc. and
attributes like bgcolor, vspace, etc. are formally deprecated and should
be replace by use of CSS.

Reasons why HTML is to be preferred to XHTML are mentionned in 2 well
written documents:

Sending XHTML as text/html Considered Harmful
http://www.hixie.ch/advocacy/xhtml

Say NO to XHTML
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Gérard
 
A

Andy Dingley

HTML can be read by any browser currently in use, which is not true of
XHTML.

Which browsers can't read Appendix C XHTML ? Given the tag soup that
browsers _must_ support to be vaguely usable on the web, I doubt there
is a single one.

Recommendations:

Don't use XHTML 1.1 or 2.0

If you do use XHTML, use Appendix C.

Use Strict (either one), because it keeps IE's CSS rendering models
under control. IMHO it's better to be slightly invalid (with <a
target="" > etc.) than to lose Strict in favour of valid Transitional.

Coding style depends on more than doctype. <font> will either be there
or it won't, depending on whether you use it. Using Transitional doesn't
make it compulsory!

There's also no reason why a site needs a consistent doctype. If it's
hard to do it on a particular page, change doctype.

XHTML is hard to generate from XSLT - if you're using Appendix C. You
may find HTML easier to keep valid. XHTML-as-XML (as generated by XSLT
with <xsl:eek:utput mode="xml" > ) is not a good choice for the web - it
certainly will cause problems.

As to which is better, HTML 4.01 vs. XHTML 1.0 / Appendix C, then there
just isn't anything clear to choose between them. If there was, then we
wouldn't need to argue over it.
 
C

cwdjrxyz

Marc said:
Which doctype should we be writing to now? What are the advantages /
disadvantages? I usually write to XHTML1 Strict, but someone in here
said they don't recommend using XHTML at all... why?

The most important thing is that you use some valid type of html. Even
old 3.2 would serve for very simple pages and is still understood by
most browsers. However it is quite common for many pages from large
corporations to be written in a html soup ranging from html 3.2 to
xhtml levels. Some such pages likely were started many years ago and
just added to by various people over the years. It is no surprise that
some such pages have problems with some common browsers and often fail
and must be patched at new browser upgrades.

Concerning xhtml 1.1, it can be used if you make the effort to learn it
well. At a minimum, in addition to writing valid html 1.1 code, you
must set up your server to serve the page with the mime type of
application/xhtml+xml associated with the extension .xhtml, or you can
also serve as .xml. If you serve a page written in valid xhtml with the
extension .html on most servers, you are just serving the page as html
and might as well use 4.01 strict. When you serve true xhtml 1.1 with
the proper mime type, you will find that it will be viewed well on the
recent Mozilla family browsers(Firefox, Mozilla, and Netscape) and
Opera. There are a few bugs in some browsers that can be overcome, such
as a CSS body background color one on the Mozilla family browsers.
However, IE6 will not display a true xhtml page served correctly, and
rumor has it that neither will the upcoming IE7. You could write a
special page for IE in html 4.01 strict as well as the xhtml 1.1 page.
However, there is a way around this. The server and browser exchange
information when they first connect. The server can ask the browser if
it can handle the correct mime type for true xhtml. This is taken care
of by a php include at the very top of the page that replaces
everything above the head tag of the page, and the page is given an
extension of .php . The include is the same for different pages, so it
is just a 3 line external link to the php code used on all pages. If
the browser likes xhtml, the php on the server writes all of the code
above the head tag required for xhtml 1.1, and that is what you see
when you view the source of the page on a recent Mozilla family or
Opera browser. However, if the browser does not like xhtml, then the
code above the head tag is written as html 4.01 strict, which is what
you see if you view the source of the page on an IE6 and some older
browsers. However, since the page is written for xhtml, everything such
as <br /> must be converted to <br> to satisfy html 4.01 strict. This
is done by a regular expression in the php code. Of course you need to
check the page on IE6 to make certain that the code gets converted
correctly and validates, but you need to check any page on IE6 anyway
as well as on more modern browsers, and it only adds a minute or two to
right click, copy the source, take it to the W3C validator, and paste
it in a text box to validate as html 4.01 strict.

There can be complications if you use some javascript. For example,
document.write is not allowed in xhtml 1.1 and use of it may cause the
page not to display or just give an xml error message. The page is
parsed as xml when you serve it correctly, and there is no telling what
a document.write might generate such as unclosed tags which are fatal
for some xml applications. Thus document.write can not be allowed.
However this can be overcome by writing some of the script in php on
the server which then downloads what the document.write would have
generated on the browser, so the xml parser is happy and can check
everything for closing tags etc.

I have written well over 100 pages in html 1.1 that are served
correctly. Once you have done this several times, it takes very little
more time that using html 4.01 strict, so for me it is no longer a big
deal. My only advice is that if you use xhtml 1.1, do it right. Else
stick with html 4.01 strict.

The reason for xhtml is to make PC html code XML pure. There are now
many other computing devices, and XML has become the standard for
information exchange between them. Xhtml 1.1 greatly improves the XML
purity, but it still does not go quite far enough. The higher levels of
xhtml in the works will require new browsers.

What code you should be using depends on your background and what kind
of pages you write. If you work for someone else, the code you should
use is what they demand, although some bosses are open to suggestion.
If you are your own boss, there are many options. If you are writing
general pages to sell things to a wide variety of people, you usually
can not get too exotic in the code you use. If you are writing for a
network where you can control everything, you can use about any kind of
code you wish. And there are many other levels between these two
extremes.
 
?

=?ISO-8859-1?Q?G=E9rard_Talbot?=

cwdjrxyz wrote :

However, IE6 will not display a true xhtml page served correctly, and
rumor has it that neither will the upcoming IE7.

It's official:

"I've also been reading comments for some time in the IEBlog asking for
support for the "application/xml+xhtml" MIME type in IE. I should say
that IE7 will not add support for this MIME type (...) Why aren't we
supporting XHTML when it's served as the "application/xml+xhtml" media
type in IE7? I made the decision to not try to support the MIME type in
IE7 simply because I personally want XHTML to be successful in the long
run."
Chris Wilson, September 15th 2005
http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

Gérard
 
M

Marc

Thanks for taking the time to write an extensive reply cwdjrxyz, please
see my comments. :)
The most important thing is that you use some valid type of html. Even
old 3.2 would serve for very simple pages and is still understood by
most browsers. However it is quite common for many pages from large
corporations to be written in a html soup ranging from html 3.2 to
xhtml levels. Some such pages likely were started many years ago and
just added to by various people over the years. It is no surprise that
some such pages have problems with some common browsers and often fail
and must be patched at new browser upgrades.

We always validate our (X)HTML markup and CSS styling, and I'm all to
aware of the html soup websites you refer to - we're often asked to work
on websites like this and we usually say that it would be cheaper for us
to start from scratch and build the website again.
Concerning xhtml 1.1, it can be used if you make the effort to learn it
well. At a minimum, in addition to writing valid html 1.1 code, you
must set up your server to serve the page with the mime type of
application/xhtml+xml associated with the extension .xhtml, or you can
also serve as .xml. If you serve a page written in valid xhtml with the
extension .html on most servers, you are just serving the page as html
and might as well use 4.01 strict. When you serve true xhtml 1.1 with
the proper mime type, you will find that it will be viewed well on the
recent Mozilla family browsers(Firefox, Mozilla, and Netscape) and
Opera. There are a few bugs in some browsers that can be overcome, such
as a CSS body background color one on the Mozilla family browsers.

Regarding serving an XHTML page with a different mimetype, why should we
do this? Is it because the browsers do not understand the XHTML
extension? Most of our pages have a .php extension, so what happens in
these cases - what mimetype would the server pass? How would the
browser interpret it?
However, IE6 will not display a true xhtml page served correctly, and
rumor has it that neither will the upcoming IE7. You could write a
special page for IE in html 4.01 strict as well as the xhtml 1.1 page.
However, there is a way around this. The server and browser exchange
information when they first connect. The server can ask the browser if
it can handle the correct mime type for true xhtml. This is taken care
of by a php include at the very top of the page that replaces
everything above the head tag of the page, and the page is given an
extension of .php .

I understand your logic, but what about when a user has the ability to
use HTML in a webform which will then be displayed on the website? How
do you make sure this is valid and inline with the doctype being used?
Isn't that a bit overkill?
There can be complications if you use some javascript. For example,
document.write is not allowed in xhtml 1.1 and use of it may cause the
page not to display or just give an xml error message. The page is
parsed as xml when you serve it correctly, and there is no telling what
a document.write might generate such as unclosed tags which are fatal
for some xml applications. Thus document.write can not be allowed.
However this can be overcome by writing some of the script in php on
the server which then downloads what the document.write would have
generated on the browser, so the xml parser is happy and can check
everything for closing tags etc.

Generally we don't use JavaScript, but an exception would be Google
AdSense banners which give you some JS to incorporate to display the
banner - again - how do we know that this JS is inline with our doctype?
I have written well over 100 pages in html 1.1 that are served
correctly. Once you have done this several times, it takes very little
more time that using html 4.01 strict, so for me it is no longer a big
deal. My only advice is that if you use xhtml 1.1, do it right. Else
stick with html 4.01 strict.

The reason for xhtml is to make PC html code XML pure. There are now
many other computing devices, and XML has become the standard for
information exchange between them. Xhtml 1.1 greatly improves the XML
purity, but it still does not go quite far enough. The higher levels of
xhtml in the works will require new browsers.

I've written most of my pages in XHTML 1 Strict or Transitional over the
last 2 years. I've never noticed any bugs which can be attributed to my
choice of doctype, but then, maybe I wouldn't notice that...?
What code you should be using depends on your background and what kind
of pages you write. If you work for someone else, the code you should
use is what they demand, although some bosses are open to suggestion.
If you are your own boss, there are many options. If you are writing
general pages to sell things to a wide variety of people, you usually
can not get too exotic in the code you use. If you are writing for a
network where you can control everything, you can use about any kind of
code you wish. And there are many other levels between these two
extremes.

I run a small company and one of our services is web development for
local businesses. We host our own websites, so we have server root
access and the freedom to do things as we wish.

My main reason for asking was because I'm currently programming a big
CMS for our use (we won't be distributing it), and it will be one script
outputting every page, so I wanted to make sure I used the best doctype
for the job from the start.

Any more info or advice would be much appreciated.

Marc
 
M

Marc

Gérard Talbot said:
The most important thing is to write with a strict DTD. Strict DTD will
bring all modern browsers (they all do support rendering mode based on
doctype declaration) into web standards compliant rendering mode. In
case of MSIE 6, this is very important to do since MSIE 6 in standards
compliant rendering mode will implement correctly the CSS box model.

Does this mean that browsers actually take note of the doctype and
interpret the markup differently? Sorry if that sounds a really dumb
question...
Overall, strict DTD disregards elements and attributes used for
presentational/style purposes: your markup code makes better (or more
correct) use of the HTML code in its original intent, in its best
intended purpose. Usage of elements like <font>, <center>, etc. and
attributes like bgcolor, vspace, etc. are formally deprecated and should
be replace by use of CSS.

That's okay, we don't use any of the elements or attributes you
mentioned, and use CSS for presentation as it is intended. There is one
attribute I have not yet found an alternative to...

<img src="" align="right" />
<p>Big long paragraph of text</p>

This makes the text wrap around the image, is there a CSS alternative to
this?
Reasons why HTML is to be preferred to XHTML are mentionned in 2 well
written documents:

Sending XHTML as text/html Considered Harmful
http://www.hixie.ch/advocacy/xhtml

Say NO to XHTML
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Thank you, I shall have a read through these documents when I get some
time. :)

Marc
 
M

Marc

Andy said:
Recommendations:

Don't use XHTML 1.1 or 2.0

Why not?
If you do use XHTML, use Appendix C.

Sorry, I'm not clear on what you mean by 'Appendix C'. Please could you
explain?
Use Strict (either one), because it keeps IE's CSS rendering models
under control. IMHO it's better to be slightly invalid (with <a
target="" > etc.) than to lose Strict in favour of valid Transitional.

Is it only IE that the choice of Transitional/Strict affects?
Coding style depends on more than doctype. <font> will either be there
or it won't, depending on whether you use it. Using Transitional doesn't
make it compulsory!

There's also no reason why a site needs a consistent doctype. If it's
hard to do it on a particular page, change doctype.

Unless you're writing a CMS from which all pages will be outputted in
the same format.
XHTML is hard to generate from XSLT - if you're using Appendix C. You
may find HTML easier to keep valid. XHTML-as-XML (as generated by XSLT
with <xsl:eek:utput mode="xml" > ) is not a good choice for the web - it
certainly will cause problems.

Sorry, you lost me completely there, I've not looked into XSLT yet.
As to which is better, HTML 4.01 vs. XHTML 1.0 / Appendix C, then there
just isn't anything clear to choose between them. If there was, then we
wouldn't need to argue over it.

But arguing makes for good discussion! :)

Marc
 
M

Marc

saz said:
HTML can be read by any browser currently in use, which is not true of
XHTML. I can't find any compelling reason to use XHTML at this time
(okay, start flaming me)

Are you referring to mobile devices?

Marc
 
A

Andy Dingley

First of all, read Appendix C of the XHTML 1.0 spec, and search
c.i.w.a.h for past comments on it.

There are two ways to serve XHTML 1.0, labelled as XML or labelled as
HTML. Almost nothing processes it as XML (usefully), many browsers will
actually have a real problem with it labelled as XML. If it's labelled
as HTML, then current, old and future browsers just chow down on it
quite happily, in the way they've always done. Appendix C describes the
compatibility issues for how to serve XHTML 1.0 as text/html.

It's not permitted to pull this same trick with XHTML 1.1 - that's
enough reason not to use it.
How does deciding not to support that doctype in IE7 make XHTML
'successful in the long run'? I don't follow...

Media type, not doctype. IE7 works fine with Appendix C XHTML.

There's no need to support XHTML (as XML) in IE7. There's almost none
of this out on the web in a valid form, and there's no need for it, as
Appendix C will cover things perfectly well.

A badly implemented pure-XML processing version of XHTML would give
_XHTML_ a bad name for IEn+1's bugs. This would set back any real useful
adoption of XHTML as XML.

IE 7 is a minor hack for a new Windows platform, so as to gain tabbed
browsing to fool the gullible. It doesn't even fix the gross CSS bugs
that it really ought to. It's certainly not a likely candidate for a
major shift in architecture, in any successful manner.

If XHTML as XML ever happens (and I hope it won;t be 2.0) then IMHO
it'll come from the mobile devices marketplace pushing their technology
back to the desktop.
 
S

saz

Are you referring to mobile devices?

Marc
Actually, I'm referring to the browsers before the XHTML Standard was
adopted in January 2000 and updated in 2002. There are still many
people that never upgrade their browser until they buy a new computer.

You can say to ignore these viewers, but my clients would not want to
hear me say that. They want every person to see their site as designed.

Once again, throughout this thread I haven't read any compelling reason
to use XHTML at this time.
 
?

=?ISO-8859-1?Q?G=E9rard_Talbot?=

Marc a écrit :
Does this mean that browsers actually take note of the doctype and
interpret the markup differently?

Yes, they interpret the HTML a bit differently but its the CSS that they
interpret much more differently.

Here's a list of differences in MSIE 6 and in Mozilla and Opera 8+:

MSIE 6:
CSS enhancements in MSIE 6:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp

Mozilla and Firefox:

Mozilla's Quirks Mode
http://developer.mozilla.org/en/docs/Mozilla's_Quirks_Mode

Mozilla Quirks Mode Behavior
http://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior

Opera 7 and 8 doctype switching:
http://www.opera.com/docs/specs/doctype/

When your webpage does not trigger quirks mode but instead trigger
standards compliant rendering mode, then there are just a few
differences and the rendering in modern browsers (browsers after 2001;
IE6, Opera 7+, Mozilla 1.x, Firefox 1.x, Safari 1.2+, etc.) their
rendering is much closer to the specs and more correct.

Sorry if that sounds a really dumb
question...

No it's not; actually not enough people actually know that.

More on this (the table is a bit outdated):

Activating the Right Layout Mode Using the Doctype Declaration
http://hsivonen.iki.fi/doctype/
That's okay, we don't use any of the elements or attributes you
mentioned, and use CSS for presentation as it is intended. There is one
attribute I have not yet found an alternative to...

<img src="" align="right" />
<p>Big long paragraph of text</p>

This makes the text wrap around the image, is there a CSS alternative to
this?

Not sure if this is what you want but I think this is what I would use:

<p> <img src="[path]/filename.ext" width="..." height="..." alt=""
style="float: right; padding: 8px;">Big long paragraph of text said:
Thank you, I shall have a read through these documents when I get some
time. :)

Marc

Gérard
 
A

Alan J. Flavell

They want every person to see their site as designed.

That's easy - I "want" my sites to be seen as each user's browser
renders them. So both sides can be happy.

SCNR.
 
A

Alan J. Flavell

There's no need to support XHTML (as XML) in IE7. There's almost none
of this out on the web in a valid form, and there's no need for it, as
Appendix C will cover things perfectly well.

Yeah, well, most of the soi-disant "Appendix C" crud that I see out
there is just a poorly XHTML-ish-camouflaged version of
quasi-HTML-tag-soup. It would never fly as *real* XHTML, as Hixie
already predicted in his well-known advocacy page.

I'm afraid that instead of what the W3C XML experts originally touted
as the "clean break" with nasty old presentational quasi-HTML tag soup
which they said XML was going to give us, their (no doubt well-
intentioned) attempts to spell out a migration from HTML to XHTML have
resulted in nothing more than a new legacy of XHTML-flavoured tag
soup.

Their IMHO misguided demonstration of how to produce XHTML/1.0
"Transitional" was certainly part of that blunder (and just don't
start me on XHTML/1.0 "Frameset"). Did they really envisage that the
hordes would stampede from HTML/4 "Transitional" to XHTML/1.0
"Transitional", leaving "Strict" for the most part lying unwanted at
the side?? If I'm feeling generous towards them, I presume they did
it as a party trick, just to prove they could do, in XML, pretty much
anything that they'd done in HTML - without realising what the
implications would be.

Whatever XML is meant for, this surely wasn't it. Was it?
 
D

David Dorward

And don't care about mainstream user agent support (e.g. GoogleBot, Lynx and
Internet Explorer)

The file extension is irrelevent

That is not a bug. Its mandated by the specs.
Regarding serving an XHTML page with a different mimetype, why should we
do this?

If you serve XHTML as text/html then it is treated as malformed HTML, and
there is no point in using it. (OTOH, if you serve it as
application/xhtml+xml, then 90% of your audience won't get it, and there is
*still* no point in using it).
Is it because the browsers do not understand the XHTML
extension?

URLs don't have file extensions.
Most of our pages have a .php extension, so what happens in
these cases - what mimetype would the server pass?

That depends on how your server is configured (unless your PHP script uses
the header() function to specify its own content type).

So you serve XHTML 1.0 (so what's the point of using 1.1 in the first
place?) or (probably) invalid HTML 4.x.
I understand your logic, but what about when a user has the ability to
use HTML in a webform which will then be displayed on the website? How
do you make sure this is valid and inline with the doctype being used?

Same way as you would do in HTML. Run their code through a validator then
prompt them to fix it and/or try to fix it automatically and/or refer the
code to an editor who can fix it manually.

Yes it is. document.write in XHTML isn't as widely supported as
document.write in HTML, but its allowed.

There is telling. You just have to know what you are putting into it in the
first place. Its a little harder then if you are outputting straight
markup, but still possible.
Generally we don't use JavaScript, but an exception would be Google
AdSense banners which give you some JS to incorporate to display the
banner - again - how do we know that this JS is inline with our doctype?

The GoogleAd code, which you are not allowed to modify, uses the old "Hide
this code from insanely ancient browsers" comment syntax. This is allowed
in HTML 4.x. Under XHTML it renders the script commented out. Google Ads
are entirely incompatible with XHTML.

Un. How?
 
?

=?ISO-8859-1?Q?G=E9rard_Talbot?=

Marc a écrit :
Thanks for taking the time to write an extensive reply cwdjrxyz, please
see my comments. :)

I would stay away from HTML 3.2 for several reasons, one being that it
triggers modern browsers into quirks rendering mode.

Some such pages likely were started many years ago and
We always validate our (X)HTML markup and CSS styling, and I'm all to
aware of the html soup websites you refer to - we're often asked to work
on websites like this and we usually say that it would be cheaper for us
to start from scratch and build the website again.


Regarding serving an XHTML page with a different mimetype, why should we
do this?

It's because XHTML should be served with a different mimetype to begin
with; it shouldn't be served as text/html to begin with.


Is it because the browsers do not understand the XHTML
extension? Most of our pages have a .php extension, so what happens in
these cases - what mimetype would the server pass? How would the
browser interpret it?


I understand your logic, but what about when a user has the ability to
use HTML in a webform which will then be displayed on the website? How
do you make sure this is valid and inline with the doctype being used?
Isn't that a bit overkill?


Generally we don't use JavaScript, but an exception would be Google
AdSense banners which give you some JS to incorporate to display the
banner - again - how do we know that this JS is inline with our doctype?


I've written most of my pages in XHTML 1 Strict or Transitional over the
last 2 years. I've never noticed any bugs which can be attributed to my
choice of doctype, but then, maybe I wouldn't notice that...?


I run a small company and one of our services is web development for
local businesses. We host our own websites, so we have server root
access and the freedom to do things as we wish.

My main reason for asking was because I'm currently programming a big
CMS for our use (we won't be distributing it), and it will be one script
outputting every page, so I wanted to make sure I used the best doctype
for the job from the start.


Then I recommend HTML 4.01 strict. If you lowercase elements and
attributes, if you avoid minimization, if you close all your tags
(except maybe <img> and <br>), then you make your HTML 4.01 strict
webpages XHTML-ready, easier/faster to convert to any kind of XHTML.

What's most important for you, as I understand your numerous posts, is
to trigger standards compliant rendering mode in MSIE 6 and MSIE 7 (beta
2 will be released in 4-6 weeks). All modern browsers now support 2
rendering modes based on doctype declarations and it will be the case
for new upcoming versions/releases in the years to come.

Gérard
 
D

David Dorward

Andy said:
Which browsers can't read Appendix C XHTML ?

W3 can read it ... but it treats <foo /> as per the SGML spec (i.e. meaning
the same as said:
Use Strict (either one), because it keeps IE's CSS rendering models
under control.

Myth. The Doctype switching question is more complicated then that. You can
trigger standards mode with a Transitional Doctype.

http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

.... will trigger Standards mode in MSIE.
IMHO it's better to be slightly invalid (with <a target="" > etc.) than to
lose Strict in favour of valid Transitional.

And better yet to not use the target attribute. It has three purposes:

1. For targetting frames. Frames have all sorts of problems and are best
avoided in almost every case.

2. For pushing new windows on users. It is better to let the user decide
when they want a new window.

3. For breaking out of third party frames. JavaScript will suffice for most
users, and users who don't have JavaScript are generally savvy enough to
break out manually.
 
C

cwdjrxyz

Marc said:
Thanks for taking the time to write an extensive reply cwdjrxyz, please
see my comments. :)


We always validate our (X)HTML markup and CSS styling, and I'm all to
aware of the html soup websites you refer to - we're often asked to work
on websites like this and we usually say that it would be cheaper for us
to start from scratch and build the website again.


Regarding serving an XHTML page with a different mimetype, why should we
do this? Is it because the browsers do not understand the XHTML
extension? Most of our pages have a .php extension, so what happens in
these cases - what mimetype would the server pass? How would the
browser interpret it?


I understand your logic, but what about when a user has the ability to
use HTML in a webform which will then be displayed on the website? How
do you make sure this is valid and inline with the doctype being used?
Isn't that a bit overkill?


Generally we don't use JavaScript, but an exception would be Google
AdSense banners which give you some JS to incorporate to display the
banner - again - how do we know that this JS is inline with our doctype?


I've written most of my pages in XHTML 1 Strict or Transitional over the
last 2 years. I've never noticed any bugs which can be attributed to my
choice of doctype, but then, maybe I wouldn't notice that...?


I run a small company and one of our services is web development for
local businesses. We host our own websites, so we have server root
access and the freedom to do things as we wish.

My main reason for asking was because I'm currently programming a big
CMS for our use (we won't be distributing it), and it will be one script
outputting every page, so I wanted to make sure I used the best doctype
for the job from the start.

Any more info or advice would be much appreciated.

I think the best thing I can do is give you an example of one of my
most complicated pages that was converted to xhtml 1.1 and served as
such. First you must make sure that the server has the mime type
application/xhtml+xml for the extension .xhtml installed - if not you
must install it. This is very easy to do from the control panel for the
Apache Unix server my domain is on - you just type the extension and
mime type into a form there.

First have a look at the old 4.01 strict page at
http://www.cwdjr.net/calendar/perpetual_calendar2.html . When you
examine the code you will find that it uses extensive javascript to
calculate a calendar for the input year and to generate the extensive
CSS for displaying this calculated calendar. This mostly is done with
document.write, and all of this has to go for xhtml 1.1 served
correctly. Instead the calculations and writing the CSS for the
calendar are done on the server using php. Then when the page is
served, all of this finished code that does the same thing as the
result of the javascript code is downloaded to the browser. The browser
can use the xml parser to determine that you are not trying to sneak
some unclosed tags, etc in as might happen if you downloaded a document
..write.

To see the page as served as xhtml 1.1 using the correct mime type,
view http://www.cwdjr.net/calendar2/perpetual_calendar.php . When you
view this page on IE6 or other browsers that can not handle
application/xhtml+xml you will find it is written in html 4.01 strict
so the browser can handle it. When you view the page on a recent
Mozilla family or Opera browser, you will find that it is written in
xhtml 1.1 .But the source code in neither case will show you how this
was done, since php is involved.

To view the actual php code used on the server, see
http://www.cwdjr.net/calendar2/perpetual_calendar.phps . Adding the s
to the php extension allows the code to be displayed as text, while
using a plain .txt file gives a mess on the IE6. But you will see a php
include at the very top of the page. To see the code for this, see
http://www.cwdjr.net/calendar2/mime2.phps . This code is what takes
care of serving the page correctly at the header stage before the
server downloads any actual code to the browser.

If you examine the php code carefully, you can see how php has been
used to replace what is done by document.write on a browser. You will
also see how a form is handled to take the input of the year so that
the php script will know what to calculate and what CSS code to
generate.

This is a very extreme example. In most cases where you do not use
extensive javascript containing many document.writes, your php page on
the server will look about the same as a basic html page with just the
php include at the top of the page to serve things properly.

If you want to verify that the code sent to the browser is correct,
right click while viewing the page, copy, go to the w3c validator, and
paste the code in the text box. If you use the extended interface at
the w3c validator, it will show you what mime type was used to serve
the page. If you take a page, even written in perfect xhtml 1.1 but
with the extension .html, you will find that it is served as just html
and does not have the required application/xhtml+xml mime type. Another
way to tell is to just go to the IE6 browser. If the page displays,
despite your xhtml code, it is just being served as html. If you take a
..xtml extension page that is served properly to IE6 you will find that
it just gives you error messages.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top