xhtml vs html 4 strict

Chuck wrote:

Is there any logical reason why one should convert if css is already being
used?

To XHTML 1.0? Only if you have a pressing need to use mixed namespaces (such
as XHTML + MathML).

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

in comp.infosystems.www.authoring.html, Chuck wrote:

Is there any logical reason why one should convert if css is already being
used?
Yes, conversion from xhtml to html4 makes sence often, especially if
xhtml is not appendix C cnforming. (it is afaik easier to convert it to
html4 than conforming xhtml)

Converion from html4 to xhtml makes no sence for you now, if you need to
ask. It may in future, but it should be trivial.
What possible, immediate, benefit would there be? I am at a loss to see
what, pragmatic, difference it would make.

Not much, unless you serve XHTML using correct mime type, then you
propably will have some problems.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera:
https://secure.bmtmicro.com/opera/bu...tml?AID=882173

On Sat, 21 May 2005 16:23:18 GMT, "Chuck"
<gi****@ddressout.you.must.be.joking> wrote:

Is there any logical reason why one should convert if css is already being
used?

XHTML is just HTML 4.01 in XML - no other differences.

There are situations for authoring / content management where having
your (*)HTML as XML is useful.

For serving up content, it makes no difference. It's impractical to
serve XHTML _as_ XML and if you stick with Appendix C etc., then XHTML
works just as well with the client browsers as HTML does.

So really it's your call. No strong general reasons either way. If you
have a specific reason for your project, then follow that.

Chuck wrote:

Is there any logical reason why one should convert if css is already being
used?

What possible, immediate, benefit would there be? I am at a loss to see
what, pragmatic, difference it would make.

I am in accord with the sentiments expressed, but I also remember
similar sentiments when CSS was introduced. It took some people a long
time to accept it and they are still playing catch up.

It seems to me that since HTML 5.0 (Web Applications 1.0), although only
in the Working Draft stage presently, will have a relationship with
XHTML. Although it would seem that there will be a division inasmuch as
documents may be authored in XHTML or HTML, it is also clear that the
intent is for a migration from HTML to XHTML. It therefore behooves one
to become familiar with XHTML today and not to be overwhelmed in a few
years from now.

--
Gus

"Gus Richter"

It therefore behooves one
to become familiar with XHTML today and not to be overwhelmed in a few
years from now.

I agree with you here, but the reason I asked the question is that I am
putting together the site for a new piece of software aimed at web
designers/developers and, whilst the site has been successfully validated as
HTML 4.01 strict + CSS, I was wondering whether it was worth converting it
to xhtml in order to capitalise on the xhtml "buzz". I am instinctively
loathe to do this as, without a practical reason to perform this exercise,
it feels like a cynical attempt to jump on a conveniently passing bandwagon.

Developing a personal, and corporate, knowledgebase in xhtml is, of course,
an ongoing and essential activity but I firmly believe in using technology
that fits the purpose not just because it is sparkly and gives off
pleasantly intoxicating technical pheremones.

Any thoughts?

Thanks

Gus Richter wrote:

I am in accord with the sentiments expressed [about XHTML], but I
also remember similar sentiments when CSS was introduced.

CSS brings real benefits. XHTML 1.0 Strict has a grand total of zero
benefits over HTML 4.01 Strict unless used in conjunction with specific
applications which require it.

On Sun, 22 May 2005 12:11:51 GMT, "Chuck"
<gi****@ddressout.you.must.be.joking> wrote:

putting together the site for a new piece of software aimed at web
designers/developers and, whilst the site has been successfully validated as
HTML 4.01 strict + CSS, I was wondering whether it was worth converting it
to xhtml in order to capitalise on the xhtml "buzz".

_What_ XHTML buzz ?

XHTML is by and large rejected by the clueful. Just look at the attitude
in this ng. Now I'm an advocate of it, but I seem to be very much in the
minority. Even then, I advocate it mainly for its benefits for internal
content management within a site, not for external publishing. It
becomes increasingly important for republishing onto mobile devices, but
that's still not a market significant enough to drive site design
techniques.

XML is popular. But there's still only a little crossover between the
XML and HTML authoring tasks, and even less between the XML and HTML
authoring communities. Even in these fairly advanced groups, there are
plenty who would rather stick with an old and obsolete technique than
embrace XML for site back-end tasks.

What would be worst of all would be the attitude taken by CIW, in their
more recent training materials. They see XHTML as "HTML 5" and push it
as the only version to author to, but they do this in a complete vacuum
of comparisons to either HTML 4 or XML. As such the tutorials are
confusing to students and the "XHTML in isolation" approach is downright
misleading.

"Andy Dingley"

_What_ XHTML buzz ?

I'm going to name no names but I have read quite a few "experts" extolling
xhtml as essential and stating that HTML 4.01 is merely a backwater. I don't
see it myself and feel that for general purpose work it's unneccesary (it's
not *that* difficult to convert, after all) but when there's an unhealthy
dose of FUD being bandied about, and when involved in projects such as the
one I am on at the moment, it never hurts to get a second opinion from
another doctor. I am, after all, trying to communicate with web-jockeys at a
level that inspires confidence in the application of this tool, both now and
in the future.

It is the ever-present disease, this latching on to the latest great thing.
There are many corporate dept. heads who are forever attaching innapropriate
acronyms and buzzwords to their specifications and briefs with no
understanding whatsoever of what they are actually asking for.

So, the buzz may sometimes be justified but it is also, frequently, merely
the sound of distressed flies searching for the next meal.

I was just checking that my radar was functioning correctly. Thanks.

On Sun, 22 May 2005 15:08:41 GMT, "Chuck"
<gi****@ddressout.you.must.be.joking> wrote:

_What_ XHTML buzz ?
I'm going to name no names

Oh, go on.... 8-)
but I have read quite a few "experts" extolling
xhtml as essential and stating that HTML 4.01 is merely a backwater.
This is very far from the case. HTML(broken) is an inevitable part of
the web for the forseeable future. So if you need to work "correctly"
with badly broken 3.2, it's clearly ridiculous to make any statement
that 4.01 is a backwater.
(it's not *that* difficult to convert, after all)

Now that starts to be a contentious statement.

There's a big difference between HTML 4.01 (typical) and valid HTML 4.01
Although conversion between valid forms is easy, the general case is no
easier than any other tag soup stirring exercise. There's a faint hope
that XML will somehow improve this, but it won't fix it, it might not
make any improvement, and it may even become worse. Look at the level of
XML well-formedness found in typical RSS feeds.
--
Cats have nine lives, which is why they rarely post to Usenet.

"Andy Dingley"

I'm going to name no names
Oh, go on.... 8-)

Uh-uh. That's just asking for trouble.

but I have read quite a few "experts" extolling
xhtml as essential and stating that HTML 4.01 is merely a backwater.
This is very far from the case. HTML(broken) is an inevitable part of
the web for the forseeable future. So if you need to work "correctly"
with badly broken 3.2, it's clearly ridiculous to make any statement
that 4.01 is a backwater.

I agree.

(it's not *that* difficult to convert, after all)
Now that starts to be a contentious statement.

:-) Indeed. The right mindset (and toolset) helps, I feel. Also a smattering
of natural pedantry, an obsessive nature and an arrogance that feeds a
stubborn refusal to submit in the face of insurmountable odds.
Look at the level of
XML well-formedness found in typical RSS feeds.

lol. Spaghetti code is spaghetti code, doesn't matter what flavour sauce you
pour over it.

In article <kl********************************@4ax.com>,
Andy Dingley <di*****@codesmiths.com> wrote:

_What_ XHTML buzz ?

You know "better living" and all that.

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

On Sun, 22 May 2005 23:13:24 +0300, Henri Sivonen <hs******@iki.fi>
wrote:

_What_ XHTML buzz ?

You know "better living" and all that.

I just like the retro feel of XML 8-)

Chuck wrote:

I'm going to name no names but I have read quite a few "experts" extolling
xhtml as essential and stating that HTML 4.01 is merely a backwater. I don't
see it myself and feel that for general purpose work it's unneccesary

As a supporter of W3C's goals and ideals, as I'm sure we all are, it is
incumbent on us to overcome our objections to change. We are informed
that the XHTML family is the next step in the evolution of the Internet
with XHTML 1.0 the first step toward a modular and extensible web, based
on XML providing the bridge for web designers to enter the web of the
future, that of the structured data/XML world, while still being able to
maintain compatibility with today's HTML 4 user agents.

XHTML 1.0 [Rec] provides conformance, backward and future compatibility.
XHTML 1.1 [Rec] proceeds to discontinue deprecated features and to
include Ruby support.
XHTML 2.0 [WD], on the immediate horizon, takes a major step forward
with new modules yet to be supported by browsers.
Web Application 1.0 [WD], on the far horizon (as HTML5.0/XHTML5.0 or
whatever they will end up calling it), updates HTML issues and addresses
Web Applications.

So we support W3C and yet say that we will disregard XHTML and continue
to use HTML 4.01 strict (hopefully, at least) since XHTML has no
improvement or benefit for us. What's wrong with this picture?

--
Gus

Gus Richter wrote:

Chuck wrote:

I'm going to name no names but I have read quite a few "experts"
extolling
xhtml as essential and stating that HTML 4.01 is merely a backwater. I
don't
see it myself and feel that for general purpose work it's unneccesary

As a supporter of W3C's goals and ideals, as I'm sure we all are, it is
incumbent on us to overcome our objections to change. We are informed
that the XHTML family is the next step in the evolution of the Internet
with XHTML 1.0 the first step toward a modular and extensible web, based
on XML providing the bridge for web designers to enter the web of the
future, that of the structured data/XML world, while still being able to
maintain compatibility with today's HTML 4 user agents.

XHTML 1.0 [Rec] provides conformance, backward and future compatibility.
XHTML 1.1 [Rec] proceeds to discontinue deprecated features and to
include Ruby support.
XHTML 2.0 [WD], on the immediate horizon, takes a major step forward
with new modules yet to be supported by browsers.
Web Application 1.0 [WD], on the far horizon (as HTML5.0/XHTML5.0 or
whatever they will end up calling it), updates HTML issues and addresses
Web Applications.

So we support W3C and yet say that we will disregard XHTML and continue
to use HTML 4.01 strict (hopefully, at least) since XHTML has no
improvement or benefit for us. What's wrong with this picture?

I'm certain that Microsoft Word 10 has features that weren't supported
three versions ago, but I don't think I use any of them, because none of
them are useful for the work I use Word to do. I figure that people who
have a use for those features will use them, but I'm not going to
contrive to use them solely for the sake of supporting Microsoft's sense
of purpose.

It's much too early to tell whether most of the customers whose sites I
work on will ever be concerned enough about whether their pages are part
of the worldwide semantic orgy to pay for implementation of every grand
capability about which W3C emits a recommendation.

In our last episode, <gt********************@golden.net>, the
lovely and talented Gus Richter broadcast on
comp.infosystems.www.authoring.html:

So we support W3C and yet say that we will disregard XHTML and continue
to use HTML 4.01 strict (hopefully, at least) since XHTML has no
improvement or benefit for us. What's wrong with this picture?

I don't see where the problem is here. Converting a valid HTML
document to a valid XHTML document is trivial. Tidy has never
failed to do it for me in the blink of an eye. The real divide
is between Transitional and Strict. As support for stylesheets
has got much better, in many cases Transitional really has lived
up to its name, and the transition is complete.
--
Lars Eighner ei*****@io.com http://www.larseighner.com/
"Shhh! Be vewwy, vewwy quiet! I'm hunting Muswims!"
- President Elmer Bush

On Mon, 23 May 2005 15:50:19 -0400, Gus Richter
<gu********@netscape.net> wrote:

As a supporter of W3C's goals and ideals, as I'm sure we all are,
don't count on that...

[...]
So we support W3C and yet say that we will disregard XHTML
and continue to use HTML 4.01 strict (hopefully, at least)
since XHTML has no improvement or benefit for us. What's wrong with this picture?

Legacy?

You might want to have a look at e.g. the www.siemens.com site.

Do you think that it would ever become possible to say that "our browser
will now only support correct markup and style sheets" and then expect
those who are depending on availability of siemens components to use it?

I'm not saying it's right, only trying to put some things in
perspective.

Siemens is a world wide multi billion operation, they may have invested
multi millions to make most of their product line fully available on
their chosen MS only platform.

The Siemens site is produced in "tag soup de jour" but Bill G. has had a
big ear open towards support of that crap.

Now, where is "David" to come in and win the game with his slingshot?

Quintessence; future browsers will never leave support of tag soup
and/or HTML4.01. They may support new stuff and all end up being "bloat
ware the jour" but as things looks for some considerable future,
HTML4.01 Strict and CSS1 (with a thoughtful addition of features from
CSS2.1) has the best chance to live as close to a "working" www as
possible for a long time to come.

My view is that W3C in it's present form is a loser, companies may find
it interesting to pump their 50 grand a year into it for the "glamouros
reflection on them to support standards" and maybe as some promised way
to provide a pension plan for the pope.

Other than that I think of it as a dead org with a relatively good web
site still available...

--
Rex

Jan Roland Eriksson wrote:

On Mon, 23 May 2005 15:50:19 -0400, Gus Richter
<gu********@netscape.net> wrote:

As a supporter of W3C's goals and ideals, as I'm sure we all are,

don't count on that...

So we support W3C and yet say that we will disregard XHTML
and continue to use HTML 4.01 strict (hopefully, at least)
since XHTML has no improvement or benefit for us.
What's wrong with this picture?

Legacy?

You might want to have a look at e.g. the www.siemens.com site.

Do you think that it would ever become possible to say that "our browser
will now only support correct markup and style sheets" and then expect
those who are depending on availability of siemens components to use it?

I'm not saying it's right, only trying to put some things in
perspective.

Siemens is a world wide multi billion operation, they may have invested
multi millions to make most of their product line fully available on
their chosen MS only platform.

The Siemens site is produced in "tag soup de jour" but Bill G. has had a
big ear open towards support of that crap.

Now, where is "David" to come in and win the game with his slingshot?

Quintessence; future browsers will never leave support of tag soup
and/or HTML4.01. They may support new stuff and all end up being "bloat
ware the jour" but as things looks for some considerable future,
HTML4.01 Strict and CSS1 (with a thoughtful addition of features from
CSS2.1) has the best chance to live as close to a "working" www as
possible for a long time to come.

My view is that W3C in it's present form is a loser, companies may find
it interesting to pump their 50 grand a year into it for the "glamouros
reflection on them to support standards" and maybe as some promised way
to provide a pension plan for the pope.

Other than that I think of it as a dead org with a relatively good web
site still available...

Actually, I was hoping for the detection of a little sarcasm in "as I'm
sure we all are".

I'm not familiar with the Siemens site, but I'm almost certain that the
directive given was to support ANY and ALL browsers on ANY and ALL OS
with ANY and ALL resolutions and screen size. If I were in that position
to decide, with such deep pockets, I would go the same route.
http://www.bigpicturesmallworld.com/...siem_dist.html
states that Siemens had 68,581 Million Euros sales world-wide for 1999.
If they forget about a 1% market share of visitors on the web, it could
amount close to 686 Million Euros in loss of sales. For the rest of us,
support for level 5 browsers is sufficient and anything more is overkill
IMHO and FWIW.

Support of tag soup is important for legacy sites, but that does not
justify new creations of the like. XHTML is "working" and backwards
compatible with level 5 browsers and I see no reason not to use it IMHO
and FWIW.

I'm certain that W3C members have their own agenda, with many (one comes
to mind immediately) speaking out of the side of their mouths, but there
are also some very fine people working to guide their output for the
good of the web. They cannot do otherwise thank goodness for Mozilla
Foundation and Opera. I do not share your pessimism, but believe that we
have come a good long way. So far, so good, and the road ahead looks
also bright, so far anyway.

--
Gus

Andy Dingley wrote:

XHTML is just HTML 4.01 in XML - no other differences.

It's worse than that. They are _almost_ the same, with no adequate
documentation of changes. The purported comparison at
http://www.w3.org/TR/xhtml1/#diffs
mentions things that aren't changes (in 4.1; the odd term
"well-formedness" is an XML novelty, but the requirements on nesting are
not), and it omits an unknown number of syntactic changes made silently
when rewriting the DTDs in XML.

For example, the optional id and xmlns attributes have been added to the
<html> tag. The type of the name attribute in <map> was changed from
CDATA to NMTOKEN.

Yucca

"Gus Richter" wrote in message...

It therefore behooves one to become familiar with XHTML
today and not to be overwhelmed in a few years from now.

Not a popular opinion on this forum, but a huge Amen from me.

Del

Gazing into my crystal ball I observed "Del Ferguson" <ra19608081
@charter.net> writing in news:Wz*******************@fe07.lga:

"Gus Richter" wrote in message...

It therefore behooves one to become familiar with XHTML
today and not to be overwhelmed in a few years from now.

Not a popular opinion on this forum, but a huge Amen from me.

Del

Agreed. XHTML Strict has helped me keep my documents very lean. No
presentatinal markup. I have always quoted attributes, and I like to write
in lowercase, and I like everything closed. As an author, I really like
it.

As far as serving the correct content type, for server side documents, I
look at the HTTP_ACCEPT header and respond accordingly.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Chuck wrote:

Is there any logical reason why one should convert if css is already
being used?

What possible, immediate, benefit would there be? I am at a loss to
see what, pragmatic, difference it would make.

It's an option if you want to force yourself or a team to be
case-sensitive and to always close tags.

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

"Philipp Lenssen" <in**@outer-court.com> wrote:

Is there any logical reason why one should convert if css is already
being used?

What possible, immediate, benefit would there be? I am at a loss to
see what, pragmatic, difference it would make.

It's an option if you want to force yourself or a team to be
case-sensitive and to always close tags.

XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive.

Using XHTML doesn't force anything on anyone. Validating against an
XHTML DTD will fail if elements and/or attribute names are not lower
case, and if elements are not closed. This is not particular to XHTML
DTDs.

For the OP, XHTML drawbacks and myths:
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

--
Spartanicus

Spartanicus wrote:

For the OP, XHTML drawbacks and myths:
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Connection refused. :(

Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:

For the OP, XHTML drawbacks and myths:
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Connection refused. :(

Temporary copy:
http://homepage.ntlworld.com/spartanicus/no-xhtml.htm

--
Spartanicus

Spartanicus wrote:

Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:

For the OP, XHTML drawbacks and myths:
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Connection refused. :(

Temporary copy:
http://homepage.ntlworld.com/spartanicus/no-xhtml.htm

Works fine. Thanks!

Minor quibble: You say "Lot's of Lemmings are jumping off
cliffs." No they aren't. Look here:

http://www.wildlifenews.alaska.gov/i...=56&issue_id=6

What do you think of developing the page as XHTML and then
changing it to HTML just before uploading to the web server?

On Tue, 31 May 2005 21:50:30 +0000, Guy Macon
<_see.web.page_@_www.guymacon.com_> wrote:

Spartanicus wrote:

Temporary copy:
http://homepage.ntlworld.com/spartanicus/no-xhtml.htm

Works fine. Thanks! What do you think of developing the page as XHTML and then
changing it to HTML just before uploading to the web server?

Total waste of energy.

Use HTML markup directly and learn to use available checkup tools, even
available on line if you can not find a way to install local versions.

Maybe this would give you an idea on how to proceed.

http://www.css.nu/markup/markup-entities.html

--
Rex
(who wonders why SGMLNORM seems to totally forgotten
as a HTML strict doc instance checkup tool)

Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:

http://homepage.ntlworld.com/spartanicus/no-xhtml.htm

What do you think of developing the page as XHTML and then
changing it to HTML just before uploading to the web server?

From the page: "If your authoring process benefits from using XML then
by all means use it. It does not form an argument for serving XHTML to
clients."

--
Spartanicus

Spartanicus wrote:

"Philipp Lenssen" <in**@outer-court.com> wrote:

It's an option if you want to force yourself or a team to be
case-sensitive and to always close tags.
XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive.

XHTML is case-sensitive for elements. HTML4 is not. How is that not
being case-sensitive?

Using XHTML doesn't force anything on anyone. Validating against an
XHTML DTD will fail if elements and/or attribute names are not lower
case, and if elements are not closed. This is not particular to XHTML
DTDs.

But in HTML4, you may leave certain elements open. This is particular
to XHTML/XML then. In SGML you may or may not decide in the doctype if
it ought to be optional, and so in XHTML you must always force the
closing.

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

"Philipp Lenssen" <in**@outer-court.com> wrote:

[XHTML]

> It's an option if you want to force yourself or a team to be
> case-sensitive and to always close tags.

XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive.

XHTML is case-sensitive for elements. HTML4 is not. How is that not
being case-sensitive?

Because upper case is invalid in XHTML element and attribute names.
In Javascript function names are case sensitive, Foobar!=fooBar, but
both are valid.

Using XHTML doesn't force anything on anyone. Validating against an
XHTML DTD will fail if elements and/or attribute names are not lower
case, and if elements are not closed. This is not particular to XHTML
DTDs.

But in HTML4, you may leave certain elements open. This is particular
to XHTML/XML then.

Only for empty elements, which unlike closing non empty elements has no
relevance for a parser. In fact a conforming HTML parser would choke on
XHTML.

--
Spartanicus

Spartanicus wrote:

"Philipp Lenssen" <in**@outer-court.com> wrote:

[XHTML]

It's an option if you want to force yourself or a team to be
case-sensitive and to always close tags.

XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive.
XHTML is case-sensitive for elements. HTML4 is not. How is that not
being case-sensitive?

Because upper case is invalid in XHTML element and attribute names.
In Javascript function names are case sensitive, Foobar!=fooBar, but
both are valid.

Your opinion that XHTML is case-insensitive is in direct opposition to
the view of the W3C. Read section 4.2 of the XHTML 1.0 specification:

"XHTML documents must use lower case for all HTML element and
attribute names. This difference is necessary because XML is
case-sensitive..."

<URL:http://www.w3.org/TR/xhtml1/>

Using XHTML doesn't force anything on anyone. Validating against an
XHTML DTD will fail if elements and/or attribute names are not lower
case, and if elements are not closed. This is not particular to XHTML
DTDs.

But in HTML4, you may leave certain elements open. This is particular
to XHTML/XML then.

Only for empty elements, which unlike closing non empty elements has no
relevance for a parser. In fact a conforming HTML parser would choke on
XHTML.

Of course non-empty elements with optional closing tags, such as <P>,
are conveniently ignored. They are perfectly valid in HTML 4.01, but
not XHTML, which is the point Philipp was making.
--
Rob

On 01 Jun 2005 15:27:58 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

XHTML is case-sensitive for elements. HTML4 is not. How is that not
being case-sensitive?

It is not a question of being "case sensitive" that kind of wording does
not even exist in the "Handbook".

The true thing is all about "case folding" where a true validating piece
of software looks into the SGML declaration for the doc instance in
process to find out about which characters needs to be "folded" into
some other characters.

In the traditional "SGML Concrete Syntax" that has always been taken to
mean e.g. 'a' folds to 'A' but SGML does not stipulate requirements for
that. You are allowed to fold anything into anything.

In the alternative "XML" version of an SGML syntax, designers went out
of the way to create a markup model that would allow just about any
"dummy" to have his/her say and still stay at least conforming to some
simplistic way of looking at markup in principle.

We are going downhill from there...

--
Rex

RobG <rg***@iinet.net.auau> wrote:

XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive.
Your opinion that XHTML is case-insensitive is in direct opposition to
the view of the W3C.
I never said that XHTML is case-insensitive.
Read section 4.2 of the XHTML 1.0 specification:

"XHTML documents must use lower case for all HTML element and
attribute names. This difference is necessary because XML is
case-sensitive..."

Note that it says "XML", not "XHTML". XML is indeed case sensitive.

But in HTML4, you may leave certain elements open. This is particular
to XHTML/XML then.

Only for empty elements, which unlike closing non empty elements has no
relevance for a parser. In fact a conforming HTML parser would choke on
XHTML.

Of course non-empty elements with optional closing tags, such as <P>,
are conveniently ignored.

They're not.

--
Spartanicus

Spartanicus wrote:

RobG <rg***@iinet.net.auau> wrote:

>XHTML documents must use lower case for all HTML element and attribute
>names. That's not the same as being case sensitive.
Your opinion that XHTML is case-insensitive is in direct opposition to
the view of the W3C.

I never said that XHTML is case-insensitive.

You questioned the statement that XHTML was case-sensitive, but also
reckon it's not case-insensitive. Is there some state in between that
is neither?

Read section 4.2 of the XHTML 1.0 specification:

"XHTML documents must use lower case for all HTML element and
attribute names. This difference is necessary because XML is
case-sensitive..."

Note that it says "XML", not "XHTML". XML is indeed case sensitive.

And, since XHTML is HTML as XML, XHTML is case-sensitive.

The fact that the authors of the XHTML specification chose to define
all their tags and attributes solely in lower case does not remove
case-sensitivity.

But in HTML4, you may leave certain elements open. This is particular
to XHTML/XML then.

Only for empty elements, which unlike closing non empty elements has no
relevance for a parser. In fact a conforming HTML parser would choke on
XHTML.

Of course non-empty elements with optional closing tags, such as <P>,
are conveniently ignored.

They're not.

They - optional closing tags - are being ignored by you. You introduced
empty tags, the treatment of which is also different in XHTML and HTML.

The OP's point was that, other differences aside, what passes as valid
HTML may well not pass as valid XHTML due XHTML's case sensitivity and
requirement for closing tags even where they are optional in HTML.

I've yet to see a convincing argument to the contrary.

--
Rob

RobG wrote:

Spartanicus told me:

Your opinion that XHTML is case-insensitive is in direct

opposition to the view of the W3C.

The fact that the authors of the XHTML specification chose to define
all their tags and attributes solely in lower case does not remove
case-sensitivity.

Exactly. Saying "all elements are lower-case, but XHTML is not
case-sensitive" would make "lower-case" a mere suggestion in XHTML;
valid XHTML elements could therefore then also be upper-case. And this
is obviously not the case. Spartanicus surely will now begin to
understand something can be *both* case-sensitive *and* lower-case (or
camel-case, or upper-case).

The OP's point was that, other differences aside, what passes as valid
HTML may well not pass as valid XHTML due XHTML's case sensitivity and
requirement for closing tags even where they are optional in HTML.

I've yet to see a convincing argument to the contrary.

Me too. I just don't see how the valid HTML4

<p>.......

would somehow force you to close the paragraph (as does valid XHTML
force you).
Again, here's some valid HTML4 with mixed case, and non-closed tags:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html><head>
<title>Title</title>
<meta http-equiv="Content-Type" content="text/html;
CHARSET=iso-8859-1">
</head>
<body>

<p>Test
<P>Test

</body>
</html>
And the same is invalid in XHTML1 in both instances, case and missing
closing tag (I could write a parser for this *without* knowing about
the DTD -- I couldn't do this in HTML4, as I'd need the DTD to tell me
which closing tags are optional and which aren't)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Title</title>
</head>
<body>

<p>Test
<P>Test

</body>
</html>
Does that mean XHTML is superior to HTML4? No! It may just be a team
preference for the reasons stated (forced case and closing tags). There
are also arguments against XHTML which may make other feel HTML is
superior (like the misleading non-XML content-type necessary for
browsers like IExplorer).

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

RobG <rg***@iinet.net.auau> wrote:

>>XHTML documents must use lower case for all HTML element and attribute
>>names. That's not the same as being case sensitive.
>
Your opinion that XHTML is case-insensitive is in direct opposition to
the view of the W3C.
I never said that XHTML is case-insensitive.

You questioned the statement that XHTML was case-sensitive

I didn't "question", I corrected an incorrect statement.
, but also
reckon it's not case-insensitive. Is there some state in between that
is neither?
Yes, read again what I wrote (which was a direct quote from the spec) if
you want to have another go at understanding what that is.

Read section 4.2 of the XHTML 1.0 specification:

"XHTML documents must use lower case for all HTML element and
attribute names. This difference is necessary because XML is
case-sensitive..."

Note that it says "XML", not "XHTML". XML is indeed case sensitive.

And, since XHTML is HTML as XML, XHTML is case-sensitive.

XHTML is a reformulation of HTML in XML, thus valid XHTML is
automatically also valid XML, the reverse however is emphatically not
the case.

In the case sensitive XML "<Span>foobar</Span>" is valid, in XHTML it is
always invalid.
The fact that the authors of the XHTML specification chose to define
all their tags and attributes solely in lower case does not remove
case-sensitivity.

You are missing the point in thinking that there are only 2 states.

>But in HTML4, you may leave certain elements open. This is particular
>to XHTML/XML then.

Only for empty elements, which unlike closing non empty elements has no
relevance for a parser. In fact a conforming HTML parser would choke on
XHTML.

Of course non-empty elements with optional closing tags, such as <P>,
are conveniently ignored.

They're not.

They - optional closing tags - are being ignored by you.

Philipp stated that "in HTML4, you may leave certain elements open."
"This" [required closing of elements] "is particular to XHTML/XML then."
It is not. Using a custom HTML DTD a validator can also produce
validation errors for non closed non empty elements. See the "Example
custom DTD" at the end of
http://www.spartanicus.utvinternet.ie/custom_dtd.htm

--
Spartanicus

"Philipp Lenssen" <in**@outer-court.com> wrote:

Saying "all elements are lower-case, but XHTML is not
case-sensitive"

But no-one is saying that.

--
Spartanicus

Spartanicus <in*****@invalid.invalid> wrote:

Yes, read again what I wrote (which was a direct quote from the
spec) if you want to have another go at understanding what that is.
It's hard to tell what you are really arguing about. You have written,
among other things:
"XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive."
It's surely not the same, but _more_. Surely any requirement to use
lower case implicitly _includes_ case sensitivity; without case
sensitivity, there can be no requirement on case.
XHTML is a reformulation of HTML in XML, thus valid XHTML is
automatically also valid XML, the reverse however is emphatically
not the case.
Why the emphasis? Sounds like an emphatic strawman.
In the case sensitive XML "<Span>foobar</Span>" is valid,
Oh no, that depends on the DTD. There need not be a DTD. If there is,
it may or may not contain an element named "Span", and its content
model may or may not allow character data.
in XHTML it is always invalid.
It is invalid in XHTML as currently defined, of course, because there
is no element named "Span".

The fact that the authors of the XHTML specification chose to
define all their tags and attributes solely in lower case does
not remove case-sensitivity.

You are missing the point in thinking that there are only 2 states.

Case-sensitive and case-insensitive _do_ form a dichotomic division.
Anything that is not completely case-insensitive is by definition case
sensitive.
Philipp stated that "in HTML4, you may leave certain elements
open." "This" [required closing of elements] "is particular to
XHTML/XML then." It is not.
It was a poor formulation. That's usual when discussing SGML or XML
syntax. Of course closing of elements is always required. Whether an
explicit closing _tag_ is required is a different issue.

You seem to be saying that SGML allows declarations that make closing
tags mandatory. That's certainly true; most element declarations in
HTML DTDs do that.
Using a custom HTML DTD a validator can
also produce validation errors for non closed non empty elements.

It isn't an HTML DTD if it isn't one of the DTDs mentioned in HTML
specifications. It might be an SGML DTD.

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

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

Yes, read again what I wrote (which was a direct quote from the
spec) if you want to have another go at understanding what that is.

It's hard to tell what you are really arguing about. You have written,
among other things:
"XHTML documents must use lower case for all HTML element and attribute
names. That's not the same as being case sensitive."
It's surely not the same, but _more_.

A requirement to use lower case for element and attribute names is not
an additional syntactical requirement to case sensitivity, it is a
different syntactical requirement.

Declaring XHTML "case sensitive" as Philipp did does not cover the
syntactical requirement regarding element and attribute case, "XHTML
documents must use lower case for all HTML element and attribute names."
does cover the syntactical requirement.

In the case sensitive XML "<Span>foobar</Span>" is valid,

Oh no, that depends on the DTD. There need not be a DTD. If there is,
it may or may not contain an element named "Span", and its content
model may or may not allow character data.

in XHTML it is always invalid.

It is invalid in XHTML as currently defined, of course, because there
is no element named "Span".

A "Span" element cannot be added to a XHTML DTD without altering the
syntactical requirement regarding element case in the XHTML spec's
prose. Adding the qualifier "as currently defined" is pointless since
any sensible discussion can only cover the present.

Using a custom HTML DTD a validator can
also produce validation errors for non closed non empty elements.

It isn't an HTML DTD if it isn't one of the DTDs mentioned in HTML
specifications. It might be an SGML DTD.

Distinction noted, but it doesn't make a difference to the incorrect
statement Philipp made.

--
Spartanicus

Jukka K. Korpela wrote:

Spartanicus <in*****@invalid.invalid> wrote:

In the case sensitive XML "<Span>foobar</Span>" is valid,

Oh no, that depends on the DTD. There need not be a DTD. If there is,
it may or may not contain an element named "Span", and its content
model may or may not allow character data.

Simple answer. If <Span>, <SPAN>, <span> and <sPaN> are all
treated as the same thing in all respects, it is case-insensitive.
If they are treated differently under any conditions, it is case-
sensitive.

On Thu, 2 Jun 2005 10:54:45 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

Spartanicus <in*****@invalid.invalid> wrote:

Yes, read again what I wrote (which was a direct quote from the
spec) if you want to have another go at understanding what that is.

It's hard to tell what you are really arguing about...

And for the real thing it's hard to discover what the heck any one in
this thread is arguing about.

You Jukka, for one, should know from your own long time experience that
there is no such thing as "case sensitive" defined anywhere within given
rules for how to build a markup language.

SGML gives the right and means to fold any individual character into any
other individual character, and that right is fully trickled down into
the SGML declaration for XML.

"Case (in)sensitivty" is an idiotic term.

"Case Folding" is the correct term.

But maybe it should have been named "character re mapping" in order to
express exactly what it is all about.

--
Rex

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

And for the real thing it's hard to discover what the heck any one
in this thread is arguing about.
It's nice that we can agree on _something_. :-)
You Jukka, for one, should know from your own long time experience
that there is no such thing as "case sensitive" defined anywhere
within given rules for how to build a markup language.
There is; the name and implementation for it may vary.

Of course, I'm not going to cite the HTML specifications for use of
phrases like "case sensitive". We know that the terminology of the
specifications is vague and wouldn't do in a standard.
SGML gives the right and means to fold any individual character
into any other individual character,
Case folding is one way to implement case insensitivity, and in many
ways an efficient way. It is more efficient to canonicalize letters to,
say, upper case when storing names into a symbol table and then just do
simple string comparisons than to store them as received and perform
any string comparisons in a case insensitive manner. But that's
implementation. Besides, such an implementation causes problems in
error diagnostics. Once you have canonicalized the case of letters, you
cannot report certain types of errors in an informative manner. You
cannot tell that case is the problem when you've lost the case. :-)
and that right is fully
trickled down into the SGML declaration for XML.
There is no SGML declaration for XML, because XML is formally defined
by a standalone specification, which makes no normative reference to
the SGML standard. All those prose about XML as a "subset" or "profile"
of SGML is misleading.
"Case (in)sensitivty" is an idiotic term.
No, just misspelled. :-)
"Case Folding" is the correct term.

Well, "case folding" is a suitable term for an operation or principle
of canonicalizing case. But surely we can define case insensitivity
quite independently of such terms. Case insensitivity means that case
is ignored when comparing strings for equality. For example, that "Foo"
and "foo" are treated as equal. Whether you achieve it by folding both
to "FOO", or by folding both to "foo", or by some other means, is
really something that a markup language definition shouldn't even
mention, unless it needs _for some other reason_ a concept of
canonicalized format for a name (and even then, that format could be
defined separately).

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

On Fri, 3 Jun 2005 04:09:43 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

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

trickled down into the SGML declaration for XML.

There is no SGML declaration for XML,
I beg to differ.

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

because XML is formally defined by a standalone
specification, which makes no normative reference to
the SGML standard.
The work on what was to become 'XML' started long before W3C was ever
thought of. Names like Goldfarb and Naggum comes to mind as original
idea generators/definition writers in very early 1990'ies.
All those prose about XML as a "subset" or "profile"
of SGML is misleading.

There's a lot of prose in that spec that is misleading, but just this
back ref to SGML is not since it has a true SGML based ref available
for it.

Without the 'Web SGML TC', and the work behind it, there would be no
XML in the first place.

--
Rex

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

"Case Folding" is the correct term.

But maybe it should have been named "character re mapping" in
order to express exactly what it is all about.

The SGML Handbook talks about case substitution. I think that's clearer
than case folding, since case folding makes it less obvious that any
character can be substituted.
But yea, character re mapping might be even clearer.

--
David Håsäther

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

There is no SGML declaration for XML,
I beg to differ.

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

It describes XML as if it were SGML, but in fact XML has been defined
independently of SGML - for rather obvious reasons.

It says: "XML documents implicitly contain the following SGML
declaration." That's hypothetical language, describing how XML _could
have been defined_ on SGML basis. (And this has some practical value of
course in software design.)
Without the 'Web SGML TC', and the work behind it, there would be no
XML in the first place.

I don't think so. The marked demand for a trivialization of XML was too
big.

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

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

There is no SGML declaration for XML,
I beg to differ.

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

It describes XML as if it were SGML, but in fact XML has been defined
independently of SGML - for rather obvious reasons.

It says: "XML documents implicitly contain the following SGML
declaration." That's hypothetical language, describing how XML _could
have been defined_ on SGML basis. (And this has some practical value
of course in software design.)
Without the 'Web SGML TC', and the work behind it, there would be
no XML in the first place.

I don't think so. The marked demand for a trivialization of SGML was
too big.

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

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

http://www.y12.doe.gov/sgml/wg8/document/1955.htm
It describes XML as if it were SGML, but in fact XML has been
defined independently of SGML

I don't think so. XML is just a restricted form (a subset or profile)
of SGML. The SGML declaration is fixed, and many features that are
seldom used in SGML can't be used at all in XML
(http://www.w3.org/TR/NOTE-sgml-xml.html lists all differences AFAIK).
I don't think this is anything "SGML people" disagrees on, as with the
case of "HTML as an SGML application".
This is my understanding at least.
for rather obvious reasons.

What would those obvius reasons be?

--
David Håsäther

On Thu, 02 Jun 2005 03:18:27 +0200, Jan Roland Eriksson
<jr****@newsguy.com> wrote:

We are going downhill from there...

But XML (by volume, out in the real world) isn't replacing elegant SGML,
it's replacing nasty unreliable CSV.

I've never used SGML. I once had an obvious "SGML project" (1997) and
went shopping for SGML vendors to sell me tools to make it all work.
Even with a blue chip budget behind me, I couldn't find a viable SGML
solution that was affordable, completable in a reasonable time, and
comprehensible.. Did it with PDFs and string in the end. These days I'd
throw XML at the problem and have it done in a week.

There never _was_ an SGML "golden age". Maybe SGML always was "right",
but it wasn't useful (outside Boeing).