Who started "get ready for XML -- code br with a trailing slash"?

[Hostile17]

I keep coming across people, online and in real life, who believe that
to code single tags like <br> and <img> with trailing slashes, <br />
and <img /> is considered "best practice" and when challenged, they
say that "everyone's going to be using XML/XHTML soon" and say that
they're "getting ready" by coding this way.

Coding this way causes validation errors in HTML 4 Transitional and
HTML 4 Strict, so it can't be "best practice".

But more to the point, XHTML isn't "coming one day". It's here. If
you're using it, code this way, if not, not.

It's all rather cargo-cult if you ask me.

Does anyone know where this idea started? Are they teaching it in
universities? Did some HTML guru tell people this was the way to go?
Some book, some website? The lack of logic offends me.

[Matthias Gutfeldt]

Hostile17 wrote:

I keep coming across people, online and in real life, who believe that
to code single tags like <br> and <img> with trailing slashes, <br />
and <img /> is considered "best practice" and when challenged, they
say that "everyone's going to be using XML/XHTML soon" and say that
they're "getting ready" by coding this way.

I think what is considered "best practice" is writing empty elements
with a space before the trailing /, like it's explained in the "HTML
Compatibility Guidelines" <http://www.w3.org/TR/xhtml1/#guidelines>:

* * *
C.2. Empty Elements
Include a space before the trailing / and > of empty elements, e.g. <br
/>, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the
minimized tag syntax for empty elements, e.g. <br />, as the alternative
syntax <br></br> allowed by XML gives uncertain results in many existing
user agents.
* * *

My guess is that somebody misunderstood the "HTML" in the title. These
guidelines are for compatibility with HTML *user agents*, not with the
HTML *document type*.
Matthias

[Jim Ley]

On 16 Sep 2003 21:21:54 -0700, ho*******@bigfoot.com (Hostile17)
wrote:

But more to the point, XHTML isn't "coming one day". It's here. If
you're using it, code this way, if not, not.
XHTML is not here today, in that the majority of browsers don't
support it, and don't claim to support it, if you believe XHTML is
here today then <br /> is fine - it's tag-soup just like the rest of
XHTML served as text/html.
Does anyone know where this idea started? Are they teaching it in
universities?

XHTML evangelists have done a lot of gibberish...

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

Jim Ley wrote:

On 16 Sep 2003 21:21:54 -0700, ho*******@bigfoot.com (Hostile17)
wrote:

But more to the point, XHTML isn't "coming one day". It's here. If
you're using it, code this way, if not, not.

XHTML is not here today, in that the majority of browsers don't
support it, and don't claim to support it, if you believe XHTML is
here today then <br /> is fine - it's tag-soup just like the rest of
XHTML served as text/html.

How can XHTML served as text/html be any more or less tag-soup than
non-X-HTML? To me there is only a syntactical difference, and whichever
flavor you prefer (x or not) should do just fine in browsers. I find
XHTML easier to parse (by my tools as well as my brain, if you know
what I mean), that's why I use it.

I don't need to know about the doctype to create the document tree. In
HTML I need to know for every element what's it all about, e.g. I don't
know if

<p>test<br>test<p>test

means

p
|
-- br
|
-- p

or

p
|
-- br
|
p

.... in other words, wether or not the second p is next sibling or child
node. I don't know without the DTD.
If you write

<p>test<br />test</p><p>test</p>

it'd be quite obvious without parsing the DTD. So I suppose someone
came up with the thought that adding the <br /> to HTML would make some
sense, maybe to human readers. Well, just some explanation. I guess
someone was just confused. It just seems plain dumb to use <br /> in
non-X-HTML. Even though browsers just won't care. Just bad for using
validation tools.
Anyway. There's a certain tendency on many websites to pretend XHTML1
has some accessibility or other bonus (like search engine optimization)
compared to HTML4 which is of course just legend.
To say "XHTML is not supported by the majority of browsers" like you do
however seems to be starting just another legend. Not that you're not
right (XHTML as XML application, etc.), but more in the sense of how
it'd be understood by most people ("Oh, I can't use XHTML in most
browsers" -- yes you can).

--
Google Blogoscoped
http://blog.outer-court.com

[Jim Ley]

On 17 Sep 2003 09:15:38 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Jim Ley wrote:

On 16 Sep 2003 21:21:54 -0700, ho*******@bigfoot.com (Hostile17)
wrote:

>But more to the point, XHTML isn't "coming one day". It's here. If
>you're using it, code this way, if not, not.
XHTML is not here today, in that the majority of browsers don't
support it, and don't claim to support it, if you believe XHTML is
here today then <br /> is fine - it's tag-soup just like the rest of
XHTML served as text/html.

How can XHTML served as text/html be any more or less tag-soup than
non-X-HTML?

Valid HTML 4.01 could be parsed as HTML, and achieve reliable results,
XHTML shorttags won't they need tag-soup parsing. There's no
difference between XHTML and tag-soup HTML, all of it relies on the
browsers being able to fix up tag-soup.
To me there is only a syntactical difference, and whichever
flavor you prefer (x or not) should do just fine in browsers.
In tag-soup ones, yeah they'll almost certainly do fine, however with
xhtml you're relying on tag-soup parsing where it's up to the browser
to work out what you intended, and not some formal specification. If
you're content that's okay, then that's fine. XHTML evangelists have
represented XHTML as more than this, suggesting it is in some way
superior to other approaches, when it's really just the same old tag
soup as other invalid HTML.
I find
XHTML easier to parse (by my tools as well as my brain, if you know
what I mean), that's why I use it.
That's fine, I'm sure any CIWAH reader is up to making their own
decisions through the mess and decide that tag-soup parsing is
reliable enough, it's when half a message gets outside ciwah and
people take half of that and end up with a garbled mess, like the OP's
story.
To say "XHTML is not supported by the majority of browsers" like you do
however seems to be starting just another legend. Not that you're not
right (XHTML as XML application, etc.), but more in the sense of how
it'd be understood by most people ("Oh, I can't use XHTML in most
browsers" -- yes you can).

Good old fashioned Tag-Soup works just great too, should I advocate
that instead? XHTML tag-soup is just as distasteful as other
tag-soups, it's all relying on the lax parsing of browsers.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

Jim Ley wrote:

On 17 Sep 2003 09:15:38 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

How can XHTML served as text/html be any more or less tag-soup than
non-X-HTML?

Valid HTML 4.01 could be parsed as HTML, and achieve reliable results,
XHTML shorttags won't they need tag-soup parsing. There's no
difference between XHTML and tag-soup HTML, all of it relies on the
browsers being able to fix up tag-soup.

To me there is only a syntactical difference, and whichever
flavor you prefer (x or not) should do just fine in browsers.

In tag-soup ones, yeah they'll almost certainly do fine, however with
xhtml you're relying on tag-soup parsing where it's up to the browser
to work out what you intended, and not some formal specification.

I think your definition of tag-soup is "not 100% valid", e.g. any XHTML
send out as text/html woul be tag-soup because XHTML should be served
as XML application.
I have a different definition; tag-soup is garbage HTML with a lot of
redundancy, one that becomes hard to manage, complex to parse,
error-prone, incompatible for cross-browser/ cross-media rendering, and
so on.
"Not 100% valid" in this case is OK to me because it's very easy to
switch from content-type X to content-type Y. It is not easy to e.g.
switch from table-layout to CSS-layout; simply not possible by just
switching a server-setting. Besides, the validator still works, so I
can check for bugs I need be concerned about.

In Germany we say "Das Kind mit dem Bade ausschutten" for what seems
you're doing with XHTML. I think there's a similar phrase in English;
http://forum.leo.org/archiv/2002_06/...31146e_en.html
--
Google Blogoscoped
http://blog.outer-court.com

[Jim Ley]

On 17 Sep 2003 09:57:30 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

"Not 100% valid" in this case is OK to me because it's very easy to
switch from content-type X to content-type Y. It is not easy to e.g.
switch from table-layout to CSS-layout; simply not possible by just
switching a server-setting.
What does table/CSS layout have to do with an XHTML/HTML decision or
you suggesting that CSS doesn't work with HTML?
In Germany we say "Das Kind mit dem Bade ausschutten" for what seems
you're doing with XHTML. I think there's a similar phrase in English;
http://forum.leo.org/archiv/2002_06/...31146e_en.html

XHTML 2.0 could be useful (I doubt it, it still seems much to limited
to be a successor to me, if we're going to have a step-change to new
user agents we might aswell go to a very rich mark-up language) but
XHTML has nothing that HTML doesn't.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

Jim Ley wrote:

On 17 Sep 2003 09:57:30 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

"Not 100% valid" in this case is OK to me because it's very easy to
switch from content-type X to content-type Y. It is not easy to e.g.
switch from table-layout to CSS-layout; simply not possible by just
switching a server-setting.

What does table/CSS layout have to do with an XHTML/HTML decision or
you suggesting that CSS doesn't work with HTML?

No, I'm not. It seems to me you equal XHTML with tag-soup. I was giving
an example of what I understand to be tag-soup (like table-layout
without signs of CSS). So in my understanding tag-soup covers XHTML as
well as HTML, and can also be avoided in both.

In Germany we say "Das Kind mit dem Bade ausschutten" for what seems
you're doing with XHTML. I think there's a similar phrase in English;
http://forum.leo.org/archiv/2002_06/...31146e_en.html

XHTML 2.0 could be useful (I doubt it, it still seems much to limited
to be a successor to me, if we're going to have a step-change to new
user agents we might aswell go to a very rich mark-up language) but
XHTML has nothing that HTML doesn't.

It is a little easier to create a document tree, because all you need
is a general XML-document-tree generator -- you don't need to know the
specific document type. Same for unquoted attributes -- in XHTML you
cannot leave attributes unquoted, so again a parser tool analyzing
XHTML could be a little easier to write. This argument alone is not
that valuable except for my own little tools, and because it seems to
make XHTML slightly simpler and more elegant.
But it seems you are suggesting XHTML is not usable for some reason
because of the lack of browser support, whereas I would say it's just
as usable as non-X-HTML, so everybody should use whatever they prefer
for whatever reasons -- it won't make a difference to the end-user
(unless you're using the <?xml ..> line, which shows in some older
browsers e.g. on Mac).

--
Google Blogoscoped
http://blog.outer-court.com

[Keith Bowes]

Jim Ley wrote:

On 16 Sep 2003 21:21:54 -0700, ho*******@bigfoot.com (Hostile17)
wrote:

But more to the point, XHTML isn't "coming one day". It's here.

XHTML is not here today, in that the majority of browsers don't
support it

Most newer browsers do: Mozilla, Netscape, Opera, Konqueror, Safari,
Amaya ... A certain outdated browser that a certain megalomaniacal
monopoly keeps forcing on people doesn't, nor do browsers that list HTML
3.2 support as a feature.

[Jim Ley]

On 17 Sep 2003 11:03:22 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

But it seems you are suggesting XHTML is not usable for some reason
because of the lack of browser support, whereas I would say it's just
as usable as non-X-HTML, so everybody should use whatever they prefer
for whatever reasons

The problem with feeding tag-soup to tag-soup browsers is it that
perpetuates the idea that tag-soup is the way to author, all XHTML
served as text/html is treated as tag-soup, therefore there's no
advantage whatsoever in serving valid or invalid XHTML, people are
free to serve whatever they want, safe in the knowledge that it will
be rendered much the same. Without the constraints of validity,
what's the advantage of XHTML?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Andy Dingley]

On Wed, 17 Sep 2003 10:16:42 +0200, Matthias Gutfeldt <wo***@gmx.at>
wrote:

I think what is considered "best practice" is writing empty elements
with a space before the trailing /, like it's explained in the "HTML
Compatibility Guidelines" <http://www.w3.org/TR/xhtml1/#guidelines>:

No, that's best practice for writing XHTML.

For writing HTML (as the OP points out) it's mere cargo-cultism.

It's positively _harmful_ to validation (if served under a HTML
DOCTYPE), but then so little web content validates anyway...

[Andy Dingley]

On Wed, 17 Sep 2003 08:47:02 GMT, ji*@jibbering.com (Jim Ley) wrote:

XHTML is not here today, in that the majority of browsers don't
support it, and don't claim to support it,
XHTML is here today, in that you can work with it, and serve it to
browsers that don't support it. They then fall back to
Bob-knows-what, but it works (for the typical crufty web values of
"works").

The fact that browsers still can;t deal properly with it does not mean
that it isn't potentially a useful thing to be working with XHTML, for
your own server-related purposes. The browsers neither know nor care
why, and they don't suffer because.
if you believe XHTML is
here today then <br /> is fine

Indeed. But only if your content is claiming to be XHTML.

[Hostile17]

> >>But more to the point, XHTML isn't "coming one day". It's here.

XHTML is not here today, in that the majority of browsers don't
support it

Before I start ranting, thanks very much for your comments,
particularly Matthias who I think hit the spot with his theory about
misinterpretation of the guidelines.

As far as I'm concerned, I've always thought of XHTML as HTML 4
rewritten, as identically as possible, in XML -- isn't that right?

The main variations being these trailing slashes and the elimination
of value-less attributes like NOWRAP or NOSHADE or whatever.

It's a version of HTML which will render OK in most browsers, but
withstand parsing as XML.

But, so what? As a lot of people have pointed out like Kottke and
Celik, valid doesn't mean meaningful.

Just because you're producing valid XHTML doesn't mean you're not
doing

<div class="header" style="font-weight: bold;">
Here's my header
</div>
<div class="bodytext">
Here's my paragraph of text
</div>

which is valid but stupid.

HTML 3.2 which uses

<h1>
Here's my header
</h1>
<p>
Here's my paragraph of text
</p>

is a hundred times better, and a lot closer to this utopian Semantic
Web thing people go on about.

The only value I see on a daily basis for XHTML is that it's the kind
of HTML you can produce with XML and XSLT, and it pretty much works in
browsers.

[Jukka K. Korpela]

ho*******@bigfoot.com (Hostile17) wrote:

As far as I'm concerned, I've always thought of XHTML as HTML 4
rewritten, as identically as possible, in XML -- isn't that right?
Yes, that's right, and the XHTML 1.0 specification rather explicitly says
that.
The main variations being these trailing slashes and the elimination
of value-less attributes like NOWRAP or NOSHADE or whatever.
These are two separate issues, and the latter is actually part of a wider
change that removes much of the syntactic variation allowed, such as end
tag omission, lower vs. upper case in tag names, and omission of quotation
marks around attribute values in many cases. Such a change (limitation) is
describable in SGML and could have been made easily without XML. The
"trailing slashes", on the other hand, are a separate change, and it
violated some fundamental principles behind SGML. As it so often happens,
SGML was retrofitted to make this "legal".
Just because you're producing valid XHTML doesn't mean you're not
doing [ markup with <div> and class attributes ]

True, but this is quite independent of the HTML vs. XHTML distinction.
Contrary to popular belief (which has perhaps partly been intentionally
induced by XML and XHTML evangelists), XHTML is no more (and no less)
structural than HTML. All those obligatory end tags etc. at most make the
structure more easily visible to the human reader of markup. (This might
often be useful, but making all end tags required is really a nuisance to
readability e.g. if you have a large (data) table, in addition to
increasing file size.)
The only value I see on a daily basis for XHTML is that it's the kind
of HTML you can produce with XML and XSLT, and it pretty much works in
browsers.

And it's really not a value in XHTML itself. The use of XHTML is just the
result of using tools that have been written to produce XHTML. There's
nothing wrong with that, of course; in practice, HTML conformant user
agents are very rare birds, so those extra slashes don't cause harm.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Matthias Gutfeldt]

Andy Dingley wrote:

On Wed, 17 Sep 2003 10:16:42 +0200, Matthias Gutfeldt <wo***@gmx.at>
wrote:

I think what is considered "best practice" is writing empty elements
with a space before the trailing /, like it's explained in the "HTML
Compatibility Guidelines" <http://www.w3.org/TR/xhtml1/#guidelines>:

No, that's best practice for writing XHTML.

Strange. I link to the XHTML specification, I quote the XHTML
guidelines, I point out that "These guidelines are for compatibility
with HTML *user agents*, not with the HTML *document type*. " - and you
still misunderstand what I'm writing?
Matthias

[The Plankmeister]

> The fact that browsers still can;t deal properly with it does not mean

that it isn't potentially a useful thing to be working with XHTML, for
your own server-related purposes. The browsers neither know nor care
why, and they don't suffer because.

Is there a difference between an xhtml document that validates, and an
"xhtml" document that does not validate, from a browser's point of view?
Surely if the browser can parse the document against the DTD and finds no
discrepencies, it can shove it on the screen just how you intended? But if
it parses badly and is riddled with errors, I assume that's the moment the
browser adds tag soup to its menu?

If so, then what's the issue with developing xhtml as long as you write well
structured documents that validate correctly?

Or have I totally misunderstood the relationship between
browsers/DTDs/xhtml?

P.

[Andy Dingley]

On Thu, 18 Sep 2003 10:16:42 +0200, Matthias Gutfeldt <wo***@gmx.at>
wrote:

Strange. I link to the XHTML specification, I quote the XHTML
guideline

Yes, but the OP was talking about it in reference to HTML

[Bart Lateur]

Philipp Lenssen wrote:

How can XHTML served as text/html be any more or less tag-soup than
non-X-HTML?

I think you misunderstand the meaning of the name "tag soup". It is used
only when the tags don't properly nest, as in:

This is <b>bold, <i>bold italic</b>, italic only</i>, normal

You're talking about a whole other phenomenon, here.

--
Bart.

[Philipp Lenssen]

Bart Lateur wrote:

Philipp Lenssen wrote:

How can XHTML served as text/html be any more or less tag-soup than
non-X-HTML?

I think you misunderstand the meaning of the name "tag soup". It is
used only when the tags don't properly nest, as in:

This is <b>bold, <i>bold italic</b>, italic only</i>, normal

You're talking about a whole other phenomenon, here.

Tag-soup is used as a more general term by most people. Just do a
Google search and you will see.

Your phenomenon would be "overlapping elements" as far as I'm concerned
(and it's also a part of tag-soup). E.g. the oldest reference I could
find from Usenet would Alan J. Flavell in "<P align=center> vs.
<center>" from 1996.

<http://groups.google.com/groups?selm...211859.4117H-1
00000%40hpplus01.cern.ch>

Even valid XML can qualify as tag soup...

--
Google Blogoscoped
http://blog.outer-court.com

[Bart Lateur]

Jukka K. Korpela wrote:

The
"trailing slashes", on the other hand, are a separate change, and it
violated some fundamental principles behind SGML. As it so often happens,
SGML was retrofitted to make this "legal".

Heh? I trust your judgement, it's not that, but... I've been told that
these were always legal in SGML, thus, James Clark's SGML parsers (the
original, and also the reference) can grok it without choking.

So what's the exact status?

--
Bart.

[Jukka K. Korpela]

Bart Lateur <ba*********@pandora.be> wrote:

The
"trailing slashes", on the other hand, are a separate change, and it
violated some fundamental principles behind SGML. As it so often
happens, SGML was retrofitted to make this "legal".

Heh? I trust your judgement, it's not that, but... I've been told that
these were always legal in SGML, thus, James Clark's SGML parsers (the
original, and also the reference) can grok it without choking.

You can see what an SGML parser does if you submit a document containing
<meta name="purpose" content="demo" />
to SGML validation. It does not matter whether the solidus (slash) is
preceded by a space or not.

The reason why SGML validators don't usually complain about <br />
is that they treat it as <br>> and normally they have no reason to
say anything about the second greater than sign, which is treated as data
character, not part of any markup. But <meta> tags occur in the <head>
part, where character data is not allowed.

The retrofitting took place in "Web SGML Adaptations Annex". It's
incorporated into XML or, to be honest, it was written to make XML
formally a variant of SGML. For an overview of differences between XML and
SGML, check http://www.w3.org/TR/NOTE-sgml-xml-971215#null

The long story: http://www.cs.tut.fi/~jkorpela/html/empty.html

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Henri Sivonen]

In article <3f***********************@dread15.news.tele.dk> ,
"The Plankmeister" <pl******************@hotmail.com> wrote:

Is there a difference between an xhtml document that validates, and an
"xhtml" document that does not validate, from a browser's point of view?
There are three kinds of parsers to consider: tag soup parsers, XML
parsers (non-validating) that do not process the external subset, and
XML parsers (either validating or non-validating) that process the
external subset.

An XHTML document can be valid but lack explicit xmlns attributes. Tag
soup parsers don't care. Parsers that process the external subset would
default the attribute, but I am not aware of any real XHTML browsers
that would process the external subset and default attributes. An XML
parser that doesn't process the external subset would put all the
elements in the default namespace, in which case the elements would not
be understood to be XHTML elements.

It is possible to construct a document which is DTDless but yields the
same document tree as a valid XHTML document. As far as browsers using
XML parsers are concerned, such a DTDless document should be equivalent
to the valid document with the same document tree. Depending on how and
to elements are written the document would also "work" as tag soup.
However, tags soup browsers might choose the quirks mode in the absence
of a doctype declaration.

Character entities, which are allowed in valid documents, don't work in
XML parsers that do not process the external subset. Real XHTML browsers
are likely to be use such parsers.

The XHTML 1.1 DTD defaults the xmlns attribute on every element.
Therefore, the document tree is different depending on whether the
attributes have been defaulted. However, in practice the browsers don't
care about the superfluous xmlns attributes.
Surely if the browser can parse the document against the DTD and finds no
discrepencies, it can shove it on the screen just how you intended?
Display usually involves CSS as well. Validity does not guarantee a
particular display.
But if
it parses badly and is riddled with errors, I assume that's the moment the
browser adds tag soup to its menu?

No, when a real XML parser encounters a fatal error--that is, a
well-formedness error--that's the end of the parse. A tag soup parser,
on the other hand, has tags soup on its menu from the beginning.

--
Henri Sivonen
hs******@iki.fi
http://www.iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Stan Brown]

In article <Xn****************************@193.229.0.31> in
comp.infosystems.www.authoring.html, Jukka K. Korpela
<jk******@cs.tut.fi> wrote:

For an overview of differences between XML and
SGML, check http://www.w3.org/TR/NOTE-sgml-xml-971215#null

With Mozilla 1.4 on Win98, I get:
"This XML file does not appear to have any style information
associated with it. The document tree is shown below."

Is the page bad, or is it Mozilla?

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Henri Sivonen]

In article <MP************************@news.odyssey.net>,
Stan Brown <th************@fastmail.fm> wrote:

With Mozilla 1.4 on Win98, I get:
"This XML file does not appear to have any style information
associated with it. The document tree is shown below."

Is the page bad, or is it Mozilla?

The page is "bad" in the sense that serving arbitrary (as in "not using
elements a browser could reasonably be expected to recognize") XML as a
content negotiation alternative is non-sensical.

Whether advertising acceptance of generic XML content types makes sense
is debatable. Whether preferring the generic XML content types over
text/html makes sense is also debatable.

Over the years, only two sites where Mozilla's acceptance of the generic
XML content types is a problem have emerged. The W3C's site and some
Danish golf-related site.

--
Henri Sivonen
hs******@iki.fi
http://www.iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html