[Plugin: Weather Forecast – WP Wunderground] Top level table has width set

You can modify the output to remove the 100% width by adding a filter to your active theme’s functions.php file:

add_filter('wp_wunderground_forecast', 'remove_100_per_width');

function remove_100_per_width($content) {
	return str_replace('width="100%" ', '', $content);
}

I’m happy to have a work-around, and I’ll run with it.

*BUT* You’ve completely sidestepped my question.

Isn’t this better to let browsers deal with rather than forcing it in html?

Tables are already block-level elements, why are you forcing style in the html instead of letting browser / css deal with it?

CSS can still override the width. What I don’t want to happen is users who don’t know CSS to have a table collapse on them when they want it to be full width. I’ve found that users like simple.

In future versions, I will add an option to specify width. For now, I think this workaround is sufficient; technical users will know how to set CSS styles and add things to their functions.php file.

CSS doesn’t appear to work in all browsers. Flagged it as resolved because of the work around, If/When you remove the need for it, I’ll come back and tag it as works with wordpress and up my rating a bit. It’s a great little plugin, but doesn’t quite work.

1.2 has an extra “width” option in the shortcode, where you can use width=0 and turn off the hard-coding.

Will there be any further updates on this plugin for XHTML compliance (now that it is quite evident HTML 4.x is completely deprecated.

I have tried to use the following shortcode in my sidebar Widget:

[forecast width=”0″]

and

[forecast width=0]

However, the ‘width’ tag is still there, still showing 100%.

This is the only thing stopping me from gaining full XHTML compliance – it seems the table design is hard-coded throughout the plugin therefore it won’t matter if I create CSS for a table design, because the table tags will still be generated.

I’m working with Zack on a number of updates for this plugin. Using table was something that bothered me because it’s not truly tabular data. But I understand why it was used initially. I suspect in order to move away from it, we need to provide a way for users to create their own CSS

I agree – I am now going through the current versions code and seeing if I can replace these with CSS and XHTML compliant tags. Looks quite messy stuff. I was also thinking of changing the image paths, instead of pulling the images from icons-ecast.wxug.com, I would like to use images on my server to reduce (minimally) server load and (slightly) page load speed.

Do you have any guesstimate as to when the next version may be released with CSS-functionality?