Question about CSS definitions

Discussion in 'HTML' started by rbaulbin@hotmail.com, Feb 6, 2008.

  1. Guest

    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
     
    , Feb 6, 2008
    #1
    1. Advertising

  2. wrote:

    > 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.

    --
    -bts
    -Motorcycles defy gravity; cars just suck
     
    Beauregard T. Shagnasty, Feb 6, 2008
    #2
    1. Advertising

  3. Scripsit :

    > 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.

    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Feb 6, 2008
    #3
  4. Jeff Guest

    Jukka K. Korpela wrote:
    > Scripsit :
    >
    >> 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.


    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
    >
    >> 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.
    >
     
    Jeff, Feb 7, 2008
    #4
  5. ..oO(Jeff)

    >Jukka K. Korpela wrote:
    >
    >> 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.


    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
     
    Michael Fesser, Feb 7, 2008
    #5
  6. dorayme Guest

    In article <>,
    Jeff <jeff@spam_me_not.com> wrote:

    > Jukka K. Korpela wrote:
    > > Scripsit :
    > >
    > >> Is there any advantage to defining classes with the element name vs.
    > >> without the element name?

    > >

    ....
    > > 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.

    >
    > ...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.

    --
    dorayme
     
    dorayme, Feb 7, 2008
    #6
  7. wrote:
    > 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.


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Feb 7, 2008
    #7
  8. Jeff Guest

    dorayme wrote:
    > In article <>,
    > Jeff <jeff@spam_me_not.com> wrote:
    >
    >> Jukka K. Korpela wrote:
    >>> Scripsit :
    >>>
    >>>> Is there any advantage to defining classes with the element name vs.
    >>>> without the element name?

    > ...
    >>> 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.

    >> ...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.


    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



    >
     
    Jeff, Feb 7, 2008
    #8
  9. Chaddy2222 Guest

    On Feb 7, 3:10 pm, Jeff <jeff@spam_me_not.com> wrote:
    > dorayme wrote:
    > > In article <>,
    > >  Jeff <jeff@spam_me_not.com> wrote:

    >
    > >> Jukka K. Korpela wrote:
    > >>> Scripsit :

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

    > > ...
    > >>> 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.
    > >> ...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.

    >
    > 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.
    --
    Regards Chad. http://freewebdesignonline.org
     
    Chaddy2222, Feb 7, 2008
    #9
  10. John Hosking Guest

    Michael Fesser wrote:
    >
    > 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.


    --
    John
    Read about the UIP: http://improve-usenet.org/
     
    John Hosking, Feb 7, 2008
    #10
  11. Andy Dingley Guest

    On 7 Feb, 00:01, Jeff <jeff@spam_me_not.com> wrote:
    > Jukka K. Korpela wrote:


    > > 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.


    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.
     
    Andy Dingley, Feb 7, 2008
    #11
  12. Jeff Guest

    Chaddy2222 wrote:
    > On Feb 7, 3:10 pm, Jeff <jeff@spam_me_not.com> wrote:
    >> dorayme wrote:
    >>> In article <>,
    >>> Jeff <jeff@spam_me_not.com> wrote:
    >>>> Jukka K. Korpela wrote:
    >>>>> Scripsit :
    >>>>>> Is there any advantage to defining classes with the element name vs.
    >>>>>> without the element name?
    >>> ...
    >>>>> 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.
    >>>> ...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.

    >> 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.


    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
    > --
    > Regards Chad. http://freewebdesignonline.org
     
    Jeff, Feb 7, 2008
    #12
  13. Jeff Guest

    John Hosking wrote:
    > Michael Fesser wrote:
    >>
    >> 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?


    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

    >
    >>
    >> 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.
    >
    >
     
    Jeff, Feb 7, 2008
    #13
  14. ..oO(John Hosking)

    >Michael Fesser wrote:
    >>
    >> 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.


    Indeed. My fault.

    >> 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?


    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.

    >> 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.


    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.

    >> 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.


    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
     
    Michael Fesser, Feb 7, 2008
    #14
  15. ..oO(Jeff)

    >Chaddy2222 wrote:
    >
    >> 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.


    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
     
    Michael Fesser, Feb 7, 2008
    #15
  16. Andy Dingley wrote:
    > On 7 Feb, 00:01, Jeff <jeff@spam_me_not.com> wrote:
    >> Jukka K. Korpela wrote:

    >
    >>> 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.

    >
    > 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.)
     
    Harlan Messinger, Feb 7, 2008
    #16
  17. John Hosking Guest

    Michael Fesser wrote:
    > .oO(John Hosking)
    >
    >> 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>


    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.
    >


    >> Wondering (and excited to hear) how you style the columns.

    >
    > 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?

    --
    John
    Read about the UIP: http://improve-usenet.org/
     
    John Hosking, Feb 7, 2008
    #17
  18. ..oO(John Hosking)

    >Michael Fesser wrote:
    >
    >> 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.


    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*

    >> 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?


    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
     
    Michael Fesser, Feb 8, 2008
    #18
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Barth

    Question about definitions

    Thomas Barth, Nov 15, 2004, in forum: C++
    Replies:
    3
    Views:
    2,598
    Victor Bazarov
    Nov 15, 2004
  2. ark

    A question on incomplete definitions

    ark, Dec 17, 2003, in forum: C Programming
    Replies:
    24
    Views:
    871
    Peter Shaggy Haywood
    Dec 22, 2003
  3. ishtar2020
    Replies:
    2
    Views:
    996
    Simon Forman
    Aug 28, 2006
  4. Roman Mashak

    question about 'static' definitions

    Roman Mashak, May 21, 2005, in forum: C Programming
    Replies:
    3
    Views:
    323
    Malcolm
    May 21, 2005
  5. richard
    Replies:
    12
    Views:
    756
    dorayme
    Mar 9, 2010
Loading...

Share This Page