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

[Richard Cornford]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

Nick Kew wrote:[color=blue]
> Michael Winter wrote:[color=green]
>> On 13/04/2006 13:04, Nick Kew wrote:[color=darkred]
>>> 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.[/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[/color]

Don't suspect that, if you can't have a worthwhile reasoned debate with
Michael Winter you can't have one with anyone.
[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]

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 ...[color=blue]
></script> is that this document should be considered to be an XHTML[/color]
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.

[David Dorward]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

VK wrote:
[color=blue]
> It was an excellent *promotional* idea at that time,[/color]

No, it wasn't. It has resulted in vast amounts of broken XHTML out there.
[color=blue]
> Here is my newly made YHTML standard[/color]
....[color=blue]
> 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[/color]

Again?

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

Line one[color=blue]
> Line two[/color]

empty paragraph

|>

One more paragraph
[color=blue][color=green]
>> 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][/color]
[color=blue]
> Amaya default page (XHTML 1.1). Pay attention to <link> and <meta>:[/color]

Err. Yes? So what?
[color=blue]
> <!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" />
> ....[/color]
[color=blue]
> *Semantically* (overyone loves this word ;-) it is not correct.[/color]

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

[VK]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;


David Dorward wrote:[color=blue]
> To copy and paste from the output of a browser installed on my system:
>
> Line one[color=green]
> > Line two[/color]
>
> empty paragraph
>
> |>
>
> One more paragraph[/color]

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(d ocument.compatM ode)">
<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

[David Dorward]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

VK wrote:
[color=blue]
> Out of pure curiosity: which browser still doesn't have a basic *HTML*
> features even in the year 2006?[/color]

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

[Toby Inkster]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

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]

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

[Alan J. Flavell]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

On Sat, 15 Apr 2006, Toby Inkster wrote:
[color=blue]
> 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]
>
> That's arguable.
>
> If the browser notices an XHTML doctype, then it could be justified
> in using an XML parser.[/color]

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

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.

[VK]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

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

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.

[Chris Morris]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

Toby Inkster <usenet200604@t obyinkster.co.u k> writes:[color=blue]
> Nick Kew wrote:[color=green]
> > Not when a document is served as text/html.[/color]
>
> That's arguable.
>
> If the browser notices an XHTML doctype, then it could be justified
> in using an XML parser.[/color]

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

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

--
Chris

[Henri Sivonen]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

In article <m2n7h3-mpq.ln1@ophelia .g5n.co.uk>,
Toby Inkster <usenet200604@t obyinkster.co.u k> wrote:
[color=blue]
> If the browser notices an XHTML doctype, then it could be justified
> in using an XML parser.[/color]

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

http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html

--
Henri Sivonen
hsivonen@iki.fi

http://hsivonen.iki.fi/

Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Toby Inkster]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

Chris Morris wrote:[color=blue]
> Toby Inkster writes:[color=green]
>> Nick Kew wrote:
>>[color=darkred]
>>> Not when a document is served as text/html.[/color]
>>
>> If the browser notices an XHTML doctype, then it could be justified
>> in using an XML parser.[/color]
>
> Internet Explorer is regularly criticised here for (against an RFC
> MUST) ignoring server-sent content-type and substituting its own
> guesswork.[/color]

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

[Andy Dingley]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

David Dorward wrote:
[color=blue]
> Appendix C depends on bugs in common browsers[/color]

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.

[David Dorward]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

Andy Dingley wrote:[color=blue]
> David Dorward wrote:[color=green]
>> Appendix C depends on bugs in common browsers[/color][/color]
[color=blue]
> 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.[/color]

OK, one bug. The whole thing is very sloppily written anyway.
[color=blue]
> 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.[/color]

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

[Alan J. Flavell]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

On Tue, 18 Apr 2006, Andy Dingley wrote:
[color=blue]
> 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.[/color]

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.

[Andy Dingley]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;


Alan J. Flavell wrote:[color=blue]
> On Tue, 18 Apr 2006, Andy Dingley wrote:
>[color=green]
> > 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.[/color]
>
> Please be explicit here.[/color]

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.

[Alan J. Flavell]

Re: Does &lt;script src=foo&gt; require an end tag &lt;/script&gt;

On Wed, 19 Apr 2006, Andy Dingley wrote:
[color=blue]
> 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".[/color]

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).
[color=blue]
> The unstated implication being that XHTML doesn't work and can't be
> used on the web.[/color]

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 <!-- ... -->
[color=blue]
> - XHTML Appendix C works fine. For practical definitions of "fine",
> as are rarely achieved by any other live web page frrom the major
> websites.[/color]

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

See above.

ttfn