Send to KindleYesterday, I raved about XAMPP in this post. In there, I made the following statement:
The other major thing that I don’t like (but which I suspect is easily fixable with a CSS tweak) is that the Sociable plugin formats the icons in a list (one per line) rather than as an inline string of icons, which other themes are doing correctly…
So, today I spent quite a bit of time playing. I enjoyed it, and it was instructive as well. I was able to easily change a bunch of things that I didn’t like about my previous theme. That said, I really like a lot of the Aspire (current) theme, other than the dark image background (which I can live with) and the note above about the sociable list not being inlined.
I decided to experiment in my new sandbox with the Aspire theme. I couldn’t find an easy way to see what css was controlling what element. A quick search said that the built-in DOM Inspector in Firefox could help resolve this. It wasn’t in my Tools menu. It turns out it isn’t installed by default on Windows. I reinstalled Firefox, selected custom, and voila, I had the DOM Inspector.
Once I inspected a page, it became obvious what the problem was. The Aspire theme defines an ID main. Then, in addition to default definitions of ul and il (unordered list, and list element), it also defines #main ul and #main il (specifically, an unordered list which appears in the main block, and the same for a list element in the main block).
The DOM Inspector showed me that the sociable.css was correctly being loaded, but that the way more specific #main selector was being applied after the sociable.css was parsed. As annoying as it is/was, there’s some logic to it. If a node can be defined ultra-specifically, and there is a css definition associated with that, then perhaps, you really want that to apply.
Unfortunately, the specific definition had display: block instead of the desired display: inline.
I’ll spare you the stupid gymnastics I performed, trying to over-ride that behavior. Suffice it to say that along the way, I tried doing something like this:
#main.sociable ul
ul#main.sociable
among other utterly useless attempts to get even more specific.
I broke down and sent a message to the current maintainer of the sociable plugin. Then, two minutes after sending him the message, while browsing formal docs for css, I stumbled on something.
In some of the attributes in the sociable.css file, he added !important to the end of the definition, in others, he didn’t. In the docs, I saw that normally, !important is used to signal to the browser that this particular attribute is important, and should be respected over a defaulted value. It’s primary use is to allow users to have stylesheets which over-ride authors stylesheets.
So, I thought, let’s experiment and add !important to the few attributes that weren’t already tagged as such (specifically, the display: inline one!). Voila! Now, even though the browser sees that #main ul comes after .sociable ul, it also knows that .sociable ul said that display: inline was !important, so it retains it!
There may be a better way to solve this problem (after all, this required me to edit the author’s version of sociable.css, which would get wiped out the next time I upgrade the plugin), but, without my sandbox (courtesy of XAMPP), I wouldn’t have found this one. In addition to XAMPP, I now also need to thank the Firefox DOM Inspector. 🙂
Leave a Reply