Core apparently has some guidelines for CSS classes but are these documented anywhere? As an example, I see that Aggregator uses "more-link;" is this a "standard?" If so, it would be nice if module developers had access to such a list so that we wouldn't be going at cross-purposes or re-inventing the wheel.

Comments

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Title: Document class guidelines » Document CSS class guidelines
Priority: Minor » Normal
MGParisi’s picture

MGParisi commented

The more link is actually an API function, same with building a table with even, odd.

More links do follow a consistent class. Tables start with

then goto odd and even classes. There are API functions that build tables. They use arrays, and provide a quick way to make a table out of a DB Query.

I do not know of any documentation on the issue, but I have filed a few patches to help fix the issues. I must admit that I have failed to use the table api properly (though I will in the future).

Many change from d5->d6 (d6 is cleaner in its class structure). Tabs do not have a current standard that I know of. I had to redo the CSS for both. I think the theme community would be best to recognize the consistencies. I would approach the theme group for a document on standards. Also the current .css files that ship with Drupal do not have any proper documentation.

You may always create the start of a document (intro and the few standards you know) and then mark it as incomplete.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Good point.

Hopefully, in D7 lists will use even/odd as well, but I haven't checked the status of that issue in a while.

arianek’s picture

arianek commented
Status: Active » Fixed

CSS coding standards have been documented - see http://groups.drupal.org/node/6355, http://groups.drupal.org/node/14421 and http://drupal.org/node/302199 If there are specific things missing from the docs, pls add them or file more specific issues. Closing this.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Fixed » Active

I am reopening this issue because while documenting the standards is great, it misses the original point of this post. There seem to be some standard class names that need to be documented as well. Some examples are "more-link," "even," and "odd." In order to keep contributed modules at the highest possible quality and core consistency, we maintainers need to know these class names so that we can use them rather than inventing our own and therefore allow site themers consistency of look and feel. IMHO, with Fields moving into core, this could become even more important. And if parts of Views move into core at some point, this would become absolutely critical.

MGParisi’s picture

MGParisi commented
Component: New documentation » Correction/Clarification

The class names more-link, even and odd are actually set by the API functions. Now I have not coded since d5 but I beleive the table is here http://api.drupal.org/api/drupal/includes--theme.inc/function/theme_table/6 and is documented.

These issues creep in when someone does not use the API... I had ran into this problem when I took over the d5 amazon module. When I optimized the code by using the API the class issues went away.

Is more API functions are introduced (such as Views beign added) then there will be more tools to use for faster development. The challenge is knowing all of the API functions and to use them during module development. An issue that is currently being handled by the more intensive module approval process and the ability to get mentoring.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Please don't focus on a few classes that are common. This is not just about theme_table. There are many classes used in core. Yes, most come from APIs, and many may very well be obscurely documented somewhere (scattered about). Others that I can think of are "front," "links," "inline," "menu," "active-trail." I don't know how many modules for which I created my own new classes (and CSS files) before I stumbled across "container-inline." How many other module maintainers have done the same? I don't expect that all such classes will be gathered at one time, but any progress is better than none. Since I seem to be entering a (hopefully) brief period of unemployment, maybe I'll start something

paul2’s picture

paul2 commented

+1
Perhaps it would help @arianek distinguish this issue from coding guidelines if perhaps this issue didn't have "guidelines" in the name. There's a big distinction between a reference of available classes to reuse (what @NancyDru is interested in) and how to write correct CSS code. It's akin to the difference between an API reference and PHP coding guidelines.

Other examples of classes I'd like to learn more about are: element-hidden and element-invisible. I'd like to know if I should be allowed to reuse these classes and other ones, or if they are theme-specific, or going to be deprecated, etc.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Title: Document CSS class guidelines » Document CSS classes

Ok, changed title

leehunter’s picture

leehunter commented
Status: Active » Fixed

This topic seems to be documented here: http://drupal.org/node/388372

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Fixed » Active

Nope. What about "more-link," "node-read-more," "clear-block," "container-inline," etc. There are lots of core classes I have discovered over the years.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Issue summary: View changes
Issue tags: +docsprint

Adding to this page seems like it might be a good project for a sprint?

And I would suggest making separate pages for Drupal 6, 7, and 8 probably?