Absolute DIV positioning in IE7

* *If text is not text, what is the point in having all these images
assembled as they are now. You could have just as well made the whole
page a single image map and positioned your form over it.

Indeed you could.
The final design has a lot of free flowing text around the page.
Having said that, on looking back at the page, large blocks of
graphical text could've been 'real' text. The fear that I have though
is that a font won't match the standard set and the designer will
crack it. Looking at this though, the font's he's used are pretty
standard. The file actually came to me as Corel exported to
Illustrator with all the fonts 'removed' and inserted as vector
objects - therefore, I didn't know 'exactly' what font he used. Had I
just seen it was Arial, then I probably wouldn't have exported the
text as images.

* *If you replace your text images with real text, the design can be
easily and badly broken (overlapping content). And if text is not text,
the site is virtually invisible to search engines and the blind.

Both good points.

* This is not print. If you really have no desire to learn html....

That's not the case at all. I posted the first step in a multi step
task and you seem to have drawn conclusions about it. As it happened,
the first step was "export from illustrator".... so I conceded that it
'looks' like that's all i've done. That template I posted was used as
the basis of a respsonably complex skin in ASPX.

It was / is my desire to learn how to get wonderful and pure HTML/CSS
to work in the evil and nasty MS browsers. I was looking for someone
to point out an IE bug / workaround. As it turns out, I found it
myself (and, as far as I know, it was an IE bug).


Kind regards,



DS

* *Jeff





On Mar 18, 1:50 pm, "rf" <r...@z.invalid> wrote:
DamienS wrote:
That is not a web page, it is a bunch of pictures of text.
Um... ok. Thanks for that input.
My point is that being pictures the page does not do anything.

There is a picture of a login panel there. How do I put in my userid and
password onto a picture of some input elements? How do I click a picture of
a submit button to log in?

When I click on that picture of a "click here" button nothing happens.
That's because it is not a button, it is a picture of a button.

View the site with Lynx, a text only browser that gives a good indication of
what the search engines see, or turn off images in your browser. What the
search engines see is a totally blank page.- Hide quoted text -

- Show quoted text -

DamienS wrote:

If text is not text, what is the point in having all these images
assembled as they are now. You could have just as well made the whole
page a single image map and positioned your form over it.

Indeed you could.
The final design has a lot of free flowing text around the page.
Having said that, on looking back at the page, large blocks of
graphical text could've been 'real' text. The fear that I have though
is that a font won't match the standard set and the designer will
crack it. Looking at this though, the font's he's used are pretty
standard. The file actually came to me as Corel exported to
Illustrator with all the fonts 'removed' and inserted as vector
objects - therefore, I didn't know 'exactly' what font he used. Had I
just seen it was Arial, then I probably wouldn't have exported the
text as images.

Not bad for Corel. What a weird strange trip it has been through.

If you replace your text images with real text, the design can be
easily and badly broken (overlapping content). And if text is not text,
the site is virtually invisible to search engines and the blind.

Both good points.

This is not print. If you really have no desire to learn html....

That's not the case at all. I posted the first step in a multi step
task and you seem to have drawn conclusions about it. As it happened,
the first step was "export from illustrator".... so I conceded that it
'looks' like that's all i've done. That template I posted was used as
the basis of a respsonably complex skin in ASPX.

I knew there was a print man in there somewhere.

Do yourself a favor and ditch the position:absolute.

The only real problem you will have is the middle. Float three columns
left and dump your "request" and "investor" in the first column.

Set everything by margins and paddings. You'll be able to get
everything down to the pixel and you'll have a much more forgiving
design when you need to make changes. Now, if none of this is going to
change or be reused, you can leave it as is.

Typically you can do any design with floats and clears and background
images. If you don't know about floats, let us know.

Jeff

It was / is my desire to learn how to get wonderful and pure HTML/CSS
to work in the evil and nasty MS browsers. I was looking for someone
to point out an IE bug / workaround. As it turns out, I found it
myself (and, as far as I know, it was an IE bug).


Kind regards,



DS



Jeff





On Mar 18, 1:50 pm, "rf" <r...@z.invalid> wrote:
DamienS wrote:
That is not a web page, it is a bunch of pictures of text.
Um... ok. Thanks for that input.
My point is that being pictures the page does not do anything.
There is a picture of a login panel there. How do I put in my userid and
password onto a picture of some input elements? How do I click a picture of
a submit button to log in?
When I click on that picture of a "click here" button nothing happens.
That's because it is not a button, it is a picture of a button.
View the site with Lynx, a text only browser that gives a good indication of
what the search engines see, or turn off images in your browser. What the
search engines see is a totally blank page.- Hide quoted text -
- Show quoted text -

DamienS wrote:

Hello again all.

Let's say that I concede that ALL of the text, except perhaps the
logo, be text - will people still flame this as bad design?

Very probably.

The very last thing you want to do when you start building a web page is to
import stuff from somewhere else, particularly from an image program. Look
at the image, print it out and scribble on it if required, swear at it if
you need to but do not ever let it near your text editor.

Build a page totally from scratch that will look *roughly* the same. And I
stress *roughly* because you will never ever get browsers to make it look
exactly the same. Not unless you simply publish an image, or better yet a
pdf, of what the graphic program produced which of course won't work for the
reasons I originally complained about :-)

* XHTML Why?
Exported that was from Adobe Illustrator. To tell you the truth, I've
not read enough about XHTML to comment.

See above.

* Transitional Why?
Once again, a decision made by Illustrator. I tend to prefer Strict.

See above.

* Why use absolute positioning? Ever!
Now, are you referring to absolute positioning vs relative (as in
position:absolute)

So - please enlighten me, what's wrong with absolute positioning if it
can be used to position absoluately in reference to a flowing parent
element?

Lets say you absolutely position some block, that one containing a request
for a free property report say. You fix its size and its position on the
screen.

Then you put some text in there. Not pictures of text but real text.

You have absolutely no control over the size of that text. You may suggest
certain values for the text size but ultimately it's the viewer who controls
the text size. And some of your viewers *will* increase their text size.
When they do the content you have carefully enclosed in that box will spill
out and cover up the content in the box below. Note there is no "if". This
*will* happen if you absolutely position and size stuff.

The browser has a far better idea of what font size and canvas size is being
used. It's in a far better position than you are to know how to lay out the
page to avoid any overlap. That is what they do all the time and they are
very good at it. Don't hobble the browser by anticipating where you might
think an element might be best positioned.

The above is the major reason you do not import something from a graphics
design program. You use brand new freshly typed HTML elements to fluidly
*simulate* what that graphic design progam has done.

It's a bad way to work (makes you waste time
counting trivial pixels, doesn't give good designs) and at best it's
a way to design fixed-width paper-print page layouts.

yeah, I agree with you here. Ideally a site should expand/shrink to
fit the available real estate.

And the content. Don't forget the content.

Having said that though - everyone in the office loved this layout (as
done by the graphic designer)... so this is the layout that we got.

A client once gave me a power point presentation showing how she wanted her
site to look. I simulated it with a vew divs and what not to convince the
graphic elements to appear roughly like the PP stuff.

On viewing the draft she exclaimed "Wow, look how it changes shape when the
window size changes. You could never get PP to do that could you". Then I
quietly leaned on Ctrl Mousewheel, changing the font size. She thought it
was wonderfull how the boxes changed shape to accomodate the changed text.
She had not realized how much she had limited herself by using PP.

You know, thinking about it, perhaps it comes down to limitations in
the toolsets of designers (Corel Draw, Illustrator, Photoshop) not
being able to create fluid designs. They work with what they have and
we get rigid designs

You've got it on one.

The second is probably the limitations of the current crop of graphic
designers.

If graphic designers were required to take a course in *fluid* web design
using just HTML and CSS and a very cut down graphics program that could only
produce, say, round corners then many of their limitations might evaporate.

Rather than delivering pixel perfect pictures of pages they might start
delivering thumbnail sketches on the backs of envelopes with accompanying
prose detailing how it should look and behave. Something like "four greenish
boxes with round corners that look a little bit like <thumbnail/>
surrounding a picture of a pretty girl.

Anyway - this post was not meant to start a debate.

That is usually what happens here.

On 19 Mar, 03:47, DamienS <damiensaw... (AT) yahoo (DOT) com.au> wrote:

Let's say that I concede that ALL of the text, except perhaps the
logo, be text - will people still flame this as bad design?

If you post the same site again, then yes.

You posted a site and asked for comment. We didn't comment on a site
that you _might_ post, but didn't.

* It's a slice-and-dice job from a bitmap editing program.

Vector editing actually if you want to split hairs.

You might have edited it as vectors, but you exported it as bitmaps.

The problem here is really with bitmaps, and their unscalability. If
you exported the vectors as vectors, this wouldn't be such a problem
(cross-platform support would be iffy though).

* Why use absolute positioning? *Ever!

Now, are you referring to absolute positioning vs relative (as in
position:absolute)

In this context, either is really unnecessary. There is some confusion
here between them, but I think you started that, as your CSS seems to
be using relative AFAIR (not quite so bad), but your post was titled
absolute.

Relative sucks because it's non-fluid and doesn't reflow well in
radically different window sizes.

Absolute sucks because it's as non-fluid (as for relative) and it
_also_ binds to pixel dimensions (absolute is rarely used with any
other dimension unit, and its few legit uses do tend to be pixel-based
anyway). This makes it break for varying font size / window size
ratios as well.

Poor use of relative (again, largely by using pixels) can give you
most of the drawbacks of absolute too.

Heck... I actually agree with pretty much all you've said. In my
opinion, fluid design rocks.

So you already know it's a poor design, then why bother us? 8-)

Having said that though - everyone in the office loved this layout (as
done by the graphic designer)... so this is the layout that we got.

Nothing wrong with the layout, the trick is to get that layout _and_
do it with competent HTML / CSS coding so that you get the semantic,
resizable and fluid benefits too. You don't get this by having it shat
out of the back-end of Dreamweevil etc.

Sadly you don't get much recognition in web design shops for being
able to do it either 8-(

You know, thinking about it, perhaps it comes down to limitations in
the toolsets of designers

I'd disagree. This might be a terminology point, particularly about
who the "designer" is. However I see this as _two_ problems, not one.

Problem #1 is the use of paper-page designers (often from the magazine
world) to do pixel-perfect layouts in a bitmap editor, then to ask a
web coder to turn them into exact representations on the web, rather
than good, fluid web pages. Using PotatoShop as your design tool isn't
either a necessary or a sufficient condition for this, but it sure
encourages the practice. Design roughs should be in crayons, nothing
sharper.

"Head First Web Design" has a nice take on this stage of the process.

Problem #2 is the poor state of WYSIWYG HTML / CSS coding tools.
WYSIWYG _does_not_work_ here, has never worked yet, and (IMHO) cannot
ever work if it's attempted in the way it currently is. A "better
dreamweevil" still won't fix it.

What we need to really make WYSIWYG work is an editing tool that
understands the site's presentational meta-structure, and allows you
to operate with an abstract representation of the site at this level.
One of the few tools to get anywhere near this was (surprisingly
enough) V1.0 of Microsoftoft Visual Studio, back in 1997.

It's no good working with "a <div>" and "some CSS property values"
attached to it. It's not even any better to abstract one from the
other by the medium of using a class as well. This representation of
the site fundamentally isn't smart enough to get you there.

What we must have instead is an editor that's smart enough to work
with "the block for the site banner that we're planning to run
horizontally across the top of the page", "the navigational menu for
the left-hand-side" and "the content block, which will be filled wth
bulky text, and with images up to the defined maximum in-page size, of
800px as a user-selectable choice". Then we can also make declarative
statements about these, such that the LHS menu will always retain its
horizontal position to the left of the content (using sideways
scrolling if necessary), but the block of RHS supplementary links will
instead be re-flowed to beneath the main content block, if there's
insufficient width in the window.

We'll also need a site-wide notion for these blocks, with a
subclassing mechanism to attach behaviours to pages. Some pages (and
some potentially large number of them) will use this behaviour, others
will use a variant of it, others something entirely different.

This is how good human designers of fluid sites work at present. There
are no automatic interactive editing tools (WYSIWYG or not) that do,
AFAIK.

When we bind CSS behaviours to our content elements, we won't do it
directly at the class level, we'll do it through groups of CSS related
to the "behaviours" as described above. The tool will assit us in
resolving any clashes or overlaps between them, as it does reduce
these behaviours down to classes (and class hierarchies) on HTML
elements, on additional HTML elements introduced purely to support
presentation behaviours (heresy!) and on the CSS selector structures
and property groupings attached to them. Then once these groups and
hierarchies are constructed and linked together, we might even think
about picking the values for the CSS properties - which is the easy
bit, and all most of the tools currently allow us to do.

That's how I build 'my' sites. The thing is though, they all end up
looking square and boxy.

A common complaint.

Looking athttp://www.csszengarden.com/
though, I concede that this is my fault and my fault alone, as kick
ass CSS with flowing design is by all means possible.

Zen Garden sucks. That's not CSS, that's draping pictures of web pages
over a skeleton. If the pictures are pretty, then the sites look
pretty too - but it's all just window dressing. Very few of the Zen
Garden sites are even tolerably good in terms of fluid design.

Zen Garden is _not_ the place to go for inspiration. Expert coders
looking for graphical ideas maybe, but if you're a coding newbie it'll
set you off in quite the wrong direction.

Andy Dingley wrote:

On 19 Mar, 03:47, DamienS <damiensaw... (AT) yahoo (DOT) com.au> wrote:

Let's say that I concede that ALL of the text, except perhaps the
logo, be text - will people still flame this as bad design?

If you post the same site again, then yes.

You posted a site and asked for comment. We didn't comment on a site
that you _might_ post, but didn't.



* It's a slice-and-dice job from a bitmap editing program.
Vector editing actually if you want to split hairs.

You might have edited it as vectors, but you exported it as bitmaps.

The problem here is really with bitmaps, and their unscalability. If
you exported the vectors as vectors, this wouldn't be such a problem
(cross-platform support would be iffy though).


* Why use absolute positioning? Ever!
Now, are you referring to absolute positioning vs relative (as in
position:absolute)

In this context, either is really unnecessary. There is some confusion
here between them, but I think you started that, as your CSS seems to
be using relative AFAIR (not quite so bad), but your post was titled
absolute.

Relative sucks because it's non-fluid and doesn't reflow well in
radically different window sizes.

Absolute sucks because it's as non-fluid (as for relative) and it
_also_ binds to pixel dimensions (absolute is rarely used with any
other dimension unit, and its few legit uses do tend to be pixel-based
anyway). This makes it break for varying font size / window size
ratios as well.

Poor use of relative (again, largely by using pixels) can give you
most of the drawbacks of absolute too.


Heck... I actually agree with pretty much all you've said. In my
opinion, fluid design rocks.

So you already know it's a poor design, then why bother us? 8-)


Having said that though - everyone in the office loved this layout (as
done by the graphic designer)... so this is the layout that we got.

Nothing wrong with the layout, the trick is to get that layout _and_
do it with competent HTML / CSS coding so that you get the semantic,
resizable and fluid benefits too. You don't get this by having it shat
out of the back-end of Dreamweevil etc.

Sadly you don't get much recognition in web design shops for being
able to do it either 8-(


You know, thinking about it, perhaps it comes down to limitations in
the toolsets of designers

I'd disagree. This might be a terminology point, particularly about
who the "designer" is. However I see this as _two_ problems, not one.

Problem #1 is the use of paper-page designers (often from the magazine
world) to do pixel-perfect layouts in a bitmap editor, then to ask a
web coder to turn them into exact representations on the web, rather
than good, fluid web pages. Using PotatoShop as your design tool isn't
either a necessary or a sufficient condition for this, but it sure
encourages the practice. Design roughs should be in crayons, nothing
sharper.

I largely agree with Andy, a few comments on how I see this.

The majority of webdesigners come from print backgrounds. And the
majority of html coders know little about design aesthetics.

So it's not bad to have the artwork in place, the problem is turning
the artwork into a workable design.

But all sites have pretty much the same layout. A header and
navigation, one to four columns under that, and a footer with
navigation. Once you have this in place the rest is styling those
container blocks.

Virtually all sites also have a fixed width. Web coders look at this
as a vast evil, but it is what most surfers have come to expect. If you
fight that you either have very simple looking sites or a very talented
developer! Heights should always be fluid, and that is where absolute
and relative positioning crash against the rocks.

Now I agree 100% with Andy that this should be looked at like
components. The problem is that CSS does not have an equal height column
component. It does have floats which is poorly understood and used by
most developers. But it is the *solution* most good web design is
built. Understanding floats is key.

The other issue I see is what to do with design level background art.
And the solution is obvious, to use that art as a background image, not
foreground. Doing that removes it as content and it no longer interferes
with the content.

"Head First Web Design" has a nice take on this stage of the process.

Problem #2 is the poor state of WYSIWYG HTML / CSS coding tools.
WYSIWYG _does_not_work_ here, has never worked yet, and (IMHO) cannot
ever work if it's attempted in the way it currently is. A "better
dreamweevil" still won't fix it.

What we need to really make WYSIWYG work is an editing tool that
understands the site's presentational meta-structure, and allows you
to operate with an abstract representation of the site at this level.
One of the few tools to get anywhere near this was (surprisingly
enough) V1.0 of Microsoftoft Visual Studio, back in 1997.

It's no good working with "a <div>" and "some CSS property values"
attached to it. It's not even any better to abstract one from the
other by the medium of using a class as well. This representation of
the site fundamentally isn't smart enough to get you there.

What we must have instead is an editor that's smart enough to work
with "the block for the site banner that we're planning to run
horizontally across the top of the page", "the navigational menu for
the left-hand-side" and "the content block, which will be filled wth
bulky text, and with images up to the defined maximum in-page size, of
800px as a user-selectable choice". Then we can also make declarative
statements about these, such that the LHS menu will always retain its
horizontal position to the left of the content (using sideways
scrolling if necessary), but the block of RHS supplementary links will
instead be re-flowed to beneath the main content block, if there's
insufficient width in the window.

We'll also need a site-wide notion for these blocks, with a
subclassing mechanism to attach behaviours to pages. Some pages (and
some potentially large number of them) will use this behaviour, others
will use a variant of it, others something entirely different.

We already have this, we can change the classname of any container. In
fact we can have multiple classnames for the same container.

When you do that you can not only adjust the size and properties of
that container but you can style the contents within with descendants of
that container class. The alternative to that is the horribly messy and
hard to maintain inline styling. Assigning classnames to every strong or
paragraph or whatever is no better than font tags. Styling the block as
a whole is the way to go. The key is descendant selectors.

This is how good human designers of fluid sites work at present. There
are no automatic interactive editing tools (WYSIWYG or not) that do,
AFAIK.

When we bind CSS behaviours to our content elements, we won't do it
directly at the class level, we'll do it through groups of CSS related
to the "behaviours" as described above. The tool will assit us in
resolving any clashes or overlaps between them, as it does reduce
these behaviours down to classes (and class hierarchies) on HTML
elements, on additional HTML elements introduced purely to support
presentation behaviours (heresy!) and on the CSS selector structures
and property groupings attached to them. Then once these groups and
hierarchies are constructed and linked together, we might even think
about picking the values for the CSS properties - which is the easy
bit, and all most of the tools currently allow us to do.

I think Andy is beyond me here!

That's how I build 'my' sites. The thing is though, they all end up
looking square and boxy.

A common complaint.

Looking athttp://www.csszengarden.com/
though, I concede that this is my fault and my fault alone, as kick
ass CSS with flowing design is by all means possible.

Zen Garden sucks. That's not CSS, that's draping pictures of web pages
over a skeleton. If the pictures are pretty, then the sites look
pretty too - but it's all just window dressing. Very few of the Zen
Garden sites are even tolerably good in terms of fluid design.

Zen Garden is _not_ the place to go for inspiration. Expert coders
looking for graphical ideas maybe, but if you're a coding newbie it'll
set you off in quite the wrong direction.

Agreed, you don't want to use the html, but if you look through these
and think background images, the designs can provide great inspiration.

The important bit I see is that almost any design is possible. The
design really is harder than the html, once you understand the process.

Jeff

In article
<f39a3dd8-9f99-4e74-82d9-54bae5f1df23 (AT) m4g2000vbp (DOT) googlegroups.com>,
Andy Dingley <dingbat (AT) codesmiths (DOT) com> wrote:

We didn't comment on a site
that you _might_ post, but didn't.

But we could have, not that we would have.

--
dorayme

Great post. Thanks.

Just one question...

Zen Garden is _not_ the place to go for inspiration.

Any other suggestions then?


DS





On Mar 19, 9:28*pm, Andy Dingley <ding... (AT) codesmiths (DOT) com> wrote:

On 19 Mar, 03:47, DamienS <damiensaw... (AT) yahoo (DOT) com.au> wrote:

Let's say that I concede that ALL of the text, except perhaps the
logo, be text - will people still flame this as bad design?

If you post the same site again, then yes.

You posted a site and asked for comment. We didn't comment on a site
that you _might_ post, but didn't.

* It's a slice-and-dice job from a bitmap editing program.

Vector editing actually if you want to split hairs.

You might have edited it as vectors, but you exported it as bitmaps.

The problem here is really with bitmaps, and their unscalability. If
you exported the vectors as vectors, this wouldn't be such a problem
(cross-platform support would be iffy though).

* Why use absolute positioning? *Ever!

Now, are you referring to absolute positioning vs relative (as in
position:absolute)

In this context, either is really unnecessary. There is some confusion
here between them, but I think you started that, as your CSS seems to
be using relative AFAIR (not quite so bad), but your post was titled
absolute.

Relative sucks because it's non-fluid and doesn't reflow well in
radically different window sizes.

Absolute sucks because it's as non-fluid (as for relative) and it
_also_ binds to pixel dimensions (absolute is rarely used with any
other dimension unit, and its few legit uses do tend to be pixel-based
anyway). This makes it break for varying font size / window size
ratios as well.

Poor use of relative (again, largely by using pixels) can give you
most of the drawbacks of absolute too.

Heck... I actually agree with pretty much all you've said. In my
opinion, fluid design rocks.

So you already know it's a poor design, then why bother us? *8-)

Having said that though - everyone in the office loved this layout (as
done by the graphic designer)... so this is the layout that we got.

Nothing wrong with the layout, the trick is to get that layout _and_
do it with competent HTML / CSS coding so that you get the semantic,
resizable and fluid benefits too. You don't get this by having it shat
out of the back-end of Dreamweevil etc.

Sadly you don't get much recognition in web design shops for being
able to do it either *8-(

You know, thinking about it, perhaps it comes down to limitations in
the toolsets of designers

I'd disagree. This might be a terminology point, particularly about
who the "designer" is. However I see this as _two_ problems, not one.

Problem #1 is the use of paper-page designers (often from the magazine
world) to do pixel-perfect layouts in a bitmap editor, then to ask a
web coder to turn them into exact representations on the web, rather
than good, fluid web pages. Using PotatoShop as your design tool isn't
either a necessary or a sufficient condition for this, but it sure
encourages the practice. Design roughs should be in crayons, nothing
sharper.

"Head First Web Design" has a nice take on this stage of the process.

Problem #2 is the poor state of WYSIWYG HTML / CSS coding tools.
WYSIWYG _does_not_work_ here, has never worked yet, and (IMHO) cannot
ever work if it's attempted in the way it currently is. A "better
dreamweevil" still won't fix it.

What we need to really make WYSIWYG work is an editing tool that
understands the site's presentational meta-structure, and allows you
to operate with an abstract representation of the site at this level.
One of the few tools to get anywhere near this was (surprisingly
enough) V1.0 of Microsoftoft Visual Studio, back in 1997.

It's no good working with "a <div>" and "some CSS property values"
attached to it. It's not even any better to abstract one from the
other by the medium of using a class as well. This representation of
the site fundamentally isn't smart enough to get you there.

What we must have instead is an editor that's smart enough to work
with "the block for the site banner that we're planning to run
horizontally across the top of the page", "the navigational menu for
the left-hand-side" and "the content block, which will be filled wth
bulky text, and with images up to the defined maximum in-page size, of
800px as a user-selectable choice". Then we can also make declarative
statements about these, such that the LHS menu will always retain its
horizontal position to the left of the content (using sideways
scrolling if necessary), but the block of RHS supplementary links will
instead be re-flowed to beneath the main content block, if there's
insufficient width in the window.

We'll also need a site-wide notion for these blocks, with a
subclassing mechanism to attach behaviours to pages. Some pages (and
some potentially large number of them) will use this behaviour, others
will use a variant of it, others something entirely different.

This is how good human designers of fluid sites work at present. There
are no automatic interactive editing tools (WYSIWYG or not) that do,
AFAIK.

When we bind CSS behaviours to our content elements, we won't do it
directly at the class level, we'll do it through groups of CSS related
to the "behaviours" as described above. The tool will assit us in
resolving any clashes or overlaps between them, as it does reduce
these behaviours down to classes (and class hierarchies) on HTML
elements, on additional HTML elements introduced purely to support
presentation behaviours (heresy!) and on the CSS selector structures
and property groupings attached to them. Then once these groups and
hierarchies are constructed and linked together, we might even think
about picking the values for the CSS properties - which is the easy
bit, and all most of the tools currently allow us to do.

That's how I build 'my' sites. The thing is though, they all end up
looking square and boxy.

A common complaint.

Looking athttp://www.csszengarden.com/
though, I concede that this is my fault and my fault alone, as kick
ass CSS with flowing design is by all means possible.

Zen Garden sucks. That's not CSS, that's draping pictures of web pages
over a skeleton. If the pictures are pretty, then the sites look
pretty too - but it's all just window dressing. Very few of the Zen
Garden sites are even tolerably good in terms of fluid design.

Zen Garden is _not_ the place to go for inspiration. Expert coders
looking for graphical ideas maybe, but if you're a coding newbie it'll
set you off in quite the wrong direction.

Understanding floats is key.

Ok Jeff, that's your second reference to the topic and I'm intrigued.

I 'think' that I have a rough idea of floats and clears... but nothing
of a level that's changing the world I live in.

Can you point me to a good reference?



Cheers,


DS

DamienS wrote:

Understanding floats is key.

Ok Jeff, that's your second reference to the topic and I'm intrigued.

I 'think' that I have a rough idea of floats and clears... but nothing
of a level that's changing the world I live in.

Can you point me to a good reference?

Let's see if Dorayme posts a link to his/her/it's Float House, which is
the most comprehensive study of everything float that I know of. I lost
my bookmarks a while back, so I don't have it.

Jeff

Cheers,


DS

In article <aNWxl.10473$jZ1.3805 (AT) flpi144 (DOT) ffdc.sbc.com>,
Jeff <jeff_thies (AT) att (DOT) net> wrote:

DamienS wrote:
Understanding floats is key.

Ok Jeff, that's your second reference to the topic and I'm intrigued.

I 'think' that I have a rough idea of floats and clears... but nothing
of a level that's changing the world I live in.

Can you point me to a good reference?

Let's see if Dorayme posts a link to his/her/it's Float House, which is
the most comprehensive study of everything float that I know of. I lost
my bookmarks a while back, so I don't have it.

It is less of a practical tutorial than a sort of personal
anthropological amble through the strange and magic world of floats by
this it here.

<http://netweaver.com.au/floatHouse/>

--
dorayme