CSSquirrel

Yesterday I wrote a post at Mindfly describing how to make use of the CSS @font-face rule for embedding fonts into web pages. I figured it was timely, as I’m getting tired of the number of times I have to use an image (or putz around with workarounds like sIFR) to substitute a special header all because of a non-web safe font, or a client with very specific typographic tastes and a very poor understanding of how the web and fonts work together (or more to the point, how they don’t). Furthermore, both Firefox and Opera have intentions to add support to the feature very soon, creating a world where all four major browsers will have the function (although with IE using EOT and not TTF it won’t be all peace and happiness quite yet).

The thing is, the more I look into the topic, the more it appears that @font-face won’t going to be ushering in a Utopian society of pretty fonts. The core issue seems to be how legal is font embedding going to be, and how will typographers feel about developers putting their font files on servers in a place where they could potentially be snatched?

So far the answers seem to be ‘not very’ and ‘not good’, respectively.

Which makes me wonder, what good, if any, will @font-face actually serve us. If, as a solution, it creates only another problem, a legal problem, that standards themselves can’t fix, is it worth the effort investing into this path to web fonts? Perhaps browser people should be looking into another technique that’ll prove to be more secure for the font files. Something that won’t look good on paper but results in a lot of angry mail from lawyers.

Although, it does make me wonder. Is there a technique that could be used with the current @font-face rule that would still protect the fonts?

@font-face. Good? Bad?

Am I the only person annoyed by how the CSS opacity property is automatically inherited by an element’s children, and it can’t be overridden in the child elements by any means? This is one of the most obnoxious limitations to a CSS property that I’ve ever encountered.

Seriously, why prevent that? I’d initially hazard a guess that it was due to technical limitations, but CSS3’s rgba colors don’t suffer from the same limitation. Too bad rgba colors aren’t universally supported yet.

Then again, neither is opacity.

-sigh-

I wonder if IE8 will support either, although frankly, if they’re going to step up to the big kid’s table, I’d rather see them implement rgba colors first.

As a response to the last comic that featured Opera (right here), viking descendant and Opera Software web opener David Storey simultaneously did three things at once:

1. He left a comment. Which I love. Feedback of any sort is appreciated, especially when it includes the phrase “funny comic”.

2. He defended his company’s product’s implementations of standards by pointing out that one of the three CSS properties I mentioned is in 9.5 (which is now launched), one is only experimentally implemented, and the third is as he puts it “not in a stable spec”. I’ll give him the first two, but I don’t think word-wrap is unstable enough to justify not implementing it.

3. Lastly, he threatened to attack me with the SVGorilla.

The idea of a smoothly scaling primate collided with my recent CSS3 rgba colors experimentation in my head, and spawned this week’s comic.

Opera’s been doing a fine job with their browser, and 9.5 is actually pretty slick. Will I use it day to day? No. It’s feature set does not offer enough to draw me away from Firefox, which is officially launching version 3.0 in mere hours. If addons became a big thing with Opera, I think it’d have a fighting chance in sucking me in, though. As a rule, I prefer browsers made by browser software companies, not operating system software companies.

That said… although the properties I’ve mentioned earlier (word-wrap, border-radius, and outline-offset, aren’t exactly going to see a lot of use by me. However, CSS3 rgba colors? I’m all over that. I especially enjoy the ability to set an element’s opacity without it affecting all of its children. I don’t think it was a good call for Opera to skip adding this into 9.5, as it means it may be a while yet before we see it in an official Opera release.

Well, on the plus side, it let me escape the vicious SVGorilla.

Firefox 3 will have display: inline-block. Hooray! I always felt this was a great way to do things like hyperlink buttons and such without having to worry about all the floating nonsense needed to get a block in certain locations. Thankfully now all the major browsers will have it.

I spent an ungodly amount of time yesterday trying to concoct a method to doing liquid column layouts without an extra wrapper element, and somewhere along the way my brain started hurting a lot. It keeps feeling to me that there’s somehow a way to trim the markup down to just the one element each per column, but it keeps barely escaping me. I was hoping inline-block would prove the key to this, but so far I’ve had no luck.

One of my thousands of permutations of CSS worked only in Opera (which I found odd), and another in IE (which didn’t surprise me, as it’s always ’special’), but as of yet nothing has produced what I desire for Firefox and Safari. Yes, I could get two elements to nest next to each other, yes I can get one to sit on one side of the screen at a fixed width. The problem is that although I can have the remaining column adjust it’s minimum size based on the width of the parent and otherwise be elastic, I couldn’t get it to expand to fill the width of the space on it’s own (rather than, say, because it has a paragraph inside it that pushes it’s borders out to fill the space it’s in).

I’m guessing there’s a reason the negative-margin layout (aka this) is still around.

I haven’t given up hope yet, but I’m beginning to hit a wall here and suspecting that it’s just not going to happen. So I’ll ask, has anyone  had any luck doing a two-column liquid layout design with CSS without resorting to a wrapper element for one of the divs (aka, standard negative margin layout)? To increase the difficulty rating, a footer would need to be beneath the columns (so you can’t just use absolute positioning) and the solution can’t use javascript.

Every time I have to slave away at a CSS solution to a problem that could be easily solved by CSS3’s multiple backgrounds or border-radius, I want to inflict harm upon myself. This is exasperated by the number of rounded corner designs I seem to be working on today. (Are those currently in, out, or tacky?)

At the moment, the only notable (sorry Konqueror) browser to support both is Webkit (Safari). Firefox supports border-radius, but neither IE or Opera support either. Granted, Opera’s percentage of the browser population doesn’t make its feature set a deal breaker, but it’s simply impossible to put these solutions into play when IE’s massive user-base can’t see them.

*sigh*

I’d be less melancholy about it if Internet Explorer 8 was going to bring at least one of these with it. But no, that would be too nice.

It annoys me that out of the various improvements CSS3 is supposed to bring to the table that these two are so far away from implementation. The amount of presentation-only markup (the great enemy that CSS is meant to fight) that would be eliminated is immense.

That’s alright. I don’t mind putting three to five elements on a page where I should only need one.

I’m going to go get some warm milk and cry myself to sleep.