XHTML or HTML 4 ?
Marc
disadvantages? I usually write to XHTML1 Strict, but someone in here
said they don't recommend using XHTML at all... why?
Marc
saz
mbra...@beasolutions.com says...
XHTML. I can't find any compelling reason to use XHTML at this time
(okay, start flaming me)
Gérard Talbot
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
--
remove blah to email me
Andy Dingley
wrote:
>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:output 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.
cwdjrxyz
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.
Gérard Talbot
> 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
Marc
see my comments. :-)
cwdjrxyz wrote:
> 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
Marc
> 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
How does deciding not to support that doctype in IE7 make XHTML
'successful in the long run'? I don't follow...
Marc
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.
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
Marc
> 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!
I always use CSS for presentation, so I wouldn't touch <font> with a
barge pole.
> 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:output 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
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)
Are you referring to mobile devices?
Marc
Andy Dingley
wrote:
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.
saz
mbra...@beasolutions.com says...
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.
Gérard Talbot
> Gérard Talbot wrote:
>> 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?
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/
>> 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?
>
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</p>
>> 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
Gérard
Alan J. Flavell
On Fri, 13 Jan 2006, saz wrote:
> 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.
Alan J. Flavell
On Fri, 13 Jan 2006, Andy Dingley wrote:
> 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?
Gérard Talbot
> Thanks for taking the time to write an extensive reply cwdjrxyz, please
> see my comments. :-)
>
> cwdjrxyz wrote:
>> 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.
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
>> 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?
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.
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.
David Dorward
>> Concerning xhtml 1.1, it can be used if you make the effort to learn it
>> well.
And don't care about mainstream user agent support (e.g. GoogleBot, Lynx and
Internet Explorer)
>> At a minimum, in addition to writing valid html 1.1 code, you
^X
>> 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.
The file extension is irrelevent
>> 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.
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).
>> 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
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.
>> There can be complications if you use some javascript. For example,
>> document.write is not allowed in xhtml 1.1
Yes it is. document.write in XHTML isn't as widely supported as
document.write in HTML, but its allowed.
>> 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.
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.
>> 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
Un. How?
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
David Dorward
> On Thu, 12 Jan 2006 09:29:25 -0600, saz <saz...@nospammersexcite.com>
> wrote:
>
>>HTML can be read by any browser currently in use, which is not true of
>>XHTML.
>
> 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 <foo>>).
> 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.
cwdjrxyz
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.
Jonathan N. Little
<snip>
>
> <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?
>
look up CSS property 'float'
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Michael Winter
[Around 6KB of needlessly quoted text]
Please learn how to post; trim quotes.
[snip]
> http://www.cwdjr.net/calendar2/perpetual_calendar.php
That's quite a bad example, on several fronts. Probably the worst, of
course, is...
[snip]
> http://www.cwdjr.net/calendar2/mime2.phps
...which totally fails to act how a compliant server should. Not only
will it serve XHTML to a user agent that would (perhaps overwhelmingly)
prefer HTML, it would even serve XHTML to an agent that explicitly
forbade it.
May I ask what's the point of that large comment? Moreover, what
possessed you to even think of scripting an obnoxious prompt that would
be viewed by the majority of your users?
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
cwdjrxyz
> On 13/01/2006 21:43, cwdjrxyz wrote:
>
> [Around 6KB of needlessly quoted text]
>
> Please learn how to post; trim quotes.
I quite well know how to trim quotes, and if you examine some of my
other posts you will see that I often do. Since the poster asked a
variety of questions that I thought might be best covered by an
example, I wanted to leave all in to show what prompted my answer. Then
after reading my example code, the poster is of course free to ask
follow up questions if desired. Who in the world worries about 6 kb
anymore - at least not I. Today broadband pages with streaming media
files of over 50 MB are not uncommon, and even on 56K dialup a 10 kb
file is fast loading. Server disc space and bandwidth charges have now
become nearly dirt cheap and continue to become even cheaper(I only pay
about $US 10 a month on an annual basis for about 2 GB of disc space
and about 200 GB of monthly bandwidth) The only way I could come close
to using up my disc space and bandwith is to use a very large number of
streaming media files.
If someone does not wish to read the quote they are quite free not to
do so. In fact I am set up so you have to click on a quote message line
to display the quote at all.
> [snip]
>
> > http://www.cwdjr.net/calendar2/perpetual_calendar.php
>
> That's quite a bad example, on several fronts. Probably the worst, of
> course, is...
>
> [snip]
>
> > http://www.cwdjr.net/calendar2/mime2.phps
>
> ...which totally fails to act how a compliant server should. Not only
> will it serve XHTML to a user agent that would (perhaps overwhelmingly)
> prefer HTML, it would even serve XHTML to an agent that explicitly
> forbade it.
>
"Bad example" is a value judgement taken alone, and is meaningless in a
technical example without technical specifics. Your follow up technical
specific concerns the mime2.php file. It is doing exactly what I want
it to do - namely serve application/xhtml+xml to any browser that
claims it will accept it at all. Some claim they would rather have
html, but I want to bypass that when at all possible. It turns out that
most recent common browsers that will accept the mentioned xhtml mime
type, even if they say they would prefer html, will in fact work just
fine using true xhtml on many properly written codes. I have written
over 100 pages with this approach, and find that it works fine on
recent Firefox, Mozilla, Netscape and Opera browsers. It serves html
4.01, as it should for IE6 and close relatives, such as the SBC/DSL DSL
browser. However, as with anything that is not yet being widely used
you have to be on the lookout for bugs, such as the CSS
background-color bug for Mozilla family browsers mentioned in a comment
in my posted code. You need to test your pages on several browsers, but
I know few persons who are so perfect that they do not have to check
html 4.01 on several browsers either. I suspect the fact that many
browsers respond that they will accept application/xhtml+xml, but
prefer html, is just to protect the browser vendors from complaints
caused by a few bugs that can turn up at this early stage. Many people
once would argue that one should not use CSS because it had many bugs,
as indeed it did in 4 era browsers. Today many posting here will jump
all over you if you do not use CSS. And of course CSS will not work on
all browsers, but now only a tiny percentage of very old browsers.
> May I ask what's the point of that large comment? Moreover, what
> possessed you to even think of scripting an obnoxious prompt that would
> be viewed by the majority of your users?
The point of the large comment is to complain that IE is out of step
with most other modern browsers and W3C standards. My little comment
may not help much, but if enough people complain about Microsoft's lack
of support of application/xhtml+xml there is a minute chance that they
might start to correct the situation within the next 5 to 10 years.The
comment will be seen only by those who look at the code, and not on
viewing the page.
The prompt is of course commented out and not used on the page. When
modifying the mime.php file, it is useful to trace what path is being
selected. Of course there may be some so dissatisfied with Microsoft's
lack of support of W3C standards that they may want to leave the prompt
on the page. I decided not to, for the reason that some, including
myself, may use the calendar generator page often, and the prompt soon
becomes tiresome.
The php calendar page posted will of course work if javascript is not
supported. Just turn off script on Firefox for example, and you should
still be able to use the page. The only thing that would not show, sans
script, is the mentioned prompt, if you used it, which I do not on my
example.
For those for whom the mention of true xhtml 1.1 causes a large
increase in blood pressure, they may use the html 4.01 strict page that
I posted. Of course javascript must be turned on for that. The
extensive calculations needed are far beyond the reach of plain html -
javascript, php, perl etc are needed. So far I have not had anyone
complain that the php page will not work on a common modern browser,
and if they did I would send them the URL for the 4.01 strict html page
at the URL I posted. Of course the page might not be suitable for some
handheld devices with a tiny screen that is too small to display a
calendar for a whole year. One likely would have to add an option to
allow display of single months to have any chance of being viewable on
a tiny screen, and even that might require better eyesight than many of
us have.
I would be happy to view the code for any of your pages written to work
on true xhtml 1.1. I am not interested in finding fault. At this early
stage every new approach to best using xhtml 1.1 and bugs that may
occur when using it helps. The more that contribute, the better. Actual
working page examples, with comments to point out how possible problems
are overcome, are much more useful than tons of verbiage and abstract
general discussions about the relative merits of this and that.
Marc
>> This makes the text wrap around the image, is there a CSS alternative
>> to this?
>
> look up CSS property 'float'
I know about float, I use it all the time, I just didn't think you could
use it like that.
Marc
Spartanicus
Any other usage ("CSS layouts" etc) is a nasty hack.
--
Spartanicus
David Dorward
> "Bad example" is a value judgement taken alone, and is meaningless in a
> technical example without technical specifics. Your follow up technical
> specific concerns the mime2.php file. It is doing exactly what I want
> it to do - namely serve application/xhtml+xml to any browser that
> claims it will accept it at all.
Incorrect. It serves application/xhtml+xml to any browser that mentions that
mime type in its accept header - even if the mentioning is to explicitly
state that it does not accept it (i.e. with a quality value of zero).
> Some claim they would rather have html, but I want to bypass that when at
> all possible.
What a great idea. Assume that you know what a browser supports better then
the browser itself. That's never going to cause a problem! </sarcasm>
> such as the CSS background-color bug for Mozilla family browsers mentioned
> in a comment in my posted code.
What background colour bug? I seem to recall some discussion on backgrounds
a while back, which came to the conclusion that XHTML was not HTML and thus
certain special cases which apply to HTML don't apply to XHTML - but I
don't remember the specifics right now.
Michael Winter
> Michael Winter wrote:
>
>> On 13/01/2006 21:43, cwdjrxyz wrote:
>>
>> [Around 6KB of needlessly quoted text]
>>
>> Please learn how to post; trim quotes.
>
> I quite well know how to trim quotes [...]
Then please be kind enough to do it in future.
> Since the poster asked a variety of questions that I thought might be
> best covered by an example [...]
Your posted was related to only the first question.
[snipped pointless drivel about bandwidth]
This is Usenet, not the Web. It is a simple courtesy to keep bandwidth
usage to a minimum and follow the preferred posting style of the group.
[snip]
> "Bad example" is a value judgement taken alone, and is meaningless in a
> technical example without technical specifics.
I have no problem mentioning the in-line CSS declarations, the absolute
positioning, the pixel dimensions (and font size), the useless and
inaccurate META element, and the generally poor markup (the worst of
which is that block of text to the right). However, that wasn't the
point of your example, so I just hinted at the presence of other issues.
> Your follow up technical specific concerns the mime2.php file. It is
> doing exactly what I want it to do - namely serve
> application/xhtml+xml to any browser that claims it will accept it at
> all.
As both David and I have said, that isn't what it does at all.
> Some claim they would rather have html, but I want to bypass that
> when at all possible.
Stop wanting that, then.
> [...] bugs, such as the CSS background-color bug for Mozilla family
> browsers [...]
The BODY element is rendered just like any other block-level element,
and only extends to surround content that is in normal flow. As such,
the background colour will not be rendered across the entire viewport.
The HTML element is the document root, and setting a background colour
there will cause it to be rendered as you'd prefer.
> I suspect the fact that many browsers respond that they will accept
> application/xhtml+xml, but prefer html, is just to protect the
> browser vendors from complaints caused by a few bugs that can turn up
> at this early stage.
Mozilla only states that it prefers XHTML so that resources that would
negotiate between, say, HTML and XHTML with MathML, would choose the
latter[1]. Opera ranks XHTML and HTML the same. I don't know off-hand
what Konqueror's and Safari's Accept header contains.
Irrespective of their reported preferences, all of these browsers do,
for some reason or another, prefer HTML. Mozilla cannot incrementally
render XHTML. Opera 7.x wouldn't execute scripts in XHTML documents.
Previous Konqueror versions, as I recall, didn't parse XHTML as XML.
[snip]
> And of course CSS will not work on all browsers, but now only a tiny
> percentage of very old browsers.
With a properly marked-up document, it won't matter that much if CSS is
not supported (or disabled); the document will be unstyled, but still
readable and in a logical order.
[snip]
> The point of the large comment is to complain that IE is out of step
> with most other modern browsers and W3C standards.
And how exactly does that help the user (especially as they won't read
it, anyway)?
> My little comment may not help much, but if enough people complain
> about Microsoft's lack of support of application/xhtml+xml [...]
Microsoft should be left to implement XHTML properly in their own time.
Rushing their efforts will do far more harm than good.
[snip]
Mike
[1] <http://www.mozilla.org/docs/web-developer/faq.html#accept>
Alan J. Flavell
On Mon, 16 Jan 2006, David Dorward wrote:
> cwdjrxyz wrote:
>
> > It is doing exactly what I want
> > it to do - namely serve application/xhtml+xml to any browser that
> > claims it will accept it at all.
>
> Incorrect. It serves application/xhtml+xml to any browser that mentions that
> mime type in its accept header - even if the mentioning is to explicitly
> state that it does not accept it (i.e. with a quality value of zero).
Blimey, *that* old chestnut again. Why *do* people insist on
reinventing the wheel, and then making it square? (or in this case
maybe triangular).
cwdjrxyz
Michael Winter wrote:
> On 16/01/2006 03:10, cwdjrxyz wrote:
>
> > Michael Winter wrote:
> >
> >> On 13/01/2006 21:43, cwdjrxyz wrote:
> >>
> >> [Around 6KB of needlessly quoted text]
> >>
> >> Please learn how to post; trim quotes.
> >
> > I quite well know how to trim quotes [...]
>
> Then please be kind enough to do it in future.
I will post exactly how I think is best in the future. This group does
not have a moderrator, and if you do not like my posts, no one is
forcing you to read them.
> > Since the poster asked a variety of questions that I thought might be
> > best covered by an example [...]
>
> Your posted was related to only the first question.
A matter of opinion. However the poster is free to ask anything else he
or she wishes.
> [snipped pointless drivel about bandwidth]
>
> This is Usenet, not the Web. It is a simple courtesy to keep bandwidth
> usage to a minimum and follow the preferred posting style of the group.
Yes I know this is archaic Usenet with multiple sources, slowness, and
far inferior to a modern BB where posts can nearly become as fast as
chat. It dates from a day when one had to very slowly download many
posts to read just a few of interest or configure a newsreader in great
detail to accept only certain posts. But the world moves on. I never
use an email agent or news reader on my computer. Rather I use domain
mail and email provided by my ISP, SBC/Yahoo DSL, which has very
effective filters and very good virus scan for attachments before even
allowing you to view them or copy them to computer. I find the new
Google access to groups very good, although it did have a few growing
pains. It arranges posts in order, so far as possible, and usually a
post you make appears almost at once, although of course it may take
considerable time to reach the many other branches of Usenet. I do not
need silly things such as a kill file, since that does not make posts
go away - it is somewhat like the ostrich who burries his head in the
sand. It might be useful for those who still insist on downloading
Usenet posts, in order to reduce the number of flame war posts, etc
downloaded. In fact I find Usenet so archaic and quaint in the old
technology it uses, that I only use 3 groups on it - on subjects of
interest that are not covered elsewhere. Since my computer is on all of
the time on DSL I can easily pop into Usenet at Google while my
computer is working on other things, such as processing video files.
> > "Bad example" is a value judgement taken alone, and is meaningless in a
> > technical example without technical specifics.
>
> I have no problem mentioning the in-line CSS declarations, the absolute
> positioning, the pixel dimensions (and font size), the useless and
> inaccurate META element, and the generally poor markup (the worst of
> which is that block of text to the right). However, that wasn't the
> point of your example, so I just hinted at the presence of other issues.
>
You seem to miss the point that there are about 60000 calendars and
each has to be custom calculated including custom CSS for each.The most
direct method is to calculate using the inline declarations. This is
just as valid as CSS in the head or in an external file. The beauty of
CSS is that you can use a mix of CSS at 3 different levels as is most
convenient. If one were downloading only one calendar, rather than one
of 60000 that had to be calculated, then much more of the CSS would be
convenient to put in the head or an external file. I also remind you
that the CSS does validate on the W3C CSS validator. The absolute
positioning, pixel dimensions, and font size are quite necessary to
control the calculation of the calendar in a reasonable manner to fit a
desired field. The calendar turns out just the way I want it to be
displayed on a screen from about 560 px wide and up. This will make the
calander viewable on nearly all modern computer screen settings
including the 560 px width old MSNTV browser without right scrolling.
If someone uses an older narrow screen setting, they can easily right
scroll to read the text which is just an extra and not needed to view
the calendar. The text is about as large as it can be to display the
full calendar down to a 560 px wide screen. Support of under 560 pixel
likely would not be practical, because the text would have to be so
small in the calendar.
> > Your follow up technical specific concerns the mime2.php file. It is
> > doing exactly what I want it to do - namely serve
> > application/xhtml+xml to any browser that claims it will accept it at
> > all.
>
> As both David and I have said, that isn't what it does at all.
>
> > Some claim they would rather have html, but I want to bypass that
> > when at all possible.
>
> Stop wanting that, then
Sorry, I have seen numerous publications concerning what the browser
might prefer to accept, what it will accept, etc. I tried several
methods considering this in early attempts to use correct xhtml 1.1
served correctly. I find that most of these just end up in serving html
instead of xhtml. However I took the bold step of using the xhtml path
for any browser that mentioned it. In theory there could, and may be,
some of the many thousand browsers that would mention
application/xhtml+xml and yet not handle it. However I found this not
to be the case for the browsers that make up by far the bulk of
browsers now being used. This includes recent versions of Firefox,
Opera, Netscape, Mozilla, IE6 and close relatives. I also had reports
that two other recent browsers also worked well. I am satasfied with
this coverage. It is far better than my bank, credit card company, etc
have. If you find a recent, often used browser for which my method
takes the wrong path, let me know. As I mentioned earlier, I posted a
URL for an old html 4.01 strict page that would work in that case.
> > [...] bugs, such as the CSS background-color bug for Mozilla family
> > browsers [...]
>
> The BODY element is rendered just like any other block-level element,
> and only extends to surround content that is in normal flow. As such,
> the background colour will not be rendered across the entire viewport.
> The HTML element is the document root, and setting a background colour
> there will cause it to be rendered as you'd prefer.
Call it a bug, or whatever you wish, but the fact is that if you write
an html page and view it on IE6, Mozilla family, or Opera browsers, the
background color extends to the bottom of the screen if the content
does not fill the whole screen, if you declare the background-color in
the body section of the CSS style sheet. However if you convert the
page to proper xhtml 1.1 and serve properly, IE6(gets html strict
instead of xhtml) and Opera still extend the background color to the
bottom of the screen for a non-full screen, while the Mozilla family
browsers stop the background color at the end of the content displayed
on the screen, with bright white instead of black to the bottom of the
screen in my example. I perhaps can think of better names than bug for
this problem, which are not suited for this group :-).
> > I suspect the fact that many browsers respond that they will accept
> > application/xhtml+xml, but prefer html, is just to protect the
> > browser vendors from complaints caused by a few bugs that can turn up
> > at this early stage.
>
> Mozilla only states that it prefers XHTML so that resources that would
> negotiate between, say, HTML and XHTML with MathML, would choose the
> latter[1]. Opera ranks XHTML and HTML the same. I don't know off-hand
> what Konqueror's and Safari's Accept header contains.
I do not have Konqueror or Safari browsers. However I did receive
screen shots on Safari and(I think) Konqueror, browsers that showed
that they worked on an xhtml page served as .xtml which will not work
on browsers such as IE6 that can not handle application/xhtml+xml.
> Irrespective of their reported preferences, all of these browsers do,
> for some reason or another, prefer HTML. Mozilla cannot incrementally
> render XHTML. Opera 7.x wouldn't execute scripts in XHTML documents.
> Previous Konqueror versions, as I recall, didn't parse XHTML as XML.
It would be nice if Konqueror supports correct xhtml. However this
browser is so little use by anyone I know - I have never seen a
Konqueror browser - that I would not be too concerned if it does not
support xhtml - after all neither does IE6.
> [snip]
>
> > And of course CSS will not work on all browsers, but now only a tiny
> > percentage of very old browsers.
>
> With a properly marked-up document, it won't matter that much if CSS is
> not supported (or disabled); the document will be unstyled, but still
> readable and in a logical order.
>
> [snip]
>
> > The point of the large comment is to complain that IE is out of step
> > with most other modern browsers and W3C standards.
>
> And how exactly does that help the user (especially as they won't read
> it, anyway)?
> > My little comment may not help much, but if enough people complain
> > about Microsoft's lack of support of application/xhtml+xml [...]
>
> Microsoft should be left to implement XHTML properly in their own time.
> Rushing their efforts will do far more harm than good.
The problem is that Microsoft did nearly no browser development for a
few years and let the IE6 become stale. However the Mozilla family
browsers, Opera, and others continued browser development. Then Firefox
started to catch on. Microsoft then started some browser development
recently, but they have a lot of catch-up to do. Apparently the IE7 is
mainly a bug fix and inclusion of some features that other browsers
such as Firefox and Opera introduced, but we will not know for sure
untill the official release of a stable version of IE7.
I am still hoping to see some of your pages written in xhtml 1.1 and
served as such.
cwdjrxyz
David Dorward wrote:
> cwdjrxyz wrote:
>
> > "Bad example" is a value judgement taken alone, and is meaningless in a
> > technical example without technical specifics. Your follow up technical
> > specific concerns the mime2.php file. It is doing exactly what I want
> > it to do - namely serve application/xhtml+xml to any browser that
> > claims it will accept it at all.
>
> Incorrect. It serves application/xhtml+xml to any browser that mentions that
> mime type in its accept header - even if the mentioning is to explicitly
> state that it does not accept it (i.e. with a quality value of zero).
>
> > Some claim they would rather have html, but I want to bypass that when at
> > all possible.
>
> What a great idea. Assume that you know what a browser supports better then
> the browser itself. That's never going to cause a problem! </sarcasm>
I answered about the same as the above in a response to Michael Winter.
To avoid extensive duplication, I will not repeat it here.
> > such as the CSS background-color bug for Mozilla family browsers mentioned
> > in a comment in my posted code.
>
> What background colour bug? I seem to recall some discussion on backgrounds
> a while back, which came to the conclusion that XHTML was not HTML and thus
> certain special cases which apply to HTML don't apply to XHTML - but I
> don't remember the specifics right now.
The above also is covered in my long response to Michael Winter
cwdjrxyz
I covered about the same as the above in a long response to Michael
Winter. Thus I will not repeat it here.
Marc
> Any other usage ("CSS layouts" etc) is a nasty hack.
Are you saying you don't approve of a layout with, for example with 2
<div>s where one is floated to put it along side the other?
Marc
David Dorward
> Yes I know this is archaic Usenet with multiple sources, slowness, and
> far inferior to a modern BB where posts can nearly become as fast as
> chat.
Oh yes, the modern BB ... with a single point of failure and inflexible
interface that usually lacks spell checking, the ability to resize the text
entry area, the speed of skimming through posts in many channels, etc etc.
> I do not need silly things such as a kill file, since that does not make
> posts go away
It might not make them go away, but it does hide them. That way I'm not
tempted to respond to moronic trolls. On the subject of which ... *plonk*
> I am still hoping to see some of your pages written in xhtml 1.1 and
> served as such.
Why? Doing so wouldn't bring any benefit.
Spartanicus
It's a nasty hack, drawbacks:
a) It was never intended to be used as such, consequently usage other
than it's intended usage is fraught with issues that many authors
struggle with.
b) The CSS float rules are preposterously complex, this has resulted in
numerous browser float bugs, resulting in even more author confusion.
--
Spartanicus
Marc
> Marc <mbra...@beasolutions.com> wrote:
>>Are you saying you don't approve of a layout with, for example with 2
>><div>s where one is floated to put it along side the other?
>
> It's a nasty hack, drawbacks:
>
> a) It was never intended to be used as such, consequently usage other
> than it's intended usage is fraught with issues that many authors
> struggle with.
> b) The CSS float rules are preposterously complex, this has resulted in
> numerous browser float bugs, resulting in even more author confusion.
So what would you recommend as an alternative? Absolute/Relative
Positioning? Tables?
Marc
Marc
> cwdjrxyz wrote:
>>served as such.
>
> Why? Doing so wouldn't bring any benefit.
David, I'd appreciate your view on my original post.
Thanks,
Marc
David Dorward
> David, I'd appreciate your view on my original post.
As I said: <news:dq8uj2$7p9$1$830f...@news.demon.co.uk>
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).
So HTML 4.01 Strict.
(Generally at least. There are some exceptions, usually involving MathML,
where XHTML could be useful - but those aren't all that common).
Spartanicus
A proper answer to that question is too big a topic for usenet.
--
Spartanicus
Marc
> Marc <mbra...@beasolutions.com> wrote:
>>>>Are you saying you don't approve of a layout with, for example with 2
>>>><div>s where one is floated to put it along side the other?
>>>
>>>It's a nasty hack, drawbacks:
>>>
>>>a) It was never intended to be used as such, consequently usage other
>>>than it's intended usage is fraught with issues that many authors
>>>struggle with.
What therefore would you count as its intended use? Just to align
images within a body of text?
>>>b) The CSS float rules are preposterously complex, this has resulted in
>>>numerous browser float bugs, resulting in even more author confusion.
>>
>>So what would you recommend as an alternative? Absolute/Relative
>>Positioning? Tables?
>
> A proper answer to that question is too big a topic for usenet.
Oh I'm sure you can try to formulate a response. I'm fairly literate in
CSS so you don't need to explain the methodology, I'm just interested in
your opinion as to what is the best alternative to floating <div>s.
Marc
Spartanicus
>>>>>Are you saying you don't approve of a layout with, for example with 2
>>>>><div>s where one is floated to put it along side the other?
>>>>
>>>>It's a nasty hack, drawbacks:
>>>>
>>>>a) It was never intended to be used as such, consequently usage other
>>>>than it's intended usage is fraught with issues that many authors
>>>>struggle with.
>
>What therefore would you count as its intended use? Just to align
>images within a body of text?
Inline content flowing beside and beneath a rectangular object that is
right or left aligned.
>>>>b) The CSS float rules are preposterously complex, this has resulted in
>>>>numerous browser float bugs, resulting in even more author confusion.
>>>
>>>So what would you recommend as an alternative? Absolute/Relative
>>>Positioning? Tables?
>>
>> A proper answer to that question is too big a topic for usenet.
>
>Oh I'm sure you can try to formulate a response. I'm fairly literate in
>CSS so you don't need to explain the methodology, I'm just interested in
>your opinion as to what is the best alternative to floating <div>s.
A comprehensively answer really is far too big a topic for the
transitory medium that is usenet. I'm not aware of a web resource that
explains all of it properly.
IIRC there was an url posted here not long ago pointing to an article on
floats written by a well known Mozilla guy. Someone here may remember it
and be able to point you to it, or a trawl through the group's archive
may help (I didn't read the article, but IIRC "float" was in the title
of the group's post).
--
Spartanicus
Alan J. Flavell
On Tue, 16 Jan 2006, cwdjrxyz wrote:
> Alan J. Flavell wrote:
> > > mime type in its accept header - even if the mentioning is to explicitly
> > > state that it does not accept it (i.e. with a quality value of zero).
> >
> > Blimey, *that* old chestnut again. Why *do* people insist on
> > reinventing the wheel, and then making it square? (or in this case
> > maybe triangular).
>
> I covered about the same as the above in a long response to Michael
> Winter. Thus I will not repeat it here.
Yeah right: you insist on sending XHTML to clients which have clearly
stated that they absolutely don't want it. Very clever.
bye
Michael Winter
[snip]
> You seem to miss the point that there are about 60000 calendars and
> each has to be custom calculated including custom CSS for each.
Rubbish. The layout for each is exactly the same, only the content
changes. The fact that you use DIV elements instead of a TABLE is your
own choice and, retracting a previous comment, is a much more potent
example of poor markup than the difficult to read, monolithic paragraph
to the right.
[snip]
> Sorry, I have seen numerous publications concerning what the browser
> might prefer to accept, what it will accept, etc.
Irrelevant. Follow the protocol. The Accept header, and the quality
values therein, are all you need to consider when negotiating by content
type and, in the event that only a media range would match
application/xhtml+xml, favour text/html.
[snip]
[MLW:]
>> The BODY element is rendered just like any other block-level element,
>> and only extends to surround content that is in normal flow. As such,
>> the background colour will not be rendered across the entire viewport.
>> The HTML element is the document root, and setting a background colour
>> there will cause it to be rendered as you'd prefer.
>
> Call it a bug, [...]
I call it quite reasonable behaviour.
> but the fact is that if you write an html page [...]
But you aren't writing HTML, are you, so a direct comparison is rather
pointless (other than to note the difference).
[snip]
> I am still hoping to see some of your pages written in xhtml 1.1 and
> served as such.
Considering that I think serving XHTML is, on the whole, a waste of
time (there are some special, rare exceptions), that isn't very likely.
Mike
Andy Dingley
wrote:
>>Are you saying you don't approve of a layout with, for example with 2
>><div>s where one is floated to put it along side the other?
>
>It's a nasty hack, drawbacks:
>
>a) It was never intended to be used as such, consequently usage other
>than it's intended usage is fraught with issues that many authors
>struggle with.
Why do you claim it was never intended as such ?
I can think of three ways to position <div>s alongside each other in
CSS: float, using tables, or absolute positioning.
Now it seems reasonable to assume that CSS _is_ intended to allow two
<div>s to be used as columns (simple separate columns, not
newspaper-flowed columns). If this is the case, then of those three
methods then float is the obvious way to do it.
What evidence do you have that CSS either wasn't intended to support
columns, wasn't intended to use float to do this, or has some other way
to do it ?
I agree that CSS floats have been hard to use and their implementations
have been less than perfect. This is largely a documentation issue
though, not the design of float itself. The brainjar.com article solves
may of these - shame it wasn't around with the initial spec.
cwdjrxyz
Michael Winter wrote:
> On 16/01/2006 23:45, cwdjrxyz wrote:
>
> [snip]
>
> > You seem to miss the point that there are about 60000 calendars and
> > each has to be custom calculated including custom CSS for each.
>
> Rubbish. The layout for each is exactly the same, only the content
> changes. The fact that you use DIV elements instead of a TABLE is your
> own choice and, retracting a previous comment, is a much more potent
> example of poor markup than the difficult to read, monolithic paragraph
> to the right.>
If you don't like the style of layout, you are quite free to write your
own perpetual calender. My style works quite well, is valid, loads fast
enough and I am content with it. Actually the way a page is written
often has little bearing on how it works at a machine level. Way back
in Fortran days, I found that it is a waste of time to worry much about
minute changes in how most of the Fortran was written. However when you
have loops nested several deep, how the loops at the bottom of the nest
are written can become rather important, and I have known people who
would work on a loop at either an assembly or even machine language
level for programs that ran several hours and pushed a mainframe to the
limits. Of course I am aware that html and script are quite different
from a compiled language such as Fortran.
> [snip]
>
> > Sorry, I have seen numerous publications concerning what the browser
> > might prefer to accept, what it will accept, etc.
>
> Irrelevant. Follow the protocol. The Accept header, and the quality
> values therein, are all you need to consider when negotiating by content
> type and, in the event that only a media range would match
> application/xhtml+xml, favour text/html.
It may be irrelevant for you but not for me. I am interested in pushing
xhtml to the limits, and apparently you are not. I really do not care
what level of html you select to use, even if it were 3.2 rather than
html 4.01 strict.
Has it ever been pointed out to you that you sometimes seem to try to
give other posters orders? For instance, "Follow the protocol" above. I
am not your student or employee. First, I have no idea who you are
other than you likely are working with some aspect of programming and
likely are in the UK. On a NG everyone seems to have a strong opinion.
I have no doubt that html 4.01 strict works quite well for you in what
you do, and if it concerns commercial web pages you would want to
change to anything new very slowly and carefully. Actually, if I have
technical questions(not just computing-related ones) for which I am
unsure and for which there are mixed answers on the web, I try to go to
the literature in peer reviewed journals published by the technical
societies, such as the American Institute of Physics, leading computer
journals(not the type owned by private companies to make money), etc.
Also in the past I was able to resolve a complicated problem or two by
contacting the W3C directly.
> [snip]
>
> [MLW:]
> >> The BODY element is rendered just like any other block-level element,
> >> and only extends to surround content that is in normal flow. As such,
> >> the background colour will not be rendered across the entire viewport.
> >> The HTML element is the document root, and setting a background colour
> >> there will cause it to be rendered as you'd prefer.
> >
> > Call it a bug, [...]
>
> I call it quite reasonable behaviour.
> > but the fact is that if you write an html page [...]
>
> But you aren't writing HTML, are you, so a direct comparison is rather
> pointless (other than to note the difference).
>
Also one should note the difference that Opera will display the
background-color to the bottom of the screen of a page for which
content does not fill the screen in either html or xhtml 1.1 served
properly, and that Mozilla family browsers do the same for html pages a
do most other browsers. Thus I would say that the Mozilla family
browsers have a problem when serving true xhtml in respect to the usual
handling of the coverage of background color, and if Opera can avoid
this problem, I do not see why Mozilla family browsers can not also.
> [snip]
>
> > I am still hoping to see some of your pages written in xhtml 1.1 and
> > served as such.
>
> Considering that I think serving XHTML is, on the whole, a waste of
> time (there are some special, rare exceptions), that isn't very likely.
Then I guess there likely is little point in continuing this
discussion, although you are of course free to do so on a Usenet group.
Michael Winter
[snip]
> I am interested in pushing xhtml to the limits, [...]
This has got nothing to do with "pushing XHTML to the limits". You are
breaking the HTTP protocol.
There are many liberties taken in Web development, but the transport
protocol should not be included among them.
[snip]
> Has it ever been pointed out to you that you sometimes seem to try to
> give other posters orders?
I am terse and they are not orders.
[Canvas background colours with XHTML]
> Also one should note the difference that Opera will display the
> background-color to the bottom of the screen of a page [...]
/Why/ should one? Have you actually read the CSS specification with
regard to background colours?
The background of the root element becomes the background of
the canvas and covers the entire canvas, [...]
Noting (again) that the HTML element is the root element. Furthermore,
For HTML documents, however, we recommend that authors specify
the background for the BODY element rather than the HTML
element. [...] This does not apply to XHTML documents.
-- 14.2 The background, CSS 2.1 [1]
If Opera Software want to apply the same rules to XHTML as they do to
HTML, that's solely their decision.
[snip]
Mike
[1] <http://www.w3.org/TR/CSS21/colors.html#q2>
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?
Okay, so I've heard the disadvantages of using HTML and also the
question "why use XHTML when you don't need to?" posed a lot. What
about some disadvantages of using XHTML - what reasons are there *not*
to use it?
Also, I found this article:
http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html - which
I have taken an excerpt from and pasted below. Would anyone care to
comment?
"The benefits of adopting XHTML now or migrating your existing site to
the new standards are many. First of all, they ensure excellent
forward-compatibility for your creations. XHTML is the new set of
standards that the web will be built on in the years to come, so
future-proofing your work early will save you much trouble later on.
Future browser versions might stop supporting deprecated elements from
old HTML drafts, and so many old basic-HTML sites may start displaying
incorrectly and unpredictably.
Once you have used XHTML for a short time, it is no more difficult to
use than HTML ever was, and in ways is easier since it is built on a
more simplified set of standards. Writing code is a more streamlined
experience, as gone are the days of browser hacks and display tricks.
Editing your existing code is also a nicer experience as it is
infinitely cleaner and more self-explanatory. Browsers can also
interpret and display a clean XHTML page quicker than one with errors
that the browser may have to handle.
A well-written XHTML page is more accessible than an old style HTML
page, and is guaranteed to work in any standards-compliant browser
(which the latest round have finally become) due to the insistence on
rules and sticking to accepted W3C specifications. As mentioned above,
XHTML allows greater access to configurations other than a computer and
browser. This interoperability is another aspect of XHTML's greater
accessibility."
I look forward to your responses.
Marc
Spartanicus
>What
>about some disadvantages of using XHTML - what reasons are there *not*
>to use it?
As posted earlier in the thread:
http://www.spartanicus.utvinternet.ie/no-xhtml.htm
--
Spartanicus
David Dorward
> Okay, so I've heard the disadvantages of using HTML and also the
> question "why use XHTML when you don't need to?" posed a lot. What
> about some disadvantages of using XHTML - what reasons are there *not*
> to use it?
Under XHTML rules <foo /> means the same as <foo></foo>. Under HTML rules it
means the same as <foo>>. Conformant browsers will spray ">" characters
all over the output of XHTML documents served as text/html. (There aren't
many browsers which get that part of the spec right, but they do exist).
> "The benefits of adopting XHTML now or migrating your existing site to
> the new standards are many. First of all, they ensure excellent
> forward-compatibility for your creations.
Compatibility with what? The new generation of browsers due out in 20 years
that aren't going to support 99%+ of the existing www?
> XHTML is the new set of
> standards that the web will be built on in the years to come, so
> future-proofing your work early will save you much trouble later on.
Converting HTML 4.01 Strict to XHTML 1.0 Strict is trivial to do
programatically. So using XHTML now will not save you "much trouble" later
on.
> Future browser versions might stop supporting deprecated elements from
> old HTML drafts, and so many old basic-HTML sites may start displaying
> incorrectly and unpredictably.
We aren't suggesting you use features which only appeared in drafts, not are
we suggesting you use deprecated features.
> Once you have used XHTML for a short time, it is no more difficult to
> use than HTML ever was,
Wrong. Its no more difficult to *write*. Getting it to clients in a sensible
way is another kettle of fish.
> and in ways is easier since it is built on a
> more simplified set of standards.
Wrong. The rules for XHTML 1.0 that conforms to Appendix C and the rules for
HTML 4.01 are pretty much identical. The only differences are:
* In XHTML elements defined as empty must be written as <foo /> not <foo>.
* In XHTML minimised attributes are not allowed
* In HTML there are a bunch of rules which say "this rule is optional IF".
In XHTML the optional clause is removed. This makes no real difference as
you can follow rules which are sometimes optional even when they are
optional!
> Writing code is a more streamlined
> experience,
Err...?
> as gone are the days of browser hacks and display tricks.
Rubbish. XHTML is not a magic wand that fixed browser bugs.
> Editing your existing code is also a nicer experience as it is
> infinitely cleaner and more self-explanatory.
Excuse me while I have a coughing fit. That's rubbish.
> Browsers can also interpret and display a clean XHTML page quicker than
> one with errors that the browser may have to handle.
That is true ... in theory (since the browser is required to throw an error
if the document is not well formed, so it doesn't have to worry about
trying to correct a certain type of error) ... but only if you serve the
document as application/xhtml+xml ... which isn't well supported ... so you
have to muck around with content negotiation.
In other words - IF you do a LOT of work then a MINORITY of your users MAY
see faster parsing of the document. (However, since most websites are
transmitted over the Internet, the time it takes to parse the document is
an insignificant fraction of the time between the request being made and
the page being rendered).
> A well-written XHTML page is more accessible than an old style HTML
> page,
Rubbish. Lets see some evidence to back that up.
> and is guaranteed to work in any standards-compliant browser
No more so then a well-written HTML document.
> As mentioned above, XHTML allows greater access to configurations other
> than a computer and browser.
No, it doesn't.
Alan J. Flavell
On Thu, 19 Jan 2006, David Dorward wrote:
> Converting HTML 4.01 Strict to XHTML 1.0 Strict is trivial to do
> programatically. So using XHTML now will not save you "much trouble"
> later on.
Right. But IMHO more to the point - those who keep warning us about
all the dreadful things that are going to happen when we code
HTML/4.01 directly, because of all the SGML-related horrors which the
HTML DTD permits, should know that XML-based processors can be invited
to output their results in normalised HTML/4.01, with those SGML
nasties automatically eliminated.
Hixie's famous rant includes, among other things, a comment along the
lines that much of which purports to be XHTML/1.0 is in reality just
XHTML-flavoured tag soup, relying just as much on browser foibles to
get the right answer, as was the HTML-flavoured tag soup which it
replaced; but if it was ever to be taken seriously as XHTML, they'd
get a nasty surprise. Based on what I've seen out there as text/html
with XHTML DTDs, I'd say the situation is at least as bad as he
predicted there. The hordes have jumped on the XHTML bandwagon
thinking it was sexy, without paying much attention to what it really
involves.
Current browsers are, after all, tuned to treating text/html as HTML,
not as XHTML. It's technically accurate to say that they only render
XHTML as intended because they implement a bug (emacs-w3, for one, had
to get the bug deliberately introduced, when it turned out that it had
been taking SGML a bit more seriously than was good for it). As long
as text/html is the practical Content-type to send, I reckon that
sending HTML is the right thing to do; XHTML will be worth using when
there's something useful to do with it, such as embedded MathML, SVG
or whatever, but then sending *that* as text/html is wrong.
An alternative approach would be to validate HTML against a
stripped-down HTML DTD, designed to disallow optional omissions etc.;
but there is no such officially-supported HTML DTD, so it's
understandable that the opponents of HTML wouldn't want to hear about
that. However, there are SGML processors which would normalise the
HTML, and address most of the issues which are in dispute (including
exposing the issue of the "<tag/content/" HTML/SGML short form which
is such a source of friction between theorists and pragmatists).
Gérard Talbot
> Marc wrote:
>
> Okay, so I've heard the disadvantages of using HTML
? If you use strict definition of HTML 4.01, I see no disadvantages.
I personally moved from XHTML 1.0 strict to HTML 4.01 strict about a
year ago after reading
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
I'm not alone to have done this. David Dorward, a regular poster in web
programming newsgroups, did the same. Also, recently, Benjamin Smedberg
did the same. See
HTML 4.01
http://benjamin.smedbergs.us/blog/2006-01-16/valid-html401/
where he interestingly writes:
"This blog is now valid HTML4.01 strict! By default, WordPress uses
XHTML with a text/html mime type, which I think is an abysmal choice.
And I don't care much for XHTML anyway (HTML4 with WhatWG extensions is
the future of the web), so I hacked my theme a little bit more and wrote
a little Wordpress plugin which disables a few XHTMLiries that WordPress
uses by default; these combined changes make this blog validate as
HTML4.01 strict."
Nvu User Guide recommends to its users to go for HTML 4.01 strict.
and also the
> question "why use XHTML when you don't need to?" posed a lot. What
> about some disadvantages of using XHTML - what reasons are there *not*
> to use it?
>
A lot of people already answered lengthly your double question in this
thread.
Need more reading? How about:
XHTML is dead
http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead
> Also, I found this article:
> http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html - which
> I have taken an excerpt from and pasted below. Would anyone care to
> comment?
>
> "The benefits of adopting XHTML now or migrating your existing site to
> the new standards are many. First of all, they ensure excellent
> forward-compatibility for your creations.
A transitional DTD does not have an assured forward-compatibility but a
strict one does. And with the current status of XHTML, I would not say
that, XHTML as defined/specified right now, is a solid guarantee of what
it will be in the future. I'm not an expert at this but it certainly
seem so.
Also, since MSIE 7 will not be supporting application/xhtml+xml, then it
certainly invite web authors to use HTML 4.01 for the next 10 years, at
least.
> XHTML is the new set of
> standards that the web will be built on in the years to come, so
> future-proofing your work early will save you much trouble later on.
That is what was expected but it doesn't seem clear anymore.
> Future browser versions might stop supporting deprecated elements from
> old HTML drafts, and so many old basic-HTML sites may start displaying
> incorrectly and unpredictably.
But this is *_exactly_* what I would say regarding transitional DTD
versus strict DTD.
In strict DTD, elements and attributes used for presentational/style are
formally deprecated, not recommended anymore.
Go and examine the code of that article
http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html
of yours:
target="_top"
bgcolor="#ffffff"
text="#000000"
are formally deprecated attributes but the markup code of that article
uses these anyway.
<h1 align="center"
is use of deprecated align.
etc,etc, etc.. That article is another good example of a webpage that
uses deprecated attributes which are not assured to be rendered in the
future. That is: XHTML markup code with deprecated attributes. The
article itself is in blatant contradiction here.
> Once you have used XHTML for a short time, it is no more difficult to
> use than HTML ever was, and in ways is easier since it is built on a
> more simplified set of standards.
What does prevent a web author from editing HTML elements with closing
tags when using HTML 4.01 strict?
e.g.:
<ul>
<li>blue
<li>red
</ul>
<ul>
<li>blue</li>
<li>red</li>
</ul>
Both lists above are valid HTML 4.01 strict but there is one which will
be parsed faster in all modern (web standards compliant) browsers.
What does prevent a web author from using lowercase for HTML elements
and for HTML attributes in HTML 4.01 strict?
What does prevent a web author from always quoting HTML attributes in
HTML 4.01 strict?
Quoting attribute values is one simple way to speed up parsing and
rendering in all modern browsers.
What does prevent a web author from avoiding attribute minimization when
using HTML 4.01 strict?
What does prevent a web author from using Tidy to eradicate more
unneeded code and small conformance errors that a validator cannot/does
not report, even in XHTML?
Several HTML elements are optional (body, html, tbody, etc.) in HTML
4.01 strict... but there is nothing preventing a web author from
explicitly declaring these.
> Writing code is a more streamlined
> experience, as gone are the days of browser hacks and display tricks.
One can still misuse markup code when writing an XHTML 1.0 page, even a
valid XHTML 1.0 page.
One can still use table for layout in XHTML. One can still use lots of
to create a padding effect in XHTML. One can still use
<blockquote> solely for the purpose to create a text indentation in
XHMTL. One can still use spacer.gif's in XHTML, lots of <br> instead of
CSS margin in XHTML, etc, etc, etc.
In fact, since Macromedia DreamWeaver has been able to use and render
XHTML, this is exactly the kind of markup code which was again and again
created, output, produced anyway and again: browser hacks and display
tricks but this time in XHTML !
"tables do a pretty lousy job of page construction. Among their
shortcomings is the implied bias of the code towards presentation rather
than structure, the necessity to nest tables in order to achieve the
most basic of layouts, and enough redundant bandwidth-hogging tags to
feed a large family of tag eating monsters for literally a month."
Tableless layout with Dreamweaver MX
http://www.macromedia.com/devnet/mx/dreamweaver/articles/tableless_layout.html
WYSIWYG Web tools comparison with hand-coded markup code. Everywhere,
hand code is better
http://www.backupbrain.com/2002_11_17_archive.html#a003122
> Editing your existing code is also a nicer experience as it is
> infinitely cleaner and more self-explanatory.
Cleaner? Not necessarly. This mostly depends on the web author
experience. Self-explanatory? Not true. This again depends entirely on
the web author's experience at wisely choosing semantic, giving
intuitive and self-explanatory identifiers to id attributes, class
attributes and at understanding of semantic markup.
If markup code is not enforced by browsers and by defined error
corrections in the specs, then XHTML is not an advancement over HTML,
especially when browsers are lead to accept XHTML served as tag soup.
Browsers can also
> interpret and display a clean XHTML page quicker than one with errors
> that the browser may have to handle.
But that is also true for strict HTML 4.01. This is not an advantage of
XHTML over HTML 4.01.
>
> A well-written XHTML page is more accessible than an old style HTML
> page,
A well-written strict HTML 4.01 page is/can be as accessible as a
well-written XHTML page. Missing alt attributes are reported as errors
by HTML 4.01 validation. XHTML code does not ensure accessibility of a
page more than an HTML one. A well written HTML webpage can be and will
be more accessible than a poorly written XHTML page.
and is guaranteed to work in any standards-compliant browser
> (which the latest round have finally become) due to the insistence on
> rules and sticking to accepted W3C specifications. As mentioned above,
> XHTML allows greater access to configurations other than a computer and
> browser. This interoperability is another aspect of XHTML's greater
> accessibility."
Even that last sentence is debattable. A valid, compliant and conformant
is a much better promise of interoperability than just usage of XHTML.
Gérard
--
remove blah to email me
David Dorward
> Right. But IMHO more to the point - those who keep warning us about
> all the dreadful things that are going to happen when we code
> HTML/4.01 directly, because of all the SGML-related horrors which the
> HTML DTD permits, should know that XML-based processors can be invited
> to output their results in normalised HTML/4.01, with those SGML
> nasties automatically eliminated.
Which is a good point. I've been focusing very much on what gets served to
the end user, but writing XHTML is not a bad idea, just delivering it to
clients. My own CMS takes XHTML input but runs it through some XSLT to
output HTML 4.01, and this works pretty well for me.
Gérard Talbot
> Also, I found this article:
> http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html - which
> I have taken an excerpt from and pasted below. Would anyone care to
> comment?
>
> "The benefits of adopting XHTML now or migrating your existing site to
> the new standards are many. First of all, they ensure excellent
> forward-compatibility for your creations.
Forward-compatibility for your XHTML creations.
Some parts of the XHTML 2 spec, as of right now (7th draft version), are
not supposed to be backward-compatible with XHTML 1.0. So there you have
it. More proof? Go to this exact url:
http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html
and then read in the right column these words:
"XHTML 2 won't come into operation for a while yet, not least because it
is not designed to be backwards-compatible (...)"
So, as of right now, your XHTML 1.0 page might (will?) have to be
re-written one day.
Again, that page shows another blatant contradiction.
XHTML is the new set of
> standards that the web will be built on in the years to come, so
> future-proofing your work early will save you much trouble later on.
> Future browser versions might stop supporting deprecated elements from
> old HTML drafts, and so many old basic-HTML sites may start displaying
> incorrectly and unpredictably.
deprecated?
The article itself, the one which was promoting XHTML, was and still is
using deprecated attributes:
[snipped]
> A well-written XHTML page is more accessible than an old style HTML
> page, and is guaranteed to work in any standards-compliant browser
> (which the latest round have finally become) due to the insistence on
> rules and sticking to accepted W3C specifications.
Even WCAG 2.0 states the opposite. Validity does not ensure
accessibility. Even WCAG 2.0 Level 1 compliance will not require validity.
http://www.w3.org/WAI/GL/2005/06/validity-accessibility.html
"It's the tools that need to be fixed and the developers and authors
that need to upgrade their skills, not the guidelines that should be
dumbed down."
http://www.456bereastreet.com/archive/200506/validity_and_accessibility/
Gérard Talbot
> Michael Winter wrote:
>> On 16/01/2006 03:10, cwdjrxyz wrote:
>>> [...] bugs, such as the CSS background-color bug for Mozilla family
>>> browsers [...]
>> The BODY element is rendered just like any other block-level element,
>> and only extends to surround content that is in normal flow. As such,
>> the background colour will not be rendered across the entire viewport.
>> The HTML element is the document root, and setting a background colour
>> there will cause it to be rendered as you'd prefer.
>
> Call it a bug, or whatever you wish, but the fact is that if you write
> an html page and view it on IE6, Mozilla family, or Opera browsers, the
> background color extends to the bottom of the screen if the content
> does not fill the whole screen, if you declare the background-color in
> the body section of the CSS style sheet.
For HTML 4.01 documents, yes: that is the expected behavior. Not for
XHTML documents.
However if you convert the
> page to proper xhtml 1.1 and serve properly, IE6(gets html strict
> instead of xhtml) and Opera still extend the background color to the
> bottom of the screen for a non-full screen,
Which is a reported bug at Opera, bug 176629.
XHTML body background propagates to canvas
http://geocities.com/csssite/operabugs/bug53.xhtml
while the Mozilla family
> browsers stop the background color at the end of the content displayed
> on the screen, with bright white instead of black to the bottom of the
> screen in my example. I perhaps can think of better names than bug for
> this problem, which are not suited for this group :-).
It was resolved as invalid several times at bugzilla.
https://bugzilla.mozilla.org/show_bug.cgi?id=147436
https://bugzilla.mozilla.org/show_bug.cgi?id=272804
Marc
> Which is a good point. I've been focusing very much on what gets served to
> the end user, but writing XHTML is not a bad idea, just delivering it to
> clients. My own CMS takes XHTML input but runs it through some XSLT to
> output HTML 4.01, and this works pretty well for me.
For what reason? Why not just take HTML input and save your CMS the
work of converting it using XSLT?
Marc
David Dorward
>> My own CMS takes XHTML input but runs it through some XSLT to
>> output HTML 4.01, and this works pretty well for me.
> For what reason? Why not just take HTML input and save your CMS the
> work of converting it using XSLT?
I had a lot of content in XHTML format already (from my XHTML fanboy days),
and it makes it easier to convert content to ATOM and other XML formats.
David Dorward
>> My own CMS takes XHTML input but runs it through some XSLT to
>> output HTML 4.01, and this works pretty well for me.
> For what reason? Why not just take HTML input and save your CMS the
> work of converting it using XSLT?
I had a lot of content in XHTML format already (from my XHTML fanboy days),
and it makes it easier to convert content to ATOM and other XML formats.
There is also the issues of things which are technically fine in HTML, but
cause problems in browsers (I had IE fail to recognise an entity because I
terminated it with a non-name character instead of a semi-colon recently).
Converting from XHTML to HTML generally avoids those issues.
Marc
>>>My own CMS takes XHTML input but runs it through some XSLT to
>>>output HTML 4.01, and this works pretty well for me.
>
>>For what reason? Why not just take HTML input and save your CMS the
>>work of converting it using XSLT?
>
> I had a lot of content in XHTML format already (from my XHTML fanboy days),
> and it makes it easier to convert content to ATOM and other XML formats.
I have a Java-based rich-text editor which outputs XHTML, and although
none of it is complex, my main problem is tag termination - ('<img ...
/>' instead of '<img ... >'). If I revert back to HTML, would XSLT be
the best way to convert this before putting it into the database? Or
would I be better of using some kind of regular expression in my PHP to
convert it?
Marc
Leonard Blaisdell
Marc <mbra...@beasolutions.com> wrote:
> I have a Java-based rich-text editor which outputs XHTML, and although
> none of it is complex, my main problem is tag termination - ('<img ...
> />' instead of '<img ... >'). If I revert back to HTML, would XSLT be
> the best way to convert this before putting it into the database? Or
> would I be better of using some kind of regular expression in my PHP to
> convert it?
Depending on how complicated your XHTML is, Tidy(free) can certainly
convert XHTML1.0 to HTML4.01 and vice versa with the click of an option.
I'm sure I'm out of my league here and have misunderstood your problem.
leo
Marc
> Depending on how complicated your XHTML is, Tidy(free) can certainly
> convert XHTML1.0 to HTML4.01 and vice versa with the click of an option.
> I'm sure I'm out of my league here and have misunderstood your problem.
Are you referring to HTML Tidy? If so, yes, you have misunderstood my
question - that's a client side application for editing HTML, I'm
talking about a server-side script that does it automatically to XHTML
that is outputted from another server-side script.
Thanks for your reply and attempt to help though. :)
Marc
Dylan Parry
proclaimed:
> Are you referring to HTML Tidy? If so, yes, you have misunderstood my
> question - that's a client side application for editing HTML
You can run it server-side, IIRC. Either by interfacing with the command
line through your scripts or by using TidyLib in conjunction with
whatever tools are available for your chosen language.
--
Dylan Parry
http://electricfreedom.org -- Where the Music Progressively Rocks!
Disclaimer: This post does not represent the opinion of me or my cats.
Marc
> You can run it server-side, IIRC. Either by interfacing with the command
> line through your scripts or by using TidyLib in conjunction with
> whatever tools are available for your chosen language.
That seems overcomplex to me, but thanks for the info, I'll investigate.
Marc