lolz.. i think perhaps it was only that i was searching google from a different perspective; since i've personally never used object tags for anything but java/flash/etc in html pages, where you do occasionally need to provide more information in the tag definition.
anyway, the page where i found that code was on the first result for a google search of:
object html inside html
any search like 'object embed html' or 'embed html with object' gives pages that compare the embed tag and object tag, of which there are many.
google respects order of terms, to a higher degree than people sometimes think... i find, the most fruitful complex search queries start with the most important word, then continue with some kind of question, without the words 'how do i', and, in this case, without any words that might pollute the results with uneccessary information. (i.e. embed)
just a tip ^_-
hmm, i suppose you'd need to know that (for the most part) cgi scripts reply in the type "text/html" to know that that was what you needed to search for in the first place; but yes, regardless of the way a page is prepared at server, the request for [data] in object tag expects a reply of type [type] not a file on the server of type [type]; any time you see HTML in the browser window after requesting a cgi-script's data, the script sent data of the type 'text/html' (or 'application/xml+xhtml' =P) so:
<object type="text/html" data="http://whatever.tld/myscript.cgi"/>
Object (checks to see if it can handle the [type] of [data])*, then requests
http://whatever.tld/myscript.cgi; myscript.cgi replies with a response typed as [type], and object shows that data using the handler for [type]. It doesn't really matter
how the server made that response, as long as it did, and as long as it's the correct type, and is headered as such.
* i assume it does this first, it wouldn't make sense to request data knowing it's unhandlalbe - if i wrote the browser, i would certainly do this check first.