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

[Eric B. Bednarz]

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

Werner Partner <kairos@sonopti kon.de> writes:
[color=blue][color=green][color=darkred]
>>>New xhtml 1.0 Standard:
>>>http://www.sonoptikon.de/kairos/index.html[/color][/color][/color]
[color=blue]
> Maybe you understood me wrong.
> My simple and humble question is:[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

Jukka K. Korpela wrote:
[color=blue]
> Werner Partner <kairos@sonopti kon.de> wrote:
>[color=green]
> > What's the solution? Back to HTML 4[/color]
>
> 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.
>[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> writes:
[color=blue]
> 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.[/color]

Certainly so, but it strikes me as a more severe point that ad-hoc XHTML
syntax served as tag soup is in no way 'forwardscompat ible' or whatnot
the jargon might be. The web is already cluttered with disinformationa l
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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

Eric B. Bednarz schrieb:
[color=blue]
> Werner Partner <kairos@sonopti kon.de> writes:
>
>[color=green][color=darkred]
>>>>New xhtml 1.0 Standard:
>>>>http://www.sonoptikon.de/kairos/index.html[/color][/color]
>
>[color=green]
>>Maybe you understood me wrong.
>>My simple and humble question is:[/color]
>
>
> 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 ;-).
>[/color]

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 +49 2366 886606 * Fax: 886608
mailto:kairos@s onoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Jan Roland Eriksson]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Tue, 06 Apr 2004 13:02:13 +0200, Bertilo Wennergren
<bertilow@gmx.n et> wrote:
[color=blue]
>Jukka K. Korpela:[color=green]
>> 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.[/color][/color]
[color=blue]
>I agree. But when an XHTML document is produced by XSLT empty elements
>tend to take the form "<element/>" in both cases.[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

Jan Roland Eriksson:
[color=blue]
> On Tue, 06 Apr 2004 13:02:13 +0200, Bertilo Wennergren
> <bertilow@gmx.n et> wrote:[/color]
[color=blue][color=green]
>>Jukka K. Korpela:[color=darkred]
>>> 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.[/color][/color][/color]
[color=blue][color=green]
>>I agree. But when an XHTML document is produced by XSLT empty elements
>>tend to take the form "<element/>" in both cases.[/color][/color]
[color=blue]
> 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?[/color]

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 <bertilow@gmx.n et> <http://www.bertilow.co m>

[Jan Roland Eriksson]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Tue, 06 Apr 2004 20:24:56 +0200, Bertilo Wennergren
<bertilow@gmx.n et> wrote:
[color=blue]
>Jan Roland Eriksson:[/color]
[color=blue][color=green]
>> On Tue, 06 Apr 2004 13:02:13 +0200, Bertilo Wennergren
>> <bertilow@gmx.n et> wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>>>Jukka K. Korpela:
>>>>...saying whether <foo /> or <foo></foo> is to be preferred,
>>>>you need not use them at random...[/color][/color][/color]
[color=blue][color=green][color=darkred]
>>>...when an XHTML document is produced by XSLT, empty elements
>>>tend to take the form "<element/>" in both cases.[/color][/color][/color]
[color=blue][color=green]
>>...Would it not be up to the XSLT programmer to...correctly define
>> what gets generated in the transformation?[/color][/color]
[color=blue]
>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.[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Tue, 6 Apr 2004 09:57:31 +0000 (UTC),
"Jukka K. Korpela" <jkorpela@cs.tu t.fi> posted:
[color=blue]
> 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.[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

Tim <tim@mail.local host.invalid> wrote:
[color=blue]
> 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>[/color]

The logical way to define meta elements in HTML _would have been_

<meta><http>Con tent-Type</http>
<value>text/html;charset=IS O-8859-1</value>
</meta>

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

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

Jan Roland Eriksson:
[color=blue]
> On Tue, 06 Apr 2004 20:24:56 +0200, Bertilo Wennergren
> <bertilow@gmx.n et> wrote:[/color]
[color=blue][color=green]
>>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.[/color][/color]
[color=blue]
> 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?[/color]

Sablotron.
[color=blue]
> 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 :-)[/color]

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 <bertilow@gmx.n et> <http://www.bertilow.co m>

[I V]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:
[color=blue]
> 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?[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:
[color=blue]
> 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?[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Wed, 07 Apr 2004 20:37:29 +0100, "I V" <ivlenin@gmx.co .uk> wrote:
[color=blue]
>On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:
>[color=green]
>>...up to the XSLT programmer to ... correctly define
>>what gets generated in the transformation?[/color]
>
>...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.[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

On Wed, 07 Apr 2004 20:37:29 +0100, "I V" <ivlenin@gmx.co .uk> wrote:
[color=blue]
>On Tue, 06 Apr 2004 19:32:36 +0200, Jan Roland Eriksson wrote:
>[color=green]
>>...up to the XSLT programmer to ... correctly define
>>what gets generated in the transformation?[/color]
>
>...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.[/color]

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]

Re: Once again: effects in Migration HTML 4.01 -&gt; XHTML 1.0

Philipp Lenssen wrote:
[color=blue]
> Jukka K. Korpela wrote:
>[color=green]
>> There was never a reason to move away from HTML 4
>>
>> currently XHTML is just an exercise.[/color]
>
> See, that's just what kids do when they start to walk and fall.[/color]

(I hate contrived metaphors.)
[color=blue]
> You might say they gained nothing by switching from walking on arms
> and legs to walking up straight using just their legs.[/color]

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.
[color=blue]
> then you will never see any evolution in HTML which actually _will_
> serve the Web one day.[/color]

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?
[color=blue]
> XHTML is intended to do just that. Switching to it today ensures that
> one day, HTML will work better than it does now.[/color]

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

--
Brian