Kongregate.com code wtf
-
I was poking around the page source for one of the games on kongregate.com, and found this buried deep within the page:
//<![CDATA[
function write_to_document( text ){
document.write(text);
}
//]]>Beats me why they'd want to wrap a core function of the language, but hey, whatever floats their boat.
The games themselves are hidden within iframes nested at least 3 deep (I stopped counting after the 3rd), and on the way down, there were more gems, such as:
BrowserDetect.init();
function getBrowserName(){
return( BrowserDetect.browser );
}and yet further on
//<![CDATA[
$('deferred_-475814673').undeferDestination=$('placeholder_-475814673');Ok, so this one's not too horrible (appears to be using the prototype library, or possibly mootools), but I'm wondering at the wisdom of using negative numbers for auto-generated dom IDs. What is it with everyone's fixation with using signed numbers for such things?
-
I think both of them are for debug purposes. This way they can force the page to believe that it's running on a specified browser. Or write_to_document() may do some other tasks too in the debug version.
-
@DrJokepu said:
I think both of them are for debug purposes.
Maybe, but if it's debug code, why's it getting spit out in what's a presumably production page? If it's being dynamically generated, then why suppress the actual debugging bits of the code, but still spit out their "override"? It'd be trivial to do some fancy magic in whatever lang they're using to generate the page to spit out something like
$debugOutput = ($debug == true) ? 'write_to_document' : 'document.write';
and then sprinkle
<script><?php= $debugOutput ?>('yohoho')</script>
and the like where needed.
-
The write_to_document function is a workaround for IE/ActiveX to get around the "Click here to activate" nonsense. This little snippet was actually a document on MSDN, but due to their reorganization, and my drunkenness, I can't seem to find it.
-
As a very minor side-WTF, they've got a function that does document.write(), which only works in HTML and does [i]nothing[/i] in XHTML/XML, enclosed within a CDATA block, which only does anything when used in XHTML/XML and is meaningless in HTML. Identity crisis?
-
@MindChild said:
The write_to_document function is a workaround for IE/ActiveX to get around the "Click here to activate" nonsense.
Actually, no. You can use document.write to spit out the embed/object tags for Flash just fine. The lawsuit was about plugins being automatically loaded via html as spit out by a server. Any content (i.e.: html) generated client-side (document.write, dom magic, etc...) wasn't covered. There's no reason to wrap doc.write for this, because doc.write is a client-side function and therefore not covered by the patent.
MSDN might as well stand for "Microsoft Documents? Not!" for all the use their search engine is.
-
@Quietust said:
Identity crisis?
Or blind copy-pasta. "Wow, I saw it mentioned in a comment on a forum somewhere, so it must be true!" If it works one way, surely it'll work another, so might as well use both methods.
-
Regardless what you think the situation is, the document.write must be in a script external to the page calling it. Rather than insist you know better, try it. You obviously will be suprised at what you see.
-
@MindChild said:
Regardless what you think the situation is, the document.write must be in a script external to the page calling it. Rather than insist you know better, try it. You obviously will be suprised at what you see.
Found the page: http://msdn.microsoft.com/en-us/library/ms537508(VS.85).aspx
To quote:
Loading Interactive Controls Externally
To create Web pages that load interactive controls that respond immediately to user input, use Microsoft JScript to load controls from external script files. You cannot write script elements inline with the main HTML page to load your control externally. If the script is written inline programmatically, for example with the writeln function, the loaded control will behave as if it was loaded by the HTML document itself and will require activation
-
@MindChild said:
Regardless what you think the situation is, the document.write must be in a script external to the page calling it. Rather than insist you know better, try it. You obviously will be suprised at what you see.
Did I say it didn't have to be in an external script? No, I didn't. Maybe I could've been more explicit in that sense, but my point remains: As long as the code that generates the embed/object tags is executed client-side, it's not covered by the patent. The write_to_document wrapper is utterly useless for this purpose, which WAS my main argument.
