Having Trouble Styling a Table in a Wordpress Post

Question

I am trying to style a table in a Wordpress post, but am having difficulty getting it to work. I have set the post to HTML-editing mode and can get some of the styles to take, but not all. (To be honest, this is not the first time I have had trouble getting table styles to work.) The contents of the post (using contrived styles and high-contrast colors to make it easy to identify elements) are below.

This is the incorrect result I am getting:

As you can see, the cells are not picking up the styles but the table itself is, well, mostly.

I thought that maybe it is the blog’s theme that is interfering, but from my understanding of HTML, the STYLE tag that comes right before the table is supposed to override anything that comes before it (and is partly doing so). If I put some style info directly into the TD tags, it works, but that is obviously not a practical solution.

Can anyone help me figure out how to get a table style to work in a Wordpress post? Thanks a lot.

---

<!-- script type="text/javascript" src="/Common/JS/SortTable.js"></script -->

<style type="text/css">
table.sortable {
    margin              : auto;

    border-style        : dashed;
    border-color        : #000000;
    border-width        : 2px;

    color               : #000000;
    background-color    : #ff0000;
}

table.sortable td {
    border-style        : dashed;
    border-color        : #000000;
    border-width        : 2px;

    width               : 100px;
    background-color    : #0000ff;
}

table.sortable .title {
    width               : 300px;
    background-color    : #00ff00;
}
</style>

<table id="mylist" class="sortable">
    <thead>
        <tr>
            <th>Title</th>
            <th>Foo</th>
            <th>Bar</th>
            <th>Baz</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td class="title">Something</td>
            <td sorttable_customkey="5"></td>
            <td sorttable_customkey="5"></td>
            <td sorttable_customkey="5"></td>
        </tr>
        <tr>
            <td class="title">Something Better</td>
            <td sorttable_customkey="4"></td>
            <td sorttable_customkey="5"></td>
            <td sorttable_customkey="5"></td>
        </tr>
        <tr>
            <td class="title">Something Worse</td>
            <td sorttable_customkey="3"></td>
            <td sorttable_customkey="4"></td>
            <td sorttable_customkey="3"></td>
        </tr>
        <tr>
            <td class="title">Something Horrible</td>
            <td sorttable_customkey="3"></td>
            <td sorttable_customkey="4"></td>
            <td sorttable_customkey="1"></td>
        </tr>
    </tbody>
</table>

Answer 1

Your understanding is partly right. Later styles override earlier ones IF they have the same or less specificity of the selectors. Specificity can be a tricky/counter-intuitive thing, but the basics are: selectors that specify an element in a more narrow (specific) way override those that define them in a broader way.

It all depends on what your theme's stylesheet does. You'll need to investigate that. For instance, on my theme, tables in posts get styles attached from the theme via

#content tr th { ... }

and

#content tr td { ... }

In your case these would take precedence over your definitions because #content selects an outermore tag than table.sortable . This defines higher specificity, because it narrows down the context of '.sortable' tables that would be selected. In this case you'd have to define your styles with

#content table.sortable tr th { ... }

and

#content table.sortable tr td { ... }

in order to have them take precedence.

An easy way to get your own styles take precedence is always to prefix your selectors with body. However, this is quite rough and can hence lead to trouble.

I'd recommend using a browser web developer tool like Firebug or WebKit's/Chrome's buildin developer tools to inspect the elements in questions and look at what style definitions override one another. This will give you a good clue as to what you can do to have your own take precedence.

Once you figured that, put your own styles in your themes/child theme's style.css...if you want to format that table only use an id selector (#mytable) or if it's more than one give them a distinct class and put that in your selectors.

Answer 2

Alright, it’s solved. It turns out the problem is due to WordPress’ “auto-p” functionality and until/if it can be updated to recognize and ignore text inside STYLE and SCRIPT blocks, an easy workaround is to use the WP Unformatted plugin which makes it easy to toggle the auto-p function on a per-post basis.

---

Update2 Dang! I tried wrapping the style and script code in CDATA tags, but that didn’t work; WordPress still wraps blank-delimited blocks in P tags. I guess I will have to file a report.

---

Update I just realized that the problem is that Wordpress automatically wraps blocks of code, delimited by blank lines in P tags. This of course messes things up if the blank line is inside a SCRIPT or STYLE block.

---

I figured it out. I added an extra style (for IMG tags) to the top of the list and it took, but then the main table style (the only one that was working) suddenly stopped working.

I then put a blank line between the STYLE tag and the new IMG style and it too stopped working (in other words, no styles were getting picked up). On a hunch, I removed the blank line and added a closing tag for the STYLE after the IMG’s style. Then I wrapped each set of styles in their own opening and closing STYLE tags and voila! It worked! (Another option is to remove the blank lines between selectors, thus cramming everything together.)

This seems to be a bug in WordPress’ parsing of posts. In fact, I came across this same bug last night in JavaScript: I tried to comment out a block of code, but found that if I had a blank line between it and the active code before it, the whole thing failed; I had to either remove the blank line or the whole commented block.

These workarounds will work for now, but it’s hardly elegant. A bit of Googling on the issue finds nothing, so I’m going to check the codex, and likely end up posting a bug report at the Wordpress site.

In the meantime, I have to make this gaudy table look good… :-)


Thanks for the effort everyone.