Migrating to XHTML: empty elements

[Mark]

(I'm new to these groups, so I'm not sure which one to use ...)

XHTML has been emabled in virtually all modern browsers. So is there any
more need for the space before the closing tags in empty elements?

The following seems to work for me in the browser's I've got:

<br/>

I no longer have IE 5, but do a significant enough number of users still
have the old browsers?

Mark

 

[Spartanicus]

Migrating to XHTML
Why?

XHTML has been emabled in virtually all modern browsers.

IE (all versions) and (afaik) KHTML browsers (Safari, Konquerer) don't
support XHTML. But perhaps you are referring to the hack whereby XHTML
code is incorrectly served as text/html thereby causing it to be treated
as tag soup by browsers?

Check out the common myths that surround XHTML and the problems that
arise from using it: http://www.spartanicus.utvinternet.ie/no-xhtml.htm

 

[dorayme]

Check out the common myths that surround XHTML and the problems that
arise from using it: http://www.spartanicus.utvinternet.ie/no-xhtml.htm

If I may come in on this... I am impressed with your case. I think I will
convert a recent site back to 4.01 strict from this xhtml which I thought at
the time I should do to "get modern" and prepare for the future and all that
.... It is humbling to read oneself into some of your remarks! Good, now I
can use all my preprogrammed keyboard commands again without making new ones
....

dorayme

 

[Mark]

Sorry Spartanicus. I didn't realise there were people left who were
trying to hold the web back.

Why?

Why not? XHTML has a number of benefits both now and in the future which
I would like to exploit, and HTML 4 no longer suits my needs.

IE (all versions) and (afaik) KHTML browsers (Safari, Konquerer) don't
support XHTML. But perhaps you are referring to the hack whereby XHTML
code is incorrectly served as text/html thereby causing it to be treated
as tag soup by browsers?

Sorry, tag soup is not a term I use a lot, so I'm not sure how to
interpret this comment.

I agree that the way pages are served as text/html rather
application/xhtml+xml is an issue non-Mozilla browsers. However, this
does stop you from attaching appropriate DOCTYPEs, and validating it as
such. It also doesn't stop them from interpreting XHTML tag formats,
which as I recall was the original question.

Check out the common myths that surround XHTML and the problems that
arise from using it: http://www.spartanicus.utvinternet.ie/no-xhtml.htm

I have. Than you. I see a few problems with the artical, though:

XHTML is stricter than HTML, especially if you have to resort to custom
DTDs to achieve the same. Certainly it less forgiving from an XML point
of view.

W3C, from my reading, regards XHTML as the next version from HTML 4, and
has based the development of future technologies on the XML base on
which XHTML rests. This includes MathML, SVG, and XForms, which, though
not currently widely supported, will certaily offer benefits to the Web.
I don't see how steering people away from XHTML is in any way going to
help in this regard.

Actually, I don't know how easy it is to generat HTML from XML. I use
XSLT, which balks on unclosed empty elements, but mayby you've found
something easier ...

You refer to lemmings jumping off a cliff. For your information,
lemmings don't jump of cliffs unless they are pushed by a Disney film
crew desperate for something to report on. So much for myth busting.

Look, all I wanted to know is whether sufficient modern browsers accept
XHTML compliant empty tags without a space before the closing slash.

But thanks for replying.

Mark

 

[Jukka K. Korpela]

(I'm new to these groups, so I'm not sure which one to use ...)

Then it's generally best to study the situation until you know the
_right_ group. The choice between comp.* and alt.* is yours of course;
usually selecting either is better than selecting both.

XHTML has been emabled in virtually all modern browsers.

I guess so, assuming that "emabled" means "screwed up" or something
like that. Try sending XHTML the right way to IE 6, and it will choke
up (well, just ask the user where to save the data).

So is
there any more need for the space before the closing tags in empty
elements?

Huh? An element has at most one closing tag.

The following seems to work for me in the browser's I've got:

<br/>

It works on IE only because IE knows neither "old" HTML nor XHTML.
It won't work by XHTML rules, whatever you do. It secretly slurps tag
soup in its old way, ignoring the slash because it does _not_ parse
"old" HTML correctly.

If you are confused, the ultimate reason is XHTML. Forget that you ever
heard of it; ignore it as marketese, academese, or nerdese. Later if
you'll find yourself in a situation where you need to and you can
combine HTML-like markup with XML markup, or utilize generic XML tools
for your HTML, _then_ it's time to learn XHTML.

Any XHTML specification or tutorial should really contain the note
"Kids, don't do this on the WWW (yet)".

 

[Jukka K. Korpela]

XHTML has a number of benefits both now and in the future
which I would like to exploit,

That's what people keep saying, but when someone asks for actual
evidence, there's just silence or long and empty explanations.

XHTML is stricter than HTML,

That's what people also keep saying. Seldom do they mention that XML is
less powerful than SGML, and consequently the XHTML DTDs must permit
quite a many things that HTML DTDs forbid. The XHTML 1.0 spec even says
this fairly explicitly in appendix B:
http://www.w3.org/TR/xhtml1/#prohibitions

 

[Spartanicus]

Sorry Spartanicus. I didn't realise there were people left who were
trying to hold the web back.

Expressions of sentiment are generally devoid of arguments, the above is
no exception.

Why not? XHTML has a number of benefits both now and in the future which
I would like to exploit

A statement devoid of an argument.

Sorry, tag soup is not a term I use a lot, so I'm not sure how to
interpret this comment.

The web lies at your fingertips filled with information, use it.

I agree that the way pages are served as text/html rather
application/xhtml+xml is an issue non-Mozilla browsers.

I can't parse that statement. It seems that you think that Mozilla is
the only application capable of handling application/xhtml+xml, this is
nonsense. And it suggests that there are no issues with serving Mozilla
application/xhtml+xml, again not correct.

However, this
does stop you from attaching appropriate DOCTYPEs, and validating it as
such.

Parsing error again, even if I fill in the assumed missing [not].

It also doesn't stop them from interpreting XHTML tag formats,
which as I recall was the original question.

Browsers don't "interpret" XHTML, they parse it as tag soup if you serve
it as text/html, and afaik in the case of KHTML browsers even if you
serve it as application/xhtml+xml.

I have. Than you. I see a few problems with the artical, though:

XHTML is stricter than HTML, especially if you have to resort to custom
DTDs to achieve the same.

That's one of the common myths bandied about, it's based on a flawed
understanding and/or goal, it's addressed and dispelled by the article.

Certainly it less forgiving from an XML point of view.

Irrelevant since you are serving it as text/html. The myth that well
formdness is has significance other than as a technical requirement that
stems from the way *proper* X(HT)ML is parsed is again dealt with and
dispelled by the article.

W3C, from my reading, regards XHTML as the next version from HTML 4, and
has based the development of future technologies on the XML base on
which XHTML rests.

XHTML 1.x is a reformulation of HTML 4 in XML. XHTML 2 is the intended
successor to XHTML 1.x. HTML 5 is the intended successor to HTML 4.x.
Neither are likely to be backward compatible with HTML4 (or it's
reformulation in XHTML).

This includes MathML, SVG, and XForms, which, though
not currently widely supported, will certaily offer benefits to the Web.

Mixed namespace documents are not an option when serving as text/html.

I don't see how steering people away from XHTML is in any way going to
help in this regard.

It helps because it reflects the reality that application/xhtml+xml is
not supported by clients that will be around for a long time, and
because serving application/xhtml+xml to Mozilla causes a nasty problem.

Actually, I don't know how easy it is to generat HTML from XML.

Search and yee shall find.

 

[Mark]

And the lemmings?