W3C home > Mailing lists > Public > www-validator@w3.org > January 2011

Re: No error for improperly closed <script> tag

From: Michael(tm) Smith <mike@w3.org>
Date: Fri, 14 Jan 2011 16:29:19 +0900
To: "Schneider, Cody" <Cody.Schneider@fisglobal.com>
Cc: www-validator@w3.org
Message-ID: <20110114072918.GC18814@sideshowbarker>
"Schneider, Cody" <Cody.Schneider@fisglobal.com>, 2011-01-13 10:54 -0600:

> Wrong: <script type="text/javascript" src="script.js
> <https://cibng.ibanking-services.com/cib/CEBMainServlet/SplashPageScript
> ?FIORG=592&amp;FIFID=091901215> "/>
> Right: <script type="text/javascript" src="script.js
> <https://cibng.ibanking-services.com/cib/CEBMainServlet/SplashPageScript
> ?FIORG=592&amp;FIFID=091901215> "></script>

This is one of the reasons why you need to be very careful about taking
content that's been created with an XML toolchain, and then serving it as

The characteristic that XML as a language has of not providing a way to
distinguish between <script src="foo"/> and <script src="foo"></script>
means that you can't expect that raw output you produce from an XML
toolchain is also going to conform to text/html parsing rules. Because it
doesn't have to -- <script src="foo"/> is perfectly fine as far a XML goes.
But it's not fine as far as text/html goes.

Anyway, in cases where you want to make sure your XML-authored content
conforms to text/html parsing rules, you can manually tell the validator to
do that (overriding what you've got in your doctype). I'd recommend trying
that with either or both of these:


For this case, the error messages those will give you are:

  Error: Self-closing syntax (/>) used on a non-void HTML element. Ignoring
  the slash and treating as a start tag.

  Error: Unclosed element script.

Another way to mitigate the problems is to set up your XML toolchain so
that as its final output it serializes your content as HTML instead of
XML. E.g., for XSLT, using <xsl:output method="html"/>

That's still not going to be completely safe because the spec(s) that XML
tools follow for serializing content as HTML do not adequately cover all
cases that they should, so they can still end up producing output that will
not always work as expected when processed by browsers and other tools that
are actually designed to consume HTML and do something useful with it.


Michael[tm] Smith
Received on Friday, 14 January 2011 07:29:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:18:03 UTC