Question about CSS definitions

R

rbaulbin

Hello -

Is there any advantage to defining classes with the element name vs.
without the element name?

p.center {properties...}
vs.
..center {same properties...}

I mean, if both above can be used for the "p" element, why do people
include the p in the definition?

Thanks,

RB
 
B

Beauregard T. Shagnasty

Hello -

Is there any advantage to defining classes with the element name vs.
without the element name?

p.center {properties...}
vs.
.center {same properties...}

I mean, if both above can be used for the "p" element, why do people
include the p in the definition?

..center can be used with other elements as well, such as:

<div class="center"> ...
<table ...
<ul .. >
etc.
 
J

Jukka K. Korpela

Scripsit (e-mail address removed):
Is there any advantage to defining classes with the element name vs.
without the element name?
Pardon?

p.center {properties...}
vs.
.center {same properties...}

You meant to ask whether there is an advantage in using an element name
in a selector before a class selector. The answer is that it depends.
And a class name like "center" is almost always a poor choice: it says
nothing about any meaning.
I mean, if both above can be used for the "p" element, why do people
include the p in the definition?

Perhaps because a selector like .foo looks so lonely and too similar to
an element name as a selector, just with the tiny ".". It also affects
the denotation of the selector (the set of elements matching it) as well
as its specificy. See an introduction to the first principles of the
basics of the elements of getting started with CSS.
 
J

Jeff

Jukka said:
Scripsit (e-mail address removed):


You meant to ask whether there is an advantage in using an element name
in a selector before a class selector. The answer is that it depends.
And a class name like "center" is almost always a poor choice: it says
nothing about any meaning.

OK, I'll bite. I've never heard you condemn a class name before, and to
start with "center" has me a bit amazed. Can you elaborate on why
"center" has no meaning? On the surface it would seem to be self
explanatory.

Jeff
 
M

Michael Fesser

..oO(Jeff)
OK, I'll bite. I've never heard you condemn a class name before, and to
start with "center" has me a bit amazed. Can you elaborate on why
"center" has no meaning? On the surface it would seem to be self
explanatory.

A class should reflect the meaning of the content which it is applied
to, not its appearance, e.g. "boldRed" vs. "warning".

But IMHO there are exceptions from this recommendation, I think "center"
is one of them. I even use these five classes in most of my stylesheets:

..ac {text-align: center}
..al {text-align: left}
..ar {text-align: right}
..fl {float: left; margin-right: 1em}
..fr {float: right; margin-left: 1em}

The float classes are mainly used on images, while the alignment classes
are mainly used in table columns. For me these five classes are purely
presentational, they mean nothing else than to align this or that in a
certain way without giving it any special meaning, hence the naming.

But in most other cases my classes are given meaningful names that
describe their intention and usage, not their look.

Micha
 
D

dorayme

Jeff said:
...Can you elaborate on why
"center" has no meaning? On the surface it would seem to be self
explanatory.

If you name a class by reference to its function, eg. navigation,
it becomes less confusing when you want to alter its style
properties. But if you name it with a word that usually names a
style, you either buy the confusion when you want to change the
style:

..center {text-align: right;}

or scrap the class and make a new one.

One of the ideas behind the separation of style from content is
to be able to hold the html constant and propose different styles
(for example, for different purposes like types of media). Having
something like .center would make it hard (because confusing) to
do this while holding the html constant.
 
J

Jonathan N. Little

Hello -

Is there any advantage to defining classes with the element name vs.
without the element name?

p.center {properties...}
vs.
.center {same properties...}

I mean, if both above can be used for the "p" element, why do people
include the p in the definition?


In addition to what has been said, adding an element to the class rule
can be useful for element specific properties

..menu { color: white; background-color: black; }
ul.menu { list-style: none; }

the latter rule only apples to ULs of class "menu" where the list
property would be applicable.
 
J

Jeff

dorayme said:
If you name a class by reference to its function, eg. navigation,
it becomes less confusing when you want to alter its style
properties. But if you name it with a word that usually names a
style, you either buy the confusion when you want to change the
style:

.center {text-align: right;}

or scrap the class and make a new one.

One of the ideas behind the separation of style from content is
to be able to hold the html constant and propose different styles
(for example, for different purposes like types of media). Having
something like .center would make it hard (because confusing) to
do this while holding the html constant.

OK, I think I see where you guys are going with this and although valid,
it is way different than the way I do it.

To me, it makes more sense to ID the sections of the site, like
#top_nav, #left_side_bar, #main_content and style everything in there as
a descendant. ex: #left_side_bar p{... I use classes for local styling
and even try to avoid them there. So, it wouldn't bother me if .center
or .bold_blue were in any part of the page. I rather think that most
stylesheets have *way* too many classes and I only use a class if it can
be used in more than one place. There's always exceptions of course
and that's where unambiguous names come in, such as .product_thumb.

Now, like most everyone, I work mostly with customers using a CMS. If
they want to center something (not that I think that's a great idea),
I'd rather have them choose a class name that said: center_bold rather
than main_content_alternate_style_1.

Jeff
 
C

Chaddy2222

dorayme said:
OK, I think I see where you guys are going with this and although valid,
it is way different than the way I do it.

   To me, it makes more sense to ID the sections of the site, like
#top_nav, #left_side_bar, #main_content and style everything in there as
a descendant. ex: #left_side_bar p{... I use classes for local styling
and even try to avoid them there. So, it wouldn't bother me if .center
or .bold_blue were in any part of the page. I rather think that most
stylesheets have *way* too many classes and I only use a class if it can
be used in more than one place.  There's always exceptions of  course
and that's where unambiguous names come in, such as .product_thumb.

  Now, like most everyone, I work mostly with customers using a CMS. If
they want to center something (not that I think that's a great idea),
I'd rather have them choose a class name that said: center_bold rather
than main_content_alternate_style_1.

   Jeff
I think your nameing system is fine.
I agree with you on the class issue but I would also say that useing
classes is better then useing inline styles.
 
J

John Hosking

Michael said:
A class should reflect the meaning of the content which it is applied
to, not its appearance, e.g. "boldRed" vs. "warning".

Agreed, at least the first part, although it seems you have swapped the
examples.
But IMHO there are exceptions from this recommendation, I think "center"
is one of them. I even use these five classes in most of my stylesheets:

.ac {text-align: center}
.al {text-align: left}
.ar {text-align: right}
.fl {float: left; margin-right: 1em}
.fr {float: right; margin-left: 1em}

So what do you do when you decide the image which has been floated right
should now be on the left?
The float classes are mainly used on images, while the alignment classes
are mainly used in table columns.

Wondering (and excited to hear) how you style the columns.
For me these five classes are purely
presentational, they mean nothing else than to align this or that in a
certain way without giving it any special meaning, hence the naming.

Exactly: they're purely presentational. But you've built their
presentation into the code by including the (abbreviated and obscure)
class names in the HTML.
 
A

Andy Dingley

Jukka K. Korpela wrote:

OK, I'll bite. I've never heard you condemn a class name before, and to
start with "center" has me a bit amazed. Can you elaborate on why
"center" has no meaning? On the surface it would seem to be self
explanatory.

It's an interesting question, deserving a good answer.

Firstly, I'm surprised you haven't heard Jukka rag on this one before.
It's a regular tripwire around here.

Thirdly, it's obviously "self explanatory". That's not the problems.

Mostly though it's about the second part of your question, 'Can you
elaborate on why "center" has no meaning?' Of course it has
"meaning", the problem is _what_ domain that meaning is applied to.

Jukka favours classnames that reflect "markup", i.e. their meaning
should be objective and based around the content of the document, not
how it's to be presented. So a classname of "legal-postscript" is OK,
but "centred" is bad. Even "legal-footer" is dubious (who's to say
that it should always be presented as a "footer"?)

Some people, myself included but not AIUI Jukka, believe that semantic
HTML can be extended by the rigorous use of classnames which have
implied binding to schema or ontology documents, as a way of extending
the public semantics of HTML. This is already easy to do (and widely
done), but not in a way that's publishable outside narrow projects
(the public web can't automatically infer the meaning of the
classnames).

An alternative approach, as described here, is to use classnames that
reflect "presentation" aspects, not content markup at all. Classnames
like "center", "red", "bold10px" are obvious indications of this.
However you should remember that the names of "presentational"
classnames are no more inferrable than "structural" classnames.
"bold10px" is no more likely to still translate to the "obvious" CSS
in an old project than "left-menu" is likely to still be on the left
rather than re-designed to the right. This lack of stability over time
and maintenance is perhaps the biggest problem with overtly
presentational classnames.

It's an article of faith hereabouts that structural class names are
good and presentational class names are always bad, hence Jukka's
reaction.

I take a rather softer line. Structural classes are good, but
presentational class names _may_ also be a good thing, under certain
constraints.

The key to this is to remember that elements can have a list of
classes applied to them, they aren't made members of a single
exclusive class at a time. This changes the relationship between
element and class. Rather than being an ordinal defining relation
(this element _is_ a "legal-postscript") it's a multi-valued
attributional relation (this element has the "legal-postscript"
behaviour and also the "center" behaviour). In this interpretation,
it's no problem to make sense of the set of classes attached to
elements. Where these presentational themse are complex (e.g. the
"corporate branding guide theme green" behaviour is to be applied),
then this can be a useful technique.

The downside is of course that we've merged content and presentaion
into a single file, by applying purely presentational behaviours (the
application of presentational class names) to the HTML directly. This
is against one of the claimed principles of HTML 4 + CSS, the supposed
separation of content and presentation.

However even this principle isn't simple:

CSS doesn't work this way entirely. HTML _does_ still convey some
presentational information, because CSS' design was simplified to
depend on it continuing to do so. If CSS was as sophisticated as
DSSSL (and as hard to use), then we wouldn't need as many <div>,
<span>, <hr> or <br> as CSS sometimes requires HTML to contain, to
permit a particular presentation.

This principle isn't that useful in practice. It's great for "Zen
Garden" or for some idealised CMS contexts, where "designers" make CSS
and content authors make pure-content HTML. For many of tus though,
the HTML + CSS process to achieve an exact design requirement is an
iterative process involving related work on both parts at once. if
this is already the case, a new need to express some presentational
aspects in the HTML file isn't losing much, but it may simplify the
required CSS considerably.
 
J

Jeff

Chaddy2222 said:
I think your nameing system is fine.
I agree with you on the class issue but I would also say that useing
classes is better then useing inline styles.

Well, I couldn't agree with you more on that! Inline styles have a
place though and that is generally in testing and demonstrating. When
you put in an inline style you know absolutely that it will override
everything else and you don't have to go to the stylesheet and find the
style.

Jeff
 
J

Jeff

John said:
Agreed, at least the first part, although it seems you have swapped the
examples.


So what do you do when you decide the image which has been floated right
should now be on the left?

I would think a lot of this has to do with how accessible the
classnames are. If this were hardwired in a template then that would
require going back in and altering the html. Nobody thinks that's a good
idea (or do they?).

But if this was set as a switch in a CMS, and I do something similar,
then adjusting how all the float left or float right images present is
easy.

I look at it this way. If it's in the template then structural naming
is preferred, and I vastly prefer descendants of sections here. But if
it is a presentational adjustment that the content author is making then
a structural name is meaningless.

There's a place for both. Andy has just elaborated on that in a
somewhat different context.

Jeff
 
M

Michael Fesser

..oO(John Hosking)
Agreed, at least the first part, although it seems you have swapped the
examples.

Indeed. My fault.
So what do you do when you decide the image which has been floated right
should now be on the left?

I change the template which is used to build the HTML. The final HTML
code for my images is script-generated with automatically added links to
a bigger version of the image and a caption text below it if available:

<p>hello world ...
{cmp:image;path=/foo,fileName=bar,descr=some caption text,align=right}
</p>

The result will then be the use of "fr" instead of "fl".

For single images here and there this is much easier than having to
define a class for each one, just in order to be able to change the
position of the image without touching the template. In more complex
situations I might assign a class to the container that holds the
image(s) and then use descendant selectors to align them, though.
Wondering (and excited to hear) how you style the columns.

By script. ;)

Since you can't apply much styling to a column except for 4 properties,
you have to assign a class to every cell in that column. If I decide in
my script, that a column should be right-aligned, the "ar" class will be
automatically added to all cells there.

In some of these cases I use more meaningful class names, for example
"price", but usually the generic alignment class is enough. It's the
same as with the images above - I don't want to clutter my stylesheets
with dozens of classes that are only used once on a single page unless
it's really necessary. Until then I use the less flexible, but more
generic way.
Exactly: they're purely presentational. But you've built their
presentation into the code by including the (abbreviated and obscure)
class names in the HTML.

I know and I have my reasons for that. I also said that these 5 classes
are more or less my only exceptions and mostly used internally for
script-generated content and templates.

Micha
 
M

Michael Fesser

..oO(Jeff)
Well, I couldn't agree with you more on that! Inline styles have a
place though and that is generally in testing and demonstrating. When
you put in an inline style you know absolutely that it will override
everything else and you don't have to go to the stylesheet and find the
style.

I also use inline styles in another case: In some of my web projects
every page has a sidebar image. These images are purely decorational,
hence included as CSS backgrounds. Since the image is different on each
page, the main styling is done in the external CSS, but the filename
comes from a short inline CSS, written by a script.

Micha
 
H

Harlan Messinger

Andy said:
Jukka K. Korpela wrote:
OK, I'll bite. I've never heard you condemn a class name before, and to
start with "center" has me a bit amazed. Can you elaborate on why
"center" has no meaning? On the surface it would seem to be self
explanatory.

It's an interesting question, deserving a good answer.

Firstly, I'm surprised you haven't heard Jukka rag on this one before.
It's a regular tripwire around here.

Thirdly, it's obviously "self explanatory". That's not the problems.

Mostly though it's about the second part of your question, 'Can you
elaborate on why "center" has no meaning?' Of course it has
"meaning", the problem is _what_ domain that meaning is applied to.

Jukka favours classnames that reflect "markup", i.e. their meaning
should be objective and based around the content of the document, not
how it's to be presented. So a classname of "legal-postscript" is OK,
but "centred" is bad. Even "legal-footer" is dubious (who's to say
that it should always be presented as a "footer"?)

Some people, myself included but not AIUI Jukka, believe that semantic
HTML can be extended by the rigorous use of classnames which have
implied binding to schema or ontology documents, as a way of extending
the public semantics of HTML. This is already easy to do (and widely [snip]
An alternative approach, as described here, is to use classnames that
reflect "presentation" aspects, not content markup at all. Classnames
like "center", "red", "bold10px" are obvious indications of this.
However you should remember that the names of "presentational"
classnames are no more inferrable than "structural" classnames.
"bold10px" is no more likely to still translate to the "obvious" CSS
in an old project than "left-menu" is likely to still be on the left
rather than re-designed to the right. This lack of stability over time
and maintenance is perhaps the biggest problem with overtly
presentational classnames.

It's an article of faith hereabouts that structural class names are
good and presentational class names are always bad, hence Jukka's
reaction. [snip]

I take a rather softer line. Structural classes are good, but
presentational class names _may_ also be a good thing, under certain
constraints. [snip]
However even this principle isn't simple:
[snip]

I have no argument with Andy's exposition, but he addresses your
question in terms of philosophy, principles, articles of faith, and
theoretical argument. The reason can also be stated in very simple and
practical terms. It corresponds to practical considerations pervasive
throughout the world of software development. If you're writing a
routine to compute the number of boxes of widgets to ship from the
number of widgets ordered, and there are 24 widgets in a box, you don't
write

const int twentyFour = 24;
int boxes = (widgets + (twentyFour - 1)) / twentyFour;

What if later the packaging changes and widgets are shipped in boxes of
30? Change "twentyFour" to "thirty" everywhere in your program? This
defeats the purpose of using a named constant.

You write:

const int widgetsPerBox = 24;
int boxes = (widgets + (widgetsPerBox - 1)) / widgetsPerBox;

Likewise with styling: you want the main navigation to look this way,
you want image captions to look that way, you want numeric table data to
look another way, so you create classes or assign IDs with names like
mainNav and imageCaption and numData and define rules for selectors such as

div#mainNav { ... }
div#mainNav ul { ... }
div#mainNav li { ... }
div.imageCaption { ... }
td.numData { text-align: right; ... }

etc.

If you want your main navigation text to be green and so you created a
class "green" and had

..green { color: green; }

what would you do if someone said, "Make it red instead"? (If you're
like some programmers I've known, you'd change it to

..green { color: red; }

and not care that your successors will be endlessly perplexed by this
and similar obscenities sprinkled throughout your code.)
 
J

John Hosking

Michael said:
.oO(John Hosking)


I change the template which is used to build the HTML. The final HTML
code for my images is script-generated with automatically added links to
a bigger version of the image and a caption text below it if available:

<p>hello world ...
{cmp:image;path=/foo,fileName=bar,descr=some caption text,align=right}
</p>

Hey, what a minute; that's cheating! Creating your pages programatically
isn't allowed, is it? That'd make it too easy.
The result will then be the use of "fr" instead of "fl".

For single images here and there this is much easier than having to
define a class for each one, just in order to be able to change the
position of the image without touching the template. In more complex
situations I might assign a class to the container that holds the
image(s) and then use descendant selectors to align them, though.


By script. ;)

Nuts. I thought maybe you had discovered some way to make colgroup
fulfill my secret fantasies.
Since you can't apply much styling to a column except for 4 properties,
you have to assign a class to every cell in that column. If I decide in
my script, that a column should be right-aligned, the "ar" class will be
automatically added to all cells there.
Cheater.


In some of these cases I use more meaningful class names, for example
"price", but usually the generic alignment class is enough. It's the
same as with the images above - I don't want to clutter my stylesheets
with dozens of classes that are only used once on a single page unless
it's really necessary. Until then I use the less flexible, but more
generic way.

[snip agreement that these five classes are purely presentational]
I know and I have my reasons for that. I also said that these 5 classes
are more or less my only exceptions and mostly used internally for
script-generated content and templates.

So do I understand correctly, that you have to run your scripts to
rebuild all your pages every time you want to revise the presentation?
Or just when reworking the look in a way that involves these 5 classes?
 
M

Michael Fesser

..oO(John Hosking)
Hey, what a minute; that's cheating! Creating your pages programatically
isn't allowed, is it? That'd make it too easy.

It was not forbidden.
Nuts. I thought maybe you had discovered some way to make colgroup
fulfill my secret fantasies.

Nope. Well, you could use JavaScript ... *duck&run*
So do I understand correctly, that you have to run your scripts to
rebuild all your pages every time you want to revise the presentation?
Or just when reworking the look in a way that involves these 5 classes?

My pages are not static. They are always generated by scripts because of
various dynamic components (user login for example). Any changes to the
stylesheets or templates take effect immediately.

Micha
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top