Two inquiries about BLIX css

  • Author
  • #335451


    I have been searching the forums and googling and such for a while now, and cannot seem to find any answers about adding text into the BLIX theme… I do not want to delete the footer, just re-word it. I know this is possible because I saw it here (

    My other inquiry is about the “Home” button on BLIX. I cannot figure out how to change this wording. I know it can be done because of the aforementioned blog.

    Can anyone help?

    The blog I need help with is



    When I say adding text into the BLIX theme, I mean adding or altering the text in the footer.



    Can you give us a link to your blog? The site linked to your name is not one, and so our answers won’t apply to it.




    Partly answered at:

    On the Home button — given that you get access to only the CSS and not the php part of the theme (contrary to which is not hosted at — here’s a possible strategy.

    In CSS you basically can’t change the text, however you can show your message in a background image and also use some method to make the existing text disappear. For the HOME button his turns out to be a little tricky because it doesn’t have any id or class that distinguishes it in a way all browsers understand. (It sometimes gets the class “selected” but not if you’ve selects a different page).

    Probably something like this would work:

    div#navigation ul li a[href=""] {
      height: something;
      background-image:path-to-image;  <--- contains your replacement message
      font-size:something;  <-- or other strategies to hide the text
      color: something;

    The a[] attribute syntax is purported to work in IE. (An alternative, using the :first-child pseudo-class would have been promising, but not supported in IE.)

    (Note that the existing CSS has already turned that “a” element into a block.)

    FWIW, for puzzles like this, this site is helpful to determine what’s likely to be supported:

    — Hope that helps



    Thanks so much gwideman for all your help! : )



    just a small observation, gwideman, you don’t need to add the element before the id selector, just:

    #navigation ul li a[href=""]

    should suffice. HTH



    devblog: Yes, of course you’re right.

    I have got into the habit of writing in the element type for classes, so if there was a navigation *class*:

    div.navigation {…}

    … because sometimes you see a class used in multiple different tags, and this helps avoid surprises.

    That impetus predisposed me to liking the increased specificity of including the element type for Ids as well. In theory there is only one element with that Id in a document, so this should be redundant, but (a) I like the reminder of what kind of element it is that I’m targeting, and (b), actually you can have multi elements with the same Id. (But whether or not the browser will find the right one, aided by the element type, I don’t know!).



    … because sometimes you see a class used in multiple different tags, and this helps avoid surprises.

    Well, a class is used to define common properties of an element, so you shouldn’t have surprises. That’s part of a good design. If you want to have two buttons, both with an orange 2px *thick* border, black background, white letters BUT with different widths, then you should write an “extra” class for the wider button. So, your markup would look like this:

    <input type="button" class="genericBtn" value="button 1" />
    <input type="button class="genericBtn widerBtn" value="button 2" />

    Your CSS would look like this:

    .genericBtn {
    background: #000;
    border: solid 2px #fc0; /*If I remember well, this is the code for orange*/
    color: #fff;
    .widerBtn {
    width: 400px;

    Notice that in button 2 you’re combining two classes. That should produce the results you want.

    Also, it’s of good practice to use descriptive names for your classes (notice in my example “genericBtn”), that will help you a big time.

    actually you can have multi elements with the same Id.

    Yes, you could have multiple elements with the same ID, and if you ever find a page whose source code shows various elements with the same ID, you should encourage whoever wrote the code of that page to grab his/her books again and go back to HTML 101. Multiple elements with the same ID in a single page is of bad practice and frowned upon. IDs should be unique in a single page… that’s why they’re IDs. To style multiple element in a page with the same attributes there’s nothing better than classes.

    Now, you do use “div.navigation” or “div#navigation” when you want to force an element to be styled the way you want. I’ll try to explain:

    Let’s say you’re trying to style the navigation bar of an existing theme. The original definition reads like this:

    .navbar {
    background: #000 !important;

    But you don’t want it to have a black background; you want it to be red, but since you can’t modify the original CSS, you write your new definition:

    .navbar {background: #f00;}

    You test it, but the background is still black. Then you say “wait, I need to add the ‘!important’ rule so my definition takes precedence.” You go back to your code and rewrite it like this:

    .navbar {background: #f00 !important;}

    You test it again, but… bummer! the background is still black. How to solve this? Well, you do it like this:

    div.navbar {background: #f00 !important;}

    NOW your navbar should have a red background.

    I hope this helps.



    Hi devblog: On most of this you’re preaching to the choir — and the choir approves :-).

    I would add that there are various reasons beyond one’s own control that there may be conflicting classes or ids — obviously bad, but nonetheless can happen. An example would be invoking add-ons from multiple sources who didn’t thoroughly distinguish their classes/ids, that sort of thing.

    BTW — in your .navbar example, then I think the custom .navbar {} CSS would override the theme’s CSS, because they have the same specificity, and important!ness, and the custom CSS would presumably be read after the theme CSS, and hence win by being later. (Though I haven’t actually tried it.)

    However, I do get your point that if that wasn’t the winning point, one could add precedence to the custom CSS by adding the element type — good note to bear in mind!



    Glad to know the choir approves! :)

    I see your point regarding IDs and Classes of add-ons that might conflict with those of the main applications, but then again, if you’re developing a widget for WordPress, not only you should be familiar with the API, but you should also follow the coding guidelines to avoid such conflicts. At least that’s what I would do. But yes, there maybe someone who, like you said, didn’t thoroughly think how to name their classes or ids, and thus making things more… difficult.

    Regarding my navbar example. No, the custom CSS wouldn’t override the theme’s CSS even being read after the theme’s because of the !important rule the first definition has. If the theme’s CSS didn’t have the !important rule, then the custom CSS wouldn’t need one either and still take precedence since is being read after. You know this already.

    I don’t know if you’ve read this, but if you haven’t, it might help a bit more:

    Nice discussion, BTW.

The topic ‘Two inquiries about BLIX css’ is closed to new replies.