Certain sIFR Selectors not working in Safari--extremely unusual bug:

Question

I am creating a site, CardinalCoffee.com, using sIFR.

It's not quite ready to go, so access by adding

72.249.85.228   cardinalcoffee.com
72.249.85.228   www.cardinalcoffee.com

to your /etc/hosts (C:\WINDOWS\system32\drivers\etc\hosts on Windows).

On the blog page (http://cardinalcoffee.com/blog/), and only on the blog page, certain sIFR selectors fail--but only in Safari. The sIFR-based navigation and blog post subheadings don't show up on the blog page, but they do every where else (and on all other browsers the /blog/ page is fine).

Here are the pertinent selectors from sifr-config.js:

sIFR.replace(itc_anna_std, {
  selector: '#top_nav li a',
    css: [
     '.sIFR-root {.sIFR-root { background-color: #f8eca8; color: #FFBF11; }',
     'a { text-decoration: none; color: #FFBF11;}',
     'a:link { color: #FFBF11; color: #FFBF11;}',
     'a:hover { color: #FFBF11; color: #FFBF11;}'
    ],
    wmode: 'transparent',
    forceSingleLine: true,
    tuneWidth: 2
});
sIFR.replace(itc_anna_std, {
  selector: '.non-admin #content_column .entry h2 a',
  css: [
     '.sIFR-root { background-color: #f8eca8; color: #170504; text-align:left;}',
     'a {text-decoration:none; color: #170504;}',
     'a:hover { color: #170504; }'  
    ],
    wmode: 'transparent',
    tuneHeight: -18,
    offsetTop: -6
});

Additionally, the font-size declaration on Subheadings (selector: .entry h2 a) seems to be ignored. Here is the pertinent style rule from sifr.css:

    .sIFR-active .non_admin #content_column .entry h2 {
     font-size: 36px;
    visibility: hidden;
    }

This is a WordPress site.

[edit]: Appears that this rule is to blame somehow:

sIFR.replace(itc_anna_std, {
  selector: '.non-admin #content-column .entry h2',
  css: [
     '.sIFR-root { background-color: #f8eca8; color: #170504;}',
     'a { text-decoration: none; color: #170504;}',
     'a:link { text-decoration: none; color: #170504;}',
     'a:hover { color: #170504;}'
    ],
    wmode: 'transparent',
    tuneHeight: -18,
    offsetTop: -6
});

(I moved the other sIFR replace to the top of the file and the navigation began to load flawlessly.)

Answer 1

Alright, looks like the fact that there was a class assigned to the <a> inside each <h2> because I was enabling an edit-in-place function with Flutter.

When I removed the class on the <a>, the replacements came through just fine.

Still doesn't explain why moving the header div.SimpleSideNav ul.sf li sIFR replacement to the top of the sifr-config.js configurations made it work, but I'm not going to look a gift horse in the mouth.