Getting this post out quickly because I suspect I may be the first to report this bug - me! First! Either that or my Google skils seriously suck.
Anyway, IE8. The browser Microsoft tried to convince us would work the way a browser was supposed to work. Did they really expect us to swallow that?? I should probably admit that it is a bit of a leap forward, even if it's not the cat's pyjamas we were told it would be. Mostly it seems to behave a bit like Firefox 2 and at least, thanks to the backwards magic that is conditional stylesheets, we can target it for its little inconsistencies.
But, alas, just like its predecessors it has moments of total insanity and it was one if these the tester on my current project discovered a few days ago. This afternoon I spent some quality time with IE8 and made the following interesting discovery.
If you zoom a document which contains block level elements with non-repeating background images where the vertical positioning of the background image is anything other than 0 or a multiple of 4px, you are likely to reveal a bug where the first 1px of the image is repeated below it, displaying as a 1px line (for vaguely box-shaped images - I guess circles and irregular shapes might not yield such an obvious result).
Fun, eh? The 4px thing I discovered through lots of trial and error and 'whaa...?' - but it only applies to the 'standard' zoom options and may break under custom zoom levels - I suspect this is because the standard zoom ratios - 50%, 75, 100, 125, 150, 200, 400 - are based around quarters (well up to the 150, I guess). I tried setting different heights on my block and inline-block elements, but always the 4 came through. Mind you, I haven't tested with different heights of background images, so I don't know whether that's a factor too, but this is hopefully a starting point for others who are battling similar things.
I have another issue awaiting me too which I'm certain is related - a repeating background image (a dropshadow) is showing a 1px line to the right of it when the page is viewed at 105%. On closer inspection it too is the 1st pixel-width of the background image - but how to fix it? No idea yet. Let me know if you have a suggestion!
Labels: browsers, bugs, code, website
Finally I have started the daunting process of moving all my blogs - this one, the Minim-Media news feed, One Creative Thing and the 16-week blog I sort-of kept in the last semester of my Grad. Dip. - over to WordPress. Blogger's been annoying me for quite a while now because it's got so incredibly slow and every post, no matter how short, takes 5 or more clicks of "This is taking longer than expected - do you want to wait?" just to get the wretched thing online. With the result that I haven't really been posting anywhere other than Vox for the last six months, and now that we've sorted out a UK host who has given us unlimited space, it's time.
And so the past two days I've been sorting out a template for One Creative Thing, because for the past year since it was created, it's been languishing in a prefab (but nice and clean) Blogger template and that, of course, is a case of "You can't take it with you when you go", so I got out my pen and watercolour pencils, and then Photoshop, and then Dreamweaver and made up a new design and coded it, and today I've been tweaking that code to turn it into a proper WordPress template. I'm rather pleased with the results, but I have to say, it's been very frustrating trying to add in widgets - everything seems to assume that you already know exactly how to get your widget into your page, and when I discovered that I needed my template to be "widget-aware", I was sent to this article on automattic.com as what seems to be the standard reference for "widgetising" a WordPress theme, but could I make head or tail of it? No. Part of the problem was that it sounds like they're widget developers themselves and I couldn't tell when they referenced a chunk of code whether that was for general widgets or their own widget (Answer: mostly it seems to be general), so, having figured it out, I thought I'd write my own description of how I did it, which hopefully might help others who are similarly bewildered.
OK. So now that you know these two vital pieces of information, how do you go about it? Firstly, I am indebted to How to widget-enable WordPress Themes in 3 Easy Steps for actually making sense of everything.
This is the file that contains functions specific to your site. What you need to do is to invoke the register_sidebar function to warn WordPress that you have a sidebar you want to add widget(s) to. You do this with:
'', 'after_widget' => '', 'before_title' => '<h4>', 'after_title' => '</h4>', )); ?>(Note that this assumes you are not using WordPress's default markup which uses H2 for all sidebar headings and an unordered list for the sidebar content - if you have this sort of setup, have a look at the "3 Easy Steps" link above for the right code.
This seems fairly self-explanatory, and maybe it is for you, but alas, my brain did not work that way and it took some time to work out the following:
'' in 'after_title'If you plan on having more than one widget in your sidebar, you need to call register_sidebar as many times as you plan to have widgets on the page, each with its own name, so adjust as follows:
register_sidebar(array( 'name' => 'sidebarname', 'before_widget' => '', 'after_widget' => '', 'before_title' => '<h4>', 'after_title' => '</h4>', ));
Note the addition of the 'name' attribute at the top of the array? That's the only difference. Just drop these one after the other, each with its own name (it may be best to make these a bit meaningful so you and anyone else who may use your theme can see what you intend to go in there. For maximum flexibility, the automattic.com article describes a good failsafe method that will show a static sidebar, should something go wrong with adding in your widgets).
Once you've registered however many sidebar areas you need to cover the widgets you want (and more than one widget may go in a sidebar area, but you might want to specify different areas for specific purposes), you're going to have to specify those areas in the sidebar.php file itself.
In each place you want the widget to appear, you need to put in a call to the 'dynamic_sidebar' function, each one customised to the name of one of the widget areas you specified in your functions.php file, like so:
<?php if ( !function_exists('dynamic_sidebar')
|| !dynamic_sidebar('sidebarname') ) : ?>
<?php endif; ?>
Note that if you put any code in between the first php tag and the second, it will be overwritten. Change the name of 'sidebarname' to be that of whichever widget you want in that space, the same as you did when registering that sidebar area in the functions.php file (that is, if you called it 'calendar_widget' in the functions.php file, you'll need to use ... !dynamic_sidebar('calendar_widget') in the sidebar.php file too.
Then in WordPress all you have to do (probably) is install your widget(s), activate them and set them for the spaces where you want them to appear. The names you gave each sidebar space in functions.php will appear on the widgets page, so you can easily determine which one you want where. Some widgets may require further tweaking of the PHP, but that is a topic for someone else to cover as I haven't yet played with any of those.
Labels: code, tools of the trade, website