So, hypothetically speaking, I have a user, some guy on the internet, who goes to my website and requests mysite.com/resource; it points to a PHP script that follows this outline:
1) Tests whether or not the user agent can understand application/xhtml+xml.
2) uses XML functions to load resource.xml.
3) If the user agent can do as asked in #1, outputs a valid XHTML document (including MIME type, trailing slashes for empty tags, CDATA blocks, and so on).
4) If the user agent cannot do as asked in #1, outputs a strictly valid HTML document, where trailing slashes in empty tags are interpreted as minor errors on the author's part, but shorttags are permissible if used correctly.
So anyway, I could do this using a bunch of custom functions, but I was wondering if there were any shortcuts or library functions that would allow me to more quickly output strictly valid text. Or possibly something like server-side parsing of XSLT?
Why would you want to output strictly valid HTML in the first place? Any browser is going to treat it with great suspicion anyway, and won't care if it's strictly valid or not, and serving up valid XHTML as text/html works perfectly, except for giving obsessive nerds a headache.
>>2
When you say "works perfectly," are you referring to the part where the document is parsed in Quirks Mode and never sees the browser's XML engine?
And IE7 obeys the W3C's box model when in Standards Compliance Mode, but uses IE6's buggy box model when in Quirks Mode.
Obviously, since it would make no sense to send HTML through an XML engine. I think you missed the point of the discussion.
I think you missed the point of content negotiation.
I think >>1 is getting too carried away with being pedantic about web standards. SGML parsers are completely competent at parsing XHTML data, there is no reason to waste your time with this excess of content negotiation. Just do your page up in valid XHTML, and send the correct MIME type if the browser can accept it. Problem solved.
<body>
<script src="some_file.js" type="text/javascript"/>
<p>works in XHTML, but not in HTML!</p>
</body>>>7
That's all fine and dandy, but the only people I've seen use <script> tags inside the body and not head are people INJECTING MALICIOUS CODE. So, by all means, go use your XHTML which does that.
I'm not sure about UA MIME type detection, but this might be what you're looking for as far as XSLT goes:
He's referring to the use of 'script' as an empty element, you can put the tags inside the body in HTML as well, Google and some WYSIWYG editors do it.
>>9
unless you want the body to be there when the script runs...
i've had problems with the body element not existing yet when i try to do document.body.onload=init; in the head instead of the body.
>>7
sometimes you want a script to run as soon as the dom tree loads, and not have it wait around for all the images/flash/ads/etc to finish loading too (which might be slow or whatever). or you want to do something more complex than can easily be achieved in an onload event. solution? chuck it in a script tag between the closing body and html tags.
Google Analytics requires you to put the urchin tracker include inside the body element for the script to function completely.
ITT we respond to trolls who got bored and left 3 months ago
>>16
Best post in this thread.
You disappoint me code/
You disappoint me, sage