21 Re: Server-side detection is still a hack

I am sure, at some point, I am wrong in my thinking, but I’ll ask the questions anyway.

When a saved document is said to be “portable,” should it also be considered that relative links from the saved page will not work? It may be portable, but the saved page is out of context from how it was meant to be delivered – via the web, by way of server, in a particular browser, at the moment whent he page was reqested.

How much should we ask the page to do itself?

Is the work of presenting the page finished at the moment it is finished loading? Does server side detection accomplish the task just as well.

Or is the issue how to best impress upon the makers of web browsing software the need to adhere to an agreed upon standard… does making hacks and workarounds actually not serve this cause.

If the page, at the time it is viewed, is presented in a way that adheres to a standard, is still functional to the user (but still uses browser specific markup), would this also make browser manufuacturers reconsider how they design their product?

If they knew that pages saved using their browser could only be viewed using their browser – and not easily shared across a company, or repurposed into other applications – would it force users of their browsers to ask them to change.

Is the use of hacks (within the page) counter-productive to the cause of promoting standards compliant, non-browser specific web pages?

posted at 11:47 am on November 17, 2002 by johnt

22 Re: Finally, an article addressing footers

“Someone had also mentioned that they think creating columns with floats is a way better solution. While it’s easier to insert a footer if you just use floats, using floats presents a whole new set of problems, hacks, and workarounds. Floats, except very simple ones, do not act reliably across browsers, and if you put a lot of content in a floating div, often times it will get cropped in some flavors of IE.”

http://www.xs4all.nl/~apple77/columns/
I am still working things out, so don’t pick on me. So far, it looks very consistent on all mainstream 5+ browsers – only Konqueror seemed to mess up the 5 and 4 column layouts (3 columns inside one). No hacks (except just the @import).

Oh yeah, another thing. Avoid DIV soup wherever possible. I know my examples don’t, but there is not much to markup either (yet).

posted at 01:30 pm on November 17, 2002 by Kris

23 absolute vs. float vs. tables vs. something else

Mike. I think half the problem is that neither absolute positioning or floated DIV are the proper way to achieve the layouts designers want. If you go the CSS2 specs ( http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-display ) you’ll see that there are more display types than just in-line or block. I’m wondering if these other types would let us create layouts without using float:x or position:absolute etc.
Unfortunately, not even Mozilla supports any of these, so I haven’t been able to play around with them.

I imagine the code might look like this:

#top {
display: block;
} #leftNav {
display: run-in;
width: 20%;
} #content {
display: run-in;
width: auto%;
} #rightInfo {
display: run-in;
width: 200px%;
} #footer {
display: block;
}

Of course, I’m not to sure what would happen if you put a whole lot of text in, the fact that it wraps. Quite a few times I’ve had a float layout that works OK, but then falls apart when you add content. It would be nice to have some options to control how wrapping in-line content within a block affects it’s width.

Then again, it maybe of no use all for layouts. W3C don’t always have the most clearest descriptions, leaving things to be interpreted 3 different ways.

—-

Kris. Nice layouts, I’ve seen a few nice floated layouts lately that seem to work well, and even across a lot of browsers. But there is only one problem with all the layouts I’ve encountered; the order of the content quite often makes no sense. While that maybe OK on smaller sites, it’s a bit of a problem for those of us who work on large .gov sites that also need to meet accessibility guidelines. I realise that it’s possible to use hidden links etc to each section, but it still feels like too much of hack.

—-

I’ve been working on a new layout for http://www.stats.govt.nz (yeah, site is horrible at the moment, the idea is to overhaul the whole thing). I’ve got 3 versions: A basic table layout, very clean, no nested stuff; a floated layout, having a few problems getting it to work on all browsers since it’s quite complex, and the content is out of order; and an absolute positioned one, that’s working OK so far except for the lack of footer.

At the moment, the table layout is by far the best. It’s code is leaner, it works in all browsers, it keeps the columns in sync which looks nice, the content is in the right order, there is no chance of content overlay (which has to be considered when designing a site in which you have not control over the content entered).

The only bad thing about the table layout so far, it doesn’t degrade fully, and it’s a hack, not the correct way to design a layout. The former being the biggest problem.

When are W3C going to take a few clues and give us something we really want? I understand what they are trying to do. But there are still big problems with CSS at the moment. It shouldn’t be this hard an complex to get a simple layout to work with no problems.

Oh well, the search for the holy grail continues I guess.

posted at 03:12 pm on November 17, 2002 by Justin Bell

24 re: absolute vs. float vs. tables vs. something e

“But there is only one problem with all the layouts I’ve encountered; the order of the content quite often makes no sense.”

Justin. Content first. They definatly make sense (to me). I put them up with no regard to layout at all, just structure and order. There was one point though when I was forced to let the order be dictated by the intended layout; it resulted into one subcolumn (that can still contain something else than basic navigation) that neede be placed before the main content. This, to ensure I could still use floats.

Lateron I realized that it may also be worth examining other types of positioning a little better in order to structure content completely independant of any layout i have in mind. All goes well, just not perfect; but when is?

It also greatly depends on the type of content some elements contain what is logical to place upfront. My examples reveal very little content and are therefore also very hard to structure semantically, hence the divsoup. But that will change once i start working on better examples.

posted at 03:40 pm on November 17, 2002 by Kris

25 The script!

Even though I don’t really agree with the javascript hack (though I’ve been very tempted to do similar things myself), here’s the code to go through each node in the DOM:

function fixHeights() { var divs = document.getElementsByTagName(‘div’); for (i = 0; i < divs.length; i++) { if (divs[i].className == ‘fixMe’) { changeHeight(divs[i]); }
}
function changeHeight(div) { var child = div.firstChild; div.style.height = child.offsetHeight + ‘px’;
}

I’m not exatly sure how your layout works, this requires that each absolute positioned div needs to have a content wrapper inside it if it has more than one child (unless you modified it to go though the siblings and get the largest height, which isn’t to hard after I think about it). The div to fix need to have the class ‘fixMe’, and the ‘fixHeights()’ goes into the onload in the body tag.
It should work on IE 5.5 and NN6.2., although, I haven’t tested it.

posted at 03:41 pm on November 17, 2002 by Justin Bell

26 Re: Look Forward Not Back

Alun David Bestor: Yes! I must have missed your post before. I totally agree. The way tables work are great for layouts. It’s fact that they were never designed to do it which is the problem. I’ve also thought about all the table types for the display properties, they seem like the best hack at the moment IMHO. But I thought they weren’t supported in any browser, like the rest of the display types other than block and in-line?

posted at 04:05 pm on November 17, 2002 by Justin Bell

27 IE 5 Mac Hack

Yes, hacking is bad, and i’m willing to simplify design to some extent… but simplification can be taken too far.

speaking of which, here’s a hack that will solve the problem of having to use javascript to sniff for ie 5. it will allow you to deliver different stylesheets or just different classes/ids to ie 5 mac.

http://www.sam-i-am.com/testsuite/css/mac_ie5_hack.html

posted at 05:24 pm on November 17, 2002 by Frank Fledman

28 IE5 mac Hack: server-side browser detection?

Instead of using the JS hack, is it possible to detect the USER-AGENT via SSI, PHP, or VBscript? Could we not route a separate stylesheet to IE5 Mac (or other non-compliant browsers)? I’ve been looking, and haven’t found a good “table of user-agent-detection” scripts for SSI. Any thoughts here?

There was an article posted on macromedia.com that discussed how they did this exact thing, different style-sheets for different browsers.

This seems much more elegant than a JS hack, especially because the browser will only get the code it needs. Thoughts?

posted at 07:28 pm on November 17, 2002 by Allan W.

29 Re: IE5 mac Hack: server-side browser detection?

I believe another argument against the server side method (besides the prior stated ‘portable document’ reason) would be file maintenance. If one wanted to make various media style sheets, they would need to make n x the number of files (n being number of different browsers). Same idea for having site ‘skins’ like AlltheWeb.com has. One would need to make a multiple versions of each file thereby increasing workload.

posted at 10:43 pm on November 17, 2002 by Dave W.

30 Beating a Dead Horse Dept.

I did a bit of playing around with display: table-row and display: table-cell last night. Go to www.washboardabs.net/examples/layouttest.html to see an example in action, using content culled from my own site and Dug’s.

The good news: They’re great for grouping divs into robust synchronised columns in Mozilla and Opera 7. The bad news: IE as of version 6 doesn’t support them, so we file it under interesting style exercises for another 3 years.

An interesting note: the test document uses alternate stylesheets, one with a float layout and one with a display: table-cell layout. Neither is set as preferred. The table-cell layout comes first in the source and is the default for Mozilla/Opera. But the float layout ends up being the default for IE6, and since it doesn’t have a builtin switcher menu it never sees the table layout it can’t handle. Hmmm… rubs chin cunningly

posted at 12:21 am on November 18, 2002 by Alun David Bestor