new page... little help please?

[Barbara de Zoete]

Barbara de Zoete


Only of course if the data in that table is tabular in nature.

But of course

Only if the content can not be styled *without* using that element.

But, of course

It is time for you to get a server that does support includes, preferable
one that suports server side scripting.

Yeah, I know. I've been thinking about that a lot recently. For me the net
and writing and designing for the www is just a hobby. When I first
started out (again since some eight to ten odd years ago) I started with
FP, frames and a free host. Since then I got rid of FP and the frames, but
I'm still with that free host. Accept for the lack of PHP (or what ever
server side scripting possibility) it seems to suffice so far.
But that lack of server side scripting is becomming a pain. So perhaps not
for long I will move on to a real host. Who knows.

<stuff about id and class>

Class is the way to go. ID is for other things, like fiddling with the
DOM using javascript.

I'm not sure what you mean here (still learning like every other day or
so, see ). I use [id]'s on <div>'s for layout mainly because an [id]
has more weight in the cascade than a [class] has, so styles I define for
a div with some [id] are preferred automatically over some of the overall
styles, when rendered by a graphical browser. With a [class] I find that
is not always the case.

 

[rf]

Barbara de Zoete

rf wrote:

Yeah, I know. I've been thinking about that a lot recently. For me the net
and writing and designing for the www is just a hobby.

As it is (well sort of) for me.

Once I moved to a host that supported PHP and MYSQL the "hobby" suddenly
became much more interesting. Sort of like playing with one nut and one bolt
and suddenly discovering a entire workshop.

I'm not sure what you mean here (still learning like every other day or
so, see ). I use [id]'s on <div>'s for layout mainly because an [id]
has more weight in the cascade than a [class] has,

Where does it say that? It does not.

so styles I define for
a div with some [id] are preferred automatically over some of the overall
styles, when rendered by a graphical browser. With a [class] I find that
is not always the case.

Nope. Style rules select elements. Selecting by ID or class is irrelevant.
What *is* relevant is the the specificality of the selection and, failing
that, the order of the style rules. All of this is explained in the
specification in the "selectors" chapter.

The problem with ID is that (to validate) only one element may have that ID.
So, you must have a seperate ID for each element that may be styled. So, the
style rule that selects that element can not be used to select another
element.

Class, on the other hand, can be used for many elements. A single style rule
can select all of those elements.

Consider:

<p id="p1"> with .p1 {font-weight: bold}
<p id="p2"> with .p2 {font-weight: bold}
<p id="p3"> with .p3 {font-weight: bold}

as against

<p class="pb">
<p class="pb">
<p class="pb"> with .pb {font-weight: bold}

Class allows the KISS principle to operate.

 

[Barbara de Zoete]

Barbara de Zoete

rf wrote:

I'm not sure what you mean here (still learning like every other day or
so, see ). I use [id]'s on <div>'s for layout mainly because an [id]
has more weight in the cascade than a [class] has,

Where does it say that? It does not.

Hang on. They do. If I set an [id] and a [class] on the same element, the
styles in the definition for the [id] get preferred over those in the
[class] regardless of their occurance in the stylesheet (what ever comes
first or last).
See <http://www.w3.org/TR/CSS21/cascade.html#cascading-order>. My
interpretation of that text is that (a) inline styles have more weight
than (b) id's, which have more weight than (c) classes, which have more
weight than (d) any preset or inherited element or attribute style. How am
I wrong in interpreting that bit of text?

so styles I define for
a div with some [id] are preferred automatically over some of the
overall
styles, when rendered by a graphical browser. With a [class] I find that
is not always the case.

Nope. Style rules select elements. Selecting by ID or class is
irrelevant.
What *is* relevant is the the specificality of the selection and, failing
that, the order of the style rules. All of this is explained in the
specification in the "selectors" chapter.

The problem with ID is that (to validate) only one element may have that
ID.

That's not a problem. That's a virtue

<snip classes versus id's used to style a bunch of paragraphs>

This is not what I mean or was talking about. I guess I've not been clear
enough than.

I agree that on an element level one should use, preferrably, classes or
perhaps stick to styling the element itself if possible. That is KISS.

I was referring to (or tried to refer to ) the situation where you
create containing <div>'s to layout a page. For those containing <div>'s I
use [id]'s as there is no second [id="content"] or [id="menu"] on one
page. Or there should not be anyway.
I prefer to use [id]'s for those containing <div>'s, because then they are
truely unique. It give me the opportunity to create fragment links
(whatchamacallit in English?) to specific parts of my page where they are
useful _and_ to style the contents of each containing <div> differently.
Really entirely differently. If I want to, that is.

<style id="example" class="don't bash me for my use of not safe colours">
body { color:green; }
strong { color:navy; }
strong.extra_important { color:red; }
strong.extra_extra_important { color:red!important; }
#top { colorurple; }
#menu { color:maroon; }
#something_else { colorrange; }
</style>

<body>
<p>Just some text that is green and <strong>some
navy too</strong>.</p>
<p>Some more green text, <strong
class="extra_important">now some red</strong>.</p>
<div id="top">
<p>And this should turn up purple. Nice </p>
<p><strong>With this still being purple</strong></p>
</div>
<div id="menu">
<p>And here some maroon, <strong
class="extra_important">staying maroon</strong></p>
</div>
<div id="something_else">
<p>And now orange (hate me yet?) with, finally,
<strong class="extra_extra_important">some red
text</strong>.</p>
<p>As this <strong style="color:red;">will be red
too</strong></p>
</div>
</body>

If with an element in the markup no color is specified with inline style,
the color expressed in either <body> or one of the [id]'s of the
containing <div> will be rendered.
With an element <strong> used in the body it will be rendered with
color:navy. In one of the containing <div>'s it will inherit the color of
that containing <div>.
If the class .extra_important is added to the element <strong>, red will
be it's color, but still only in the body.
If strong.extra_extra_important is used in one of the containing <div>'s,
than the color will be red there also, due to the !important rule.

Therefore the use of an [id] for a containing <div> gives a firm control
over the design of your page (where that is applicable; always keeping in
mind that it is impossible to design pixel perfect for all those different
graphical browsers out there, let alone the not graphical ones).
At least this is how I understand the cascade works and it is what I think
I see happening. But if I'm wrong, I'm sure someone will point that out to
me

 

[Spartanicus]

I use [id]'s on <div>'s for layout mainly because an [id]
has more weight in the cascade than a [class] has,

Where does it say that? It does not.

Indeed, but (I hope) you know what she meant, id has a higher
specificity if all other factors are equal.

Nope. Style rules select elements. Selecting by ID or class is irrelevant.
What *is* relevant is the the specificality of the selection and, failing
that, the order of the style rules. All of this is explained in the
specification in the "selectors" chapter.

The cascade including specificity is set out in the cascade section.

The problem with ID is that (to validate) only one element may have that ID.
So, you must have a seperate ID for each element that may be styled. So, the
style rule that selects that element can not be used to select another
element.

That's no argument for not using id's, just that they should only be
used once per document.

[Silly example snipped]

 

[neredbojias]

Without quill or qualm, DaKitty quothed:

oops, that's no good.
Thanks for pointing that out.
Any hints as to why? (Wile I'm off troubleshooting it)

Looking much better now. The only diff I see is the white center
background goes all the way down in IE and not in Moz, but the text is
visible.

I validated your page and the only really serious thing might be
something about a meta tag in the wrong place. There was also something
about a background image, the usual top/left/right/bottom-margin stuff,
and no alt tags. It's getting there.

 

[Lauri Raittila]

Barbara de Zoete

I use [id]'s on <div>'s for layout mainly because an [id]
has more weight in the cascade than a [class] has,

Where does it say that? It does not.

Hang on. They do. If I set an [id] and a [class] on the same element, the
styles in the definition for the [id] get preferred over those in the
[class] regardless of their occurance in the stylesheet (what ever comes
first or last).

That is specifity, not cascading. Cascading is stuff that happen between
userstylesheet and authorstylesheet etc.

See <http://www.w3.org/TR/CSS21/cascade.html#cascading-order>.

Yes, says exactly opposite
http://www.w3.org/TR/CSS2/cascade.html#cascading-order
2. The primary sort of the declarations is by weight and origin: for
normal declarations, author style sheets override user style sheets which
override the default style sheet. For !important" declarations, user
style sheets override author style sheets which override the default
style sheet. "!important" declaration override normal declarations. An
imported style sheet has the same origin as the style sheet that imported
it.
3.The secondary sort is by specificity of selector

My
interpretation of that text is that (a) inline styles have more weight
than (b) id's, which have more weight than (c) classes, which have more
weight than (d) any preset or inherited element or attribute style. How am
I wrong in interpreting that bit of text?

You are confusing cascade and specifity.

That's not a problem. That's a virtue

Yes. You also get fragment identifiers, that are good thing to have
anyway.

 

[Barbara de Zoete]

If I set an [id] and a [class] on the same element, the
styles in the definition for the [id] get preferred over those in the
[class] regardless of their occurance in the stylesheet (what ever comes
first or last).

That is specifity, not cascading. Cascading is stuff that happen between
userstylesheet and authorstylesheet etc.

See <http://www.w3.org/TR/CSS21/cascade.html#cascading-order>.

Yes, says exactly opposite
http://www.w3.org/TR/CSS2/cascade.html#cascading-order
2. The primary sort of the declarations is by weight and origin: for
normal declarations, author style sheets override user style sheets which
override the default style sheet. For !important" declarations, user
style sheets override author style sheets which override the default
style sheet. "!important" declaration override normal declarations. An
imported style sheet has the same origin as the style sheet that imported
it.
3.The secondary sort is by specificity of selector

I think I'm getting what you mean, but it took me a few hours of
rethinking. Once a mental model of this relatively abstract stuff has
settled it is hard to remodel, I guess.

You are confusing cascade and specifity.

Yeah, I understand that now. I was focussing on specifity (never heard
that word before today).

 

[DaKitty]

And how is that going to improve your html ablilities, hmm?
No, really. If you get the TV channel you want, there wouldn't be much
time left to try if Kris' advice can work for you. It is really an
excellent advise. I've read newsgroups on www authoring and design for
well over a year now, and my skills have improved drastically because of
that and I'm still learning something new almost every day.

I doubt if that had been the case had there been a TV channel, that has
all the great British detective TV series with atleast Morse and the Ruth
Rendell series, rotating every hour .

I need background noise.
When it's too quiet, I can't think. I get distracted by too many things
going on in my head and get nothing done. When I have a small distraction in
the background, then I focus really well.
Plus, I live alone and work out of my house... it gets waaay too quiet in
here.

 

[DaKitty]

Without quill or qualm, DaKitty quothed:


Looking much better now. The only diff I see is the white center
background goes all the way down in IE and not in Moz, but the text is
visible.

I validated your page and the only really serious thing might be
something about a meta tag in the wrong place. There was also something
about a background image, the usual top/left/right/bottom-margin stuff,
and no alt tags. It's getting there.

thanks!
I was checking it in IE6 and firefox at the same time, they were showing up
the same... I think...
Maybe not, I was getting kind of tired when I stopped.

 

[DaKitty]

Hah! I wish I knew how to do all that!
Maybe in a few months or so of learning, I'll know... umh.... 1/3 of
it...

Well, looks like it will be a looong time before I have a 'perfect' html.
Yikes.

If you look into html and css you will find it is more easy to learn how
to code by hand (a trade you'll have use for for as long as you code for
the www) than to learn how to use a program (which is only useful as long
as you use that program).

With html all you really need at first is knowledge on the basic page
structure and knowlegde on a handful of elements and their attributes. If
you master those, you can already write and code pages with solid
structure that are semantically right and that any browser can parse. And
you can write those pages fast too.
Depending on what you do in your page, for me those elements are:
- <h#>
- <p>
- <ul> and <ol>, with <li>
- <img>
- <a>
- <table>, with <colgroup>, <col>, <thead>, <tfoot>, <tbody>, <tr>,
<th>, <td>
- <div>
- <span>
- and an occasional <iframe> because my server doesn't allow me to
<!--#include

CSS is probably a bit different in that the possibilities for using css
seems indefinite. If you start out to style the basic elements for your
pages (even on an attribute level if you want, although Internet Explorer
doesn't support that) and once you know what you're doing there, you move
on to laying out the page itself (with <div> and [id] so you can do with
isolated and identifiable parts of a page what ever you want to), it
shouldn't be too long before you can come up with some pretty nice styling
and lay out too.

Anyway, I think that is the way to learn. Get the basical structure,
understand how to use semantically correct markup, style the elements you
use (instead of using a lot of [class]es and [id]'s), lay out the page
with unique [id]'s on some containing <div>'s. Done.
Not only is that the way to learn, it is also (I think) the correct order
to create any new page. So once you start learning in this order, you keep
learning with every page you create. At least, that is my experience.

Hi,
Thanks for a really nice detailed and informative post... I'm saving it so I
can review more this coming weekend.
I'm little short on time to tinker this week. ...tired this evening...
Thanks, Connie

 

[Barbara de Zoete]

You are also allowing dreamweaver to use deprecated things like

elements. Don't. In fact don't let dreamweaver insert *any* code for
you.
Whatever code it does insert is usually rubbish.

Start again by reproducing the page with a real editor. Not a WYSIWYDG
one,
something text only like notepad or crimson. Really. You will be far
better
off.

Hah! I wish I knew how to do all that!
Maybe in a few months or so of learning, I'll know... umh.... 1/3 of
it...

Well, looks like it will be a looong time before I have a 'perfect' html.
Yikes.

If you look into html and css you will find it is more easy to learn how
to code by hand (a trade you'll have use for for as long as you code for
the www) than to learn how to use a program (which is only useful as
long
as you use that program).

With html all you really need at first is knowledge on the basic page
structure and knowlegde on a handful of elements and their attributes.
If
you master those, you can already write and code pages with solid
structure that are semantically right and that any browser can parse.
And
you can write those pages fast too.
Depending on what you do in your page, for me those elements are:
- <h#>
- <p>
- <ul> and <ol>, with <li>
- <img>
- <a>
- <table>, with <colgroup>, <col>, <thead>, <tfoot>, <tbody>, <tr>,
<th>, <td>
- <div>
- <span>
- and an occasional <iframe> because my server doesn't allow me to
<!--#include

CSS is probably a bit different in that the possibilities for using css
seems indefinite. If you start out to style the basic elements for your
pages (even on an attribute level if you want, although Internet
Explorer
doesn't support that) and once you know what you're doing there, you
move
on to laying out the page itself (with <div> and [id] so you can do with
isolated and identifiable parts of a page what ever you want to), it
shouldn't be too long before you can come up with some pretty nice
styling
and lay out too.

Anyway, I think that is the way to learn. Get the basical structure,
understand how to use semantically correct markup, style the elements
you
use (instead of using a lot of [class]es and [id]'s), lay out the page
with unique [id]'s on some containing <div>'s. Done.
Not only is that the way to learn, it is also (I think) the correct
order
to create any new page. So once you start learning in this order, you
keep
learning with every page you create. At least, that is my
experience.

Hi,
Thanks for a really nice detailed and informative post... I'm saving it
so I
can review more this coming weekend.
I'm little short on time to tinker this week. ...tired this evening...
Thanks, Connie

Take your time. It took me about a full year to grasp the concepts and
implications of 'structure', 'semantics and markup', css for presentation
(both at element level and at page layout level).