XHTML vs. HTML 4.01

[Whitecrest]

Do you have a practical example? This seems a bit arcane to me and I'd
really like to see it in practise. As I understand it, which is not well,
this is something that seldom makes much difference in real life.

What do you want as an example? A page that can't be xhtml? Pick any
site that uses padding and margins in quirks mode. The site looks
different in IE and mozilla based browsers.

If this is unimportant to you, then you are right, it doesn't matter.
But if the presentation does matter to you then XHTML and strict are
useless.

 

[Spartanicus]

I am really into learning XML, plus maintain a growing web site as a
volunteer webmaster. If it does no harm to have an XHTML web page, the
benefits of indexible pages and future compatibility seem attractive.

You seem to suggest that HTML is less "indexable" and/or future
compatible than XHTML, please explain.

Though, at the moment, I have legit XML copies of the stuff that I am
posting - so maybe actual XHTML is not all that desirable.

I am not sure. Most of the "guts" of a page are quite transposable
between XHTML and HTML Strict with little effort.

If you are using XML as a source then you can generate HTML Strict just
as easily as XHTML, so where's the benefit of choosing XHTML as the
output format?

 

[Jeff Thies]

What do you want as an example? A page that can't be xhtml?

Forget xhtml. The source of this thread was: HTML 4.01 Strict.

I don't have IE6, but I've never seen any difference in Moz based or Opera.
Nothing, zill. Maybe we just use the box model differently, but I wouldn't
have asked if I didn't want to see it.

Pick any
site that uses padding and margins in quirks mode. The site looks
different in IE and mozilla based browsers.

If this is unimportant to you, then you are right, it doesn't matter.

My clients want consistent results across a range of browsers including Mac
IE and Safari, usually that includes adjustments down to single pixels.
Rediculous as that sounds.

If you don't have an example, then just forget about it. It's not worth
the hassle.

Jeff

 

[Whitecrest]

Forget xhtml. The source of this thread was: HTML 4.01 Strict.

looks like the title says XHTML vs HTML 4.0 strict to me.

I don't have IE6, but I've never seen any difference in Moz based or Opera.
Nothing, zill. Maybe we just use the box model differently, but I wouldn't
have asked if I didn't want to see it.

And that is your decision, but you are not seeing what 80-90% of the
rest of the world are seeing then. You might want to install a copy to
see what others see.

My clients want consistent results across a range of browsers including Mac
IE and Safari, usually that includes adjustments down to single pixels.
Rediculous as that sounds.

Doesn't sound ridiculous at all. Design matters sometimes.

If you don't have an example, then just forget about it. It's not worth
the hassle.

Pick any site that uses strict. If they have a complicated design they
probably break.

 

[The Doormouse]

You seem to suggest that HTML is less "indexable" and/or future
compatible than XHTML, please explain.

Sure. If I want to data mine my past page updates, the XHTML ones can fly
through an XSLT transform with minimal, if any, editing. This could be
done server-side, allowing me to repurpose documents on demand. That just
isn't going to happen with standard HTML.

If you are using XML as a source then you can generate HTML Strict just
as easily as XHTML, so where's the benefit of choosing XHTML as the
output format?

Right. There is no benefit at this time. However, if I was not using an
XML source, the next best thing would be XHTML.

Also, having an XML source means storing that file on the server, should
I ever need it in the future.

The Doormouse

 

[Spartanicus]

Sure. If I want to data mine my past page updates, the XHTML ones can fly
through an XSLT transform with minimal, if any, editing.

To clarify: the phrase "indexable" as used by The Doormouse has no
relevance in a www context. The advantage is that the author can use XML
tools on the code (the only valid reason for outputting XHTML, note that
this rarely applies).

 

[Jukka K. Korpela]

Seems to me that, if we are talking about HTML/xHTML, we should use the
definition which the W3C uses in the HTML/xHTML specs.

Even when they are self-contradictory or contain false (and absurd)
presuppositions?

I don't think it's adequate to call deprecated constructs obsolete,
although my dictionaries give the impression that in normal English,
"deprecated" indicates disapproval, even rejection. The W3C technospeak
uses it for other purposes. Maybe "deprecated" might be informally
characterized as obsolescent - but not obsolete.

Regarding the W3C definition of "obsolete", it seems to imply that for
elements and attributes that are not obsolete, support by user agents
_is_ guaranteed. Now, can we sue someone for lack of support to <abbr>
on IE, for example? The W3C?

 

[C A Upsdell]

Even when they are self-contradictory or contain false (and absurd)
presuppositions?

Surely it is more absurd when each debator chooses their own definition,
regardless of what definition is provided in the recommendation.

Regarding the W3C definition of "obsolete", it seems to imply that for
elements and attributes that are not obsolete, support by user agents
_is_ guaranteed.

The recommendation says 'should', not 'must'.

Now, can we sue someone for lack of support to <abbr> on IE, for example?

The W3C?

Only if the recommendation is made a law, which is not the case ... yet ...
hmmm, I wonder if SCO, or Eolas, or Forgent would be interested in pursuing
this? ;-)

 

[Jukka K. Korpela]

The recommendation says 'should', not 'must'.

No, this is not about 'should' vs. 'must' but about _definitions_.
Definitions themselves are not normative, just descriptions of concepts
used in giving recommendations or doing something else.

And the definition "An obsolete element or attribute is one for which
there is no guarantee of support by a user agent" logically postulates
that there are elements or attributes for which there _is_ guarantee of
support by a user agent. The concept of guarantee is not defined, so I
guess we need to imply an everyday meaning. Anyway, where is the
guarantee?

Unless you can point out some statement of guarantee of support by user
agents for some elements or attributes, we can deduce that the W3C
definition of "obsolete" leads us to the conclusion that _all_ elements
and attributes are obsolete.

Or, alternatively, that the definition is nonsense and isn't meant to
mean what it says.

 

[Neal]

Unless you can point out some statement of guarantee of support by user
agents for some elements or attributes, we can deduce that the W3C
definition of "obsolete" leads us to the conclusion that _all_ elements
and attributes are obsolete.

Or, alternatively, that the definition is nonsense and isn't meant to
mean what it says.

Well, for starters, <html> and <title> are going to be observed by any
conforming browser. So those aren't obsolete.

If it weren't so late here, I might come up with a few more. Yet your
point carries.

 

[Leif K-Brooks]

And the definition "An obsolete element or attribute is one for which
there is no guarantee of support by a user agent" logically postulates
that there are elements or attributes for which there _is_ guarantee of
support by a user agent.

Perhaps a user agent which doesn't support all non-obsolete elemenents
isn't really an HTML user agent.

 

[Andy Dingley]

That depends on which definition of obsolete you are using.

Then you'd be wrong.

Regarding deprecated as simply "obsolete" is inaccurate. Regarding the
target attribute, this is a significant inaccuracy. There is no
intention to _remove_ the "target" concept from the future of (X)HTML,
merely to re-implement it by another and hopefully better route. In
the meantime, the old target attribute is deprecated (don't use it
until something better comes along) but is far from obsolete.

 

[Jukka K. Korpela]

Well, for starters, <html> and <title> are going to be observed by
any conforming browser. So those aren't obsolete.

I don't think current browsers normally care the least about <html>, they
just skip it. As for <title>, there is no _required_ behavior, i.e.
browsers need not observe it any particular way, except syntactically.

But irrespective of this, there is no _guaranteed_ support by user
agents.

Maybe the W3C misspelled "required" as "guaranteed"? This would actually
make some sense.

 

[Andy Dingley]

Perhaps a user agent which doesn't support all non-obsolete elemenents
isn't really an HTML user agent.

Absolutely not. This is clearly stated. The expectations of "user
agent" are deliberately absolutely minimal.

For one thing, a user agent that fully supports HTML 2.0 (that being
the current version of the day) does not cease to be a user agent when
HTML 3.2 introduces the <dancing-penguins> tag.

 

[Steve Pugh]

For one thing, a user agent that fully supports HTML 2.0 (that being
the current version of the day) does not cease to be a user agent when
HTML 3.2 introduces the <dancing-penguins> tag.

I remember the <dancing-penguins> tag. When Netscape 2.1 came out
everybody put dancing penguins on their site! Shame that Microsoft had
to go and spoil everything by not supporting it and inventing their
own <strutting-canaries> tag.

Now, what's the CSS equivalent of <dancing-penguins type="tango"> ?

Steve

 

[Jukka K. Korpela]

I remember the <dancing-penguins> tag. When Netscape 2.1 came out
everybody put dancing penguins on their site! Shame that Microsoft had
to go and spoil everything by not supporting it and inventing their
own <strutting-canaries> tag.

That was because penguins were taken as allusions to Linux. For a short
period of time, Microsoft actually supported <dancing-penguins> but with
an attribute called life-span, with a permitted value range of 0 to
5,000, defaulted to 1,000 (interpreted as microseconds).

The real reason for abolishing the tag was that the much more powerful
and expressive <marquee> tag was invented. Using it, you can create the
dancing penguins effect, too, see for a demo at
http://www.cs.tut.fi/~jkorpela/test/peng.html
based on a relatively simple <marquee> with an image inside it.

 

[Steve Pugh]

The real reason for abolishing the tag was that the much more powerful
and expressive <marquee> tag was invented. Using it, you can create the
dancing penguins effect, too, see for a demo at
http://www.cs.tut.fi/~jkorpela/test/peng.html
based on a relatively simple <marquee> with an image inside it.

Now that's odd. Opera 7 supports <marquee> (spit) but that page
doesn't scroll in Opera unless I switch images off in which case the
alt text does scroll. Oh I see, the image is wider than the marquee.
Looks like Opera isn't dancing compliant. ;-)

Steve

 

[C A Upsdell]

And the definition "An obsolete element or attribute is one for which
there is no guarantee of support by a user agent" logically postulates
that there are elements or attributes for which there _is_ guarantee of
support by a user agent. The concept of guarantee is not defined, so I
guess we need to imply an everyday meaning. Anyway, where is the
guarantee?

Unless you can point out some statement of guarantee of support by user
agents for some elements or attributes, we can deduce that the W3C
definition of "obsolete" leads us to the conclusion that _all_ elements
and attributes are obsolete.

The full definition of 'obsolete' from the HTML 4.01 recommendation -- the
second sentence of which you conveniently omitted -- is:

"An obsolete element or attribute is one for which
there is no guarantee of support by a user agent.
Obsolete elements are no longer defined in the
specification, but are listed for historical purposes
in the changes section of the reference manual."

It is clear from this definition -- and from the definition of 'deprecated',
also from the HTML 4.01 recommendation -- is that 'deprecated' and
'obsolete' are not synonymous. Deprecated elements are defined in the
specification as elements which may become obsolete in some later
recommendation; whereas obsolete elements are not defined in the
recommendation at all. So it would be fallacious to conclude, as you have
done, that "all_ elements and attributes are obsolete": only those not
defined in the recommendation are obsolete.

 

[Jukka K. Korpela]

The full definition of 'obsolete' from the HTML 4.01 recommendation
-- the second sentence of which you conveniently omitted -- is:

"An obsolete element or attribute is one for which
there is no guarantee of support by a user agent.
Obsolete elements are no longer defined in the
specification, but are listed for historical purposes
in the changes section of the reference manual."

I omitted the sentence that had not been quoted and that does not
actually constitute part of the _definition_. The first sentence defines
what "obsolete" means in W3C parlance; the second one _uses_ this word to
say something (which might be true or false, depending on the state of
affairs).

It is clear from this definition -- and from the definition of
'deprecated', also from the HTML 4.01 recommendation -- is that
'deprecated' and 'obsolete' are not synonymous.

It indeed is. _I_ didn't say they were synonyms. My point was about
_guaranteed support_ to non-obsolete elements and attributes.

So it would be fallacious
to conclude, as you have done, that "all_ elements and attributes are
obsolete": only those not defined in the recommendation are
obsolete.

My conclusion was a deductio ad absurdum, aimed at proving that the W3C
definition of "obsolete" is nonsensical. You have not proved this
reasoning fallacious. We agree on the notion that all elements and
attributes are obsolete cannot be right; but what I'm saying that this
nonsensical statement is a logical consequence of the W3C definition.

 

[Neal]

My conclusion was a deductio ad absurdum, aimed at proving that the W3C
definition of "obsolete" is nonsensical. You have not proved this
reasoning fallacious. We agree on the notion that all elements and
attributes are obsolete cannot be right; but what I'm saying that this
nonsensical statement is a logical consequence of the W3C definition.

Look at this, though. "A" could mean "any" instead of "all". I read this
now to mean that an element that is not obsolete is guaranteed to work in
"some" UA somewhere, not necessarily all - and clearly not all.

But I do agree, it is a poorly written definition.