New links in the subscribe sidebar - RSS-2 filecasting feeds links, about the feeds link
11-September-2005
permalink email thisPhew! Trivial task turns into testing trial... I've just changed the layout of links in the Subscribe sidebar, so that the whizzy new RSS-2 filecasting, main-content feeds were exposed to the feed-consuming public.
I also took the opportunity to add a link to a new bit of stub content explaining all the formats and options ( there are loads of undocumented feed sources at the moment, for instance categories). I also flagged the default feed ( the RSS-2 that will be auto- discovered) on the assumption that it would be good to have one simple choice, and also to indicate for users with auto-discovery which of the feeds they will get.
Extended text for this entry:
Gtting the new RSS-2 links in - surprisingly - required some fiddling and careful thinking. There are a *lot* of options now about the feeds available. Even paring it down to the bone, there are 6 canonical feeds for current weblog updates: whether or not to include discussion items in the feed times whether to consume the RSS-2, RSS-1 or atom formats (if we wanted to allow a choice of main-content or summary for atom feeds, for instance, this would obviously be complicated still further :o).
In order to make the options seem more natural (well - they are!), I decided to use little badge icons instead of text, and found some nice looking ones in a google image search (apologies if these are not open-content, but badges like that are so easy to make that they should be). There beginneth the fiddling. Thee badges are 80 pixels wide and there are three of them. That'll fit into the smallest th sidebar will get in the default styling IF they have no borders or margins. But for some reason they were inheriting a think gray border in firefox but not safari (I shudder to think what IE/Win would have done at this point) - which caused the 3rd badge to wrap, and they were also wrapped in a very ugly way in the 'clean' alternative style.
So I had to override the rule that added the border. But still it turned out to be a pain to get them to appear correctly in all the browsers. AND in any case I hate having to fiddle the ALT and TITLE attributes in images-in-links in order to fool IE/Win into using title text nicely. AND the ,arkup for the img tag was going to add up to 700-odd bytes more than a plain-text link would. So I bit the bullet and did the css-background trickery.
And of course it turns out I'd forgotten how to trick IE into playing nicely with making the link as big as the image but no bigger, so I had to dig out an old stylesheet to look up the technique. Sigh - another 15 minutes gone.
Got that to work, and then ha to deploy. At which point cache after cahce comes up to bite. Have to invalidta all the sidebar caches. Have to squeeze the rules past the draconian caching on our production server. Which is really the point of this post...
... Temporarily... I've added the style rules in-line into the markup of the sidebars through the main siadbar macro. It was the only way to get the new rules past some caching proxies (and safari) until the http cache expiry runs out next month :o)
Don't worry - when we 'release', we'll rename all the important css and js files so that they get past our caches but have rational naming.
So - after making a meal of a snack - there are now links in the sidebar for the new feed.
By the way - a confession - I still do not know where that crazy border was being inherited from ( the wonders of the 'cascading' in css and the anarchy of our rapid application development :o)
Linking and trackbacks
When linking to this weblog entry, please use the 'permalink', which is http://www.knownet.com/Members/mmalloch/blog/entries/8104881547
