Always, always follow the non-normative Appendix C when sending XHTML as text/html. Doing otherwise creates problems. And you do not want to blame Internet Explorer for not supporting something it does not even support.
(I am well aware that my weblog does not follow Appendix C strictly.)
Interesting stuff, personally I’ve never been tempted to use: <script /> in that form.
Related:
>> Only XHTML documents that are compatible with legacy tag soup (as >> defined by XHTML 1.0 Appendix C) may be sent as text/html. > > That appendix is informative so I don't need to follow it XHTML1.0: # 5. Compatibility Issues # # This section is normative. [...] # # XHTML Documents which follow the guidelines set forth in Appendix C, # "HTML Compatibility Guidelines" may be labeled with the Internet Media # Type "text/html" [RFC2854], as they are compatible with most HTML # browsers. -- http://www.w3.org/TR/xhtml1/#media RFC2854, section 2, refers to the above: # In addition, [XHTML1] defines a profile of use of XHTML which is # compatible with HTML 4.01 and which may also be labeled as text/html. -- http://www.ietf.org/rfc/rfc2854 In any case, if there was any ambiguity about the thinking of the HTML working group, the XHTML Media Types note published to clarify these issues should remove any doubts (section 3.1): # In particular, 'text/html' is NOT suitable for XHTML Family document # types that adds elements and attributes from foreign namespaces -- http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#text-html
<script /> is equal to <script> when served as text/html, as far as IE, Opera and Firefox are concerned (they ignore the slash). Firefox seems to close the script element directly if there's no closing tag.
Another thing to test is <textarea />... :)
Hepp. I like it. ;-)
Another thing to test is <textarea />... :)
Nope, same problem. I remember needing some fairly vicious hacks when I was generating XHTML with an XSLT, because the XSLT processor insisted on converting it to the short form.
Of course, this was back in ~1999, so it's possible things have changed since then, but I doubt it.
zcorpan is correct. If you want script elements to behave in MSIE without blowing your mind, you should follow these rules:
<script ... />. Always use the long form <script ... ></script>. type attribute. Yes, sometimes it'll work without it. However skipping it ruins validation and could break future browsers. Just DTRT. Here's an example of correct usage:
<script type="text/javascript" src="http://www.example.com/script.js" ></script>I learned these tips the hard way.
P.S. Anne, your IRI box doesn't accept my well-formed URI, "http://www.slashdot.org/~quantum%20jim/journal" correctly. In fact, it strips the %25 sign ;) off of it. I consider you an authority on identifiers, so please fix it!
Jim Dabell, XSLT 2.0 has an XHTML specific output method. See xsl:output in the current XSLT 2.0 WD. It complies with Appandix C.
Jimmy, I am sorry about that. That will be fixed when I drop WordPress as weblog system. The right thing by the way would be using HTML.
One option is taking SAX output from the XSLT processor and using an HTML serializer.
Appendix C is always a good read :).
~Grauw
This one bit me when setting xsl:output to method="xhtml" with Xalan. It insists on making empty elements self-closing even when they're not marked as EMPTY in the DTD. I ended up putting in a single ';' (nice and simple JS program there) between the script tags.
<script />is equal to<script>when served astext/html, as far as IE, Opera and Firefox are concerned (they ignore the slash).
According to the HTML standard, it should be equivalent to <script>> (note the extra greater-than at the end). The slash terminates the tag, since HTML sets SHORTTAG YES.
Since anything served as text/html must be interpreted as HTML, IE actually gets this right. The closing tag is not optional for the SCRIPT element type.
According to the HTML standard, it should be equivalent to
<script>>(note the extra greater-than at the end). The slash terminates the tag, since HTML setsSHORTTAG YES.
I know, but none of the browsers I listed support SHORTTAG.
Since anything served as
text/htmlmust be interpreted as HTML, IE actually gets this right. The closing tag is not optional for theSCRIPTelement type.
Does HTML define how UAs should handle invalid code (in this case, a missing SCRIPT closing tag)? If not, niether is wrong, I guess.
Btw, what should happen if we set SHORTTAG NO in an SGML declaration, if the UA supports SHORTTAG?
Another thing to test is <textarea />... :)
Nope, same problem.
Yes, but this time all browsers (that I have tested) will put the rest of the document inside the TEXTAREA, i.e., they won't close the element until the document has finished. :)
And how is that different from SCRIPT? (Except for parsers that have implemented a workaround for unclosed SCRIPT elements.)
It looks funnier. :)