XHTML or HTML 4 ?

[Alan J. Flavell]

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

 

[=?ISO-8859-1?Q?=BBQ=AB?=]

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).

<http://dbaron.org/log/2005-12>

 

[Michael Winter]

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.

[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]

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]

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]

On 18/01/2006 17:20, cwdjrxyz wrote:

[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

 

[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>&gt;. 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]

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).

 

[=?windows-1252?Q?G=E9rard_Talbot?=]

Marc wrote :

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
&nbsp; 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

 

[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.

 

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

Marc wrote :

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:

http://validator.w3.org/check?uri=h...matically)&doctype=XHTML+1.0+Strict&verbose=1

[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

 

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

cwdjrxyz 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

Gérard

 

[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]

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]

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]

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]

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