Standard Module Format

It's a nice thing when you can have a single layout that can be used
differently by adding styles. Sometimes that means adding containers
(divs) that can be used or not.

<div class="some_container">
<div class="styles for top or left of box"></div>

box contents, typically "some_container" would be a floated column and
would contain headings, paragraphs, images...

<div class="styles for bottom or right side of box"></div>
</div>

Those "styles" will usually be a background image or perhaps a border.

Something more here:

http://www.schillmania.com/projects/dialog2/

Who is doing similar things to add the little polish touches? Have you
settled on a standard? What is that?

On a slightly different note:
I've always had trouble with the standard box model ignoring padding and
borders when accounting for widths, but you can do something like this:

<div id="container">
<div id="column_1"> <!-- Set widths and margins-->
<div class="inside"><!-- Set padding and borders -->
content here
</div>
</div>

<div id="column_2">
<div class="inside">
content here
</div>
</div>

....

Now, widths and margins can be set for column_1 and column_2 (which
can be floated), and padding and borders can be set for "inside" using a
descendant of it's parent. If you adjust padding or borders (which is a
common design thing to do), then the width remains the same, you don't
have to go back and recalculate widths.

Is anyone with me on this, or is there a flaw here? I tried bringing
this up in the html groups but just got ridiculed there. If this group
feels the same way, I'll just give up.

Jeff

On 2008-03-24, Jeff <jeff (AT) spam_me_not (DOT) com> wrote:
[...]

On a slightly different note:
I've always had trouble with the standard box model ignoring padding and
borders when accounting for widths, but you can do something like this:

div id="container"
div id="column_1"> <!-- Set widths and margins--
<div class="inside"><!-- Set padding and borders --
content here
</div
/div

div id="column_2"
<div class="inside"
content here
</div
/div

...

Now, widths and margins can be set for column_1 and column_2 (which
can be floated), and padding and borders can be set for "inside" using a
descendant of it's parent. If you adjust padding or borders (which is a
common design thing to do), then the width remains the same, you don't
have to go back and recalculate widths.

Is anyone with me on this, or is there a flaw here?

No flaw, I'd say that's the best way to set an outer margin width if
that's what you want to do.

Note that you put the margins on the outer box but the padding, borders
and background on the inner one.

You also can try CSS3 box-sizing: border-box or -moz-box-sizing:
border-box.

Purists will avoid divs that are only there so you can style them but
that have no "semantic" meaning but in my opinion that's setting the bar
too high.

Sometimes people propose more extensions to CSS to achieve results that
can already be achieved using the existing rules and another level of
nesting. But if you ask me it's not worth it. Simplicity is more
important, and perhaps people underestimate how much more power there is
in a simple set of rules if you allow yourself to create a few extra
elements to apply them to.

Note also that the order in which elements appear in the source document
already dictates a lot about the layout, however you style it: it's not
as if content and presentation are completely decoupled. It has become a
bit of a mantra to claim that they are or should be but the reality is
more subtle.

Ben C wrote:

On 2008-03-24, Jeff <jeff (AT) spam_me_not (DOT) com> wrote:
[...]
On a slightly different note:
I've always had trouble with the standard box model ignoring padding and
borders when accounting for widths, but you can do something like this:

div id="container"
div id="column_1"> <!-- Set widths and margins--
<div class="inside"><!-- Set padding and borders --
content here
</div
/div

div id="column_2"
<div class="inside"
content here
</div
/div

...

Now, widths and margins can be set for column_1 and column_2 (which
can be floated), and padding and borders can be set for "inside" using a
descendant of it's parent. If you adjust padding or borders (which is a
common design thing to do), then the width remains the same, you don't
have to go back and recalculate widths.

Is anyone with me on this, or is there a flaw here?

No flaw, I'd say that's the best way to set an outer margin width if
that's what you want to do.

Note that you put the margins on the outer box but the padding, borders
and background on the inner one.

You also can try CSS3 box-sizing: border-box or -moz-box-sizing:
border-box.

My understanding is that the level of support is poor. You can take
it out of strict, but that exposes other issues. I hadn't heard of the
-moz-box-sizing but I'm pretty sure IE won't grok that.

Purists will avoid divs that are only there so you can style them but
that have no "semantic" meaning but in my opinion that's setting the bar
too high.

And there's a place for that. But in the current commercial market it's
a real disadvantage for the author as it leads to real plain jane pages.
I've been a bit stunned by the use of background images in some layouts.
Zen Garden does that, but I think this can be done simpler with just a
few more containers just for styles.

http://www.mezzoblue.com/zengarden/alldesigns/

Sometimes people propose more extensions to CSS to achieve results that
can already be achieved using the existing rules and another level of
nesting. But if you ask me it's not worth it. Simplicity is more
important, and perhaps people underestimate how much more power there is
in a simple set of rules if you allow yourself to create a few extra
elements to apply them to.

It's not like nesting tables. And divs have no special symantic
meaning. I think your argument of simplicity (and consistency) carries a
lot of weight.

I've waited a long time to get a reasonable set of rules that apply
(more or less consistently) to most browsers. I'm not waiting longer or
just designing for a few browsers or writing CSS hacks to turn on/off
styles (if I don't have to).

Note also that the order in which elements appear in the source document
already dictates a lot about the layout, however you style it: it's not
as if content and presentation are completely decoupled. It has become a
bit of a mantra to claim that they are or should be but the reality is
more subtle.

That's true. I haven't hacked my way through the wikipedia layout,
but they go through some severe measures to order the content. I'm
impressed. I'm also confused.

Ultimately where I want to go is a very small handful of layouts that
can be assembled to achieve whatever look you want. I think this can be
done with a slight variant of the above layout (perhaps in 1 to 4 column
variants) or perhaps with unused "columns set to display: none".

Thanks, I feel better about the path I'm headed down.

Jeff

In article <13ug05sj037tsc0 (AT) corp (DOT) supernews.com>,
Jeff <jeff (AT) spam_me_not (DOT) com> wrote:

Ultimately where I want to go is a very small handful of layouts that
can be assembled to achieve whatever look you want. I think this can be
done with a slight variant of the above layout (perhaps in 1 to 4 column
variants) or perhaps with unused "columns set to display: none".

Thanks, I feel better about the path I'm headed down.

The other thing you can do is simply grab one of your previous jobs and
change the content. This way will have the advantage that the names of
the ids and classes, for example, will be reasonably meaningful.

--
dorayme

dorayme wrote:

In article <13ug05sj037tsc0 (AT) corp (DOT) supernews.com>,
Jeff <jeff (AT) spam_me_not (DOT) com> wrote:

Ultimately where I want to go is a very small handful of layouts that
can be assembled to achieve whatever look you want. I think this can be
done with a slight variant of the above layout (perhaps in 1 to 4 column
variants) or perhaps with unused "columns set to display: none".

Thanks, I feel better about the path I'm headed down.

The other thing you can do is simply grab one of your previous jobs and
change the content. This way will have the advantage that the names of
the ids and classes, for example, will be reasonably meaningful.

I do that with menus. And I have a set of standard ID's for base
containers, like header, content and footer. I rarely use classes (but
style by descendants), but that is changing. I don't have a standard
layout model or template and that is what I seek.

What I really want to do, since I'm on my own now, is spiff up the
details. I've been very plain in my designs and low graphics, but I want
to do things with curves and shapes, etc... lapping out of their
boxes. Traditionally this has been done with tables and chopping up
images, something I can't bring myself to do.

But, if you are using background images and few extra containers,
there is a lot that can be done.

I'm a very simple guy and I need to up my skill set. Ever seen my
personal site, for my photography, it's really nothing...

http://thelimit.com

Jeff

Ben C wrote:

snip

Purists will avoid divs that are only there so you can style them but
that have no "semantic" meaning but in my opinion that's setting the bar
too high.

snip

A div has no semantic meaning in any case. It's purely structural.

As far as nesting goes, I like to follow a sort of "spatial" standard.
If I need extra markup to accomplish something visually, I prefer
nesting rather than adding loose tags; for example, if I need a fancy
corner on something:

<div class="Module">
<div class="void">
<p>Some content</p>
</div>
</div>

rather than:

<div class="Module">
<div class="fancy-corner"></div>
<p>Some content</p>
</div>

because I like it when the entire structure of that module - sans any
styling - collapses into a single spatial box. This is just a personal
preference, though.

Also, when you're looking through the markup, it's much easier to read
this way (in my opinion) because you can easily see that the extra
nested div does not add a sub-structure to the module.

Of course, it's still best to try and minimize extra markup wherever
possible (this is often an interesting challenge, too).

Jeremy

In article <13ugcae3fo4406c (AT) corp (DOT) supernews.com>,
Jeff <jeff (AT) spam_me_not (DOT) com> wrote:

I'm a very simple guy and I need to up my skill set. Ever seen my
personal site, for my photography, it's really nothing...

http://thelimit.com

I would not say that at all. Don't be so modest.

--
dorayme

Jeremy wrote:

Ben C wrote:

snip

Purists will avoid divs that are only there so you can style them but
that have no "semantic" meaning but in my opinion that's setting the bar
too high.

snip


A div has no semantic meaning in any case. It's purely structural.

As far as nesting goes, I like to follow a sort of "spatial" standard.
If I need extra markup to accomplish something visually, I prefer
nesting rather than adding loose tags; for example, if I need a fancy
corner on something:

div class="Module"
div class="void"
p>Some content</p
/div
/div

rather than:

div class="Module"
div class="fancy-corner"></div
p>Some content</p
/div

because I like it when the entire structure of that module - sans any
styling - collapses into a single spatial box. This is just a personal
preference, though.

I started off thinking that way, then I tried adding corners that
would go with an existing border and hit the wall (borders can't match
corners). Do you have a method for that? Without the border issue, I
really prefer your method. Perhaps I've missed a "trick".

But the again, combining a background image, such as a gradient, that
goes through the container, with another one positioned differently,
is impossible without nested divs.

Also, when you're looking through the markup, it's much easier to read
this way (in my opinion) because you can easily see that the extra
nested div does not add a sub-structure to the module.

I'm not so worried about that because you can mark the div's class in
a way that this is evident. And that bit of html can live on a single
line. I'm not crazy about it, but I don't mind it.

Of course, it's still best to try and minimize extra markup wherever
possible (this is often an interesting challenge, too).

Well, you could remove it, if it isn't needed. It doesn't bother me so
much because it is so little html. But then, I haven't lived with it
yet... Ideally what I would like is a flexible framework to design with.

Now, I've lived with nested table Dreamweaver html from a designer,
so my bar is lower. After you've read *that* html, this is clarity.

Jeff

Jeremy