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

**rhythmace@gmail.com** · Apr 13 '06, 02:15 AM

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

:) 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:[color=blue]
> rhythmace@gmail .com wrote:[color=green]
> > 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.[/color]
>
> 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(t ypeof 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[/color]

**Richard Cornford** · Apr 13 '06, 07:45 AM

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

VK wrote:[color=blue]
> Steve Pugh wrote:[color=green]
>> "Fine" as in perfectly good XHTML for creating two
>> script elements?[/color][/color]

Absolutely fine.
[color=blue][color=green]
>> The fact that browsers get it wrong is no big surprise.[/color][/color]

Browsers supporting XHTML, receiving this mark-up as part of an XHTML
document (so served as an XHTML document), do not get this wrong.
[color=blue]
> "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."[/color]

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+.
[color=blue]
> Sometimes ciwas and siwah just nock me out: I feel like
> I got crazy - or everyone around me did. :-)[/color]
<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.

**David Dorward** · Apr 13 '06, 08:45 AM

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

Toby Inkster wrote:[color=blue][color=green]
> > <script type="text/javascript" src="foo.js" />[/color][/color]
[color=blue]
> That should actually be fine, assuming XHTML.[/color]

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).

**Michael Winter** · Apr 13 '06, 10:35 AM

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

On 12/04/2006 23:58, VK wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> On 12/04/2006 22:52, VK wrote:
>>[color=darkred]
>>> What do you mean by "fine"?[/color]
>>
>> 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?[/color]
>
> By XHTML processor, not XML processor (there is a difference).[/color]

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.
[color=blue]
> Yes it may slip through if a validator (or a parser) is buggy and
> doesn't use declared DTD in parsing.[/color]

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)
[color=blue]
> But the whole thread was about this block:
>
> <script type="text/javascript" src="foo.js">
> <script type="text/javascript">
> ...script in here...
> </script>[/color]

And it was established that it was bogus. That isn't in question.
[color=blue]
> or this:
> <script type="text/javascript" src="foo.js" />
> <script type="text/javascript">
> ...script in here...
> </script>[/color]

/You/ posted that and, as Toby pointed out, it's quite acceptable for XHTML.
[color=blue]
> As neither one will work by definition [...][/color]

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?
[color=blue]
> The first one is: "A syntax allowed by HTML parsing rules but
> practically useless, misleading and error prone".[/color]

No, it isn't: it's invalid. After that lengthy discussion, you still
don't understand how NET-enabled start-tags work?
[color=blue]
> The second one is: "A syntax allowed by some XHTML validators but
> practically useless, misleading and error prone".[/color]

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.

**Andy Dingley** · Apr 13 '06, 10:55 AM

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

Toby Inkster wrote:
[color=blue][color=green]
> > <script type="text/javascript" src="foo.js" />[/color][/color]
[color=blue]
> That should actually be fine, assuming XHTML.[/color]

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).

**Nick Kew** · Apr 13 '06, 01:25 PM

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

Michael Winter wrote:
[color=blue]
> I meant what I wrote. An XHTML document is also an XML document, so
> using an XML processor is appropriate.[/color]

Not when a document is served as text/html.

--
Nick Kew

VK · Apr 13 '06, 04:15 PM

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

Michael Winter wrote:[color=blue]
> [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.[/color]

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(ty peof 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. ;-)

**Michael Winter** · Apr 13 '06, 04:45 PM

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

On 13/04/2006 13:04, Nick Kew wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> I meant what I wrote. An XHTML document is also an XML document, so
>> using an XML processor is appropriate.[/color]
>
> Not when a document is served as text/html.[/color]

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.

**Nick Kew** · Apr 13 '06, 06:15 PM

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

Michael Winter wrote:[color=blue]
> On 13/04/2006 13:04, Nick Kew wrote:
>[color=green]
>> Michael Winter wrote:
>>[color=darkred]
>>> I meant what I wrote. An XHTML document is also an XML document, so
>>> using an XML processor is appropriate.[/color]
>>
>>
>> Not when a document is served as text/html.[/color]
>
>
> Why would I serve a document as text/html and then expect it to be
> parsed by an XML processor?[/color]

/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

**Michael Winter** · Apr 13 '06, 06:55 PM

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

On 13/04/2006 18:46, Nick Kew wrote:
[color=blue]
> Michael Winter wrote:[/color]

[snip]
[color=blue][color=green]
>> Why would I serve a document as text/html and then expect it to be
>> parsed by an XML processor?[/color]
>
> /me suspects he's being trolled, but bites anyway[/color]

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

I wouldn't serve an XHTML document as HTML.
[color=blue]
> 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>.[/color]

Understood. However, ten posts ago (starting with
<p710h3-bh7.ln1@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.

**Michael Winter** · Apr 13 '06, 07:05 PM

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

On 13/04/2006 16:59, VK wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>>[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.[/color]
>
> A dead man cannot have a headache; a dead technology cannot have
> *current* issues.[/color]

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

[snip]
[color=blue]
> This is (I presume) your beloved XHTML generated by Amaya:[/color]

What's Amaya got to do with anything?

[snip]
[color=blue]
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
> "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">[/color]

[snip]
[color=blue]
> <meta http-equiv="content-type" content="text/html;
> charset=iso-8859-1" />[/color]

XHTML 1.1 should not be served as HTML. The Appendix C compatibility
guidelines apply only to XHTML 1.0.

[snip]
[color=blue]
> <script type="text/javascript" src="test.js" />[/color]

The inclusion of the meta element above wouldn't happen to a goof, would it?

[snip]
[color=blue]
> 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[/color]

Not surprising.
[color=blue]
> 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[/color]

Not surprising.
[color=blue]
> 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.[/color]

It's taken you all of this time to come to that conclusion?
[color=blue]
> Otherwise it is treated even by XHTML-capable browsers as a regular
> HTML with broken markup and trash all around the places.[/color]

As it should be.
[color=blue]
> 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.[/color]

And again, you're stating the obvious.
[color=blue]
> If you can cope with these small obstacles then just go ahead. ;-)[/color]

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.

VK · Apr 13 '06, 08:35 PM

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

Michael Winter wrote:[color=blue]
> Understood. However, ten posts ago (starting with
> <p710h3-bh7.ln1@ophelia .g5n.co.uk>), the discussion changed, at least as
> I see it, to one of strictly XHTML.[/color]

Actually the very OP's question was about an *HTML* markup on an *HTML*
page:
<http://groups.google.c om/group/comp.infosystem s.www.authoring .html/tree/browse_frm/thread/6ff8329925aae8a 6/f73f7d7a5ebda22 7?rnum=1&hl=en& _done=%2Fgroup% 2Fcomp.infosyst ems.www.authori ng.html%2Fbrows e_frm%2Fthread% 2F6ff8329925aae 8a6%2F32017f7ed ac4940d%3Fhl%3D en%26#doc_f73f7 d7a5ebda227>

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.

**David Dorward** · Apr 14 '06, 07:45 AM

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

VK wrote:
[color=blue]
> It seems to me that either I'm lost or someone in W3C is lost.[/color]

XHTML as text/html was a really, really bad idea in the first place.
[color=blue]
> So, anyway: one *can* use <script> without closing tag on a valid XHTML
> page served with Content-Type application/xhtml-xml.[/color]

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

VK · Apr 14 '06, 08:45 AM

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

David Dorward wrote:[color=blue]
> XHTML as text/html was a really, really bad idea in the first place.[/color]

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(d ocument.compatM ode)">
<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.
[color=blue]
> 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>.[/color]

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>Welcom e 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 :-)

VK · Apr 14 '06, 08:55 AM

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

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

:-)

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment