cf_lensflare

A stupid little story to share.

I do a lot of work with Cold Fusion. The other day I hear that Macromedia (who owns ColdFusion) has been bought out by Adobe.

So a friend of mine makes a comment about how one of ColdFusion’s new features is a lens flare tag that throws up a lens flare on a web page. Lens flare being one of the most (ab)used filters in Adobe Photoshop.

Well I think for a minute, and decide it’s absolutely doable, and set to work. I created a lens flare on a black background in Photoshop. I then used the color selection tool to select and remove the black color. This left me with a nice transparent png flare. Good enough for me, afterall this is just a quick goof, nothing I want to really waste time on.

I then create a quick custom tag in ColdFusion which creates a DIV and absolutely positions it on top of the page in the upper left-hand area via some inline CSS.

The PNG is placed inside the div block. I even threw in the filter line needed to get IE 6 working with transparent PNGs.

Silly stuff.

Developer Notes

Several layouts of mine have utilized a trick where side columns’ widths are defined in EMs. The reason behind this is that if a user increases the default font size of their browser, the column’s width will increase with the font so that everything you expect to fit on a single line in that column will continue to fit on a single line regardless of the user’s font size.

While mucking around with a new layout, I’ve found that IE needs to be coaxed into performing this trick. Most of my layouts have a top-level element that contains the entire page (usually named pageWrapper or pageContainer) and if I set width: auto in my CSS for this element, IE starts resizing the columns as expected.

Another oddity I’ve come across is font sizes in Opera. In a couple of my layouts I’ve thrown in some CSS to increase Opera’s base font size by 10% so it would match the sizes seen in other browsers. Well it appears this is only the case for Arial. When using Arial, Opera seems to use a font size 10% smaller than other browsers. When not using arial (Times New Roman) the default font size in Opera matches other browsers.

Just thought I’d share.

New Layout?

Here is a mock-up of a layout I started taking a crack at today. Seems simple enough, doesn’t it? Well it isn’t.

The key to this design is placing gaps between the various block elements in the layout. Most of that is a simple matter of defining margin values on each of those elements. However we run into problems when trying to put gaps between the three columns.

One other feature I want is to keep all three columns the same height, just like in skidoo too This is achieved through some CSS trickery best explained in the original skidoo layout. At the moment, I know of no real other way to achieve this effect, short of using some kind of javascript.

Another effect I want is that, since we’re introducing gaps between elements, each element should have a border around it to futher define the border of each element. It makes things look more clean, imho.

So, first thing’s first. How do I create a gap between the three columns? I don’t. I make it look like there is a gap. I can do this by turning those 1px black vertical borders you see separating the three columns in the a href=”http://webhost.bridgew.edu/etribou/layouts/skidoo_too/index.html”>skidoo too layout into 10px wide borders that match the background color users will see in the gaps between other elements. That’s pretty straightfoward.

The next problem is I need to wrap all three columns in a 1px border. Long story short, I can’t wrap any of these columns in a single DIV or other such element and apply a border. If I did, those DIV blocks would only run as tall as the content for each column. Remember, a href=”http://webhost.bridgew.edu/etribou/layouts/skidoo_too/index.html”>skidoo too fakes the appearance of three columns carrying the full height of the page. In reality, each of the three columns have their own element that is only as tall as the content for that column. You can’t apply a border to them because the bottom for the 3 separate columns will be in different places.

Okay, so what to do here? We’ll have to use several other elements to paste a border around each column.

First thing is to create the side borders. The middle column’s side border is simple enough. I can add in a new DIV block, just below the element now being used to create the 10px wide gap, and apply side borders to it. That gets me the side borders for the middle column. I do the same, but put the DIV as the parent of the 10px gap creating element. This creates the right border for the left column, and the left border for the right column, or the inside borders for the outside columns. :)

So next is the outside borders for the side columns. This is simple enough, I can insert a new DIV element that becomes a parent to the element creating the borders used as the background colors for the side columns. Set the side borders for this new DIV to match the others, and we’ve got side borders for all three columns in place.

Now the really tough part: top and bottom borders.

I could use this newly created parent DIV that creates the side borders for the side columns. Just one problem: this border will carry across the top of the “gaps” between the three columns, destroying the illusion.

So my approach is to take the element generating the gaps (created using borders that match the background color) and setting top and bottom margins to -1px.

That, in theory, should work. It doesn’t. IE and FireFox both have their problems with this approach, and that’s been driving me nuts all day.

The solution I’ve come to (for the moment, anyways) is to use the element parent to the gap-creating element. This is the same element used to create the inside borders for the side columns. Setting -1px top and bottom margins on this seems to work better for IE and FireFox. But there are still problems.

Long story short, via trial-and-error I’ve found the most compatible solution is to stick a 1px vertical padding on the element that generates the background colors for the side columns. I then apply a -2px vertical margin on the element used to create the inside borders on the side columns. This seems to work.

A few loose ends to clear up. IE still needs some hasLayout hackery to get things rendering correctly. There’s no science to figuring out what elements need the hack (or which one) except by trial-and-error. Once that was squared away, things started working as intended.

Believe me, I was very surprised this actually seems to work. Opera, FireFox and IE 6 all seem to be happy. I’ll need to do a lot more testing, debugging, and cleaning of the code, so my soon-to-be new layout is not ready for prime-time yet. And in fact, when I do “release” it, I’m going to tell you not to use it, ever, because it’s ugly and certainly as buggy as any CSS layout. But you won’t really listen or care, and that’s okay. :)

Anyways, I said I was going to share, so here it is.

This is a simplified layout that I used to figure out the column-gap problem. A lot of the CSS in the demo below isn’t in this example, so I suggest looking at this first.

And here is the full-out demo of what I have so far. Note that the relevant CSS is being imported from here and here. The latter is what you should look at as the former is just bits of skidoo extracted and simplified a bit and nothing veterans to this site haven’t seen before.

Very fun stuff (once it’s working).

OH! One last bit of info. There is some additional padding on the side columns to offset their real boundaries with the appeared boundaries.

Again, DO NOT USE THIS STUFF IN A REAL WEBSITE. It’s far from tested and perfect. It’s here to 1) show you what I’m working on and 2) as an educational tool for CSS developers and 3) a “proof of concept”.

I’ll post a real working version of this sometime soon (hopefully).

Typefaces and sIFR

I received an e-mail from Wil who wanted to pass along some quirks he found with the gargoyles layout. It seems that when using sIFR inside the masthead area, any padding on that element needs to be removed. He also mentioned a bug relating to sIFR and possibly percentage values.

Anyways, first thing that crossed my mind was what the hell is sIFR? A quick search led me here and here.

Essentially, sIFR is a package used to replace HTML elements with Flash (the FR in sIFR standing for Flash Replacement).

The (original) reason behind this is to provide a richer set of fonts to the user without having to worry whether or not the user has that font installed on their system. By creating a Flash movie with the font embedded in it, you can give the user the visual experience of the font.

The way it works is you first create an element, say a H1 element, which acts as the title for your page. When the page loads up, that H1 element is rendered. Then the javascript kicks in and calculates the dimensions that H1 element contains. It then inserts a Flash movie over the targetted H1 element, giving the movie the same dimensions as the H1 element. Flash users get the rich text, non-flash users get the usual H1 text.

Very cool stuff. A couple of comments on this.

The first thing I like about this is that all of the information presented to the user is contained within the HTML document. The headline is there in H1 format which allows screen readers, search engines, and any non-flash users to access the information. This is very important. A lot of sites that use Flash, especially for minor parts of the page such as a heading, don’t provide an alternative source (such as text) for the information presented in the movie.

Another thing I like about this approach is that the replacement is done inline, without requiring user interaction. A lot of Flash-based sites require the user to select a non-flash link before being presented with the text-alternative for the site (if one even exists!)

I like that the HTML document can stand on its own. Remove the Flash and you’ve still got a complete document. You’re building on top of a complete document rather than taking a bit of information, sticking it into a Flash movie, and then creating a text-alternative as an afterthought.

It’s building on-top of an HTML document, rather than breaking an HTML document.

Typefaces

Now. My brief sIFR research pointed me towards an article titled The Scourge of Arial. It talks about how Arial is a pervasive font, found everywhere, and how the author dislikes the font.

Here’s my opinion: I like Arial. It’s functional, ubiquitous, easy to read. It looks clean without any aliasing of any kind. One of my big gripes with a lot of the more fancy fonts is that you’re going to need to alias them in order to make them look good. But aliasing, especially within Flash, creates very fuzzy edges that make the text look almost out of focus.

In website management, my top priority is the delivery of information to the user. Design is a very distant second. It would seem that the two should coinside; design will help determine how the information is delivered to the user. And this is absolutely true, but I much prefer to under-design than over-design an interface used for delivering information.

I’m old enough to remember the earlier days of the internet (think 1990ish) when all we had were flat pages made up of just paragraphs, lists, and headings. Very, very boring stuff, but also very efficient at delivering information. Afterall, if your user is busy looking at the rotating image element on your page, then they aren’t reading your content (assuming your content is text and not, say, an art gallery displayed primarily with images.)

I like CSS in that it allows additional visual structure to the layout of a page. You can provide implicit relationships between various pieces of your page, such as a sidebar which is not the main content and could be skipped by a reader who needs to pick through the page quickly. You identify this sidebar by having a literal bar on the side of the page, maybe with a different colored background, that identifies that block of information as a sidebar. You can also break key information blocks down into columns for easier access to headlines (3 story titles on the top of the page without needing to scroll. Nifty.)

Once we get into typeface, graphical elements (that serve no purpose other than to be visually interesting) and such, I start to lose interest as they belong to this distant secondary priority when it comes to website design. Which is why all the layouts you see here are pretty blocky and plain looking. But then again, I’m not a graphical designer, I’m just a guy who plays around with CSS.

ST:Gargoyles Right Column Width

While trying to catch up on my e-mail, I received one from Tim who mentioned he had a problem with the gargoyles layout. He had an image, say 200px wide, sitting in the right column. When a browser window was narrowed to the point that column was too narrow to contain the image, the column was pushed down below the content.

This is one of the big problems (if not the biggest) with fluid layouts. Fluid layouts work great as long as the browser is wide enough to allow the fluid elements to contain their content.

What is a fluid layout?

Really quick to make sure we’re all on the same page. A fluid layout is where the layout’s dimensions (typically the width) is based on the width of the browser. So if a user has their browser maximized on a 1024×768 desktop, that layout will expand to use up all 1024 pixels across the screen ( … of course you have to take into consideration the size of borders and scrollbars and such, making the actual size of the layout more like 980-990 pixels wide, but with fluid layouts you don’t rely on pixel values anyways, so this doesn’t really matter. :)

This is especially good for users who have very very large resolutions (1600×1280 anyone?). Imagine a website where the width of the layout is fixed at 600 pixels. Mr. 1600×1280 is going to have over half his screen left unused. It’s wasted space.

So the upshot of a fluid layout is it conforms to the user’s screen, and doesn’t force the user to conform to yours. I like that very much.

But your layout’s dimensions (width of a given column, etc…) is all based on the width of the user’s window. So if a user shrinks there window to a very narrow width, that browser is going to try and fit your website’s content into that narrow area. It won’t fit, and you start to see the layout break.

A fixed width layout defines how wide it must be. The browser that is narrowed below the fixed width value will simply generate a horizontal scrollbar. The layout remains as intended, but the user has to horizontally scroll. Isn’t this just as inconvienent as a broken fluid layout? Maybe, but I don’t think so.

CNN.com is fixed width. Gargoyles is fluid.

Onto the matter at hand…

My layout is bursting!

The gargoyles layout is especially unique in that not just 1 column is fluid. Both the middle and right columns are fluid. Both columns shrink and expand as the browser window does. (The left column is fixed at 14ems, which is actually kind of fluid in that as you change the default font size, the width of the left column increases. But that has nothing to do with what I’m talking about.)

Fluid elements, fluid layouts, etc.. they all run into the same problem. As I’ve already said (twice now? or was it three times?) if the browser window’s width is made too narrow, that a fluid element is not wide enough to contain its content, then the column is going to be pushed down because it’s a floated element. This is to be expected since that is how floats work. So when using a fluid layout, or any layout with a fluid element, you need to keep this “issue” in mind.

Okay, so how do we fix it?

The simplest solution is to just not use anything with a static width, like an image, inside a fluid element. But you don’t want to bore your readers/users do you? So we’ll have to do something to let images work regardless of window size. Incidentally, text can trigger this “issue” as well. Set a column 50px wide, increase the font size to some insane value like 1000%, and even a small word like “hello” is going to be too wide to fit. So even sticking to just text really won’t work.

Min-width might work, but IE doesn’t recognize that CSS attribute; so scratch that idea.

Well we could set a static width on the right column. Set it at 220px or something similar, and just make sure you and any other content providers understand nothing wider than 200px can go into the right column.

This works rather well, actually, and is what I suggest most people do. So do that, and don’t read any further, because I’m only going to confuse you.

Okay?

Seriously, stop reading.

Okay, but remember, you asked to be confused!

So you really want that fluid look and feel. Well you could write up some elaborate javascript that monitors the width of your variously fluid elements and when the window is resized too narrow, the javascript assigns a static width to either the element(s) in question, or the entire layout.

Controlling individual elements in the manner described above would be nice because it would allow for more … “fluidity” because if you have more than one fluid element, as soon as one hits its min-width limit, that gets locked at that min-width allowing other fluid elements to continue shrinking. Applying a global width lock (locking the width of the body element, for example) as soon as the first fluid element hits its limit wouldn’t be as efficient as other elements won’t be able to shrink to their limits, resulting in a page that doesn’t go as narrow as possible before applying the width lock.

Javascript? Did you go “uck” or “ew” when you saw I was heading in a js direction? Thing is, with IE, we have to if we want any kind of min-width functionality. The trick is to not be controlled by it. Javascript is there to help enhance the layout, but is not an integral part.

Take the case of the min-width emulation I put together in Javascript for IE. It’s there to set a 600 pixel min width on the gargoyles layout. If you don’t have Javascript enabled, it won’t change how the layout looks or functions, except when you set a really narrow window. How often will that happen? My theory is when a browser window is set that narrow (under 600px wide) the user is probably doing so just to get it out of the way. When the user wants to go back to your website, they re-enlarge or maximize the window. So I’m not really worried about it. It isn’t integral to my site.

So what about Tim’s case?

Well, I suggested we make use of the min-width emulation. Calculate out what the min-width for the whole layout is to keep the right-hand column from going too narrow to contain the image in question. The default width for that column is 30%. The math here is simple, image width / column width or 200 / .3 which gives us 667 pixels. Now there’s some gray area between IE and FireFox box models and how widths are calculated, so to make things simple, I’d add on an extra 20 or so pixels, and just to keep things whole, I say add 33 and give us an even 700 for the min-width value. At that point the right-hand column will never go more narrow than 200 pixels.

That is what I suggested.

Now what about that stuff about controlling min-width values for individual elements? Can I put something together for that?

Thing is… that gets really really tricky. Because of how contorted my CSS can get, it’s not just a matter of altering the width property on a given element. I have to start paying attention to margin and negative margin values on other elements to make sure a correct amount of space is reserved for the right column. Things get very complicated very quickly. It’s an interesting idea, but not one I’m going to attempt anytime soon.

Besides, I’ve drained my brain on this one, and I’m out of steam.

So there you go. Hope it wasn’t too much of a mindless ramble.

Bricolage

Just wondering if anyone has had any experience with the Bricolage CMS and if so, could you post your thoughts or comments about it.

I’m a bit curious about how people feel about it.

Oh, and I’m back. Been away the past couple weeks.