**************
* MESSAGE 01 *
**************
I've been trading e-mails with a colleague for the last few days and he
asked if there are any CSS methodologies available. While I have practices
that I consistently follow, I do not know of any that are wide-spread or
commonly accepted as the best way to set up and maintain style sheets. So,
does anyone know of a good methodology already in existence? If not, anyone
interested in assisting me as I begin to document and revise one?
In case there aren't any, here are a some of the practices I follow. Please
feel free to let me know of poor decisions in my methods, and suggest new ones!
Style Sheet Organization
- Classes, IDs and elements are listed in alphabetical order unless
otherwise noted. The properties of each class, element and ID are in
alphabetical order as well. So the "acronym" tag comes before the "body"
tag which comes before the "price" ID in the stylesheet. I find this makes
it much easier for me and other developers to locate specific items within
the stylesheet quickly.
- The link pseudo-classes are grouped together, but do not follow the
alphabetical organization within that grouping as some browsers will use
the last pseudo-class listed, even if the more accurate one is listed
earlier. Rather annoying.
- When possible, elements should be grouped if they have a common
attribute, or set of attributes. An example would be to assign the same
font to the "body", "p", "input" and "td":
body, input, p, td {
font: small Georgia, Garamond, "Times New Roman", serif;
}
- When possible descendant styles should be used to cut down on the code
in the style sheets. Below is an example of applying a specific style to an
input element within a form with an element that has been assigned the
"Purchase" class. Example:
.Purchase form input {
border: 1px solid #654819;
height: 18px;
}
Style Naming Convention
- Classes and IDs use mixed case to make them easier to read. In the
HTML 4.01 spec, classes and IDs are case sensitive; though some browsers do
not recognize the fact. Elements are left in lower case. * I know this
one may end up being controversial as naming conventions often tend to be *
- Do not start an ID or class with a digit or use underscores as they
may not work in all browsers.
- Classes and IDS should never be an adjective or infer placement as a
future redesign may not place the item in the same spot, or use the same
background color. So, instead of using an ID of "TopBox", use an ID
specific to its contents, perhaps "GlobalNav".
Thanks!
Alex
**************
* MESSAGE 02 *
**************
I too am interested in a methodology if there is one. I do know that I don't
follow the above. I group my classes between separator comments based on
location/use. For example all classes used in the header are grouped
together, same for left navs, forms, etc. I also put all global classes such
as body at the top since I use these to set font face and color and can
override them further down the CSS.
Eugenia
**************
* MESSAGE 03 *
**************
I'm also interested in what people do.
I've tended towards having four major sections to my css files:
1) Site structure (main divs, body, anything that defines the major
areas of the site like header, footer, nav, body, etc.) --- another way
to think of this is anything that defines a physical box that stuff
goes in. I never have more than 5 or 6 defs here.
2) Styles specific to the boxes above. This is where stuff like
#navPanel h1 would go, etc.
3) Overrides to default html: this is where h1, h2, h3, p, li, ul,
fieldset, etc definitions go.
4) Custom classes/ids that are not specific to a box but are
site/page-wide.
This has worked out the best in terms of editing and going back later
to see what I did.
-A
Andy J. W. Affleck
andyjw@raggedcastle.com
http://www.raggedcastle.com/webcrumbs/
iChatAV/AIM: andyjw23
**************
* MESSAGE 04 *
**************
>> - Classes, IDs and elements are listed in alphabetical order unless
>> otherwise noted...
This is not completely right, since the order has a value when evaluating
rules, so most times you may want to establish a precise order, for
instance: I want to specify in BODY general attributes, but use specific
ones in ACRONYM. It can be done if I use:
body{...}
acronym{..}
but not
acronym{..}
body{...}
With IDs the same thing happen, position inside the document is relevant.
I think this apply to all your other structure as well...
regards,
------------------------------------------------------------
Nelson Rodriguez-Pena A.
Web & Multimedia Design & Development
nelson@webstudio.cl
------------------------------------------------------------
**************
* MESSAGE 05 *
**************
At 09:48 AM 7/23/2003, Slaydon, Eugenia wrote:
>I group my classes between separator comments based on
>location/use. For example all classes used in the header are grouped
>together, same for left navs, forms, etc. I also put all global classes such
>as body at the top since I use these to set font face and color and can
>override them further down the CSS.
I used to follow a method that closely resembles this, but I found it is
much easier for me (and other people on a project team) to locate what they
are looking for alphabetically. This was especially true when I/we had to
edit some large style sheets months after the project was complete.
Alex
**************
* MESSAGE 06 *
**************
on 7/23/03 10:20 AM, Nelson Rodriguez-Pena at nelson@webstudio.cl wrote:
> ... the order has a value when evaluating
> rules, so most times you may want to establish a precise order, for
> instance: I want to specify in BODY general attributes, but use specific
> ones in ACRONYM. It can be done if I use:
>
> body{...}
> acronym{..}
>
> but not
>
> acronym{..}
> body{...}
>
> With IDs the same thing happen, position inside the document is relevant.
I agree - I list all general attributes first and then tackle the document
structure and specific attributes, in order of location.
This method also makes it easier to troubleshoot bugs. With the style rules
ordered by location, you can examine a troublesome spot AND the rules being
applied to elements surrounding it. An alphabetical listing of style rules
would make this very difficult.
Besides, applications usually have shortcut keys for the "Find" function if
you're looking for a specific rule, so that seems to eliminate the need for
alphabetical indexing.
Great idea to put together a methodology. I'd love to see the finished list.
Regards,
Alicia
**************
* MESSAGE 07 *
**************
> I used to follow a method that closely resembles this, but I found it is
> much easier for me (and other people on a project team) to locate what
they
> are looking for alphabetically. This was especially true when I/we had to
> edit some large style sheets months after the project was complete.
>
> Alex
I tend to follow my markup structure in my CSS. So in the same manner that
I have id's and classes setup in the markup, so my CSS reflects the same
structure. I hope that made sense.
Then when I go back to edit/review something. I look at the markup and
determine approximate position in the markup that i want to look up, and go
to that area of the CSS.
I also tend to group all my id's and classes that are related/nested
together. So if i have a several nested divs, then they would all fall
relatively close in the CSS.
Jason Estes
The BEWB
www.bewb.org
**************
* MESSAGE 08 *
**************
At 10:20 AM 7/23/2003, Nelson_Rodriguez-Pena wrote:
> >> - Classes, IDs and elements are listed in alphabetical order unless
> >> otherwise noted...
>
>This is not completely right, since the order has a value when evaluating
>rules, so most times you may want to establish a precise order, for
>instance: I want to specify in BODY general attributes, but use specific
>ones in ACRONYM. It can be done if I use:
>
>body{...}
>acronym{..}
>
>but not
>
>acronym{..}
>body{...}
>
>With IDs the same thing happen, position inside the document is relevant.
>
>I think this apply to all your other structure as well...
Really? I thought the cascade applied to the order in which the styling is
applied as opposed to the order it is in within the style sheet (unless
there are conflicting style sheets or in-line styles defining the same
element, class or ID). My understanding of the cascading order (
http://www.w3c.org/TR/CSS1#the-cascade -Rule 4) leads me to believe that
the acronym element is more specific than the body and thus its style rules
would take precedence over those set in the body. My experience has shown
this to be the case for all but :link and its cohorts.
Alex
**************
* MESSAGE 09 *
**************
Alex Jones wrote:
> I used to follow a method that closely resembles this, but I found it
> is much easier for me (and other people on a project team) to locate
> what they are looking for alphabetically. This was especially true
> when I/we had to edit some large style sheets months after the
> project was complete.
If you are using TopStyle, it has a selectors tab that groups all the styles
by elements, classes and IDs, then lists them in alphabetical order. I tend
to group styles by structure, then use that tab when I want to find (and
jump to) a particular style. It's terrific feature!
-- Kath ...
work --> www.winebow.com
home --> www.cyber-kat.com --> topkat@cyber-kat.com --
**************
* MESSAGE 10 *
**************
Hi,
>> Great idea to put together a methodology. I'd love to see the finished
list.
I agree with that too. I've found that a great way of organizing mi styles
is separating rules in files that have sense as modules, so for example, an
intranet will have:
- login.css: having everything it needs, it shouldn't be much...
Then, entering the main page, I'll load the main styles:
- main.css with the main rules, like BODY, P, Hx, etc. describing
presentational attributes, but *not LAYOUT*;
- layout.css which describes de layout an page distribution of elements,
headers, columns, footer, etc.
- print.css with printing styles.
If other pages use specific styles, they load/call then when needed.
This makes it very easy to modularize and find what you need when editing...
My 2 pesos (which are in fact less than 2 cents...).
regards,
------------------------------------------------------------
Nelson Rodriguez-Pena A.
Web & Multimedia Design & Development
nelson@webstudio.cl
------------------------------------------------------------
**************
* MESSAGE 11 *
**************
> I used to follow a method that closely resembles this, but I
> found it is
> much easier for me (and other people on a project team) to
> locate what they
> are looking for alphabetically.
But listing everything alphabetically can break the cascade. In otherwords,
you can override another style inadvertantly if grouping in this manner.
I simply organize my styles based on what they're styling. All the
navigation styles go in one section (following the cascade), the content
styles in another, the footer in another, etc.
And, of course, I use lots of comments.
-Darrel
**************
* MESSAGE 12 *
**************
Hi Alex,
Really? I thought the cascade applied to the order in which the styling is
applied as opposed to the order it is in within the style sheet (unless
there are conflicting style sheets or in-line styles defining the same
element, class or ID). My understanding of the cascading order (
http://www.w3c.org/TR/CSS1#the-cascade -Rule 4) leads me to believe that
the acronym element is more specific than the body and thus its style rules
would take precedence over those set in the body. My experience has shown
this to be the case for all but :link and its cohorts.
Well, in http://www.w3.org/TR/REC-CSS1#cascading-order point 5 it says:
5. Sort by order specified: if two rules have the same weight, the latter
specified wins. Rules in imported style sheets are considered to be before
any rules in the style sheet itself.
So it might matter, though not always. It surely is better having things
organized in a way that helps avoiding this problems...
regards,
------------------------------------------------------------
Nelson Rodriguez-Pena A.
Web & Multimedia Design & Development
nelson@webstudio.cl
------------------------------------------------------------
**************
* MESSAGE 13 *
**************
On Wed, 23 Jul 2003, Alicia Lane wrote:
: I agree - I list all general attributes first and then tackle the document
: structure and specific attributes, in order of location.
I do a sorta 3 way hybrid from what y'all have said:
1) General Attributes (body, a, blockquote, etc)
2) Large layout blocks (header, body, footer) definitions for quick overview
(helps a LOT with multiple designers working on umpteen bazillion sites)
Some major subsections for a site might go here in logical order, e.g. a
block that's always set left for nav
3) Specific styles in alphabetical class name
Seems to help get the basic structure and definitions down fast and keep the
file easy to jump through.
**Michael
--
KoNfUzEd konfuzed@gatech.edu | Guard what you say or send by writ
http://konfuzed.com/ | dispatch; Every ear and eye has a
| tongue to match.
**************
* MESSAGE 14 *
**************
At 10:40 AM 7/23/2003, Alicia Lane wrote:
>I agree - I list all general attributes first and then tackle the document
>structure and specific attributes, in order of location.
>
>This method also makes it easier to troubleshoot bugs. With the style rules
>ordered by location, you can examine a troublesome spot AND the rules being
>applied to elements surrounding it. An alphabetical listing of style rules
>would make this very difficult.
Hrrrm, the way I tend to name my classes and IDs ensure they are grouped,
even within an alphabetized framework. But unless I am wrong about the
cascading order (more info in a previous reply to Nelson Rodriguez-Pena) I
do not see how this is very beneficial. If you change the structure of the
(X)HTML at a later date you would have to return and restructure your CSS -
even if the styles didn't change. Also, how would you address a class or ID
that might be placed in a different part of the structure depending on the
page or module being viewed? Does that make it a general attribute?
I do see value in grouping the general attributes and then structure, but
I'm trying to question everything (including my own assumptions). :)
Playing the devil's advocate.
>Besides, applications usually have shortcut keys for the "Find" function if
>you're looking for a specific rule, so that seems to eliminate the need for
>alphabetical indexing.
Well, different people use apps in different ways. :) While I like to use
the find function often, some designers and developers either don't think
to use it, or are just wired to scroll.
>Great idea to put together a methodology. I'd love to see the finished list.
This is a great discussion so far, please keep it up! If people are
interested, I would be more than happy to set up a site to start gathering
and archiving the discussion to turn into some documentation. It would be
easy enough to set up multiple authors for those interested in actively
participating.
Alex
**************
* MESSAGE 15 *
**************
At 10:58 AM 7/23/2003,Nelson_Rodriguez-Pena wrote:
>I agree with that too. I've found that a great way of organizing mi styles
>is separating rules in files that have sense as modules
>If other pages use specific styles, they load/call then when needed.
>
>This makes it very easy to modularize and find what you need when editing...
A good idea. I tend to use a print style sheet, though I haven't broken my
styles out into modularized components, but it makes a good deal of sense.
Alex
**************
* MESSAGE 16 *
**************
At 11:05 AM 7/23/2003, =?us-ascii?Q?Nelson_Rodriguez-Pena?= wrote:
>
>5. Sort by order specified: if two rules have the same weight, the latter
>specified wins. Rules in imported style sheets are considered to be before
>any rules in the style sheet itself.
>
>
>So it might matter, though not always. It surely is better having things
>organized in a way that helps avoiding this problems...
>
Hrrrm, I have interpreted this to mean that if two rules of the same name
(two paragraph tags, or two classes named 'price') then the last one
specified would be used. As this shouldn't happen within a single style
sheet the only real problem crops up when linking or importing more than
one style sheet that uses the same rule. At that point wouldn't the last
one linked to or imported be the one used?
I agree that the organization should avoid causing problems.
Alex
**************
* MESSAGE 17 *
**************
At 10:54 AM 7/23/2003, Kathleen Heytink wrote:
>If you are using TopStyle, it has a selectors tab that groups all the styles
>by elements, classes and IDs, then lists them in alphabetical order. I tend
>to group styles by structure, then use that tab when I want to find (and
>jump to) a particular style. It's terrific feature!
Oooooh, I wasn't aware of that! I need to go look at TopStyle again me
thinks. Come to think of it, that product as well as any others like it may
be good sources to review regarding the structuring of the style sheets.
Thanks for the info!
Alex
**************
* MESSAGE 18 *
**************
>
> Really? I thought the cascade applied to the order in which the styling is
> applied as opposed to the order it is in within the style sheet (unless
> there are conflicting style sheets or in-line styles defining the same
> element, class or ID). My understanding of the cascading order (
> http://www.w3c.org/TR/CSS1#the-cascade -Rule 4) leads me to believe that
> the acronym element is more specific than the body and thus its style rules
> would take precedence over those set in the body. My experience has shown
> this to be the case for all but :link and its cohorts.
>
>
> Well, in http://www.w3.org/TR/REC-CSS1#cascading-order point 5 it says:
>
>
> 5. Sort by order specified: if two rules have the same weight, the latter
> specified wins. Rules in imported style sheets are considered to be before
> any rules in the style sheet itself.
>
>
> So it might matter, though not always. It surely is better having things
> organized in a way that helps avoiding this problems...
acronym is more specific than body. its the equivalent of:
body { ... }
* acronym { ... }
I have never had a problem with alphabetizing my css, for that reason.
but your main point is correct. if I do:
p {color: red}
p {color: blue}
blue wins because it is the latter specified.
**************
* MESSAGE 19 *
**************
on 7/23/03 11:23 AM, Alex Jones at alexj_list@agrussell.com wrote:
> Hrrrm, the way I tend to name my classes and IDs ensure they are grouped,
> even within an alphabetized framework.
I'd love to see some examples of how you accomplish this naming scheme - I
could learn a thing or two myself! I'm especially curious how you handle
element selectors such as a.head or a#head?
> Well, different people use apps in different ways. :) While I like to use
> the find function often, some designers and developers either don't think
> to use it, or are just wired to scroll.
Good point - a well thought-out methodology accommodates a wide range of
working styles.
Alicia
**************
* MESSAGE 20 *
**************
I allways structure mine according to the FLOW of the page,
for example for a 3 column CSS layout:
body {
blah blah
}
right-content {
blah-blah
}
center-content {
blah-blah
}
left-content {
blah-blah
}
footer {
blah-blah
}
then style the p, h1,'s a's,,,,etc
markinoregon
Website under construction (as allways)
www.markthesteelhead.com
**************
* MESSAGE 21 *
**************
On 7/23/03 10:35 AM, "Alex Jones" wrote:
> Style Naming Convention
> - Classes and IDs use mixed case to make them easier to read. In the
> HTML 4.01 spec, classes and IDs are case sensitive; though some browsers do
> not recognize the fact. Elements are left in lower case. * I know this
> one may end up being controversial as naming conventions often tend to be *
I prefer all-lowercase, but I could easily switch, and frankly, mixed-case
seems to be used a lot and it's easy to make a good "case" for it.
> - Do not start an ID or class with a digit or use underscores as they
> may not work in all browsers.
Absolutely agreed.
> - Classes and IDS should never be an adjective or infer placement as a
> future redesign may not place the item in the same spot, or use the same
> background color. So, instead of using an ID of "TopBox", use an ID
> specific to its contents, perhaps "GlobalNav".
We've been moving toward that for a while -- we haven't gone back to fix old
labels, but it makes much more sense for current and future.
As for the structure and organization of the style sheet, here's what I find
works best:
Comment every section -- this is a must, since it leaves a roadmap for your
groupings.
Organize by purpose -- for instance, my style sheets are broken up as
follows, from top to bottom:
Global - body, img, anything else which needs to cascade down to the entire
document
Layout - This is where all the positioning occurs, and is primarily ID's (I
try to restrict Classes to non-layout elements, such as text styles). The
order in this section is very important: everything is ordered to mirror the
document flow of my XHTML (e.g. header, content, footer). This works much
better than ordering Alphabetically (IMO), and it makes more sense
considering the cascading nature of style declarations. Only positioning is
styled here, no text, usually no color unless a background color is set for
an element.
Headings - h1,h2,h3, etc. Variations on each are listed underneath the
primary element style, e.g.
h1 { this:that; }
h1.class { specific:yes; }
#content h1 { more:specific; }
Text - Here I define all text styles (except lists, which get their own
section later on), starting with the basic paragraph style (which is usually
just p { margin:0; padding:0; } ) and then setting more specific styles
associated with ID's (again, following the XHTML document flow from top to
bottom)
Lists - ul, ol, etc. This gets as specific as necessary.
Links - All links are placed here, starting with a, a:link and then getting
more specific, once again following the XHTML document flow.
Forms - All form styles go here.
Misc - Anything else goes here, e.g. acronym, custom span elements if
needed, etc.
This works great for me, and has worked on many different projects, and has
even helped with problem solving: since the CSS flow (within groupings)
follows the XHTML document flow, it's easy to figure out parent/child
relationships, and grouping by type allows me to quickly locate an element
in the style sheet (which is a tremendous help in larger style sheets)
Regarding specificity: I think elements need to be listed from least
specific to most specific.
Cheers,
-D
--
dan rubin
superfluous banter: small talk blog.
**************
* MESSAGE 22 *
**************
I see it as hugely dependent upon the project, so a fixed order isn't
always suitable.
In general terms, I proceed from general to specific. HTML tags first,
then IDs. All specific styles for the ID follow each individual ID.
Classes follow the HTML tags that they are used on.
For example:
body styles
p styles
classes used to modify p styles
section id styles
id p styles
classes used only to modify id p styles
As I explain it, I realize it seems complex, but it's been quite simple
for me to use. And it makes it easy for me to find the style I'm
looking for, without worrying about what happens when another style is
added before a given one. Since the file itself proceeds from general to
specific, later styles should not be overridden by earlier ones. It also
helps me stay aware of the rules of cascade.
Of course, the other thing I try to do is limit the number of styles. If
the stylesheet is getting too complicated for me to find my way around
easily, then the design is too complex, and it's time to simplicate. ;{>}
OTOH, there's a part of me that notes a milestone in the development of
this list; that we've started to focus on methodologies rather than the
actual task of CSS. And I think there's a Kat grinning right along with
me. Platonic commentary, anyone? (And yes, that's an obscure joke that
doesn't need to be commented upon on list, nor will it be explained, as
it is far off-topic.)
Have fun,
Arlen
**************
* MESSAGE 23 *
**************
on 7/23/03 12:15 PM, Jim Gay at jgay@tla.com wrote:
> but your main point is correct. if I do:
> p {color: red}
> p {color: blue}
>
> blue wins because it is the latter specified.
What about this, though?
div#foo p {color: red}
p {color: blue}
Which wins?
Alicia
**************
* MESSAGE 24 *
**************
Austin, Darrel wrote:
>>locate what they
>>are looking for alphabetically.
>
> But listing everything alphabetically can break the cascade. In otherwords,
> you can override another style inadvertantly if grouping in this manner.
>
I often do things like this:
.ThisBoxType, .ThatBoxType, SpecialBoxType
{
border: 2px solid #dddddd;
}
.SpecialBoxType
{
border-bottom: none;
}
This is a simple example of something that needs a specific order in the
CSS-document, to use the cascade.
I've been searching the Internet for CSS coding standards, but couldn't
find anything ... This really needs to be done!
/Anders
**************
* MESSAGE 25 *
**************
Wow, there has been an amazing amount of feedback so far! Please keep it
coming. I will try to respond to all of the ideas as I have time.
At this point it really does look like this could turn into a worthwhile
project, so I am going to set up a project site over the next few days to
ensure the momentum isn't lost. If you are interested in working on the
project please drop me a line off-list at css@silverspider.com. :) I will
post more info to the list as it develops.
Please note, this in no way should take away from this discussion on the
list, but I don't think the project should take over CSS-D; filling the
mailboxes of those who aren't interested in the project.
For those who have chimed in with such great feedback, thank you. For those
who haven't added your thoughts on the matter, please jump in as well!
Alex
**************
* MESSAGE 26 *
**************
>> but your main point is correct. if I do:
>> p {color: red}
>> p {color: blue}
>>
>> blue wins because it is the latter specified.
>
> What about this, though?
>
> div#foo p {color: red}
> p {color: blue}
>
> Which wins?
div#foo p should. its more specific. ids are at the top of the chain with a
higher score of specificity.
foo followed by p is more specific than just saying p
p {} sets up the rules for all p tags. but #foo p {} sets up the rules for
any p child of #foo.
http://www.w3.org/TR/REC-CSS2/cascade.html#specificity
* {} /* a=0 b=0 c=0 -> specificity = 0 */
LI {} /* a=0 b=0 c=1 -> specificity = 1 */
UL LI {} /* a=0 b=0 c=2 -> specificity = 2 */
UL OL+LI {} /* a=0 b=0 c=3 -> specificity = 3 */
H1 + *[REL=up]{} /* a=0 b=1 c=1 -> specificity = 11 */
UL OL LI.red {} /* a=0 b=1 c=3 -> specificity = 13 */
LI.red.level {} /* a=0 b=2 c=1 -> specificity = 21 */
#x34y {} /* a=1 b=0 c=0 -> specificity = 100 */
this is the same reason the Modified Simplified Box Model Hack works.
http://www.info.com.ph/~etan/w3pantheon/style/modifiedsbmh.html
* html
is more specific than
so it doesn't matter what order you place them in the css file.
so the hack works if its
* html p {}
p {}
or
p {}
* html p {}
-- please note that * html p is valid css, but shouldn't work in a proper
standards browser. its a hack on IE browsers.
'*' signifies whatever comes before , but in this case its
nothing, since the is 'html' and html is the root; there is
nothing before html, so '* html' leads nowhere.
IE doesn't understand this properly, and gives it a higher specificity
score.
**************
* MESSAGE 27 *
**************
div#foo p {color: red}
p {color: blue}
The div id foo will set all p elemnts in it to red,
All other p elemnts in the document will be blue.
*I think*
markinoregon
Website under construction (as allways)
www.markthesteelhead.com
**************
* MESSAGE 28 *
**************
I have two methodologies that have not been mentioned in this thread
(that I've noticed, anyways...)
1) Because different browsers have different defaults regarding
margins and such, I try to normalize this with declarations such as the
following:
body, div, ul, li, td, h1, h2, h3, h4, h5, h6 {
font-size: 100%;
font-family: Arial, Helvetica, sans-serif;
}
div, span, img, form, h1, h2, h3, h4, h5, h6 {
margin: 0px;
padding: 0px;
background-color: transparent;
}
These lines are the very beginning of the default stylesheet on the
site I'm currently working on.
After this I am able to explicitly style all of these elements without
worrying about some browser default messing up by styling something I
haven't declared. Theoretically this helps me get more consistent
results. These declarations as a standard thing to cut-and-paste into
any stylesheet are a work in progress, but I think I've got a good
start here.
2) I externalize all stylesheets. I have one stylesheet called
default.css, and then separate stylesheets as needed for various
sections of the site. Each page @imports the sheet particular for that
section of the site, and then the section-specific sheets all @import
the default.css sheet before any other styles are specified.
I believe this level of modularization makes it easier to track
problems, and allows enormous flexibility while allowing me to present
different page types.
Potential drawback is that NN4 and company don't understand @import.
I see that as an advantage, though, as I feed NN4 a simplified
stylesheet via .
Ultimately each .htm document has two style-related lines in the
:
a to default-legacy.css, and @import url("section-specific.css")
In case you haven't all noticed by now, I'm kind of anal. But that's a
good thing when dealing with CSS, IMO. ;)
Beyond those two, I tend to organize styles by general tag styles,
followed by ID selectors in roughly the order that they appear in the
page, followed by class selectors. I use BBEdit (Mac only), which has
a wonderful drop-down menu that lists all selectors in a CSS sheet so
you can jump directly to any of them quite quickly. :)
Regards,
Steve
**************
* MESSAGE 29 *
**************
Alex Jones wrote:
> Style Naming Convention
>
> - Do not start an ID or class with a digit or use underscores as they
> may not work in all browsers.
The spec. says:
In CSS2, identifiers (including element names, classes, and IDs in
selectors) can contain only the characters [A-Za-z0-9] and ISO 10646
characters 161 and higher, plus the hyphen (-); they cannot start with a
hyphen or a digit.
Underscores shouldn't be used AT ALL in CSS identifiers, they are not
standards compliant. Hypens are a nice alternative to make the
identifiers more readable.
> - Classes and IDS should never be an adjective or infer placement as a
> future redesign may not place the item in the same spot, or use the same
> background color. So, instead of using an ID of "TopBox", use an ID
> specific to its contents, perhaps "GlobalNav".
This is a very good point, IMHO.
It separates presentation from content even more, and gives you
identifiers that make sense.
/Anders
**************
* MESSAGE 30 *
**************
Hi again :)
I think it's worth mentioning that in cases I have to work with other people
or in complex projects, it helps *a lot* making wireframes, I prepare some
specific wireframes only for CSS, this is more of a visual map where y
organize columns, blocks, etc. and add important information like which
columns are liquid or fixed, width, and stuff like that. I attach to them
their IDs and/or classes. It's been really helpful.
regards,
------------------------------------------------------------
Nelson Rodriguez-Pena A.
Web & Multimedia Design & Development
nelson@webstudio.cl
------------------------------------------------------------
**************
* MESSAGE 31 *
**************
:
: > - Classes and IDS should never be an adjective or infer placement as a
: > future redesign may not place the item in the same spot, or use the same
: > background color. So, instead of using an ID of "TopBox", use an ID
: > specific to its contents, perhaps "GlobalNav".
:
Yes, I often run into the argument about "descriptive" naming conventions--I
say, there's descriptive (what it looks like) and then there's descriptive
(its function) ... which is going to be more useful next year when the look
of the site has changed? This is true in css just as it is with frames and
just as it is with database tables and field names and just as it is for
functions.
Donna
**************
* MESSAGE 32 *
**************
Yesterday I was serving on the internet searching for some
great methodologies. How does zeldman, bowman etc.... it.
After a long search I found myself a great methodologie that
looks great and after trying I think it is great. It's fine
and very clean.
The site where I got it was www.37signals.com (They make
really great shit!!!)
This is the methodologie:
Make two differtent stylesheets.
This one goes like
#Header
#Content
#Footer
This method works perfect for me since yesterday, but I
follow this topic shortly, maybe there is some better method
;)
izzii
**************
* MESSAGE 33 *
**************
At 10:44 AM 7/23/2003, you wrote:
>At 10:20 AM 7/23/2003, Nelson_Rodriguez-Pena wrote:
>> >> - Classes, IDs and elements are listed in alphabetical order unless
>> >> otherwise noted...
>>
>>This is not completely right, since the order has a value when evaluating
>>rules, so most times you may want to establish a precise order, for
>>instance: I want to specify in BODY general attributes, but use specific
>>ones in ACRONYM. It can be done if I use:
>>
>>body{...}
>>acronym{..}
>>
>>but not
>>
>>acronym{..}
>>body{...}
>>
>>With IDs the same thing happen, position inside the document is relevant.
>>
>>I think this apply to all your other structure as well...
>
>Really? I thought the cascade applied to the order in which the styling is
>applied as opposed to the order it is in within the style sheet (unless
>there are conflicting style sheets or in-line styles defining the same
>element, class or ID). My understanding of the cascading order (
>http://www.w3c.org/TR/CSS1#the-cascade -Rule 4) leads me to believe that
>the acronym element is more specific than the body and thus its style
>rules would take precedence over those set in the body. My experience has
>shown this to be the case for all but :link and its cohorts.
>
>Alex
Yes, but say you define base font-sizes in your #mainbody (14px) and
#sidebar (12px) divs and then use percentages for your h1, h2, and h3 tags,
intending that those percentages scale based on the font size set in the div.
Since h1-h3 would come before both mainbody and sidebar in your CSS when
arranged alphabetically, the font percentage sizes would scale based on the
user's default font size rather than those set in the divs, while those for
your #callout div would scale as you intended.
Of course, even methodologies that put all the html tag definitions before
all the classes would run into this sort-order problem.
**************
* MESSAGE 34 *
**************
Hi izzii, I think this method is the best, since you separate the layout
for the text-properties.
I first saw it on an example template (don't remember which) and I
continue using it, this method gives me more flexibility changing the
display position or the texts, as long as they are in different files...
An good example of this could be if you have two stilesheets, and you
only want to change from one to another the font properties only:
Cheers,
Jose