Does <script src=foo> require an end tag </script>

rhythmace wrote:

<script type="text/javascript" src="foo.js">

<script type="text/javascript">
...script in here...
</script>
...

But as far as I can tell, the first script tag requires a </script>
close tag. Is the close tag required for valid markup?

Yes -- the SCRIPT element requires an end tag. But you have an end tag
there.

The real question, is "how many SCRIPT elements do you have there?" The
answer is one.

The second "<script..." bit will be treated as Javascript data within the
first SCRIPT element, and should cause a Javascript error (but not a
validation error).

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Apr 8 '06 #3

rh*******@gmail.com wrote:

<script type="text/javascript" src="foo.js">

<script type="text/javascript">
...script in here...
</script>

That was already explained why such script declaration will not work.
I'd just like to alert you about another common mistake of this kind:

<script type="text/javascript" src="foo.js">
// code here
</script>

// code here block will be ignored and only foo.js code will be
executed (unless it's Netscape 2.x w/o src attribute support)

So the rule is: external file requires separate <script> block with
closing tag.

The only working option:

<script type="text/javascript" src="foo.js"></script>
<script type="text/javascript">
// code here
</script>

Apr 8 '06 #4

rhythmace

Excellent! Thanks so much guys. Actually the browsers appear to be
smart about this and afaict they do interpret 2 script tags, not 1, so
they might have some heuristic. For example, if it is not possible to
nest script tags then maybe they just autoclose the first one???

Apr 8 '06 #5

rh*******@gmail.com wrote:

Actually the browsers appear to be
smart about this and afaict they do interpret 2 script tags, not 1, so
they might have some heuristic.

No they don't: it is your allusion. Probably you happened to have a
variable/function you're checking against both in external file and in
inline code.

Any way: your syntax doesn't work (and cannot work), so please stop
confusing potentional readers ;-) :-|

A code to dismiss your allusion:

// THIS SYNTAX IS INTENTIONALLY WRONG
// FOR DEMONSTRATION PURPOSES

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" src="foo.js" />
<script type="text/javascript">
var v = 1;
</script>
</head>

<body onLoad="alert(typeof v)">

</body>
</html>

// FF 1.5.0.1 : undefined
// IE 6.0 : undefined
// Opera 8.5 : undefined
And for a sake of it:
// NN 4.5 : undefined

Apr 9 '06 #6

VK wrote:

// THIS SYNTAX IS INTENTIONALLY WRONG
// FOR DEMONSTRATION PURPOSES
[...] <script type="text/javascript" src="foo.js" />
<script type="text/javascript">
var v = 1;
</script>

That should actually be fine, assuming XHTML.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Apr 12 '06 #7

Toby Inkster wrote:

VK wrote:
// THIS SYNTAX IS INTENTIONALLY WRONG
// FOR DEMONSTRATION PURPOSES

[...]
<script type="text/javascript" src="foo.js" />
<script type="text/javascript">
var v = 1;
</script>

That should actually be fine, assuming XHTML.

Of course it is *not*. The parsing rules get stricter, but the basics
are the same. <script> tag requires closing tag. After meeting <script
type="text/javascript" src="foo.js" /> UA will ignore everything until
it meets the closing tag </script>. This way the internal block will be
ignored.

You seem to have a strange idea about the /> syntax. It is not (and
cannot be) used to override (X)HTML standards - say to transform a
paired tag into a single one against specifications. Why wouldn't you
try to use then <div />Content 1 <div />Content 2

Apr 12 '06 #8

On 12/04/2006 21:58, VK wrote:

Toby Inkster wrote:
VK wrote:
[snip]

<script type="text/javascript" src="foo.js" />

[snip]
That should actually be fine, assuming XHTML.

Of course it is *not*.

Yes, it is. Toby said XHTML, not HTML.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Apr 12 '06 #9

> <script type="text/javascript" src="foo.js" />

<script type="text/javascript">
var v = 1;
</script>

Michael Winter wrote: Yes, it is <fine>. Toby said XHTML, not HTML.

What do you mean by "fine"? That it will pass XHTML validation on W3C
validator? Yes it currently will because there is obviously a bug in
the current version. It allows you to use the /> syntacs against the
declared DTD - thus in paired tags. After the validator will learn to
pay more attention to the declared DTD's, this issue will be solved.

If by "fine" you mean "will produce the intended result" - then of
course and once again *no*. From two declared blocks above anly the
external file foo.js will be loaded.

Apr 12 '06 #10

On 12/04/2006 22:52, VK wrote:

[snip]

Michael Winter wrote:
Yes, it [an empty-element tag] is fine. Toby said XHTML, not HTML.

What do you mean by "fine"?

That it, when read by an XML processor, will add a script element to the
document tree. What else do you think I could have meant?

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Apr 12 '06 #11

Michael Winter wrote:

What do you mean by "fine"?

That it, when read by an XML processor, will add a script element to the
document tree. What else do you think I could have meant?

By XHTML processor, not XML processor (there is a difference). Yes it
may slip through if a validator (or a parser) is buggy and doesn't use
declared DTD in parsing.

But the whole thread was about this block:

<script type="text/javascript" src="foo.js">
<script type="text/javascript">
....script in here...
</script>

or this:
<script type="text/javascript" src="foo.js" />
<script type="text/javascript">
....script in here...
</script>

As neither one will work by definition (only one script element with
external file will be created) I would be highly hesitating to call it
"fine" ;-)

The first one is: "A syntax allowed by HTML parsing rules but
practically useless, misleading and error prone".

The second one is: "A syntax allowed by some XHTML validators but
practically useless, misleading and error prone".

To be short I would use only the constant part of both descriptions: "A
practically useless, misleading and error prone syntax". ;-)

Apr 12 '06 #12

Steve Pugh

"VK" <sc**********@yahoo.com> wrote:

<script type="text/javascript" src="foo.js" />
<script type="text/javascript">
var v = 1;
</script>
Michael Winter wrote:
Yes, it is <fine>. Toby said XHTML, not HTML.

What do you mean by "fine"? That it will pass XHTML validation on W3C
validator? Yes it currently will because there is obviously a bug in
the current version. It allows you to use the /> syntacs against the
declared DTD - thus in paired tags. After the validator will learn to
pay more attention to the declared DTD's, this issue will be solved.

Care to state where in any XHTML DTD this requirement is?

There's a suggestion in the text of the XHTML 1.0 spec (not the DTD)
that /> only be used for elements that are defined as empty in HTML
4.01, for reasons of pseudo-compatability with (buggy) HTML parsing
engines.

But that's as far as it goes. The Validator only reads the DTD and not
the spec (that being what a validator does) there is no bug in the
validator.
If by "fine" you mean "will produce the intended result" - then of
course and once again *no*. From two declared blocks above anly the
external file foo.js will be loaded.

"Fine" as in perfectly good XHTML for creating two script elements?
The fact that browsers get it wrong is no big surprise.

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

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

Apr 12 '06 #13

Steve Pugh wrote:

"Fine" as in perfectly good XHTML for creating two script elements?
The fact that browsers get it wrong is no big surprise.

"No big deal that this code doesn't work on any of existing/ever
existed browsers and there are doubts that it ever will in any near
future. It is still fine - because it is theoretically correct."

Sometimes ciwas and siwah just nock me out: I feel like I got crazy -
or everyone around me did. :-)

It might help to accomodate if ciwah would be piwah:
philosophy.infosystems.www.abstractions.html :-)

But as I see "authoring" instead of "abstractions" then could we be a
tiiiny bit more reality connected?

Apr 13 '06 #14

Nick Kew

Steve Pugh wrote:

Care to state where in any XHTML DTD this requirement is?

There's a suggestion in the text of the XHTML 1.0 spec (not the DTD)
that /> only be used for elements that are defined as empty in HTML
4.01, for reasons of pseudo-compatability with (buggy) HTML parsing
engines.
Wrong.

Nothing to do with buggy HTML parsing. Everything to do with
taking advantage of error-tolerance in HTML parsers.
But that's as far as it goes. The Validator only reads the DTD and not
the spec (that being what a validator does) there is no bug in the
validator.

Indeedie. That's why validation is only one part of checking.

If by "fine" you mean "will produce the intended result" - then of
course and once again *no*. From two declared blocks above anly the
external file foo.js will be loaded.

"Fine" as in perfectly good XHTML for creating two script elements?
The fact that browsers get it wrong is no big surprise.

What browsers get that wrong?

Hint: if you serve documents as "text/html", browsers rightly apply
HTML rules, not XML rules. So if you violate Appendix C - as in
the example given - browsers are right to see the first <script
as unclosed. If you want browsers to apply XML rules, serve
them XML MIME types.

--
not me guv

Apr 13 '06 #15

rhythmace

:) Ok VK, point taken.

It's not my delusion/illusion actually, hence the thread. I have a user
complaining that our search robot is getting the contents of his page
wrong. He must think the page is working as he intends. I told him not,
but I would consult the wise and friendly experts. There is no other
source for his script. It's a whole gaggle of browser sniffing code
amongst
other things. He must be quite frustrated as to why it doesn't work :)

VK wrote:

rh*******@gmail.com wrote:
Actually the browsers appear to be
smart about this and afaict they do interpret 2 script tags, not 1, so
they might have some heuristic.

No they don't: it is your allusion. Probably you happened to have a
variable/function you're checking against both in external file and in
inline code.

Any way: your syntax doesn't work (and cannot work), so please stop
confusing potentional readers ;-) :-|

A code to dismiss your allusion:

// THIS SYNTAX IS INTENTIONALLY WRONG
// FOR DEMONSTRATION PURPOSES

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" src="foo.js" />
<script type="text/javascript">
var v = 1;
</script>
</head>

<body onLoad="alert(typeof v)">

</body>
</html>

// FF 1.5.0.1 : undefined
// IE 6.0 : undefined
// Opera 8.5 : undefined
And for a sake of it:
// NN 4.5 : undefined

Apr 13 '06 #16

Richard Cornford

VK wrote:

Steve Pugh wrote:
"Fine" as in perfectly good XHTML for creating two
script elements?
Absolutely fine.
The fact that browsers get it wrong is no big surprise.

Browsers supporting XHTML, receiving this mark-up as part of an XHTML
document (so served as an XHTML document), do not get this wrong.
"No big deal that this code doesn't work on any of
existing/ever existed browsers and there are doubts
that it ever will in any near future. It is still fine
- because it is theoretically correct."
Haven't you learnt yet that your pontificating about the generality of
web browsers suffers significantly form you lack of familiarity with web
browsers and your lack of understanding of web technologies? Existing
browsers do include Mozilla and Opera 8+.
Sometimes ciwas and siwah just nock me out: I feel like
I got crazy - or everyone around me did. :-)

<snip>

It is you. When you find yourself in a minority of one the odds are good
that it is you who is wrong, and when you find yourself in a minority of
one in a technical newsgroup it is virtually a certainty.

Richard.

Apr 13 '06 #17

Toby Inkster wrote:

<script type="text/javascript" src="foo.js" />
That should actually be fine, assuming XHTML.

Although not Appendix C XHTML, so it is not suitable for serving as
text/html (and Internet Explorer is among the browsers which will
produce a result you probably won't like if you try it).

Apr 13 '06 #18

On 12/04/2006 23:58, VK wrote:

Michael Winter wrote:
On 12/04/2006 22:52, VK wrote:
What do you mean by "fine"?
That it [an empty-element tag], when read by an XML processor, will
add a script element to the document tree. What else do you think I
could have meant?

By XHTML processor, not XML processor (there is a difference).

I meant what I wrote. An XHTML document is also an XML document, so
using an XML processor is appropriate. Of course, the /application/
should understand XHTML, but the processor itself needn't.
Yes it may slip through if a validator (or a parser) is buggy and
doesn't use declared DTD in parsing.
What?

Empty-element tags may be used for any element which has no
content, whether or not it is declared using the keyword EMPTY.

-- 3.1 Start-Tags, End-Tags, and Empty-Element Tags,
Extensible Markup Language (XML) 1.0 (Second Edition)
But the whole thread was about this block:

<script type="text/javascript" src="foo.js">
<script type="text/javascript">
...script in here...
</script>
And it was established that it was bogus. That isn't in question.
or this:
<script type="text/javascript" src="foo.js" />
<script type="text/javascript">
...script in here...
</script>
/You/ posted that and, as Toby pointed out, it's quite acceptable for XHTML.
As neither one will work by definition [...]
Your definition, perhaps, but then you've often shown the tendency to
dream up definitions that happen to suit your outlook, not reality,
particularly in c.l.javascript. Do you plan to make it a habit of it
here in ciwah, too?
The first one is: "A syntax allowed by HTML parsing rules but
practically useless, misleading and error prone".
No, it isn't: it's invalid. After that lengthy discussion, you still
don't understand how NET-enabled start-tags work?
The second one is: "A syntax allowed by some XHTML validators but
practically useless, misleading and error prone".

No, it isn't. It should be allowed by all validating XML processors, and
hardly misleading or error-prone[1].

[snip]

Mike
[1] An exception, and perhaps a significant one, is when viewed
by people that don't understand XML and, more importantly,
the issues surrounding XHTML on the Web. It would seem that
you, VK, fall into this category.

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Apr 13 '06 #19

Andy Dingley

Toby Inkster wrote:

<script type="text/javascript" src="foo.js" />
That should actually be fine, assuming XHTML.

Assuming "XHTML as XML, for only browsers that understand it" it's OK.

For anything else, including "XHTML as Appendix C" or "XHTML as tag
soup" OR "XHTML to anything at all that isn't playing the entire XML
game all the way" then it fails badly (IE6 will hide your whole
document)

So as a general working practice for anything vaguley near "the web",
<script type="text/javascript" src="foo.js" /> is entirely unworkable.
You need to preserve the separate start and end tag, no matter what.

This is one reason why it's awkward to produce viable XHTML from XSLT.
You have to stick some whitespace in there (to force the tags separate)
and the slightest sloppy coding in a default XML/XSLT mindset will
break your site

(Yes, I've done it on a live site and had an outage for a whole
morning).

Apr 13 '06 #20

Nick Kew

Michael Winter wrote:

I meant what I wrote. An XHTML document is also an XML document, so
using an XML processor is appropriate.

Not when a document is served as text/html.

--
Nick Kew

Apr 13 '06 #21

Michael Winter wrote:

[1] An exception, and perhaps a significant one, is when viewed
by people that don't understand XML and, more importantly,
the issues surrounding XHTML on the Web. It would seem that
you, VK, fall into this category.

A dead man cannot have a headache; a dead technology cannot have
*current* issues.

But just as of a pure curiosity, like "what did dinosaurs eat":

This is (I presume) your beloved XHTML generated by Amaya:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-1" />
<title>No title</title>
<meta name="generator" content="amaya 8.8.3, see
http://www.w3.org/Amaya/"
/>
<script type="text/javascript" src="test.js" />
<script type="text/javascript">
var v = 1;
</script>
</head>

<body>
</body>
</html>
Where test.js contains:
// test.js
function init() {
window.alert(typeof v);
}
window.onload = init;

After having all this uploaded to the server and after adding new MIME:

1) If served as text.html MIME text/html
Firefox 1.5.0.1 - v undefined
Opera 8.54 - v undefined
IE 6.0 - v undefined

2) If served as text.xht MIME application/xhtml+xml
Firefox 1.5.0.1 - v number
Opera 8.54 - v number
IE 6.0 - "Save As" dialog pops up with security warning

So: if someone is deally dying to see "full power of XHTML in action"
:-) they they have to serve the above nonsense as
application/xhtml+xml.

Otherwise it is treated even by XHTML-capable browsers as a regular
HTML with broken markup and trash all around the places.

But if you decide to serve your pages as application/xhtml+xml, you
have to be ready for two (at least) drawbacks:

1) you pages will not be indexed and parsed by all major search engines
including Google.

2) you pages will not be accessible neither to the current nor to the
future IE users.

If you can cope with these small obstacles then just go ahead. ;-)

Apr 13 '06 #22

On 13/04/2006 13:04, Nick Kew wrote:

Michael Winter wrote:
I meant what I wrote. An XHTML document is also an XML document, so
using an XML processor is appropriate.

Not when a document is served as text/html.

Why would I serve a document as text/html and then expect it to be
parsed by an XML processor?

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Apr 13 '06 #23

Nick Kew

Michael Winter wrote:

On 13/04/2006 13:04, Nick Kew wrote:
Michael Winter wrote:
I meant what I wrote. An XHTML document is also an XML document, so
using an XML processor is appropriate.

Not when a document is served as text/html.

Why would I serve a document as text/html and then expect it to be
parsed by an XML processor?

/me suspects he's being trolled, but bites anyway

Because that's the situation that gives rise to this thread:
the fact that <script ... /> served as text/html is parsed
by browsers as <script ...>, not <script ...></script>.

--
Nick Kew

Apr 13 '06 #24

On 13/04/2006 18:46, Nick Kew wrote:

Michael Winter wrote:
[snip]

Why would I serve a document as text/html and then expect it to be
parsed by an XML processor?

/me suspects he's being trolled, but bites anyway

No, but it was a rhetorical question. My apologies if you thought otherwise.

I wouldn't serve an XHTML document as HTML.
Because that's the situation that gives rise to this thread:
the fact that <script ... /> served as text/html is parsed
by browsers as <script ...>, not <script ...></script>.

Understood. However, ten posts ago (starting with
<p7************@ophelia.g5n.co.uk>), the discussion changed, at least as
I see it, to one of strictly XHTML.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Apr 13 '06 #25

On 13/04/2006 16:59, VK wrote:

Michael Winter wrote:
[1] An exception, and perhaps a significant one, is when viewed
by people that don't understand XML and, more importantly,
the issues surrounding XHTML on the Web. It would seem that
you, VK, fall into this category.
A dead man cannot have a headache; a dead technology cannot have
*current* issues.

XHTML is dead? Hardly. However, there is generally little point in
serving it to user agents, at the moment.

[snip]
This is (I presume) your beloved XHTML generated by Amaya:
What's Amaya got to do with anything?

[snip]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[snip]
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-1" />
XHTML 1.1 should not be served as HTML. The Appendix C compatibility
guidelines apply only to XHTML 1.0.

[snip]
<script type="text/javascript" src="test.js" />
The inclusion of the meta element above wouldn't happen to a goof, would it?

[snip]
1) If served as text.html MIME text/html
Firefox 1.5.0.1 - v undefined
Opera 8.54 - v undefined
IE 6.0 - v undefined
Not surprising.
2) If served as text.xht MIME application/xhtml+xml
Firefox 1.5.0.1 - v number
Opera 8.54 - v number
IE 6.0 - "Save As" dialog pops up with security warning
Not surprising.
So: if someone is deally dying to see "full power of XHTML in action"
:-) they they have to serve the above nonsense as
application/xhtml+xml.
It's taken you all of this time to come to that conclusion?
Otherwise it is treated even by XHTML-capable browsers as a regular
HTML with broken markup and trash all around the places.
As it should be.
But if you decide to serve your pages as application/xhtml+xml, you
have to be ready for two (at least) drawbacks:

1) you pages will not be indexed and parsed by all major search engines
including Google.

2) you pages will not be accessible neither to the current nor to the
future IE users.
And again, you're stating the obvious.
If you can cope with these small obstacles then just go ahead. ;-)

Yes, it's called content negotiation. However, I don't see the point. I
have continued to say that serving HTML (written as HTML) is preferable,
and I'll continue to do so for quite a while, yet.

To make my opinion clear: XML and XHTML have their uses, but, for the
time being, not in this regard.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Apr 13 '06 #26

Michael Winter wrote:

Understood. However, ten posts ago (starting with
<p7************@ophelia.g5n.co.uk>), the discussion changed, at least as
I see it, to one of strictly XHTML.

Actually the very OP's question was about an *HTML* markup on an *HTML*
page:
<http://groups.google.com/group/comp.infosystems.www.authoring.html/tree/browse_frm/thread/6ff8329925aae8a6/f73f7d7a5ebda227?rnum=1&hl=en&_done=%2Fgroup%2Fcom p.infosystems.www.authoring.html%2Fbrowse_frm%2Fth read%2F6ff8329925aae8a6%2F32017f7edac4940d%3Fhl%3D en%26#doc_f73f7d7a5ebda227>

XHTML jumped out somewhere after the OP's question was already
answered: when everyone seems decided to find a way to make the
original markup anyhow functional.

It was a discover for me that at least one markup system (XHTML) allows
to override *inline* a tag syntax: thusly make a pared tag to be
treated as single one. I cannot say though that it was a functional
enlightment for me as I never use XHTML. Theoretically it may be
interesting to know how all this music is supposed to be arranged:
/> as denoting no-closing-tag element
/> as denoting paired-tag-treat-as-single-tag-no-content
/ / NET-enabling tag with NET tag

It seems to me that either I'm lost or someone in W3C is lost. I guess
that the first is most definitely more true, as XHTML in its Full Real
Understanding seems to take a lot of years of study and a lot of cups
of coffee - plus a specific set of mind I must be missing :-)

So, anyway: one *can* use <script> without closing tag on a valid XHTML
page served with Content-Type application/xhtml-xml. It breaks the
search engine indexing and makes the page unavailable to IE users (at
least not available in the conventional way). But if it's a question of
life or death - then here is the way.

P.S. I'm having Amaya not for theoretical discussions about XHTML, but
because I use it as a free SVG editor. But as I do not have (nor
seeking) any practical exprience with XHTML, I let Amaya to generate
demo pages - to get them valid without hassles.

Apr 13 '06 #27

VK wrote:

It seems to me that either I'm lost or someone in W3C is lost.
XHTML as text/html was a really, really bad idea in the first place.
So, anyway: one *can* use <script> without closing tag on a valid XHTML
page served with Content-Type application/xhtml-xml.

When designing XML they decided that having the start or end of an element
implied was a bad idea and got rid of optional and forbidden start/end
tags, so every element requires explicit ending.

So in XHTML <link> is forbidden, but <link></link> is fine.

And they made a shorthand syntax for empty elements making <link/>
identically equivalent to <link></link>.

Then they came up with XML and tried to make it compatible with HTML.

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

Apr 14 '06 #28

David Dorward wrote:

XHTML as text/html was a really, really bad idea in the first place.
It was an excellent *promotional* idea at that time, but having nothing
to do with technical issues; and now it is the pay time I'm affraid for
spoofing supporters for so long.

The idea was, by using the native "durty HTML tolerance" of any browser
plus some features of the leading browser, - to represent XHTML as a
common widely cross-browser accepted standard: without fighting with
browser producers for the actual standard support.

Here is my newly made YHTML standard to illustrate the used trick. I
spent less than a minute to make it up, so details are still sketchy
:-)

Any way: the required DTD is
<!DOCTYPE YHTML PUBLIC "-//VK//DTD YHTML 1.0 Strict//EN">

Single tags are denoted by slash: <br />

Paired tags currently having no content can be shorten by vertical bar:
<p |> instead of <p></p>

Withing a tag a non-parsed area is denoted by / / NET pair:
<p /no parsing/>

A sample page:

<!DOCTYPE YHTML PUBLIC "-//VK//DTD YHTML 1.0 Strict//EN">
<html>
<head>
<title>YHTML 1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body onLoad="alert(document.compatMode)">
<p>Line one<br />
Line two</p>
<p /empty paragraph/>
<p>One more paragraph</p>
</body>
</html>

As you can see this page (by using HTML durt tolerance and known IE's
box switch rules) is rendered just fine on any browser and produces the
expected layout. It also puts the browser into CSS1Compat mode. It is
absolutely, up to the last point, the same as "XHTML'ed" trash
currently served from some sites.

As you may guess nothing prevent me to publish it on say geocities.com
and announce that YHTML standard in its basic form supported by all
current UA's (and it's true). I also will add a note that current UA's
alas and unfortunately are still missing totally correct support of
*all* syntax rules.

Now proove me wrong. And the difference (if any) with the XHTML trick.
So in XHTML <link> is forbidden, but <link></link> is fine.
And they made a shorthand syntax for empty elements making <link/>
identically equivalent to <link></link>.

Amaya default page (XHTML 1.1). Pay attention to <link> and <meta>:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG
1.1//EN"
"http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>Welcome to Amaya</title>
<link href="amaya.css" rel="stylesheet" type="text/css" />
.....

- so now, they just put together two syntax: /> for single tags (like
meta or link) and /> for paired tags shortcuts id they do not have
content: <div /> instead of <div></div>.

*Semantically* (overyone loves this word ;-) it is not correct. But now
YHTML fixes this issue :-)

Apr 14 '06 #29

I'm still learning the new syntax, sorry:
instead of:
<p /empty paragraph/>
must be:
<p /empty paragraph/ |>

:-)

Apr 14 '06 #30

Richard Cornford

Nick Kew wrote:

Michael Winter wrote:
On 13/04/2006 13:04, Nick Kew wrote:
Michael Winter wrote:
I meant what I wrote. An XHTML document is also an XML
document, so using an XML processor is appropriate.

Not when a document is served as text/html.
Why would I serve a document as text/html and then expect
it to be parsed by an XML processor?

/me suspects he's being trolled, but bites anyway

Don't suspect that, if you can't have a worthwhile reasoned debate with
Michael Winter you can't have one with anyone.
Because that's the situation that gives rise to this thread:
the fact that <script ... /> served as text/html is parsed
by browsers as <script ...>, not <script ...></script>.
The question that seems pivotal here is whether a document served as
text/html should be regarded as XHTML (or, under what circumstances a
document served as text/html may be regard as not being an HTML
document).

When Toby Inkster said "assuming XHTML" the determination of what
actually is XHTML became critical to determining the veracity of that
statement.

The nature of some documents can be unambiguously determined:-

A document wittier as XHTML, validated as XHTML (of some version),
served as content type application/xhtml+xml, interpreted by the
receiving browser as XHTML, and (if supported) having an XHTML DOM
created by the browser to be scripted for that document, is
unambiguously an XHTML document.

(Michael and I share a particular interest in DOM scripting, but as the
thread itself is centred around script elements that final (optional)
aspect of document interpretation seems to be particularly pertinent
here.)

Similarly, a document written as HTML, validated as HTML (again of some
version), served as text/html, interpreted by the receiving browser as
HTML, and having an HTML DOM created for it, is unambiguously an HTML
document.

There is an awful lot (realistically, almost the entire Internet) that
doesn't satisfy either case. Pertinent among which is Appendix C XHTML
1.0 served as text/html:-

A document written as XHTML with additional regard to the constraints of
Appendix C, validated as XHTML (theoretically version 1.0, strict or
transitional), served as text/html, interpreted by the receiving browser
as HTML (albeit error-filled HTML, so "tag-soup") and for which an HTML
DOM is created to be scripted.

The implication of pointing out that because this document is served as
text/html <script ... /> will not be interpreted as <script ...</script> is that this document should be considered to be an XHTML

document. Otherwise Toby's "assuming XHTML" is not applicable to this
case. And this is the point where a divergence of interpretation comes
into play.

An individual, like myself or Michael, with an interest in the scripting
of the DOM, may regard the type of DOM created for a document as the
critical determinatior of the type of the document; that is, if the DOM
is an XHTML DOM the document must be an XHTML document. While if a DOM
is an HTML DOM the document should be considered an HTML document. This
position would regard Appendix C XTML 1.0 served as text/html as an HTML
document, albeit a formally malformed HTML document.

Another individual, primarily concerned with mark-up rather than
scripting, may regard passing validation as a particular document type
as critical in determining the type of a document. A position that would
accept Appendix C XHTML 1.0 served as text/html as an XHTML document.

My opinion (and it is an opinion, influenced by my particular interest
in the scripting of the resulting DOM) is that the author of Appendix C
XHTML 1.0 served as text/html is better off perceiving their creations
as formally malformed HTML, as that explains why <script .. /> will not
be interpreted as <script ... ></script>, rather than thinking of it as
XHTML that doesn't follow the rues of XML (as may otherwise be expected
(assuming that the document qualifies as well-formed XML)).

Ultimately, as it is the factor that decides which type of DOM is
created, as a result of how the browser will interpret the document, it
is the type of document advertised by the HTTP content-type header that
determines whether the document is XHTML or HTML. If you advertise a
document as text/html you are writing HTML and if you advertise it as
application/xhtml+xml it is XHTML that is being written. Appendix C
served as text/html is only XHTML in the mind of the author, it is HTML
to the receiving browser.

By now you have guesses that I am not a supporter of Appendix C XHTML. I
don't mind if the future of the Internet is XHTML, I just prefer that
people understand when they are writing XHTML and when they are not.

Richard.

Apr 14 '06 #31

VK wrote:

It was an excellent *promotional* idea at that time,
No, it wasn't. It has resulted in vast amounts of broken XHTML out there.
Here is my newly made YHTML standard .... As you can see this page (by using HTML durt tolerance and known IE's
box switch rules) is rendered just fine on any browser
...
Now proove me wrong
Again?

To copy and paste from the output of a browser installed on my system:

Line one Line two
empty paragraph

|>

One more paragraph

So in XHTML <link> is forbidden, but <link></link> is fine.
And they made a shorthand syntax for empty elements making <link/>
identically equivalent to <link></link>.

Amaya default page (XHTML 1.1). Pay attention to <link> and <meta>:
Err. Yes? So what?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG
1.1//EN"
"http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>Welcome to Amaya</title>
<link href="amaya.css" rel="stylesheet" type="text/css" />
.... *Semantically* (overyone loves this word ;-) it is not correct.

Semantically the meta data is complete garbage, and the title is silly. This
has nothing to do with XML empty element shorthand.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Apr 15 '06 #32

David Dorward wrote:

To copy and paste from the output of a browser installed on my system:

Line one
> Line two

empty paragraph

|>

One more paragraph

Out of pure curiosity: which browser still doesn't have a basic *HTML*
features even in the year 2006?
My "YHTML" sample renders properly (with expected 3-paragraph DOM) even
on Netscape 4.5, not talking about Firefox or IE.

<!DOCTYPE YHTML PUBLIC "-//VK//DTD YHTML 1.0 Strict//EN">
<html>
<head>
<title>YHTML 1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body onLoad="alert(document.compatMode)">
<p>Line one<br />
Line two</p>
<p /empty paragraph/ |>
<p>One more paragraph</p>
</body>
</html>

leads to:

Line one
Line two

One more paragraph

Apr 15 '06 #33

VK wrote:

Out of pure curiosity: which browser still doesn't have a basic *HTML*
features even in the year 2006?

Nope. XHTML features, not HTML features. Appendix C depends on bugs in
common browsers - as I've mentioned to you before. W3 is interpreting the
markup under the standard SGML rules for HTML.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Apr 15 '06 #34

Nick Kew wrote:

Michael Winter wrote:
I meant what I wrote. An XHTML document is also an XML document, so
using an XML processor is appropriate.

Not when a document is served as text/html.

That's arguable.

If the browser notices an XHTML doctype, then it could be justified
in using an XML parser.

(In the same way, if it noticed an HTML 3.2 doctype, it could be
justified in ignoring OPTGROUP elements, which weren't introduced
until HTML 4.0.)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Apr 15 '06 #35

Alan J. Flavell

On Sat, 15 Apr 2006, Toby Inkster wrote:

Nick Kew wrote:
Michael Winter wrote:
I meant what I wrote. An XHTML document is also an XML document, so
using an XML processor is appropriate.
Not when a document is served as text/html.

That's arguable.

If the browser notices an XHTML doctype, then it could be justified
in using an XML parser.

If the browser notices anything which doesn't conform to XHTML/1.0
Appendix C, then (according to RFC2616) it would be perfectly entitled
to tell its user that this content *is not* text/html, and the
security rules of '2616 forbid it to be processed - would you care to
download it to file, or quit?

There have been more than enough cases of vulnerabilities based on
various kinds of not-quite-HTML being interpreted too liberally by
client agents. Those who insist on trying the same thing on with an
XHTML flavour, really ought to expect to be held to higher standards,
don't you think?

And, in saying that, I'm being *liberal*, since by rights Appendix C
demands the implementation of a bug in HTML rendering agents.
Ideally, App.C would be ruled incompatible with HTML, and thus ultra
vires. OK, as a realist I know I'll have to go along with what the
W3C have published, no matter that it's an internal contradiction...
(In the same way, if it noticed an HTML 3.2 doctype, it could be
justified in ignoring OPTGROUP elements, which weren't introduced
until HTML 4.0.)

Of course, we all know that, in reality, browsers pay no attention to
the DOCTYPE in their HTML parsing considerations (paradoxically, some
of them use the HTML DOCTYPE in deciding which bugs to introduce into
their CSS, but lt's not go there today).

[Anyhow, I have a page which includes Ruby Annotation, and it sort-of
works as text/html, so I'm in no position to criticise in practice,
even if I know that in theory it's wrong.]

But any distinction between versions of HTML is meant to be fairly
covered by the text/html Content-type; whereas there was meant to be a
major shift introduced with the move to XHTML. Appendix C has been a
deplorable contribution to muddying the waters of that shift, with
consequent pollution of XHTML with all the legacy of HTML-du-jour
tag-soup from which XML-based markups were supposed to rescue us.

Not that this hasn't been said a hundred times before.

Apr 15 '06 #36

Toby Inkster wrote:

If the browser notices an XHTML doctype, then it could be justified
in using an XML parser.

(In the same way, if it noticed an HTML 3.2 doctype, it could be
justified in ignoring OPTGROUP elements, which weren't introduced
until HTML 4.0.)

Right. And if it notices HTML 4.01 Strict DTD then it ignores
<iframe>'s which is excluded from there. And of couse all naive
attempts to bypass it by using script should be ignored either: on DOM
change commands like appendChild the content is checked first and
ignored if doesn't correspond to DTD. And then happy users will just
jump on this new browser as the most attractive on the market.

Apr 15 '06 #37

Chris Morris

Toby Inkster <us**********@tobyinkster.co.uk> writes:

Nick Kew wrote:
Not when a document is served as text/html.
That's arguable.

If the browser notices an XHTML doctype, then it could be justified
in using an XML parser.

Internet Explorer is regularly criticised here for (against an RFC
MUST) ignoring server-sent content-type and substituting its own
guesswork.

Furthermore, in practice, 99%+ of XHTML doctyped pages served as
text/html are just HTML with extra /s, many of which would break if
parsed with XML well-formedness requirements. While this would
probably be a good thing for the web, it would be impractical for a
mainstream web browser to implement.
(In the same way, if it noticed an HTML 3.2 doctype, it could be
justified in ignoring OPTGROUP elements, which weren't introduced
until HTML 4.0.)

That's slightly different - both are text/html content (and yes, I
think that would be justified).

--
Chris

Apr 15 '06 #38

Henri Sivonen

In article <m2************@ophelia.g5n.co.uk>,
Toby Inkster <us**********@tobyinkster.co.uk> wrote:

If the browser notices an XHTML doctype, then it could be justified
in using an XML parser.

Even the WG that came up with the infamous Appendix C disagrees.

http://lists.w3.org/Archives/Public/...0Sep/0024.html

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

Apr 15 '06 #39

Chris Morris wrote:

Toby Inkster writes:
Nick Kew wrote:
Not when a document is served as text/html.

If the browser notices an XHTML doctype, then it could be justified
in using an XML parser.

Internet Explorer is regularly criticised here for (against an RFC
MUST) ignoring server-sent content-type and substituting its own
guesswork.

But in the case of a document served as text/html -- and given that HTML
is SGML-based -- if the DOCTYPE is unrecognised, a browser would be
justified in downloading the DTD, parsing it, and thus realising that a
construct like <script ... /> is valid.

(Not that I'm suggesting that this is what Internet Explorer -- or indeed
any other browser -- does.)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Apr 15 '06 #40

Andy Dingley

David Dorward wrote:

Appendix C depends on bugs in common browsers

What are they? As far as I know it's only depending on _one_ bug
(SHORTTAG not being implemented) and that only relevant for the empty
elements.

In the general world of cruft, I'd want a lot more brokenness before I
started to throw a whole protocol out on the basis of it.

Apr 18 '06 #41