Why isn't there a CSS Browser Selector. I know that in theory, standards such as CSS, (x)HTML, etc. are there to make it so we don't have to rely on something like a browser selector, but in the real world, we are reduced to using hacks and browser sniffing to get the job done.

Browser sniffing is sub-standard (excuse the pun), because we cannot rely on the user-agent string. But if we are going to browser sniff, then sniffing via Javascript is even worse.

Hacks are sub-standard (ditto) because they depend on comments to tell you what is going on. Imagine trying to figure out a voice-family hack if you aren't familiar with it at all.

Instead imagine if you could just do something like this:
@band-pass[ie5] { margin: 0; padding: 10 } /* This style for IE 5 only */
@low-pass[ie6] { margin:0 } /* this style for IE 6 and lower */
@band-reject[webkit] { margin: 0 } /* for every browser except webkit/safari*/

The closest to an ideal solution is some kind of pre-processing of a CSS file, so that you could use a @band-pass[ie5] style syntax, and it would transform that into the relevant CSS bandpass hack for that browser.

Update: Sorry about the... erm... substandard title. It is fixed now.

Say you have a webpage, with a background image and a select box. In Internet explorer 5.5, you will run into an issue where the background image won't fully load, and the contents of the previous page will be your background instead. Moving the scroll bar will sometimes fix the problem, or sometimes make it worse.

That is, if you are using IE 5.5 in stand-alone mode, along with IE 6.0.

Which goes to show, the only sane way to browser test is to install VMWare or have a separate machine for every IE version you need to test. Yes thats right, a separate computer for every (Microsoft) browser that you need to test.

Imagine that.

Insert heaping of scorn upon Microsoft here. Man. Just make your browsers stand-alone-able already.

In standards-compliant mode, compatibility with other versions of Internet Explorer is not guaranteed. When standards-compliant mode is switched on, the rendering behavior of documents might differ in future versions of Internet Explorer. You should not use this mode for content that is fixed in nature, such as content that is stored on a CD.

MSDN Library

Seeing as how I have my web-dev hat on lately, I've been dealing a lot with CSS, HTML, layout issues, and other sundry.

I crave unit testing. Unit testing is a method where programmers can test the results of any code they create, or (especially) modify, to make sure that it conforms to a set of requirements. It is also called a "test harness" which simultaneously brings images of something that saves your life if you slip and fall down a cliff, and something that binds you.

Unit Testing is practically automatic. When you write code, you write some tests that run along side the code, and when you are ready to "push the change upstream" and make your code live, you run the unit-tests first, to be sure that everything is running well. Running the tests is as easy as clicking on a test button, or launching your favourite build utility; they are painless to run and it only takes just a few mindless seconds.

Web Developers don't have that luxury. Instead, when it is time to test, they have to open at least 2 browsers—though quite likely 4-6 and visually inspect the results. This can get downright physically painful (multiple IEs anyone?). Trying to do any effective CSS refactoring is effectively impossible, because there is no easy way to test the results. Something. Must. Be. Done.

A web development unit tester

A web development unit tester would do something like this:

1. Automagickally validate the rendered HTML page (rendered because changes are you are using some kind of ASP/JSP/PHP funkiness) for valid (x)HTML, CSS, broken images and broken links
2. Visually compare the rendered pages against a set of "templates" to ensure that any changes to the stylesheet or underlying markup don't have any adverse effects.

The first requirement is simple. Painless basically. Validators, of the link, css, html and image variety, have existed for ages. All that it takes is the ability to chain them all together, and launch them from a simple button (or command, if you are strong—GUIs are for the weak). The second requirement is the most important and difficult part, especially if unit-testing CSS is to become a reality.

How can unit-testing happen for CSS?

Not Easily.

Essentially what needs to happen is that a visual representation needs to be compared to ensure that everything "looks good". This fuzzy definition really encodes the problem. One solution I have thought of involves opening the page in all of the target browsers rendering engines, rendering the full page directly to an image, and then comparing the images pixel vs. pixel against a known "last-good" result. If the pixels differ, the offending pixels could be highlighted and the developer could choose to specify that the variation is within acceptable bounds and not be warned about it again, or fail the test.

This would be especially helpful when moving style-declarations around a style sheet, for instance, when pushing up a declaration to a parent element, or down to a child element. These kind of refactorings should change nothing in the visual presentation of the page, but should make the stylesheet smaller, easier to read, and easier to parse: for machines and humans.

Who wants to build this?

One of the most annoying things about S9y is the fact that the main stylesheet is a PHP script, which includes the bulk of the S9y codebase itself. Not only does this make retrieving the stylesheet a non-trivial operation, but it also means that the stylesheet itself cannot be cached. The reason why the S9y developers chose to do this is so that plugins can check to see if any styles are defined for particular classes, and if they are not provide reasonable defaults.

As an aside, a better method might be to call the main css file statically, and have each plugin provide its own static css file. It is trivial to check to see if 'my_plugin_name.css' exists in the current theme dir. All this could be done in the head block.

In the meantime, for any S9y theme authors, or even anyone who just wants to make their S9y installation just a little faster, here is a great fix:

1. In the current theme you are using, copy the style.css to main.css.
2. Change style.css to this: @import "/templates/your-theme-dir/main.css;.
3. View the text of http://yourblogdomain/serendipity.css. Ideally you should just have the @import directive.
4. If you don't that means that some plugins are defining their own default styles. To make sure the directives in your /main.css override them properly, you can just put the name of the class in a comment. For instance, I override the defaults of the FreeTag and searchQuery plugins in my style.css. So, my main css looks like this:

   @import "/templates/midibuffer/main.css";
   /*
   .serendipity_searchQuery {}
   .serendipity_freeTag {}
   */

There ya go. hopefully that will speed you up a little.

Badges are popular. What are badges? They are the funky little 80 x 15 graphics. They usually exist to point to RSS feeds, or brag about which blogging software is being used, or how valid a given page is. They are most popularly used by bloggers the world over. So today I ran into a link about how to make HTML + CSS only (no image) W3C validated buttons. I thought, why not apply this to badges?

These badges come in two flavours, absolute and relative. The absolute badges are, erm, absolutely sized, and fit within the 80x15 pixel constraints. The relative positioned badges size up and down with the font. There is no 'semantically-null' markup here either, assuming you agree with the proposition that divs can contain semantic meaning, for instance, when they are used as containers.

When you want to use this, give the left and right hrefs their own classes, and style them as you will (different foreground and background colors, etc.).

I think that my choice of fonts is reasonable, but I would love to hear from mac and linux users as to a good choice for a monospace font.

The buttons

Increase and decrease your text size, to see the difference between absolute and relative

Other badges

The code

<style>
.badge
{
    overflow: hidden;
    margin: 3px;
    border: 1px solid #000;
    padding: 1px;
    
    color: #000;
    background-color: #fff;
    font-family: Silkscreen, "Andale Mono", "Lucida Console", "Courier New", Courier, mono;
    font-weight: bold;
}

.badge a
{
    display: block;
    padding: 2px 3px 1px 3px;
    text-decoration: none;
}

a.badgeLeft
{
    float: left;
    
    margin: 0px;
    margin-right: 3px;
    border: 0px solid #fff;
    border-right-width: 1px;

    color: #000;
    background-color: #fff;
    text-decoration: none;
}

a.badgeRight
{
    color: #fff;
    background-color: #000;
}

.badgeRelative
{
    max-width: 11em;
    font-size: xx-small;
}

.badgeAbsolute
{
    max-width: 80px;
    max-height: 15px;
    
    font-size: 7px;
}
</style>

Usage

Here is the basic markup:

<div class="badge badgeRelative">
     <a class="badgeLeft" href="#">???</a>
     <a class="badgeRight" href="#">DEFAULT</a>
</div>

Depending on what you want, you will want to use the badgeRelative or badgeAbsolute class. This will give you:

Then it is just a case of customizing the left and right classes. The best way to do it is to add a class, and style for it, for instance:

<style>
a.s9y
{
    color: #fff;
    background-color: #986;
}

a.power
{
    color: #000;
    background-color: #FEA;
}
</style>
<div class="badge badgeRelative">
    <a class="badgeLeft s9y" href="#">S9y</a>
     <a class="badgeRight power" href="#">POWERED BY</a>
</div>

Which will give you this:

There ya go. Have fun with the code, it's released to the public domain.

As you can see, I'm updating the look of the website. It's a whole lot better then the last design. Thanks to shell for some awesome help with this. We make a great team.

I call this skin, "Midi Buffer is Full". Amazingly enough.

I went with an absolutely sized site, which is probably going to piss some people off, but with this design, I opted for precision pixel control. Maybe I will revisit it for accessibility later.

I used Colr to choose my initial colorscheme, and then Shell helped with the tweaking, to make it all just right. Colr is a hella cool app. Go check it out.

There is still plenty of work to be done, I have to tweak the styles a bunch more. Watch this space for updates.

Leave me a comment and tell me what you think, or to give me any suggestions.

Update 1: Styling work is going well. The site looks good in Firefox. Looks not so great in Internet Explorer. If you are using IE, just hold your horses, or get a real browser.