Povert

It's Pronounced "Pah-vert." You povert.

Archive for the ‘WWW’ Category

Dynamic Resizing of Cross-Domain Iframes

Monday, May 19th, 2008

If you’ve ever wanted to have an iframe resize itself based on its (cross-domain) contents, you may have run into some problems.

I had to tackle this somewhat recently. The solution is silly, but it works.

The problem is that an iframe can’t communicate with its parent if they’re on different domains. For example, let’s say I put an iframe here on povert.com. The iframe could be pointing to, say, flappingcrane.com. Povert.com can’t access any useful information about the iframe, and vise-versa.

The solution is to have the iframed content (in this case flappingcrane.com) iframe something else from the original domain. So you could set up a file on povert.com called yaygo.html. Then flappingcrane.com iframes that, with a GET query. That GET query should contain any information you want to communicate to the parent (povert.com). Since yaygo.html is on povert.com, it can refer to povert.com with parent (though, since they’re different domains, it can’t do anything useful) and to flappingcrane.com with parent.parent. Because they’re on the same domain (even with the intermediate flappingcrane.com iframe), it can do something useful — like pass values from the GET query to a function:


parent.parent.setFunProps(iframeid, width, height, tacoflavor);

setFunProps() can then take those values and do what it wants with it (resize the iframe, whatever).

Another tidbit. If you give a name attribute to an iframe, that iframe’s contents can access the name with window.name. You can’t access window.id though, unfortunately. Either are handy for identifying to the parent document what iframe is requesting a resize, though there are other crappier ways to do it (passing its own url to match against iframe src, for example).

UPDATE: As I mention in my comment below, you can see an example of this at http://povert.com/fun/iframe/.

UPDATE (Oct 28, 2009): Looks like it doesn’t work in any version of IE now. It’s possible that Microsoft saw this as a security hole and fixed it.

Strudel, new Feed, S3

Wednesday, April 16th, 2008

“Toaster Strudel” is available at Flapping Crane’s music section. Good stuff. I use part of it for one of my ringtones.

Also, I’ve revamped the Flapping Crane RSS feed. This sucker now has MP4 videos that are good for watching on TV (with Apple TV or probably XBox 360) or on an iPhone. Haven’t tested it on other iPods. May not work on them.

Finally, I’m in the process of compressing new versions of all our old videos and uploading them to Amazon’s S3. This should allow for faster downloads.

I haven’t flipped the switch on S3 yet, and probably won’t for a while. I want to get as many vids on there as possible.

Worst HTML/CSS/JS

Friday, November 9th, 2007

I’ve been working on what I believe may be some of the worst and most offensive (but still “working”) use of HTML, CSS and Javascript possible. You know, for fun.

Here’s what I’ve got so far (line breaks added for *cough* legibility):


<SCRIPT LANGUAGE=JSCRIPT>
eval("document.write('<!--[IF LT IE 9]>
<STYLE>*LI#BLUENAV{
_ZOOM:1!IMPORTANT*BACKGROUND-COLOR:
PAPAYAWHIP!IMPORTANT<![ENDIF]--></STYLE>
<BASEFONT SIZE=30 COLOR=YELLOWGREEN FACE=GEORGIA>
<TABLE CELLPADDING=10 CELLSPACING=10 BORDER=20>
<TD><U><TABLE><S><LI ID=BLUENAV>
<FONT FACE=VERDANA STYLE=FONT-SIZE:LARGE>
<B><CENTER><MARQUEE BGCOLOR=MISTYROSE WIDTH=50%>
Tacos</MARQUEE><BR>
<IMG ALIGN=LEFT SRC=SPACER.GIF WIDTH=200 HEIGHT=20>')")
</SCRIPT><NOSCRIPT><A HREF=HTTP://MICROSOFT.COM>
<FONT FACE=COURIER COLOR=SADDLEBROWN>
YOU&NBSP;NEED&NBSP;INTERNET&NBSP;EXPLORER&NBSP;TO&NBSP;
EXPERIENCE&NBSP;THIS&NBSP;WEB&NBSP;SITE&NBSP;
AS&NBSP;INTENDED

To see it in action, click here. You’ll need IE, of course. It wouldn’t be as crappy otherwise.

Key points:

  • <script> has a LANGUAGE attribute. And it’s JSCRIPT, for fun.
  • Elements are closed only when absolutely necessary
  • No quotes around element attributes
  • Nearly everything in uppercase
  • eval()
  • document.write()
  • Needlessly nested (and otherwise unnecessary) tables
  • Not a <tr> to be found.
  • Insane colors: PapayaWhip, MistyRose, YellowGreen and SaddleBrown
  • <basefont> and <font>
  • <li> without a <ul> or <ol>
  • <noscript> — some people may argue with me about this one, but it’s certainly not an indicator of whether the viewer is using IE
  • Pointless use of &nbsp;
  • <marquee>
  • <u>, <s>, <b> and <center>
  • IE conditional comments (useful, but crappy nonetheless)
  • * and _ CSS hacks
  • !important
  • Improperly formatted (but working) css
  • Opening <style> tag inside conditional comment, closing tag outside.
  • No DOCTYPE
  • No attempt at an even reasonably structured HTML document — no <html>, no <head>, no <body>, etc.
  • Oh, and SPACER.GIF doesn’t exist, of course. That’s a double-whammy, actually. Spacer images blow.

IE 6 Can Get Punched by a Goat

Monday, January 29th, 2007

Ran into an interesting javascript problem today.

One of our programmers wrote a script which grabbed some external data and formatted it into a table. Straightforward stuff. He opted for the W3C DOM method. I advised against it, simply because that route is a pain when it comes to IE 6 in my experience.

For those of you who don’t know, it’s kind of similar to writing normal HTML, except it’s done dynamically. So you typically start by creating a node:

yaytable = document.createElement("table");

Even if you don’t know javascript but you know some HTML you can pick it up. You then create the row:

yayrow = document.createElement("tr");

and the cell for the data that goes in one of the columns:

yaycell = document.createElement("td");

Then you create the node that contains whatever data you want to put in there:

yaydata = document.createTextNode("Whee!");

Then you can slap them all together:

yaycell.appendChild(yaydata);
yayrow.appendChild(yaycell);
yaytable.appendChild(yayrow);
document.body.appendChild(yaytable);

So far, so good. In firefox, this results in:

<table><tr><td>Whee!</td></tr></table>

Yay, a dynamically generated table. Now, there’s an easier way to do this — one that makes a lot of us web guys a little ill:

document.body.innerHTML += "<table><tr><td>Whee!</td></tr></table>";

A lot quicker. But it’s not part of the standard, and it comes with its own drawbacks.

Anyway, like I said, he used the first method. It’s a neat way to do it. You can, for example, do something like — yayrow.style.backgroundColor = ‘red’; — or something later on. Using the innerHTML way, you really just have to rewrite the string, which is inconvenient.

A quick note — I’m sure that this simple example would probably work in IE 6. However, in his case, it did not work. I’m really not sure why. You could look at the dom in IE and see the table in there, along with all of the data. You could pull up a javascript console and output the contents of (for example) yaytable.innerHTML and you could see it. But it wasn’t visible on the page. It worked fine in Firefox, of course.

He struggled with it for a good long time. I won’t say how long. Eventually I told him that since it was a quick job, he really should go the easy route, propriety be damned. It would have taken all of 10 minutes, if that.

Still, he had spent a lot of time on it. Understandably, he wasn’t ready to scrap it.

I eventually figured out a way to do it. It’s ironic and stupid. Basically, tack something like this on to the end of the previous code:

crap = yaytable.innerHTML;
yaytable.innerHTML = crap;

And, I shit you not, it worked. I think I know why, but it still doesn’t explain why there was a problem in the first place.

Anyway, I guess the point in all this is that yeah, there is a “right” way to do things. And it should work. And people who haven’t spent nearly every day for years struggling to get IE 6 to do even the simplest things scoff when you tell them to not expect reasonable behavior from it. I get that from people all the time. Luckily, sometime after I turned 26 or so, I stopped caring when people thought I was an idiot. If you prove me wrong, yay. Makes my life easier.

When you’re creating something for a client, 99% of the time they don’t care how you do it. They just want it done. And sometimes it’s not worth the effort to try to do it the right way.

Not that there isn’t value in trying, of course. There is. I plan on figuring this out, in fact. It’s probably something very simple that I’m overlooking, even though several people looked at this problem. It could be due to a lot of factors. I don’t know.

I ran into a similar problem a while back with flapping crane. Check out line 149 of scripts.js sometime for a laugh (hint — use View Source). It’s in the loadSkit() function.

Update: Yay, I think I found a fix. IE seems to require a TBODY tag. Quick example:

yaytable = document.createElement("table");
yaytbody = document.createElement("tbody");
yayrow = document.createElement("tr");
yaycell = document.createElement("td");
yaydata = document.createTextNode("Whee!");
yaycell.appendChild(yaydata);
yayrow.appendChild(yaycell);
yaytbody.appendChild(yayrow);
yaytable.appendChild(yaytbody);
document.body.appendChild(yaytable);

From the spec:

The TBODY start tag is always required except when the table contains only one table body and no table head or foot sections. The TBODY end tag may always be safely omitted.

Am I reading that wrong? More info.

Povert is proudly powered by WordPress
Entries (RSS) and Comments (RSS).