monkinetic weblog | redmonk.net

desk
Originally uploaded by redmonk.

My desk at work. The closest I could come to making the Windows PC bearable was put R.E.M. on the desktop and my Apple/Mac totems nearby.

OMG, the countdown to Sept 26 continues. Witness White and Nerdy (some tidbits on Wikipedia), Weird Al’s new single from Straight Outta Lynwood. Look for a cameo from Seth Green (as an action figure collector, which he really is) and an inspired appearance by Donny Osmond (and probably others).

Update: YouTube now says:

“This video has been removed at the request of copyright owner RIAA because its content was used without permission”.

Guess someone should have taken Weird Al’s advice:

Oh, you don’t wanna mess with the R-I-double-A

They’ll sue you if you burn that CD-R

It doesn’t matter if you’re a grandma or a seven year old girl

They’ll treat you like the evil hard-bitten criminal scum you are

Update #2: Looks like Al re-uploaded the video himself to YouTube.

Wow, I so want one of these: chumby, the hackable, soft, squeezable, networked, alarm-clock-but-oh-so-much-more thingy. More later on my recent bout with serious technolust.

(Geekery ahead)

Wow. I just got schooled in the specifics (pun intended) of CSS cascade specificity. As usual, the trouble started when IE would not render a layout properly. After hunting down a bug related to IE’s non-support for the child selector (>), I found that I could not get some descendant selelectors to override properly.

Firstly, here’s the structure and css I was using initially:

HTML:

ol#container
    li
        ul.subcontainer
            li

CSS:

ol#container>li { float: left; ... }

Fireflox floated the LIs perfectly, while IE completely ignored the float on the intial LI. After hunting down the fact that IE does not support that initial child selector, I removed it and went about overriding those styles to reset them to default values for descendant LIs.

ol#container li { float:left ... }

So, that fixed the initial problem, but now both Firefox and IE were floating both the initial LIs and all descendant LIs. I tried selectors of varying specificity, trying to override those first styles, and nothing worked.

So, next step was to figure out what the cascade was doing. I poked around the W3C CSS spec until I found the section on specificity. Lo and behold, I discovered that id selectors are like the “bunker-busters” of the CSS world:

A selector’s specificity is calculated as follows:

• count the number of ID attributes in the selector (= a)
• count the number of other attributes and pseudo-classes in the selector (= b)
• count the number of element names in the selector (= c)
• ignore pseudo-elements.

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Some examples:

* {} /* a=0 b=0 c=0 -> specificity = 0 */

LI {} /* a=0 b=0 c=1 -> specificity = 1 */

UL LI {} /* a=0 b=0 c=2 -> specificity = 2 */

UL OL+LI {} /* a=0 b=0 c=3 -> specificity = 3 */

H1 + [REL=up]{} / a=0 b=1 c=1 -> specificity = 11 */

UL OL LI.red {} /* a=0 b=1 c=3 -> specificity = 13 */

LI.red.level {} /* a=0 b=2 c=1 -> specificity = 21 */

#x34y {} /* a=1 b=0 c=0 -> specificity = 100 */

Adding an id to a css selector adds *100* to the specificity value, making it almost impossible, short of another id selector, to override. The final fix involved removing the id selector on the initial selector, then I was able to override the LI styles later on the css. Whew!

“have all your geek buddies messed up iTunes or something?”

“yes, we broke it with our love“

Well, one thing that may happen is you may begin wonder what a mashup with snippets of interviews by Terri Gross on Fresh Air and say, Green Day (perhaps something from American Idiot) might sound like…

I must remember to download this on the home machine: Hazel, a wonderful-looking rule-based system maintenance app for OS X.