Templatix Blog

When working with DIV-s (as I’ve been doing, for a while now), if you want a layout going down as long as its contend goes, you’re forced to work with FLOAT-s. That is, with DIV-s that are positioned RELATIVE and that have a float:left or a float:right set up on them.

The Problem
The problem is that the FLOAT’s visual rendering model is an archaic one, dating back when a float was limited to an <IMG>’s align: left / align: right, which allowed the text to flow around an image (or an image to “text-wrap”). Back in the day, a float was limited, conceptually, to < IMG > si < P >. What resulted from the old model? Something like this:

If you look closer, you’ll see that the image included in the first < P > (marked with magenta in the image) has an align=”left” (the functional equivalent of float: left; in CSS), which makes the < P >-s (including the ones to follow) to seamlessly flow around the image. All nice an dandy.

But what do you do when you want that image/float to “force” the height of it’s containing holder? What do you do if you want that < P > -ul containing the image to stretch down in a way to include ALL the image? That was easy peasy with tables, but DIVs make it much harder. Continue reading ‘CLEARFIX – problem and solution for FF and IE (incluing IE7)’

Here’s an older, html trick, from the days when CSS was just a dream…

If you ever tried to get an 1px; border on a table, in HTML, you probably wrote this: < table border = ” 1 ” bordercolor = ” #000000 ” > etc. But see it in a browser and it’ll show 2px borders instead. WHY? Simple, if you come to think about it: because, when defining the 1px border, it applies to both the table and it’s cells (by means of inheritance), and the 2 borders adding up always result in disurbing, thick, 2px borders. To better understand how this happens, suffice it to give the table acellspacing=”5″ – only then will you see how, in fact, the border was 1px thick… The 2 cases look like this:

Still, what to do, if CSS isn’t at hand and you still want that fine 1px border? Use this little trick:

< table cellspacing = ” 1 ” bgcolor = ” #000000 ” > … and then give all the cells a white background-color. This way, with no table-border but with an 1px spacing, the spacing WILL BECOME the 1px border you wanted in the first place.

SIMPLY PUT: menu with submenus, CSS-only (no JS)

Any modern browser (implicitely excluding all versions of IE), if is playing by the CSS book, has support for the dynamic pseudo-class “:hover” on ALL tags, not just on the lonely sad pathetic < a >.

Note: As you may already know, in CSS there’s a series of dynamic pseudo-classes (:hover, :active si :focus) that traditionally get associated with “a” in order to create different styles for the 3 possible different states of a link, as in a:hover, for instance.

Modern browsers, as I was saying, having implemented the support for this, allow for the association of the pseudo-classes with any HTML tag. In other words, you could very well define something like:

td       {background-color: #cccccc;}
td:hover {background-color: #336699;}

which would result in a background-color change on those td-s, on roll-over, without any need whatsoever to use HTML-bloating javascript code.

Continue reading ‘:hover’

It happens often, when working with tables, to “forget” empty cells, i.e. cells without any content at all within, not with even as much as a shy & nbsp ;. That makes them look awkward in the browser (awkward = borderless) and,most of all, to look like coding errors, which coulod become unpleasant. For those lacking the patience to fiddle again the whole html code, there’s a solution: to define the following property in the CSS code:

{ empty-cells: show }

This will force all the empty cells to SHOW the border, even if empty. (the other possible values for this property are: hide and inherit)

Here goes a mighty fine job: a test meant to show just how well implemented is the CSS support in a browser. The test starts from a rendering considered corect (reference) and you get to compare that render with the test-page as viewed in your browser. Extremely interesting for a CSS geek like me…

Acid Test 2

For the sleepless… a page built exclusively with CSS… even though it doesn’t look like html… guess how they did it.

For those using Firefoxe’s Firebug, inspecting DOM elements is already a breeze. But what about Internet Explorer? The guys at slayeroffice have created a new DOM inspector that works on any browser, which is easy to install, by simply bookmarking it. It’s not as advanced as the Firebug, but it can prove extremely useful sometimes. See here

…or “Building An Expanding DHTML Menu With CSS and JavaScript – revisited”.

What’s this all about: a vertical menu with submenus which are hidden initially and show on rollover.

Requests:

1. On roll-over over a zero-level element, the corresponding sub-menu must appear
2. On roll-over over another zero-level element, besides the effect from point 1. any other secondary menu must hide, only the the submenu corresponding to the active roll-over must remain visible

The most elegant solution I found is in the page linked at the beginning of the article, but it was a bit too long for what I needed, so I took it, adapted it, and I got exactly what I need (see here a functioning example, with all it needs to understand it, if you look in the source).

Later edit: for a more elegant menu version (in terms of coding and approach), but less functional and without JS, read here (in Romanian).

Versiunea in Romana a acestui articol aici.

I used to write some time ago about the possibility to create graphically rich and yet still editable buttons.

The first problem with tha approach was an optimisation issue: foe each button you’d have to use 2 images, hence 2 different requests on the server. In time, and on a crowded server, any problem of this nature begins to show, and to ask for optimisation.

Second problem: on top of that, our buttons lacked any roll-over effect.

This made me re-think the approach of this problem:

1. Before, I used to use 2 tags, like so:

A)
<li>
  <a>button here</a>
</li>

The new approach still uses 2 tags, but this time in a bit different manner:

B)
<a>button here<div class=end></div></a>

The new DIV, marked by the class “end”, has the precise role of defining (graphically speaking) the right end of the button. I’ll just go ahead and enter below an explanatory graph, followed by, well, explanations:

As you can see in the image above, instead of using more images, we’re just going to use a single image, long enough to cover any scenario* and double in height: one row for the normal state and one row for the “over” state.

Continue reading ‘Graphically rich yet still editable Buttons (and/or tabs) (optimised and now with roll-over)’

I wrote, some time ago, about how to solve this problem with min or max dimensions in more retarder browsers.

The solution proposed was to use conditional javascript expressions inside the CSS file. Not very elegant, and quite limited.

Meanwhile I found a much simpler, more elegant and better validating solution. Let’s say we want to get a min-height of 400px. How do we go about it? Easy enough, we use 3 CSS properties instead of just one, like so::

min-height: 400px;
height: 400px;
height: auto !important;

And, miracle! It works! In every browser that I always test against: IE6, IE7, FF, Opera, Safari. Enjoy…