Archive for January, 2006

An effort in futility, CSS vertical alignment

Sunday, January 29th, 2006

A little over a year ago I would have never considered using CSS for positioning. In my mind it always produced unexpected results when viewed in different browsers. After a bit of pushing and enlightenment from Randy and Steve H., I’ve been warming up to the idea.

A recent project seemed like a strong candidate for the use of semantic markup and CSS. This was a departure from my world of certainty, where tables were used to create structure. However, just knowing (X)HTML and CSS wasn’t enough. Based on someone’s recommendation, I bought two books by Dan Cederholm. While a worthy investment and a very informative read it still left me with some questions.

The books served as excellent models for the use of semantic markup and the separation of design and content. The only disconcerting thing was reading this in Web Standards Solutions:

We’re not going to argue either side, but instead state that using a table is sometimes the best way to achieve certain form layouts—especially complex forms that involve multiple controls like radio buttons, select boxes, etc. Relying solely on CSS to control the layout of complex forms can be frustrating, and often involve adding extraneous <span> and <div> tags, with more code bloat then that of a table.

What happen? Somebody sent up us the bomb. In other words, this was the last thing I wanted to read. Where is my knight in shining armor, my holy grail? The CSS can conquer anything, let me show you how attitude. I have to hand it to the guy, he didn’t just say that it’s better to forego certain formatting for the sake of reserving tables only for tabular data.

This leads to me to the issue of trying to overcome the problem of replicating certain levels of formatting, traditionally only achieved through the use of tables. Foremost, and probably the only unsolved issue is vertical alignment. Yes, I know there is an element for it, but it’s not recognized in IE, so STFU K THNX. It’s disgusting how many sites promote CSS hacks as a solution for this. How can someone tell me that a situation where a hack has to be used is more acceptable then using equivalent, compliant HTML.

It seems that my options are to:

  1. Use compliant CSS
  2. Use compliant CSS and a hack
  3. Use a table
  4. Not do it at all

I can’t use option 1, it wouldn’t render in 90% of the browsers out there (e.g. IE). Option 2 seems like the way to go, except that it doesn’t guarantee anything, and still fowls up (e.g. Mac IE). 3 is appealing, and would produce consistent results in just about every single browser out there, however it defeats the purpose of separating style from markup, and there is always someone out there looking to take you to task for it. 4 isn’t acceptable, there is no place for telling a client that they can’t have something in the middle of a page or element because CSS won’t do it.

My choice, a combination of the above. I’d really love to say screw it and use a table. It does exactly what I want, in arguably a lot less code. With an IE hack and Opera fix, the CSS becomes far more complex, and it still won’t work 100% of the time. In the case of putting the main page content dead center in the screen, I’d have to say I’d certainly use a table now. Thankfully I’m not faced with that decision. What I’m working on now calls for a string of text to be vertically aligned in a parent element of known height. The string can occupy one or more lines, which makes it a little more complex. My choice here, fake it. It appears to be the only viable solution aside from breaking down and using tables. It was actually the solution that Randy proposed about a week ago.

It’s annoying to use a compromise. I bet secretly a lot of other developers feel the same way and that’s why there is so little written about the issue. When I asked google about this, it returned mostly pages describing the vertical-align attribute, a huge number of hacks, and a bunch of noise. What I didn’t see was someone rationalizing what the realistic solutions were.

This situation clearly exemplifies that CSS was not designed to completely take over representational attributes. It seems like many people treat positional CSS like a secret waiting to be unlocked, which is the wrong approach when trying to get people to embrace something. In order for mass adoption the standard should focus on a complete set of tools that are easily implemented, the moment hacks and workarounds are involved credibility is lost and confusion arises.

Until CSS is endowed with at least the same level of control that standard HTML provides, we all are going to be stuck in a mix of compromises.

Get Info Update

Wednesday, January 18th, 2006

In an earlier post titled “Get Info“, I discussed the sorry state of affairs surrounding our search for an ideal time tracking and invoicing solution. Of note was the many bugs that we encountered while test-driving Studiometry.

A few weeks have passed since we gave up on Studiometry and I’m proud to report that Software closed all 12 of our tickets, all without a response. I can forgive flawed software if the developer is willing to take steps to resolve the issues, or at the least acknowledge them, but to completely ignore them is downright disrespectful.

iBiz isn’t without its issues, but the developer actually takes the time to respond to bug reports and in many cases quickly addresses them. WIth this kind of interaction, iBiz may actually grow into a more reliable program and better meet my expectations for a time tracking an invoice application.

What’s in a Name

Sunday, January 15th, 2006

Being a mostly Mac shop here, we tend to closely follow Apple news, or at least I do. I’m relatively surprised that I haven’t seen more comments out there about Apple’s choice of name for their new Intel powered pro laptop, the “MacBook Pro”. I understand that it can’t be called a “PowerBook” anymore because it lacks a PowerPC processor, not that many people actually equate the two. It seemed that most thought the name was supposed to indicate that the laptop was geared toward professionals, while the iBook with it’s fewer features and lower price point was for the casual user.

With the new name Apple has had to take a more direct approach because the processor type is absent. Apple’s processor marketing used to tie in very well with model names. Except for the sticky situation when the hyped G5 couldn’t feasibly be put in a laptop. Prior to this instance, the incorporation worked out well and served as evident marker that a product was revised, and that it was time for users to upgrade. I myself seem to fall into that, having owned a PowerBook from almost every processor class. With the new name, I’m not sure how Apple will perpetuate the upgrade cycle.

So why not keep the processor name in? The seemingly smart answer is that they could be more processor independent in the future, which I doubt. They seem to be stuck with Intel for now, for better or for worse. The less obvious answer is, that they can’t have another PowerBook Duo, or anything close to that. Intel’s naming may have gotten less atrocious, but this time its name is very similar to that lackluster laptop.

While I don’t care much for the name “MacBook Pro,” I don’t mind that it’s using an X86. This may give them the ability to release products faster and focus on other elements of the hardware. I was getting tired of chip shortages blowing away every product, and that whole processor leapfrog game. I also see a lot of opportunity for PC users who aren’t completely confident in the Mac OS to buy the new laptop just because it could possibly run windows if they wanted it to.

BBEdit: Escape and Encase a String in Quotes (Updated)

Monday, January 9th, 2006

2007-01-28: I’ve updated the script to correct for a stupid mistake on my part. Now single quotes won’t be unnecessarily escaped.

Here at the Firefall Pro labs we use BBEdit for most of what we do, which is programming of some sort. While working on a PHP script it occurred to me that I spend a small portion of my time encasing strings in quotes and escaping quotes within. Normally this is insignificant, but this time quickly adds up when encapsulating bits of html markup.

The typical recourse is to run a find and replace on selected text and have the quotes replaced with a backslash and a quote (\”). However this only accounts for one type of quotes. To get both you either need to run it again, or make a GREP pattern. Often either solution ends up taking almost the same amount of time that it would to do it by hand, albeit with a little more accuracy, but not at a huge savings in time.

I had hoped that BBEdit would magically have some sort of built in function to do this. They have a few text transformation tools, why not this? Certainly everyone who programs in BBEdit would use it. I didn’t find it, so I e-mailed it in as a feature request. They said maybe it would find it’s way in one day, but till then I should just write my own.

So I did. This file should be placed in BBEdit’s Unix Filters folder and the “.txt” ending should be changed to “.php”. It should run in most BBEdit 8 / 10.4 environments. Naturally use it at your own risk. Despite how simplistic it is, if you find it useful, let me know.

Interoffice Communication

Monday, January 9th, 2006

From Tin Cans, to Retardation

New York, NY, Firefall Pro employees discover a new method of short signal communication. “Gone are the days of tin-cans and string,” remarked Aniel Sud, after untangling himself from a mess of headphone wires. “I can talk into friggin microphone, no wait, earphone. Wait, headphone, is that right? And Aniel can hear me,” proclaimed Dan, loudly and unintelligibly.

“These two have ushered in a transformation in the way we will communicate here at Firefall Pro,” announced Scott Park. “We used to just yell and grunt at each other, but now we have an advanced method of communication, that transcends the intarweb and all other mediums.”

With this leap forward in technology the company foresees being bought by major intarweb player google. Expert in the field, Dan Cuconati (pictured above, right) said, “with this influx of capital we will be able to purchase much larger earphones, and expand our R&D.”

Living with iBiz [Updated]

Tuesday, January 3rd, 2006

Now that I’m forced to live with iBiz I’m going to create a running list of the bugs I find. My hope is that the developer will be spurred on to fix these issues if they are publicly displayed. This list will be updated as new bugs are discovered.

  • Changing the name / class, of an event resets the time log. (2006/01/12)
  • While iBiz uses the data format set in system, it clips long dates in the info panel and there is no way to resize the columns or panel. (2006/01/12)
  • When moving an event, such as changing it’s order among the list of events, or changing the “Job Event” field, the event’s “Log” is cleared. (2006/01/03) Fixed 2.4.9
  • Client checkboxes do not retain their state across relaunches in iBiz Server. (2006/01/03) Fixed 2.4.9
  • A client in the “Client’s” pane may remain bolded even if all active timers have been stopped on all copies of iBiz. This persists even if the client is deselected and then reselected. (2006/01/03)