Skip to main content

On The Endless Wonders Of Internet Explorer

May be somebody will stumble upon this post and save some time for him/herself.
Apparently—it only become apparent after several hours of trial, cursing and error, as it usually goes with IE—, Internet Explorer (up to version 7) throws a runtime error, if you try to modify innerHTML of the dynamically created element under certain conditions.
The conditions, as it always go with IE, are significantly lacking consistent logic. For starters, if you assign innerHTML to the element before you insert it into a DOM tree, the error may not come up at all, but will surface later, when you try to modify it.
So far it looks like the error mostly comes up, if you change innerHTML of the block element inserted into inline element (which is not kosher in standard-compliant HTML, so it makes sense), and some nested block elements (like DIVs inside Ps—why is that considered wrong, too?—for instance).
So, if one really-really need to insert a division into a paragraph, and work it's innerHTML (like I did), one has to use span instead and set it's display property to block—that seems to trick IE into errorless mode.

I've put up a test page to illustrate all of the above.

Needless to say, Firefox and Safari handle all variations correctly no matter what.

P.S. I am mostly pissed because my Palm T|X had a severe crash this morning, and is currently stuck with a white screen of death (even the reset button doesn't work, damn it). Now I have to wait for the battery to drain and hope that it will reset itself after that.

P.P.S It did. Yay.

Popular posts from this blog

WordPress: How to add custom fonts to a twenty seventeen child theme.

Quick help to those who have tried to find some help and failed (as I have so I have to write the code myself). Assuming that you have your virgin child theme configured and activated: here is a function which goes into the functions.php file (of your configured and activated child theme): function childtheme_twentyseventeen_fonts_url() { $replace_original_font = true; // unless you really like Libre Franklin if ($replace_original_font !== true) { $hyph = '-custom-'; } else { $hyph = '-'; }; $font_families = array( //add your Google fonts and weights (400 and 700 are defaults for normal and bold) here: 'Oswald:200,400,700', 'Lato:200,400,700', ); $query_args = array( 'family' => urlencode( implode( '|', $font_families ) ), 'subset' => urlencode( 'latin,latin-ext' ), ); $fonts_url = add_query_arg( $query_args, 'https://fonts.googleapis.com/css' ); wp_enqueue_style( 'twentyseventeen' ....

{position:fixed} in iOS 6

I stumbled upon this oddity when upgrading to iOS 6 while working on a mobile advertising project, and it took me a better part of the day to figure out what is going on: all of a sudden an element {position:fixed} stopped working in a correct manner (which is staying put, while the page is scrolling), and started "sticking" to the scrolling page, moving out of the viewport, and then just "jumping" back to the correct location after the scrolling was finished.If you scroll this page , you will see it—hint: that's the one labeled "broken"—assuming that you have a correct device/browser combination. Mine was iPhone4 and iOS 6.0 (6.0.1-6.1.3 behaves just the same). On the original page, where I first encountered the problem, all of my elements were created dynamically using JavaScript, but at the end of the day (literally) it become clear, that the glitch is in the iOS 6 CSS implementation.Here is what happens: if you have an element {position:fixed} whic...

How to Make a Website Everyone Has