By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,276 Members | 2,063 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,276 IT Pros & Developers. It's quick & easy.

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

P: n/a
W3C HTML validator passes this:

....
<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? I know browsers
accept this, but that's not the question. Is it valid?

Apr 8 '06 #1
Share this Question
Share on Google+
44 Replies


P: n/a
rh*******@gmail.com writes:
W3C HTML validator passes this:
Here's your SCRIPT element type start tag:
<script type="text/javascript" src="foo.js">
Here's some arbitrary CDATA content:
<script type="text/javascript">
...script in here...
Here's your SCRIPT element type end tag:
</script>
Next time, enable 'view parse tree' (or whatever it is called, I can't
be bothered to have a look).
But as far as I can tell, the first script tag requires a </script>
close tag.
Yes. Well, end tag.
Is the close tag required for valid markup?
Yes.
I know browsers
accept this,
Ah. I don't, I have too many of them to make generalised statements
about their treatment of generalized markup.
but that's not the question. Is it valid?


Yes.
(who cares?)
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Apr 8 '06 #2

P: n/a
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

P: n/a
VK

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

P: n/a
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

P: n/a
VK

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

P: n/a
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

P: n/a
VK

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

P: n/a
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

P: n/a
VK
> <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

P: n/a
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

P: n/a
VK

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

P: n/a
"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

P: n/a
VK
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

P: n/a
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

P: n/a
:) 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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a

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

P: n/a
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

P: n/a
VK
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
VK

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

P: n/a
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

P: n/a
VK

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

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

:-)

Apr 14 '06 #30

P: n/a
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

P: n/a
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

P: n/a
VK

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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
VK
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
Andy Dingley wrote:
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.
OK, one bug. The whole thing is very sloppily written anyway.
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.


No need to throw anything out. XHTML as text/html is silly at best, so just
transform to HTML 4.01 first.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Apr 18 '06 #42

P: n/a
On Tue, 18 Apr 2006, Andy Dingley wrote:
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.


Please be explicit here. By "protocol" do you mean XML-based markups,
properly so called; or do you mean the broken dialect of HTML(sic)
which is described in XHTML/1.0 Appendix C?

If it's the former, then I didn't see any real suggestion that it
ought the be "thrown out", although it still seems premature to serve
it out in a general web context.

If it's the latter, I'd hardly call it a "whole protocol"; as you well
enough know, the only dialect of XHTML that's approved to be served
out as broken text/html is XHTML/1.0 Appendix C. Since XHTML/1.0 is
*designed to be* functionally equivalent to genuine HTML/4.01 - just
that it comes with a few extra restrictions and gotchas - it seems to
me, at least, that the logical thing to do is to continue to serve out
good HTML/4.01, as long as one is serving it as text/html; until the
web is good and ready to use some real XML-based markups, to do things
which HTML4 is unable to do.

What you use in the way of internal process is entirely your own
business. It can perfectly well be XML-based if you wish. Or
something else. As long as the seams don't show, it's none of the
web's concern what you use as internal process: it's the final product
that counts. I'm just suggesting that it should emit HTML/4.01 to the
actual real live web, for the time being.

That's for the general web context, anyway.
Apr 18 '06 #43

P: n/a

Alan J. Flavell wrote:
On Tue, 18 Apr 2006, Andy Dingley wrote:
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.


Please be explicit here.


OK then - David Dorward (representing the anti-XHTML camp, not any
personal bias) was scare-mongering yet again by claiming that XHTML,
"depends on bugs in common browsers". The unstated implication being
that XHTML doesn't work and can't be used on the web.

- This is untrue. It's one bug (AFAIK) and it's truly trivial.
Claiming any more really is scare-mongering without basis.

- XHTML Appendix C works fine. For practical definitions of "fine", as
are rarely achieved by any other live web page frrom the major
websites.
The web lives in a swamp of broken sites. An XH/C site that's even
moderately competent comfortably exceeds the standards of almost all
large sites from major public bodies. Yes, of course your theoretical
points are just, but _in_practice_ they merely need to be observed and
worked with, they're not a basis to abandon using XH/C for serving to
everything on the web, right now.

I'm not advocating this - but if you want to do XH/C today, you _can_
do. And it's no more broken, unworkable or browser hostile than
anything pumped out by FP, Word or even most DW. It's the developer's
choice - either way works.

Apr 19 '06 #44

P: n/a
On Wed, 19 Apr 2006, Andy Dingley wrote:
OK then - David Dorward (representing the anti-XHTML camp, not any
personal bias) was scare-mongering yet again by claiming that XHTML,
"depends on bugs in common browsers".
It's a factual statement that Appendix C depends on one particular bug
(unless one refuses to believe the W3C's assertion that HTML is an
application of SGML, and that its DTD doesn't mean what it says).
The unstated implication being that XHTML doesn't work and can't be
used on the web.
I didn't read that implication into it. This is all about advice and
good-practice, rather than about what may or may not give an
impression of "working" in practice.

We'd need to deal separately with the cases that really do not work.
And, for the most part IME, those are cases where the would-be authors
of XHTML don't understand XHTML, and continue to write a sort of bad
HTML which they suppose to be XHTML. For the most part, that stuff
will work (for the usual modest values of the term "work"), *as long
as* it's slurped as HTML: it's only when it's treated as genuine XHTML
that it will dismally fail. I cite, for example, the continuing habit
of authors writing so-called XHTML and putting inline <script> and
<style> elements with their content wrapped in <!-- ... -->
- XHTML Appendix C works fine. For practical definitions of "fine",
as are rarely achieved by any other live web page frrom the major
websites.
I'm not very happy with the principle of "most everything else is crap
anyway, so a bit more crap does no harm". I set myself higher aims,
and if anyone asks my advice then I'm inevitably going to at least
start by advising them the same. I can be a practical fellow when
push comes to shove, but at least I prefer to know what's right, and
to aim for it as best I can, even if practicalities sometimes
supervene.
The web lives in a swamp of broken sites. An XH/C site that's even
moderately competent comfortably exceeds the standards of almost all
large sites from major public bodies.


See above.

ttfn
Apr 19 '06 #45

This discussion thread is closed

Replies have been disabled for this discussion.