Once again: effects in Migration HTML 4.01 -> XHTML 1.0

[Werner Partner]

I put this question already, but erhaps it "came under the wheels"
because it was hidden in another thread. Nevertheless it's important for
me to understand the problem and solve it.

Old html 4.01 Standard:
http://www.sonoptikon.de/kairos/kontakt.php

The crucial lines are:
-------------------
<table cellpadding=4 cellspacing=1 width="100%">
<tr>

<td bgcolor="#eeeeee" class="doc">
<img src="pics/kairos.jpg" alt=""></td>
<td bgcolor="#eeeeee" class="doc" valign="middle" width="100%">
<h1>kairos: Bildung - Gesundheit - Leben</h1>
</td>
</tr>
<tr><td bgcolor="#eeeeee" class="doc" valign="top" align="center">
-------------------

New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html

The crucial lines are:
-------------------
<table class="frame">
<tr>

<!-- linke obere Ecke -->
<td class="icon"><img src="pics/kairos.jpg" alt=""></img></td>
<!-- Banner -->
<td class="banner">
<h1>kairos: Bildung - Gesundheit - Leben</h1>

</td>
</tr>

<!-- linker Streifen -->
<tr>
<td class="lframe">
-------------------

with css lines:
-------------------
..frame { width:100%; border-spacing:1px; }
/* <table cellpadding=4 cellspacing=1 width=\"100%\"> */

..icon { background-color:#EEEEEE; vertical-align:middle; padding:4px;
width:1%; }

..banner { background-color:#EEEEEE; vertical-align:middle; padding:4px; }

..lframe { background-color:#EEEEEE; vertical-align:top;
text-align:center; padding:0 }
-------------------

You see that the little picture left above is "jumping", the grey frame
under the picture is thicker in xhtml-Version, and the Banner ist higner.

The central question seems to me how build "cellpadding" and
"cellspacing" in css.

Of course the difference is minimal and maybe someone may say that it's
"Korinthenkackerei", but I am interested to make "correct" code and to
solve the problem.

Thanks

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Eric B. Bednarz]

Werner Partner <ka****@sonoptikon.de> writes:

I put this question already, but erhaps it "came under the wheels"
Then there was probably a reason for that. :)
New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html
It's text/html. The formal public and the system identifier in the
doctype declaration mismatch (naturally, that returns 'standards
compliance mode'). Please, stop doing what you are doing and revert to
good old fashioned tag salad.
The central question seems to me how build "cellpadding" and
"cellspacing" in css.

The central answer is
<http://www.w3.org/TR/CSS2/box.html#padding-properties>
<http://www.w3.org/TR/CSS2/tables.html#separated-borders>

The decentralised answer is that cellpadding and cellspacing are
better supported by your target audience (tagsoup slurpers) and valid
attributes in XHTML1.0(strict).
--
| ) 111010111011 | http://bednarz.nl/
-(
| ) Distribute me: http://binaries.bednarz.nl/mp3/aisha

[Werner Partner]

Eric B. Bednarz schrieb:

compliance mode'). Please, stop doing what you are doing and revert to
good old fashioned tag salad.

???:
http://validator.w3.org/check?uri=ww...e%2Findex.html

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Werner Partner]

Eric B. Bednarz schrieb:

Werner Partner <ka****@sonoptikon.de> writes:

I put this question already, but erhaps it "came under the wheels"

Then there was probably a reason for that. :)

New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html

Maybe you understood me wrong.
My simple and humble question is:

Why is the padding-bottom in the element left above about twice as broad
as the other paddings. What can be wrong?

I tried now:
..icon { background-color:#EEEEEE; vertical-align:middle;
padding-top:4px; padding-left:4px; padding-right:4px;}

Now I have that what I wanted: padding all around 4 px

Werner
--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Jukka K. Korpela]

Scripsit Werner Partner <ka****@sonoptikon.de>:

Eric B. Bednarz schrieb:

compliance mode'). Please, stop doing what you are doing and revert
to good old fashioned tag salad.

???:
http://validator.w3.org/check?uri=ww...e%2Findex.html

Eric mentioned a mismatch in the doctype declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
It is definitely incorrect. The reason why a validator does not report an
error is that it simply uses the first quoted string (the formal public
identifier) to fetch the DTD from its internal reperoire, instead of
using the second string (system identifier, or a URL in practice) at all.

But the doctype declaration _is_ contradictory. The document proper,
i.e. the <html> element, may comply with both Strict and Transitional (in
fact, compliance to Strict implies compliance to Transitional), but the
doctype declaration must uniquely define the DTD. Besides, the XHML 1.0
specification lists a limited number of allowed doctype declarations.

However the main point Eric is probably trying to make is that on the Web
of this day, and tomorrow too, old HTML 4 works better than any XHTML.

XHTML doesn't create big problems as a rule - this is what helps the
survival of the meme - but it creates various nasty little problems and
gives nothing in return. That's as far as practical HTML authoring on the
WWW is considered; specialized applications and projects that prepare for
the future to come might make XHTML feasible - but there's really no
reason not to follow guidelines like using <meta ... /> and not
<meta ...></meta>. In fact, the XML specification says:

"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/REC-xml/#sec-starttags

An element that is declared EMPTY has the keyword EMPTY in its definition
in the formal syntax (DTD), and this means that the element _cannot_
contain anything. The <meta> element belongs to this category (since it
has historically been defined in an odd way that puts all data into
attributes.) This is to be distinguished from "casually empty" content,
such as in <td></td>, where the element _could_ have content of various
kind but here happens to be empty.

Thus, although
<br></br>
and
<br />
are formally both valid in XHTML, only the latter should be used.
On the other hand, although
<p></p>
and
<p />
are formally valid and equivalent in XHTML, the latter should not be
used. (Actually the former should not be used either, but this relates to
other principles, not the syntactic issues.)

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

[Bertilo Wennergren]

Jukka K. Korpela:

In fact, the XML specification says: "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/REC-xml/#sec-starttags
[...]
Thus, although
<br></br>
and
<br />
are formally both valid in XHTML, only the latter should be used.
On the other hand, although
<p></p>
and
<p />
are formally valid and equivalent in XHTML, the latter should not be
used.

A small nit: The above only applies when "interoparability" is a factor.

for interoperability

[Definition: Marks a sentence describing a non-binding
recommendation included to increase the chances that XML documents
can be processed by the existing installed base of SGML processors
which predate the WebSGML Adaptations Annex to ISO 8879.]

<URL:http://www.w3.org/TR/REC-xml/#dt-interop>

So if you're already doing things that make it impossible to process the
document "with the existing installed base of SGML processors
which predate the WebSGML Adaptations Annex to ISO 8879", then the above
SHOULD and SHOULD NOT don't apply at all.

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

[Stephen Poley]

On Mon, 05 Apr 2004 20:15:00 +0200, Werner Partner
<ka****@sonoptikon.de> wrote:

Old html 4.01 Standard:
http://www.sonoptikon.de/kairos/kontakt.php
New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html
You see that the little picture left above is "jumping", the grey frame
under the picture is thicker in xhtml-Version, and the Banner ist higner.

Using which browser? With Opera 7.23 the frame under the logo is
*thinner* in the XHTML version.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Jukka K. Korpela]

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

So if you're already doing things that make it impossible to process
the document "with the existing installed base of SGML processors
which predate the WebSGML Adaptations Annex to ISO 8879", then the
above SHOULD and SHOULD NOT don't apply at all.

It doesn't apply as a recommendation in the XML specification. But that
recommendation, _very literally interpreted_, is pointless anyway. It's
not SGML processors that we are worried about but Web browsers.

Besides, even if there's no SHOULD or SHOULD NOT saying whether
<foo /> or <foo></foo> is to be preferred, you need not use them
at random. It is fairly logical to use <foo /> if and only if emptyness
is inherent (part of the element's definition), and to use <foo></foo> to
signal that a container is empty.

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

[Bertilo Wennergren]

Jukka K. Korpela:

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

So if you're already doing things that make it impossible to process
the document "with the existing installed base of SGML processors
which predate the WebSGML Adaptations Annex to ISO 8879", then the
above SHOULD and SHOULD NOT don't apply at all.

It doesn't apply as a recommendation in the XML specification. But that
recommendation, _very literally interpreted_, is pointless anyway. It's
not SGML processors that we are worried about but Web browsers.
Indeed.

From that practical perspective, the recommendation to use "<br />" but
"<p></p>" applies when serving XHTML 1.0 as "text/html" (in
compatibility mode), but not at all when sending XHTML as
"application/xhtml+xml".
Besides, even if there's no SHOULD or SHOULD NOT saying whether
<foo /> or <foo></foo> is to be preferred, you need not use them
at random. It is fairly logical to use <foo /> if and only if emptyness
is inherent (part of the element's definition), and to use <foo></foo> to
signal that a container is empty.

I agree. But when an XHTML document is produced by XSLT empty elements
tend to take the form "<element/>" in both cases.

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

[Werner Partner]

Jukka K. Korpela schrieb:

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

So if you're already doing things that make it impossible to process
the document "with the existing installed base of SGML processors
which predate the WebSGML Adaptations Annex to ISO 8879", then the
above SHOULD and SHOULD NOT don't apply at all.

It doesn't apply as a recommendation in the XML specification. But that
recommendation, _very literally interpreted_, is pointless anyway. It's
not SGML processors that we are worried about but Web browsers.

Besides, even if there's no SHOULD or SHOULD NOT saying whether
<foo /> or <foo></foo> is to be preferred, you need not use them
at random. It is fairly logical to use <foo /> if and only if emptyness
is inherent (part of the element's definition), and to use <foo></foo> to
signal that a container is empty.

That's what I meant, and even in <meta grgrgr grgrgrgrg></meta> it gives
a sense to write begin and end tag, although the space _between_ the
tags is _always_ empty, but it is clearer than <meta grgrg grgrgr grgrgr />

regards

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Werner Partner]

Jukka K. Korpela schrieb:

Scripsit Werner Partner <ka****@sonoptikon.de>:

Eric B. Bednarz schrieb:

compliance mode'). Please, stop doing what you are doing and revert
to good old fashioned tag salad.

???:
http://validator.w3.org/check?uri=ww...e%2Findex.html

Eric mentioned a mismatch in the doctype declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
It is definitely incorrect. The reason why a validator does not report an
error is that it simply uses the first quoted string (the formal public
identifier) to fetch the DTD from its internal reperoire, instead of
using the second string (system identifier, or a URL in practice) at all.

Taking away the tomatoe from my eye I see the error!

Thanks

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Werner Partner]

Stephen Poley schrieb:

On Mon, 05 Apr 2004 20:15:00 +0200, Werner Partner
<ka****@sonoptikon.de> wrote:

Old html 4.01 Standard:
http://www.sonoptikon.de/kairos/kontakt.php
New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html
You see that the little picture left above is "jumping", the grey frame
under the picture is thicker in xhtml-Version, and the Banner ist higner.

Using which browser? With Opera 7.23 the frame under the logo is
*thinner* in the XHTML version.

I activated old IE and tried:
I think it is a mozilla-bug?

Thanks

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Werner Partner]

Jukka K. Korpela schrieb:

Scripsit Werner Partner <ka****@sonoptikon.de>:

Eric B. Bednarz schrieb:

compliance mode'). Please, stop doing what you are doing and revert
to good old fashioned tag salad.

???:
http://validator.w3.org/check?uri=ww...e%2Findex.html

Eric mentioned a mismatch in the doctype declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
It is definitely incorrect. The reason why a validator does not report an
error is that it simply uses the first quoted string (the formal public
identifier) to fetch the DTD from its internal reperoire, instead of
using the second string (system identifier, or a URL in practice) at all.

But the doctype declaration _is_ contradictory. The document proper,
i.e. the <html> element, may comply with both Strict and Transitional (in
fact, compliance to Strict implies compliance to Transitional), but the
doctype declaration must uniquely define the DTD. Besides, the XHML 1.0
specification lists a limited number of allowed doctype declarations.

However the main point Eric is probably trying to make is that on the Web
of this day, and tomorrow too, old HTML 4 works better than any XHTML.

XHTML doesn't create big problems as a rule - this is what helps the
survival of the meme - but it creates various nasty little problems and

What's the solution? Back to HTML 4 and using consequently style sheets
like in XHTML? Designing XHTML-compatible in HTML 4 (without <br /> and
<hr /> ...).

regards

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Jukka K. Korpela]

Werner Partner <ka****@sonoptikon.de> wrote:

What's the solution? Back to HTML 4
There was never a reason to move away from HTML 4 (plus sometimes
browser-specific extensions) in Web authoring. Such reasons may emerge,
but currently XHTML is just an exercise.
and using consequently style sheets like in XHTML?
Yes, there's no difference in that respect. (Well, to be exact, there is,
but it's rather theoretical mostly and only applies to <style> elements.)

Designing XHTML-compatible in HTML 4 (without
<br /> and <hr /> ...).

Yes. The rules for always quoting attribute values, always using explicit
end tags etc. were good practices even before XHTML. But it's really not
a big issue, since if you will move from HTML 4 to XHTML later, you will
anyway need a conversion and checking tool.

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

[Werner Partner]

Jukka K. Korpela schrieb:

Werner Partner <ka****@sonoptikon.de> wrote:

What's the solution? Back to HTML 4

There was never a reason to move away from HTML 4 (plus sometimes
browser-specific extensions) in Web authoring. Such reasons may emerge,
but currently XHTML is just an exercise.

and using consequently style sheets like in XHTML?

Yes, there's no difference in that respect. (Well, to be exact, there is,
but it's rather theoretical mostly and only applies to <style> elements.)

Designing XHTML-compatible in HTML 4 (without
<br /> and <hr /> ...).

Yes. The rules for always quoting attribute values, always using explicit
end tags etc. were good practices even before XHTML. But it's really not
a big issue, since if you will move from HTML 4 to XHTML later, you will
anyway need a conversion and checking tool.

Good advice!
XHTML was a good practice, let's see later :-)

regards

Werner

--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Eric B. Bednarz]

Werner Partner <ka****@sonoptikon.de> writes:

New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html

Maybe you understood me wrong.
My simple and humble question is:

No, I didn't.
Firstly, all you can expect on Usenet is the right to initiate a
discussion; whether or not that discussion proves to be useful in
respect to your query is purely incidental.
Secondly, your question seems to be related to CSS, not HTML.

You announced a problem on an 'XHTML' page; although my UA supports
application/xhtml+xml and explicitly announces to prefer it over
text/html I get served the latter. Viewing source, the very first thing
I see is a blatant error (it doesn't matter if your page 'validates' at
*some* remote system -- depending on the existence of a catalogue, a
catalogue entry for the FPI and the setup of the catalogue, results can
be different, if it *were* XHTML /possibly/ even in UAs).

Hence my suggestion to stay away from XHTML (at least until you have
achieved some deeper understanding about the things you are doing; at
that point, the desire for random XMLisation will probably have faded
away ;-).
--
| ) 111010111011 | http://bednarz.nl/
-(
| ) Distribute me: http://binaries.bednarz.nl/mp3/aisha

[Philipp Lenssen]

Jukka K. Korpela wrote:

Werner Partner <ka****@sonoptikon.de> wrote:

What's the solution? Back to HTML 4

There was never a reason to move away from HTML 4 (plus sometimes
browser-specific extensions) in Web authoring. Such reasons may
emerge, but currently XHTML is just an exercise.

See, that's just what kids do when they start to walk and fall. You
might say they gained nothing by switching from walking on arms and
legs to walking up straight using just their legs. In fact, they will
certainly fall more often, and break some vases. But once they get out
of that period, walking straight brings a lot of advantages. And would
you tell a kid to not learn walking because it can't walk perfectly
right away?

It's the same with innovation on the Web. If you want perfection, if
you want it to work perfectly rightaway, in short, if you want to cut
the exercise part -- then you will never see any evolution in HTML
which actually _will_ serve the Web one day. XHTML is intended to do
just that. Switching to it today ensures that one day, HTML will work
better than it does now.

That's the theory. In practice, most people have no reason to care
about HTML in either way (i.e. use valid code according to _whatever_
doctype). Most successful pages are based on nasty tag soup with a lot
of <font>s that isn't just old-fashioned, but was flawed from the
beginning. Just take Google for example.

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

[Eric B. Bednarz]

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

However the main point Eric is probably trying to make is that on the Web
of this day, and tomorrow too, old HTML 4 works better than any XHTML.

Certainly so, but it strikes me as a more severe point that ad-hoc XHTML
syntax served as tag soup is in no way 'forwardscompatible' or whatnot
the jargon might be. The web is already cluttered with disinformational
tutorials that teach you how to "migrate to XHTML in 10 minutes", while
-- as someone in another NG recently sharply observed -- in fact it
takes 24 hours to properly learn any language (look at a web designer's
book shelf for evidence ;-).

An awful lot of that stuff which appears to 'work' today would actually
*break* tomorrow if it was treated as what it is supposed to be. OTOH,
if 'real' XHTML would ever achieve a mainstream status on the web,
parsers would surely very soon become fussy^W, pardon, liberal enough
to, erm, recover from fatal errors.
--
| ) 111010111011 | http://bednarz.nl/
-(
| ) Distribute me: http://binaries.bednarz.nl/mp3/aisha

[Werner Partner]

Eric B. Bednarz schrieb:

Werner Partner <ka****@sonoptikon.de> writes:

New xhtml 1.0 Standard:
http://www.sonoptikon.de/kairos/index.html

Maybe you understood me wrong.
My simple and humble question is:

No, I didn't.
Firstly, all you can expect on Usenet is the right to initiate a
discussion; whether or not that discussion proves to be useful in
respect to your query is purely incidental.
Secondly, your question seems to be related to CSS, not HTML.

You announced a problem on an 'XHTML' page; although my UA supports
application/xhtml+xml and explicitly announces to prefer it over
text/html I get served the latter. Viewing source, the very first thing
I see is a blatant error (it doesn't matter if your page 'validates' at
*some* remote system -- depending on the existence of a catalogue, a
catalogue entry for the FPI and the setup of the catalogue, results can
be different, if it *were* XHTML /possibly/ even in UAs).

Hence my suggestion to stay away from XHTML (at least until you have
achieved some deeper understanding about the things you are doing; at
that point, the desire for random XMLisation will probably have faded
away ;-).

Well, the thread grow little bit longer, it was useful for me in several
respects, and the original question faded away because it seemes to be a
mozilla-bug.

I just did not see the blatant error, and the Validator did not "see" it
either. So everyone is satisfied. I began to walk, fell and am going on
walking. :-)

Werner
--
-----------------------------------------------------------
Werner Partner * Tel [phone] * Fax: 886608
mailto:ka****@sonoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Jan Roland Eriksson]

On Tue, 06 Apr 2004 13:02:13 +0200, Bertilo Wennergren
<be******@gmx.net> wrote:

Jukka K. Korpela:

Besides, even if there's no SHOULD or SHOULD NOT saying whether
<foo /> or <foo></foo> is to be preferred, you need not use them
at random. It is fairly logical to use <foo /> if and only if emptyness
is inherent (part of the element's definition), and to use <foo></foo> to
signal that a container is empty.

I agree. But when an XHTML document is produced by XSLT empty elements
tend to take the form "<element/>" in both cases.

Hmm... XSLT is a Turing complete programming language. Would it not be
up to the XSLT programmer to show some manners and correctly define
what gets generated in the transformation?

The original idea behind the introduction of NESTC (thought out by
some prominent SGML'ers none the less) was to give non validating
(DTD'less) XML parsers a way to distinguish between the intended
"meaning" of an element as in "I'm empty by nature" [<foo/>] or "I'm
just an empty container" [<bar></bar>].

We all know who sabotaged that idea, but it's all history now, just go
on and live with the mess gents :-)

--
Rex

[Bertilo Wennergren]

Jan Roland Eriksson:

On Tue, 06 Apr 2004 13:02:13 +0200, Bertilo Wennergren
<be******@gmx.net> wrote:

Jukka K. Korpela:

Besides, even if there's no SHOULD or SHOULD NOT saying whether
<foo /> or <foo></foo> is to be preferred, you need not use them
at random. It is fairly logical to use <foo /> if and only if emptyness
is inherent (part of the element's definition), and to use <foo></foo> to
signal that a container is empty.

I agree. But when an XHTML document is produced by XSLT empty elements
tend to take the form "<element/>" in both cases.

Hmm... XSLT is a Turing complete programming language. Would it not be
up to the XSLT programmer to show some manners and correctly define
what gets generated in the transformation?

Could be. But as an ordinary user who wants to use XSLT that is hardly
an option. In such a case one would just have to accept that the form
"<element/>" will be used in both cases. There is hardly enough
motivation to try to make an XSLT processor make a distinction.

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

[Jan Roland Eriksson]

On Tue, 06 Apr 2004 20:24:56 +0200, Bertilo Wennergren
<be******@gmx.net> wrote:

Jan Roland Eriksson:

On Tue, 06 Apr 2004 13:02:13 +0200, Bertilo Wennergren
<be******@gmx.net> wrote:

Jukka K. Korpela:
...saying whether <foo /> or <foo></foo> is to be preferred,
you need not use them at random... ...when an XHTML document is produced by XSLT, empty elements
tend to take the form "<element/>" in both cases.

...Would it not be up to the XSLT programmer to...correctly define
what gets generated in the transformation?

Could be. But as an ordinary user who wants to use XSLT that is hardly
an option. In such a case one would just have to accept that the form
"<element/>" will be used in both cases. There is hardly enough
motivation to try to make an XSLT processor make a distinction.

A comment that leads me to believe that you are using some "ready made"
XSLT program for your own needs, not bothering too much about the "fine
print" that comes with it?

XSLT programs are always available in source code, no need to let it get
you in areas where you don't want it to. Go learn XSLT; and then tweak
your source code til you get what you want (which may not be isolated to
only "empty" element processing as this partial thread came to be :-)

--
Rex

[Tim]

On Tue, 6 Apr 2004 09:57:31 +0000 (UTC),
"Jukka K. Korpela" <jk******@cs.tut.fi> posted:

An element that is declared EMPTY has the keyword EMPTY in its definition
in the formal syntax (DTD), and this means that the element _cannot_
contain anything. The <meta> element belongs to this category (since it
has historically been defined in an odd way that puts all data into
attributes.) This is to be distinguished from "casually empty" content,
such as in <td></td>, where the element _could_ have content of various
kind but here happens to be empty.

It did strike me that if you were to use a meta element, then it'd be more
logical to use it something more like this:

<meta http-equiv="Content-Type">text/html; charset=ISO-8859-1</meta>

Though I imagine that would cause all sorts of compatibility issues with
things that like to parse XHTML as if it were just HTML.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Jukka K. Korpela]

Tim <ti*@mail.localhost.invalid> wrote:

It did strike me that if you were to use a meta element, then it'd be
more logical to use it something more like this:

<meta http-equiv="Content-Type">text/html; charset=ISO-8859-1</meta>
The logical way to define meta elements in HTML _would have been_

<meta><http>Content-Type</http>
<value>text/html;charset=ISO-8859-1</value>
</meta>

or something more structured.
Though I imagine that would cause all sorts of compatibility issues
with things that like to parse XHTML as if it were just HTML.

It would cause no parsing problem. But meta tags just weren't defined
that way.

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

[Bertilo Wennergren]

Jan Roland Eriksson:

On Tue, 06 Apr 2004 20:24:56 +0200, Bertilo Wennergren
<be******@gmx.net> wrote:

Could be. But as an ordinary user who wants to use XSLT that is hardly
an option. In such a case one would just have to accept that the form
"<element/>" will be used in both cases. There is hardly enough
motivation to try to make an XSLT processor make a distinction.

A comment that leads me to believe that you are using some "ready made"
XSLT program for your own needs, not bothering too much about the "fine
print" that comes with it?
Sablotron.
XSLT programs are always available in source code, no need to let it get
you in areas where you don't want it to. Go learn XSLT; and then tweak
your source code til you get what you want (which may not be isolated to
only "empty" element processing as this partial thread came to be :-)

I can see the point of using "<element/>" only for elements that can't
have content, and "<element></element>" only for elements that can have
content. It would be kind of clean and nice and logic (although XML or
XHTML doesn't mandate it). But it doesn't seem nearly important enough
for me to go hack the source code of Sablotron. Maybe for others the
distinction is really that important.

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

[I V]

On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:

Hmm... XSLT is a Turing complete programming language. Would it not be
up to the XSLT programmer to show some manners and correctly define
what gets generated in the transformation?

I don't think that's true. Turing completeness, after all, says nothing
about input or output, just about data manipulation. The data that XSLT
programs manipulate is in the form of XML trees. How the XSLT parser
chooses to output that tree is not something the XSLT program needs to be
able to determine.

--
" - Penny, I worry that you are loosing heart... You are not the sweet little
girl I once knew. Where's your sense of wonder?
- Currently flowing into a sanitary napkin... Guess where my childlike
innocence and idle dreams are currently wedged. Come on, I dare you."
http://www.huh.34sp.com/

[I V]

On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:

Hmm... XSLT is a Turing complete programming language. Would it not be
up to the XSLT programmer to show some manners and correctly define
what gets generated in the transformation?

I don't think that's true. Turing completeness, after all, says nothing
about input or output, just about data manipulation. The data that XSLT
programs manipulate is in the form of XML trees. How the XSLT parser
chooses to output that tree is not something the XSLT program needs to be
able to determine.

--
" - Penny, I worry that you are loosing heart... You are not the sweet little
girl I once knew. Where's your sense of wonder?
- Currently flowing into a sanitary napkin... Guess where my childlike
innocence and idle dreams are currently wedged. Come on, I dare you."
http://www.huh.34sp.com/

[Jan Roland Eriksson]

On Wed, 07 Apr 2004 20:37:29 +0100, "I V" <iv*****@gmx.co.uk> wrote:

On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:

...up to the XSLT programmer to ... correctly define
what gets generated in the transformation?

...data that XSLT programs manipulate is in the form of XML
trees. How the XSLT parser chooses to output that tree is not
something the XSLT program needs to be able to determine.

If my parser do not output a true representation of its original
input, but makes "pre-transformations" behind my back, I would change
parser.

--
Rex

[Jan Roland Eriksson]

On Wed, 07 Apr 2004 20:37:29 +0100, "I V" <iv*****@gmx.co.uk> wrote:

On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:

...up to the XSLT programmer to ... correctly define
what gets generated in the transformation?

...data that XSLT programs manipulate is in the form of XML
trees. How the XSLT parser chooses to output that tree is not
something the XSLT program needs to be able to determine.

If my parser do not output a true representation of its original
input, but makes "pre-transformations" behind my back, I would change
parser.

--
Rex

[Brian]

Philipp Lenssen wrote:

Jukka K. Korpela wrote:

There was never a reason to move away from HTML 4

currently XHTML is just an exercise.
See, that's just what kids do when they start to walk and fall.

(I hate contrived metaphors.)
You might say they gained nothing by switching from walking on arms
and legs to walking up straight using just their legs.
Except that XHTML is not walking upright. It's the same crawling that
HTML offered, only with new impediments that weren't there with HTML.
then you will never see any evolution in HTML which actually _will_
serve the Web one day.
Some www technologies have been adopted: CSS is used increasingly
because it solves problems. XHTML does not solve any problems that I can
see. So why change?
XHTML is intended to do just that. Switching to it today ensures that
one day, HTML will work better than it does now.

That's optimistic of you. But I think I'll stick with HTML.

--
Brian

[Brian]

Philipp Lenssen wrote:

Jukka K. Korpela wrote:

There was never a reason to move away from HTML 4

currently XHTML is just an exercise.
See, that's just what kids do when they start to walk and fall.

(I hate contrived metaphors.)
You might say they gained nothing by switching from walking on arms
and legs to walking up straight using just their legs.
Except that XHTML is not walking upright. It's the same crawling that
HTML offered, only with new impediments that weren't there with HTML.
then you will never see any evolution in HTML which actually _will_
serve the Web one day.
Some www technologies have been adopted: CSS is used increasingly
because it solves problems. XHTML does not solve any problems that I can
see. So why change?
XHTML is intended to do just that. Switching to it today ensures that
one day, HTML will work better than it does now.

That's optimistic of you. But I think I'll stick with HTML.

--
Brian

[Jim Ley]

On 6 Apr 2004 15:04:58 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

XHTML is intended to do
just that. Switching to it today ensures that one day, HTML will work
better than it does now.

Yep that was the theory, but as you note it doesn't serve me an
individual any better being the person that breaks vases.

In any case I can get all the benefits (if indeed there are any) in
moving to XHTML 2.0 by moving to XHTML 2.0 - I don't have to take
incremental steps in between, unlike learning to walk, where the
intermediate steps are essential.

In any case with future W3 specs such as XBL, and SVG 1.2, the
rendering and the semantic format of your mark-up can become much more
distinct, this with render XHTML 2.0 obsolete in the face of more
specific vocabularies that are actually rich enough to describe some
interesting semantics, something that XHTML 2.0 is not offering much
of at all.

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

[Jim Ley]

On 6 Apr 2004 15:04:58 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

XHTML is intended to do
just that. Switching to it today ensures that one day, HTML will work
better than it does now.

Yep that was the theory, but as you note it doesn't serve me an
individual any better being the person that breaks vases.

In any case I can get all the benefits (if indeed there are any) in
moving to XHTML 2.0 by moving to XHTML 2.0 - I don't have to take
incremental steps in between, unlike learning to walk, where the
intermediate steps are essential.

In any case with future W3 specs such as XBL, and SVG 1.2, the
rendering and the semantic format of your mark-up can become much more
distinct, this with render XHTML 2.0 obsolete in the face of more
specific vocabularies that are actually rich enough to describe some
interesting semantics, something that XHTML 2.0 is not offering much
of at all.

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