Webmaster Forum / HTML, CSS, Scripts / CSS / August 2005

Doesn't do nearly enough. For one thing, there's no separate page header,
which means that once the header is added, his absolute positioning
trick for the left and right columns is going to be a serious problem.
He also sidesteps the issue of doing columns within the footer.

This text size is a little smaller than I would normally use; this
is an experimental page with a lot of test stuff going on relative
to styles.  I needed to be able to fit a lot of stuff in view to see
how things interact.

At least the text sizing is completely responsive to the text size
option in the browser.

Could you vague that up for me, please?

Diane

In article
<pt2kg110otkpq8d9mjlecje499td5oguda@news.spartanicus.utvinternet.ie>,
invalid@invalid.invalid says...

Whic is pretty much why I continue to use tables for layout.  They're
versatile, flexible, robust, and mostly bug-free, which is a lot more than
anyone can say about CSS.

I got bugged by all this again when I happened to notice that one of
the local web design firms put "using CSS for page layout" as a
job skill requirement.  Unfortunately, their own web site is full
of the same hacks and limitations that everything else I've seen using
CSS is prey to.

I understand about all the bugs and incompatibilities in various
browser implementations and display models, but the W3C CSS standards
must take a large share of the blame as well. The ability to put
together a robust and predictable grid structure is the foundation
of any good visual structure. I know that some people have put
together some very interesting pages with CSS, but they all seem to
work around structual weaknesses and omissions in the CSS standard.

Diane

For us css layout newbie's, where would you say there is a good layout
to start with, bearing in mind all the browser hacks etc that are
required in this 'art'?

__________________
Regards

David M Wicker
www.atf-uk.co.uk
__________________

Well-constructed layout tables have none of the defects you refer to,
and allow for a fair amount of "float" as well.  If (and so far, that's
still a big IF) the web ever makes much headway on mobile devices, the
world will have to change, but so far CSS hasn't blzed that trail well
enough to be a true replacement for tables.

That kind of misses the point, and underscores one of my basic complaints
about CSS.  There are *centuries* of experience with text layout and
visual design. Much of it translates very well to flexible media like
the web. However, CSS was seemingly designed in deliberate contempt of that
body of experience. It's not just the CSS layout problems; it's part of the
basic vocabulary and capability of fundamentals like text and paragraph
typography controls.

CSS has also perpetuated some of the worst aspects of the things it
was designed to replace.  As much as I hate <font> tags, the average
user has a lot more flexibility to deal with under-sized type if a
page is written using <font size="small"> than if the page is written
with <span style="font-size: 8px;"> (or equivalent with proper external
style sheets). One resizes automatically when I select larger type
size from IE's menu bar; the other doesn't.  The web would be a much
friendlier environment if CSS had not supported absolute type sizes,
especially in pixels or points.  (Inline style definitions are another
hot button, but I'll stay off that one for today.)

Font-sizing rants aside, the basics of visual design and visual
structure don't change so much from one medium to another.  Things
like running headings and running footings are extremely useful in
print, and have their functional equivalent in page headers and footers
on the web. It's something that's easy with tables and very difficult
with CSS.

Alan, I know you've been doing web pages longer than most of us, and the
fact that neither you nor many other talented people have become "good
at it" yet is indicative of the problems inherent in CSS.

When I do see attractive pages in CSS (such as Zen Garden), I can almost
hear the sigh of relief from the designer along the lines of "ahhh,
another page where I've avoided the necessity of complex headers and
footers!".  The problems don't show up until you try to translate those
techniques to a different visual structure.  CSS isn't just limiting;
it's constricting.

Diane

snip all

my own .02 centavos...

i've been doing heavy css in last few weeks.

but i decided to avoid relearning tables.

at this point. i think (partly intuitively) that advantages of css outweigh those of tables.

to the OP: i've had good results with full horizontal divs. top and bottom (which i ahvne't
used on any of my real pages)

teh intervening horiz divs are full iwdth "wrappers".

within *some of* those divs, i have inserted more divs! and inset a few divs into one of
those inserted divs. ha!
yep, much like nesting tabels.

but eventually i run into the real truth. html is not layout (eg, quark) or desktop
publishing (eg, word). (admittedly those don't produce 'fluid' layout, but their layout
details are much quicker to adjust)

html has no layout-editing flex.

so i also agree with those who say that teh much-vaunted css showcase pages work
due to simplicity and evasion:
huge (wasted white space) margins, lots of flowable content (wrapped text, but few large
images)

------
by good results with my pages, i mean that i can drag the edges of window rather  
small (30% of maximiazed width), and content behaves decently fluidly.

how do i do it with so many images?
overflow attribute.

also as at least one person here mentoined: I use em and % to size things. and watch
the arithmetic. here and there tweaking with px makes sense (such as locating targets
or borders relative to images.)

unfortunately, my layout expectatoins have caused me greif... i've had to do so much
tweaking when i decide to reword text. and the connectoins within the content cannot fit
into 2 dimensions.

-------
one other layout thing. IE can't seem to handle more than one 100% hor wrapper. so i
just stack rows of divs. layout of Html file:

'header' hor100
       wrapper100[
div50 div25 div25
div50 div50
div30 div30 div 35
         ]end wrapper100
optional 'footer' hor100

       all divs are float left class
       leftmost divs are clear left class
       divs containing only images are overflow:hidden;  class

my css has list of divs by % width
like this

.div3 {width:29.5%;}
.div35 {width:34.5%;}
#wrapper100 {width:99.5%;}

       etc

note, one must be careful about "reusing" .divs! otherwise, use the once-only id type
divs:
#div35 {width:35%}

if you need multiple 35% that cannot have clear left (or magrin tweaks) in common?
then use
#a-div35, #b-div35 {width:35%}

then in style sectoin of html file, i list whichever divs need clear left
and second list of divs that need overflow hidden

then individual divs that need individual margin and padding tweaks. and..

I'm trying to develop some standard methods for flexible visual dividers. HR is not
reliably stylable.  and i've used nbsp with some lines of H3 ("blank lines") to force
dividers.
(but i'm trying to kill my need for precise visual layout!)

---------
and i've got indents i can't overrride in some divs. i assume one of the outer wrapper divs
has caused the indent (margin, padding) Yet specifying margin and padding in the
particular inner div has no effect. (of course, complelty killing all styles removes all
indenting  :-)   )

-------

on my current luxury wishlist, is hi % opcatiy on a non scrolling {position:fixed; }
pagename div, but i'd like the div to slip under a scrolling menu (regular div) at top. yet,
z-index doesn't work.

regarding silly w3 standards?
1        not allowing block elements inside a href

how else are we to incorporate an img and caption into the same link!?!? this is
necessary for hover behavior. maybe i haven't stumbled across the solutoin.

2        excessive wordiness class="blah" style="border-style-top:whatever"
3        strong? b is faster.