XHTML 1.1 compliance

Patrick:

http://validator.w3.org/check?uri=ht...t%2Findex.html It tells me:
Line 6, column 62: character data is not allowed here
...ame="description" content="Patrick Gebhardt Homepage" /> relevant html code:
[...]
6: <meta name="description" content="Patrick Gebhardt Homepage" />

That's not what's in your code. I find this instead:

<meta name="description" content="Patrick Gebhardt Homepage"></meta>>

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #2

Andreas Prilop

4p*@gmx.de (Patrick) wrote:

6: <meta name="description" content="Patrick Gebhardt Homepage" />

No, you have
<meta name="description" content="Patrick Gebhardt Homepage"></meta>>

--
Top-posting.
What's the most irritating thing on Usenet?

Jul 20 '05 #3

4p*@gmx.de (Patrick) wrote:

i'm trying to get my page to XHTML 1.1 compliance, i used the
validator from validator.w3.org but i still get one error message
which i cant explain. Would be nice if someone can take a look on it:

http://validator.w3.org/check?uri=ht...t%2Findex.html
Have you changed it? That page doesn't match the code below at all.
The page above dosn't validate because you're using a made-up doctype
- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"> the
correct doctype is <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
It tells me:
Line 6, column 62: character data is not allowed here
...ame="description" content="Patrick Gebhardt Homepage" />
^

Jul 20 '05 #4

Wired Earp

Steve Pugh wrote:

<meta></meta> will validate. I'll leave it to someone who understands
the logic (or lack thereof) of XHTML 1.1 to explain why.

You should give it a try. It is actually fairly simple.
--
Wired Earp
Wunderbyte

Jul 20 '05 #5

Wired Earp <wi*******@wunderbyte.com.invalid> wrote:

Steve Pugh wrote:
<meta></meta> will validate. I'll leave it to someone who understands
the logic (or lack thereof) of XHTML 1.1 to explain why.

You should give it a try. It is actually fairly simple.

What's fairly simple? The lack of logic behind XHTMl 1.1? It may be
simple, but it's also a waste of time as XHTML 1.1 is a dead end (not
supported by the browser with the lion's share of the market, not
backwards-compatible with HTML, not fowards-compatible with XHTML 2).

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 20 '05 #6

Steve Pugh:

Wired Earp <wi*******@wunderbyte.com.invalid> wrote:
Steve Pugh wrote:
<meta></meta> will validate. I'll leave it to someone who understands
the logic (or lack thereof) of XHTML 1.1 to explain why.
You should give it a try. It is actually fairly simple.

What's fairly simple? The lack of logic behind XHTMl 1.1?
I think what was meant, was the logic that says that "<element/>" and
"<element></element>" are equivalent.
It may be
simple, but it's also a waste of time as XHTML 1.1 is a dead end (not
supported by the browser with the lion's share of the market, not
backwards-compatible with HTML, not fowards-compatible with XHTML 2).

The browser with the lion's share has a shrinking share of the market.
Propably the next version of that browser will support XHTML 1.1. That
sounds to me not like a dead end, but like a standard that we can't
_yet_ use generally. I believe there was a time when HTML 4 was a bit
like that.

We do not yet know if XHTML 1.1 will be forwards-compatible with XHTML
2, since we don't yet know what XHTML 2 will look like. We don't even
know if there will ever be an XHTML 2.

I use XHTML 1.1 in my authoring. On the server I serve it to user agents
that claim they can handle XHTML. Others get the pages converted to HTML
4.01.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #7

Bertilo Wennergren <be******@gmx.net> wrote:

Steve Pugh:
Wired Earp <wi*******@wunderbyte.com.invalid> wrote:
Steve Pugh wrote: <meta></meta> will validate. I'll leave it to someone who understands
the logic (or lack thereof) of XHTML 1.1 to explain why.You should give it a try. It is actually fairly simple.

What's fairly simple? The lack of logic behind XHTMl 1.1?

I think what was meant, was the logic that says that "<element/>" and
"<element></element>" are equivalent.

And I know that they're equivalent. That's why I suggested replacing
one with the other in the first place.

But why does one validate in XHTML 1.1 and the other not? Does XHTML
1.1 not permit the shorter version? Or is this a flaw in the
validator? Or is there something else at work?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 20 '05 #8

Bertilo Wennergren <be******@gmx.net> wrote:

I think what was meant, was the logic that says that "<element/>"
and "<element></element>" are equivalent.
The logic here is simply the general XML rule for "Empty Element Tags",
saying, among other things,
"Empty-element tags MAY be used for any element which has no content,
whether or not it is declared using the keyword EMPTY. For
interoperability, the empty-element tag SHOULD be used, and SHOULD only
be used, for elements which are declared EMPTY."
http://www.w3.org/TR/2004/REC-xml-20...#sec-starttags

The logic behind that logic (or "logic") is that XML was designed to
allow tag soup to be used freely, with no structural declarations, and
for this, it was necessary to make end tags mandatory. And while this
would have been achieved easily, they probably thought that
<br></br> would not sell well (it looks almost as foolish as it is),
so they introduced the shorthand <br/>, then retrofitted it into a
munged version of SGML and asked everyone to be silent about the fact
that this introduced a conflict between HTML and XHTML and to propagate
the meme that adding a space would magically change this.
I use XHTML 1.1 in my authoring. On the server I serve it to user
agents that claim they can handle XHTML. Others get the pages
converted to HTML 4.01.

I tend to admire people who have principles and who live by them, but
doesn't that go too far? If you really do what you describe, then you
send XHTML to poor IE too, since it claims it can handle _everything_.
It lists some image and application types, then */* (which is fairly
pointless, since that covers those specific types too), and that's it.
If you dare to send it any HTML, or even plain text, then - judging by
what the browser claims - you can just as well send it XHTML.

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

Jul 20 '05 #9

Steve Pugh <st***@pugh.net> wrote:

I think what was meant, was the logic that says that "<element/>" and
"<element></element>" are equivalent.
And I know that they're equivalent.

Only in XML. Not in SGML-based HTML (which is more or less something
that lives in validators only).
That's why I suggested replacing
one with the other in the first place.
XHTML recommends <meta ... />, not <meta ...></meta>, and you suggested
the opposite change. This is a "should" statement. (It would not be
even possible to make it a formal requirement.)
But why does one validate in XHTML 1.1 and the other not?

Both <meta ... /> and <meta ...></meta> validate in XHTML and fail to
validate in SGML-based HTML.

The most common consequence of people's attempts to use XHTML is that
they use the XHTML syntax but declare an HTML 4.01 doctype. This will
generate error messages for almost any nontrivial document.

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

Jul 20 '05 #10

Steve Pugh:

Bertilo Wennergren <be******@gmx.net> wrote:
I think what was meant, was the logic that says that "<element/>" and
"<element></element>" are equivalent.

And I know that they're equivalent. That's why I suggested replacing
one with the other in the first place. But why does one validate in XHTML 1.1 and the other not? Does XHTML
1.1 not permit the shorter version? Or is this a flaw in the
validator? Or is there something else at work?

The code in question had "<meta ...></meta>>" or something similar. The
validation problem was with the extra ">".

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #11

Jukka K. Korpela:

Bertilo Wennergren <be******@gmx.net> wrote:
I use XHTML 1.1 in my authoring. On the server I serve it to user
agents that claim they can handle XHTML. Others get the pages
converted to HTML 4.01.

I tend to admire people who have principles and who live by them, but
doesn't that go too far? If you really do what you describe, then you
send XHTML to poor IE too, since it claims it can handle _everything_.
True. What I actually do, is serving XHTML to user agents that
explicitly claim support for "application/xhtml+xml". I don't count
support for "*/*".

(I also pay attention to the "q" values.)
It lists some image and application types, then */* (which is fairly
pointless, since that covers those specific types too), and that's it.
If you dare to send it any HTML, or even plain text, then - judging by
what the browser claims - you can just as well send it XHTML.

I silently ignore "*/*" - protecting MSIE from itself.

Actually I also protect Netscape 6 from itself, ignoring its explicit
claim to be able to accept "application/xhtml+xml". To do that I
actually sniff the user agent string. Horror! So if some user agent
tries to spoof Netscape 6, it will get HTML 4.01. I can live with that.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #12

Jukka K. Korpela:

XHTML recommends <meta ... />, not <meta ...></meta>, and you suggested
the opposite change. This is a "should" statement. (It would not be
even possible to make it a formal requirement.)

Well, we're talking XHTML 1.1 here, so the compatibility guidelines
don't apply at all. "<meta .../>", "<meta ... />" and "<meta ..></meta>"
are completely equal in XHTML 1.1, validationwise and otherwise.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #13

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

Steve Pugh <st***@pugh.net> wrote:
I think what was meant, was the logic that says that "<element/>" and
"<element></element>" are equivalent.
And I know that they're equivalent.

Only in XML. Not in SGML-based HTML (which is more or less something
that lives in validators only).

XHTML 1.1 is under discussion here. However the OP's page was being
served as text/html...

That's why I suggested replacing
one with the other in the first place.

XHTML recommends <meta ... />, not <meta ...></meta>, and you suggested
the opposite change. This is a "should" statement. (It would not be
even possible to make it a formal requirement.)

True but the recommended version did not validate. However the reason
for this was missed by everyone who replied to the thread, including
myself. See below.

But why does one validate in XHTML 1.1 and the other not?

Both <meta ... /> and <meta ...></meta> validate in XHTML and fail to
validate in SGML-based HTML.

But <meta /> did not validate in this particular XHTML 1.1 page (which
had a correct XHTML 1.1 doctype, but an incorrect content-type
header).
The most common consequence of people's attempts to use XHTML is that
they use the XHTML syntax but declare an HTML 4.01 doctype. This will
generate error messages for almost any nontrivial document.

Irrelevant. The doctype was correct for XHTML 1.1.

However I've now spotted what was wrong with the OP's code:
<?xml version="1.0" encoding="iso-8859-1"> - missing a '?' at the
end.

The combination of that, plus serving the page as text/html led to the
original error. (Served with a proper content type it gives a
different and slightly less obscure error.)

Now based on some previous experience I suggested changing <meta /> to
<meta></meta> as that had solved a problem I had then. I can't recall
what my old problem was and it's clearly not universal. I apologise
for misleading anyone.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 20 '05 #14

Alan J. Flavell

On Sun, 29 Feb 2004, Bertilo Wennergren wrote:

Well, we're talking XHTML 1.1 here,
If it's served as text/html, as someone said it was[1], then it cannot
be XHTML 1.1. I think the specification is clear about that, even if
it expresses it somewhat differently. Remember that according to
RFC2616 the server-provided content-type is authoritative - the client
agent is not permitted to unilaterally[2] guess something else.
so the compatibility guidelines don't apply at all.

Indeed. All bets would be off in that case.

[1] I can see that the page at the cited URL has been changed since
the discussion started.

[2] it may be permissible to call the user's attention to some
apparent discrepancy and offer a fixup, but that would be different.

Jul 20 '05 #15

Bertilo Wennergren <be******@gmx.net> wrote:

Steve Pugh:
Bertilo Wennergren <be******@gmx.net> wrote:

I think what was meant, was the logic that says that "<element/>" and
"<element></element>" are equivalent.

And I know that they're equivalent. That's why I suggested replacing
one with the other in the first place.

But why does one validate in XHTML 1.1 and the other not? Does XHTML
1.1 not permit the shorter version? Or is this a flaw in the
validator? Or is there something else at work?

The code in question had "<meta ...></meta>>" or something similar. The
validation problem was with the extra ">".

The code on the page itself changed so often that any attempt to study
it was pointless - it was never XHTML any of the times I looked at it.
Everything I wrote was based on the code given in the original post
itself:

1: <?xml version="1.0" encoding="iso-8859-1">
2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
3: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
4: <head>
5: <title>There's no place like 127.0.0.1</title>
6: <meta name="description" content="Patrick Gebhardt Homepage" />

The <meta /> is fine. The problem is the missing '?' in the xml
declaration.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 20 '05 #16

Steve Pugh:

Bertilo Wennergren <be******@gmx.net> wrote:
The code in question had "<meta ...></meta>>" or something similar. The
validation problem was with the extra ">".

The code on the page itself changed so often that any attempt to study
it was pointless
Indeed.
- it was never XHTML any of the times I looked at it.
It was XHTML with some errors, no? One of the errors being the wrong
media type.
Everything I wrote was based on the code given in the original post
itself:
[...]
The <meta /> is fine. The problem is the missing '?' in the xml
declaration.

This is interesting. How does the validator actually understand the rest
of the code because of that mistake? I guess the answer will involve
some deep SMGL voodoo...

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #17

Spartanicus

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

Well, we're talking XHTML 1.1 here,

If it's served as text/html, as someone said it was[1], then it cannot
be XHTML 1.1. I think the specification is clear about that, even if
it expresses it somewhat differently.

The spec specifies that XHTML 1.1 should (not must) not be served as
text/html. I've had this thrown back at me when I pointed it out to
people with "Valid XHTML 1.1" buttons on their site who were serving it
as text/html that it was valid to do so.

--
Spartanicus

Jul 20 '05 #18

Neal

On Sun, 29 Feb 2004 16:51:35 +0000, Spartanicus <me@privacy.net> wrote:

The spec specifies that XHTML 1.1 should (not must) not be served as
text/html.

I believe I remember seeing that, but I've torn through
http://www.w3.org/TR/xhtml11/ and cannot find any reference to serving as
text/html or anything else, for that matter. I assume I just missed it,
anyone know where this is?

Jul 20 '05 #19

Spartanicus:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
If it's served as text/html, as someone said it was[1], then it cannot
be XHTML 1.1. I think the specification is clear about that, even if
it expresses it somewhat differently.

The spec specifies that XHTML 1.1 should (not must) not be served as
text/html. I've had this thrown back at me when I pointed it out to
people with "Valid XHTML 1.1" buttons on their site who were serving it
as text/html that it was valid to do so.

What about sending it as "image/gif"? The specs doesn't even say "should
not" about that, so it must be even better, no?

XHTML 1.1 is not meant to be served as "text/html", so don't do it.

User agents that weren't programmed to understand XHTML 1.1, can't
really understand it (well), so don't serve it to them. Serve them
something they can handle better.

Those who can handle it, say they can handle "application/xhtml+xml", so
that's the media type to serve XHTML 1.1 with.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #20

Bertilo Wennergren <be******@gmx.net> wrote:

What about sending it as "image/gif"? The specs doesn't even say
"should not" about that, so it must be even better, no?

XHTML 1.1 is not meant to be served as "text/html", so don't do it.

But wouldn't text/plain be adequate? After all, despite all the efforts
to make markup pointlessly verbose, XHTML documents are still documents
with text content, with interspersed markup. And, in fact, the results
might be better than after browsers' attempts at displaying the
document by their rules.

Technically text/plain should really be _plain_ text, so what about
text/x-html? :-)

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

Jul 20 '05 #21

Jukka K. Korpela:

Bertilo Wennergren <be******@gmx.net> wrote:
What about sending it as "image/gif"? The specs doesn't even say
"should not" about that, so it must be even better, no? XHTML 1.1 is not meant to be served as "text/html", so don't do it.

But wouldn't text/plain be adequate?
"Adequate" is an interesting word... It would be better than
"image/gif", I'd guess, and probably better than "text/html", at least
in the long run.
After all, despite all the efforts
to make markup pointlessly verbose, XHTML documents are still documents
with text content, with interspersed markup. And, in fact, the results
might be better than after browsers' attempts at displaying the
document by their rules. Technically text/plain should really be _plain_ text, so what about
text/x-html? :-)

That would probably work about as "well" as "image/gif".

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #22

Alan J. Flavell

On Sun, 29 Feb 2004, Neal wrote:

I believe I remember seeing that, but I've torn through
http://www.w3.org/TR/xhtml11/ and cannot find any reference to serving as
text/html or anything else, for that matter.
Indeed, that spec defines what's inside XHTML, it doesn't say how it
should be wrapped up for HTTP or MIME.
I assume I just missed it, anyone know where this is?

Well, RFC2854 is the definition of text/html, as best as anyone has
actually "defined" it.

Published specification:
The text/html media type is now defined by W3C Recommendations;
the latest published version is [HTML401]. In addition, [XHTML1]
defines a profile of use of XHTML which is compatible with HTML
4.01 and which may also be labeled as text/html.

So, that definition seems to say that anything which claims to
be text/html is specified either by Appendix C of XHTML/1.0, or else
by one of the HTML TRs, i.e HTML4.01 or earlier. (I'm not sure where
that leaves ISO-HTML, to be honest!!!).

But it sure doesn't include XHTML/1.1 or later. That says to me that
if it's advertised as text/html it cannot, by definition, be XHTML/1.1
or later. Remember, by RFC2616 the server-provided content type is
authoritative (yes, I said that before).

There's a technical note at the W3C which gives a (non-normative)
overview of the situation,
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/

"This document summarizes the best current practice"

Where it says that

'text/html' SHOULD be limited to HTML-compatible XHTML 1.0 documents

there's two conditions involved: that the document should be
XHTML/1.0, and that the document should comply with that Appendix C.

As I read that, it could be interpreted to mean that it's not
completely ruled-out to use text/html for XHTML/1.0 even if it fails
to comply[1] with Appendix C; however, it does say also in conjunction
with this:

The use of 'text/html' for XHTML SHOULD be limited for the purpose of
rendering on existing HTML user agents

I'm not sure that it says anything at all about the (non)applicability
of text/html to XHTML/1.1, or anything else other than 1.0 - but
anyway, this note is non-normative, so surely the RFC takes
precedence, no?

Ah, angels on pinheads...

[1] I could give you one concrete example where it would make
sense to do so. But it's not the issue here.

Jul 20 '05 #23

Neal

On Sun, 29 Feb 2004 18:16:29 +0000, Alan J. Flavell <fl*****@ph.gla.ac.uk>
wrote:

On Sun, 29 Feb 2004, Neal wrote:
I assume I just missed it, anyone know where this is?

Well, RFC2854 is the definition of text/html, as best as anyone has
actually "defined" it.
...

Thank you, Alan. I think I understood some of that!

One further question, which is likely rather ignorant (which is why I am
asking) - what exactly is the harm caused by serving XHTML as text/html?
What are the things that can reasonably be expected to go wrong?

Jul 20 '05 #24

Neal:

One further question, which is likely rather ignorant (which is why I am
asking) - what exactly is the harm caused by serving XHTML as text/html?
What are the things that can reasonably be expected to go wrong?

Try this code in a browser that does not know anything more recent than
HTML 4.01:

================================================== =================
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="style.css" type="text/css"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>XHTML 1.1 test</title>
<meta name="Description" xml:lang="en" content="XHTMl 1.1 test"/>
</head>
<body>

<h1>XHTML 1.1 test</h1>

<p>Text...</p>

<hr/>

<p>Some more text.<br/>
Yet more text.</p>

<div><img src="image.png" alt="whatever"/></div>

<table>
<tbody>
<tr>
<td>cell</td><td>cell</td>
</tr>
<tr>
<td/><td>the cell next to this one is empty!</td>
</tr>
</tbody>
</table>

</body>
</html>
================================================== =================

There are lots of empty elements that will probably throw some browsers,
since I haven't put any helpful spaces before the "/>". The empty
"<td/>" will probably give the most trouble. An additional space won't
help there.

The encoding is only declared in the XML declaration. (I know, I really
should declare in the HTTP header too...)

The style sheet is declared in a process instruction. That's meaningless
to such browsers.

The document language, English, is declared in an "xml:lang" element.
That won't mean a thing to such browsers. Google likes to know the
language of your pages!

Of course you could avoid actually using any of that funny stuff. There
are valid alternatives for most of it - but not all ("xml:lang" e.g.).
But then, why not go for XHTMl 1.0, or even HTML 4.01?

And I haven't even used any ruby!

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #25

Alan J. Flavell

On Sun, 29 Feb 2004, Neal wrote:

On Sun, 29 Feb 2004 18:16:29 +0000, Alan J. Flavell <fl*****@ph.gla.ac.uk>
wrote:
On Sun, 29 Feb 2004, Neal wrote:
I assume I just missed it, anyone know where this is?
Well, RFC2854 is the definition of text/html, as best as anyone has
actually "defined" it.
...

Thank you, Alan. I think I understood some of that!

Well, I _did_ say "Angels on pinheads" - that ought to be some kind of
clue, no?
One further question, which is likely rather ignorant (which is why I am
asking) - what exactly is the harm caused by serving XHTML as text/html?
What are the things that can reasonably be expected to go wrong?

With respect, I'm not at all sure that you're asking a meaningful
question. Very roughly and broad-brush speaking, there are two kinds
of browser: HTML-tag-soup-slurpers, and XML-based agents. Some
browsers can do both, with a switch to decide which.

In a WWW context, what are you trying to achieve? If you want widest
coverage, then I personally would still recommend spec-conforming
HTML/4.01, which the HTML-tag-soup-slurpers are quite capable of
dealing with, modulo a few bugs.

The most popular browser-like object, after all, not only does not
support XHTML, but doesn't even conform to certain mandatory
requirements of the applicable non-XHTML specifications. But with
just a little care it can cope with standards-conforming markup, which
is also entirely accessible to competing browsers. So, in a WWW
context and with no particular yen to favour an implementation that
deliberately spits in the face of the applicable interworking
specifications, I'd put my first priority as conforming as closely as
possible to the specs, and as a close second, to avoid provoking any
known incompatibilities of that popular browser-like object.

Assuming of course that my aim was to get the message to the
readership, irrespective of their choice of platform and "browser".
If, on the other hand, I was aiming at a spectacular demonstration of
the capabilities of XHTML with SVG with Ruby with ... then I'd be
doing something different, and quite deliberately excluding the
majority of potential readers...

With the exception of some kind of technical demonstration, I can see
no particular reason to send them Appendix-C-conforming XHTML/1.0, on
the other hand.

If you want some of the enhanced functionality that later versions of
XHTML promise, then in a WWW context you'd almost certainly still want
some kind of fallback for the - majority - of browsers out there that
can't cope with your preferred offerings.

I'm not sure that really answers the question you asked, but, after
all, what's the sound of one hand clapping?

--

By the way, folks, AFAICS there's a major virus outbreak in progress,
and it's whizzing right past our commercial anti-virus defences, and
only getting caught locally by the measures that I hand-knitted over
the last 24 hours. Most victims won't be so lucky. If you get mails
with .zip attachments which, as encoded, are in the 30-40KB range,
even if they're apparently from known sender addresses (faked), for
heaven's sake don't open them. This has been some kind of public
service announcement.

Jul 20 '05 #26

Jan Roland Eriksson

On Sun, 29 Feb 2004 18:06:20 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

...XHTML documents are still documents with text content,
with interspersed markup...

Don't fall into that trap :-)

As originally thought of, a marked up document is...

"content embedded in markup"

....NOT...

"markup embedded in content"

http://www.css.nu/markup/markup-tagsoup.html#Markup

And to connect to the original question in this thread; as per the
web-SGML-TC, a validating parser would be within its full right to
flag an error for a markup sequence like...

<meta></meta> and only allow the <meta/> form

....if the 'meta' element has been defined as 'EMPTY' in the definition
subset.

The original reason to introduce the <gi/> notation was to allow for
XML parsers, that works without a definition subset, to distinguish
between elements that was deliberately used as EMPTY elements, as
compared to the <gi></gi> version which signals an element that can
have content but just happens have none.

During the definition phase of XML, M$ managed to bite the head of
that well thought out finesse and got it into specs that <gi/> and
<gi></gi> should be treated as the same thing. If that idea came as a
result of sheer dumbness or not is beyond my judgment today.

Suffice to say that M$ managed to take away a valuable detail from the
original definition of XML that was rather well thought out from the
beginning.

--
Rex

Jul 20 '05 #27

Jan Roland Eriksson

On Sun, 29 Feb 2004 12:44:45 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

[...]

...XML was designed to allow tag soup to be used freely, with no
structural declarations, and for this, it was necessary to make
end tags mandatory...
Umm, Yes.
...<br></br> would not sell well (it looks almost as foolish as
it is), so they introduced the shorthand <br/>, then retrofitted
it into a munged version of SGML...

Retrofitted? Munged SGML?

Not sure that I understand what you are referring to here?

The web-SGML-TC is from December 4 1997 and that is the place where
NESTC was introduced. From that point on the <gi/> notation was
allowed for elements defined 'EMPTY' and/or deliberately used as such.

See section 'K.4.2 Delimiters' here...

http://www.y12.doe.gov/sgml/wg8/document/1955.htm

--
Rex

Jul 20 '05 #28

Jan Roland Eriksson <jr****@newsguy.com> wrote:

...<br></br> would not sell well (it looks almost as foolish as
it is), so they introduced the shorthand <br/>, then retrofitted it
into a munged version of SGML...
Retrofitted? Munged SGML?

Yes. OK, OK, not chronologically by implementations and specifications,
but the general idea was to introduce an ad hoc tag type and change
SGML to allow it.
Not sure that I understand what you are referring to here?

The web-SGML-TC is from December 4 1997 and that is the place where
NESTC was introduced.

That's what I was referring to.

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

Jul 20 '05 #29

Jan Roland Eriksson <jr****@newsguy.com> wrote:

...XHTML documents are still documents with text content, with
interspersed markup...
Don't fall into that trap :-)

I already did. I appreciate your rescue efforts. :-)
As originally thought of, a marked up document is...

"content embedded in markup"

...NOT...

"markup embedded in content"
But the Mime type text "is intended for sending material which is
principally textual in form". It doesn't explicitly say what that type
really is, but it defines, in a sense, it by negation. The subtype
text/plain is defined so that it "does not provide for or allow
formatting commands, font attribute specifications, processing
instructions, interpretation directives, or content markup".
Logically, those are things that other subtypes of text may contain.

And if it's suitable to serve an XHTML document as text/xhtml or
text/xml, then it should be acceptable to serve it as text/x-html
(which programs should take as text/plain if they don't recognize the
subtype) or even as text/plain.
http://www.css.nu/markup/markup-tagsoup.html#Markup
That's illustrating, but it does not prove that it would be wrong to
treat (X)HTML (or SGML or XML) as text with interspered markup - which
is just a different way of looking at things. You can be very strict
about semantics, syntactic structures, and syntax details, or you can
play very loose with them, and you can use the purest structural markup
or completely layout-oriented control markup, no matter which way
(markup with embedded text vs. text with interspered markup) you look
at thinhs.
And to connect to the original question in this thread; as per the
web-SGML-TC, a validating parser would be within its full right to
flag an error for a markup sequence like...

<meta></meta> and only allow the <meta/> form

...if the 'meta' element has been defined as 'EMPTY' in the
definition subset.
I'm not sure I see why. But in any case, it's past winter's snow now.
This lovely hackery was added to make the world safe for XML-like
things, and in XML, <meta></meta> and <meta/> are equivalent except
that there's a statement against using the latter if the element is not
declared empty - but authors will keep missing this.
Suffice to say that M$ managed to take away a valuable detail from
the original definition of XML that was rather well thought out
from the beginning.

I have no reason to doubt such statements in general, but I don't quite
see what you are referring to here.

XML could live just fine without such a special rule. It's pointlessly
verbose anyway. And it would be a _good_ thing if people designing
markup systems would have to stop thinking whenever they are about to
introduce an empty element.

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

Jul 20 '05 #30