Forum: Ruby on Rails guides on css strategy

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2701c824d560c66c31b3d58d36fe17cf?d=identicon&s=25 itsastickup (Guest)
on 2009-02-18 02:45
(Received via mailing list)
I'm having to design the UI to a small site, and that means dabbling
in css. I've never been able to get any kind of decent idea as to how
to decide on classes and id-ing. I've had a sniff around the internet
without success: people seem to be as clueless as me. I've even
examined the css/markup of a few sites and it hasn't been
enlightening.

Does anyone know of a good source of info on css class decisions, and
ids? Even better with rails inm ind. Something that broke through for
you might be good. I'm not so interested in how css works: that's easy
to find, and I have a pretty good idea already.
B14575f0ca69f10938fdd67e7156e0e1?d=identicon&s=25 Craig Demyanovich (Guest)
on 2009-02-18 06:38
(Received via mailing list)
I'm no CSS expert by any stretch of the imagination. However, I do have
one
bit of advice: don't name classes based on attributes, such as color;
instead, name classes for what they are. For example, don't create a
class
named blue_table; rather, create one named line_items, if that's what
you're
presenting.

The problem with a name such as blue_table is that you might change the
color to green and the markup to use something other than a table. Then
you
also should change the CSS class name, but you only have to change it
because it's named poorly.

One of my partners likes the Blueprint CSS framework [
http://www.blueprintcss.org/ ]. I suspect it will serve as a good
example.

Regards,
Craig
2701c824d560c66c31b3d58d36fe17cf?d=identicon&s=25 itsastickup (Guest)
on 2009-02-18 12:04
(Received via mailing list)
Thanks, Craig.
B408c8d259cc9b98cf69da4afcad92fb?d=identicon&s=25 Paul Campbell (paul)
on 2009-02-18 12:30
(Received via mailing list)
A warning about Blueprint: The appeal of Blueprint is in its
outstanding grid framework: less on its naming conventions (it uses
span-1, span-2 etc. as class names, which are NOT semantic, although
very useful)

I find the best way to think of ids and classnames as specific and
generic and nothing to do with style. So If you have one main headline
on a page, it would have an ID of "headline", whereas if you had a
series of articles, you could have a class="articles" ...

... that said, you could also have a surrounding div called "articles"
and refer to the elements inside using CSS selectors.

But as said above: IDs are specific and unique. Classnames are generic
and not specifically related to styles ... the rest is really up to
you!

Paul
91a72b0ad3e43e3ef3a31816667ec694?d=identicon&s=25 bill walton (Guest)
on 2009-02-18 17:41
(Received via mailing list)
Hi,

On Tue, 2009-02-17 at 17:44 -0800, itsastickup wrote:
>
> I'm having to design the UI to a small site, and that means dabbling
> in css. I've never been able to get any kind of decent idea as to how
> to decide on classes and id-ing.

IME, the decisions you'll need to make will depend on the nature of the
site, especially as it relates to the volume of Javascript you'll be
using.  The HTML / Javascript / CSS interdependencies can get to be
quite a bit to manage.  Like you, I've been unable to find what I would
call a usable set of guidance.  Here's what I've come to.

We've got three 'identifiers' to work with: id, name, and class.  CSS
uses id and class.  Javascript uses id and name.  So, to keep the issues
as separate as possible, I try to avoid using id for CSS.  The problem
I've run into is that it's difficult to decide what 'class' a thing
belongs to until you've got lots of other things to compare it to.  So
what I'm ending up doing in actual practice is to initially use id to
style elements as the UI emerges, then refactor to classes as the site
comes together.  It's turning out to be a non-trivial exercise.

HTH,
Bill
Bee69cfed999cd13e3bff73d472a39ee?d=identicon&s=25 Hassan Schroeder (Guest)
on 2009-02-18 18:51
(Received via mailing list)
On Wed, Feb 18, 2009 at 8:38 AM, bill walton <bwalton.im@gmail.com>
wrote:

> We've got three 'identifiers' to work with: id, name, and class.  CSS
> uses id and class.  Javascript uses id and name.  So, to keep the issues
> as separate as possible, I try to avoid using id for CSS.

Huh??  JavaScript offers various ways to access elements of the
DOM, and 'class' is certainly one of them. Can you be more specific
about what "issues" you're trying to "keep separate"?

And if you have *one* of an element that needs styling, why not use
an ID to target your CSS?

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2009-02-18 23:54
Hassan Schroeder wrote:
> On Wed, Feb 18, 2009 at 8:38 AM, bill walton <bwalton.im@gmail.com>
> wrote:
>
>> We've got three 'identifiers' to work with: id, name, and class.  CSS
>> uses id and class.  Javascript uses id and name.  So, to keep the issues
>> as separate as possible, I try to avoid using id for CSS.
>
> Huh??  JavaScript offers various ways to access elements of the
> DOM, and 'class' is certainly one of them. Can you be more specific
> about what "issues" you're trying to "keep separate"?
>
> And if you have *one* of an element that needs styling, why not use
> an ID to target your CSS?
>
> --
> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com

To add a couple of point to this: First the name attribute is deprecated
because it turned out to be a mistake. It server the exact same purpose
as id and it redundant. Secondly, any sane person uses something like
jQuery or Prototype, which access elements in the DOM using CSS
selectors. So the trend is to try to bring JavaScript and CSS closer
together and not to separate them.

So given that there is not three identifiers there is just one, which is
id. The class attribute does not identify a DOM element. It identifies
the styles to apply to the element. Notice I said styles (plural).

This is perfectly legal:

HTML fragment
----
<ul id="articles">
  <li id="article_1" class="article_title">
    ...
  </li>
  <li id="article_2" class="article_title selected">
    ...
  </li>
  <li id="article_3" class="article_title">
    ...
  </li>
</ul>

CSS
-----
.article_title {
  font-size: 14pt;
  font-color: blue;
  font-weight: bold;
}

.selected {
  background-color: #ffc;
}

Notice that all id attributes are unique on the page and are used to
identify DOM elements. CSS class names describe the styling and are not
used to identify the DOM elements.
Bee69cfed999cd13e3bff73d472a39ee?d=identicon&s=25 Hassan Schroeder (Guest)
on 2009-02-19 00:30
(Received via mailing list)
On Wed, Feb 18, 2009 at 2:54 PM, Robert Walker
<rails-mailing-list@andreas-s.net> wrote:

> To add a couple of point to this: First the name attribute is deprecated
> because it turned out to be a mistake. It server the exact same purpose
> as id and it redundant.

Actually not redundant in forms -- e.g. radio button elements can
be grouped by a shared name /and/ have unique IDs -- but...

> So given that there is not three identifiers there is just one, which is
> id. The class attribute does not identify a DOM element.

No, it doesn't identify a *unique* DOM element, but ...

> Notice that all id attributes are unique on the page and are used to
> identify DOM elements. CSS class names describe the styling and are not
> used to identify the DOM elements.

..e.g., you mentioned Prototype, which provides a convenient
 getElementsByClassName() method which identifies a *set* of
DOM elements. :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
91a72b0ad3e43e3ef3a31816667ec694?d=identicon&s=25 bill walton (Guest)
on 2009-02-20 16:42
(Received via mailing list)
Hi Hassan,

On Wed, 2009-02-18 at 09:50 -0800, Hassan Schroeder wrote:
> On Wed, Feb 18, 2009 at 8:38 AM, bill walton <bwalton.im@gmail.com> wrote:
>
> > We've got three 'identifiers' to work with: id, name, and class.  CSS
> > uses id and class.  Javascript uses id and name.  So, to keep the issues
> > as separate as possible, I try to avoid using id for CSS.
>
> Huh??  JavaScript offers various ways to access elements of the
> DOM, and 'class' is certainly one of them.

I probably should have said JS libraries, specifically the Prototype /
Scriptaculous libraries, which is what I was thinking of.  I think it's
accurate to say that in those libraries, identification via id / name
predominates.

> Can you be more specific
> about what "issues" you're trying to "keep separate"?

My focus at this point is refactoring an Ajax application.  My CSS has
gotten out of hand size-wise, primarily as a result of using id to
identify elements.  As I refactor back to classes, every modification /
elimination of id in the html requires examination / testing of the JS
to make sure I haven't eliminated a needed reference. The same isn't
required when making changes to classes.

>
> And if you have *one* of an element that needs styling, why not use
> an ID to target your CSS?
>

Absolutely agree.  The OP asked about guidelines.  Just trying to
communicate what I've found helpful.  Sorry if I struck a nerve.

Best regards,
Bill
Bee69cfed999cd13e3bff73d472a39ee?d=identicon&s=25 Hassan Schroeder (Guest)
on 2009-02-20 17:15
(Received via mailing list)
On Fri, Feb 20, 2009 at 7:42 AM, bill walton <bwalton.im@gmail.com>
wrote:

> I probably should have said JS libraries, specifically the Prototype /
> Scriptaculous libraries, which is what I was thinking of.  I think it's
> accurate to say that in those libraries, identification via id / name
> predominates.

Sure, but...

>  As I refactor back to classes, every modification /
> elimination of id in the html requires examination / testing of the JS
> to make sure I haven't eliminated a needed reference. The same isn't
> required when making changes to classes.

..that's not true if you use getElementsByClassName to gather up
collections of elements to operate on --  or maybe I'm the only one :-)

> Absolutely agree.  The OP asked about guidelines.  Just trying to
> communicate what I've found helpful.  Sorry if I struck a nerve.

Nerves? What nerves? All my nerves are currently committed to
dealing with the JRuby on OC4J installation I'm inheriting :-)

No, just wanted to make the point that class names in HTML can be
equally useful for identifying JS objects -- obviously a YMMV area!

H*
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2009-02-20 17:19
(Received via mailing list)
> We've got three 'identifiers' to work with: id, name, and class.  CSS
> uses id and class.

CSS also uses element's name itself and can use variuos combinations,
descendants etc.

> Javascript uses id and name.  So, to keep the issues
> as separate as possible, I try to avoid using id for CSS.

Popular JavaScript libraries let you use CSS selectors, so whatever
you use in CSS to target elements works in JS too (and even more,
because sometimes library can provide more methods than browser
has implemented for CSS).


> The problem
> I've run into is that it's difficult to decide what 'class' a thing
> belongs to until you've got lots of other things to compare it to.  So
> what I'm ending up doing in actual practice is to initially use id to
> style elements as the UI emerges, then refactor to classes as the site
> comes together.  It's turning out to be a non-trivial exercise.

That sounds strange. Maybe you just lack some practice?
Two things to remember: IDs must be unique on the page, and
you do not necessarily need classes (or id's for that matter) at all,
there are other means to target elements.
Lets say you want to target LI elements in some UL. You don't
have to provide them all with classes or ids: just give some id to
UL and then you can specify your LIs using "#myulid li"
Likewise, to target paragraphs which got just after header you don't
need to use id or class: "h2 + p" will work just fine.
It is definitely worth spending some time with
http://docs.jquery.com/Selectors
- good grasp on these will help to simplify your code.

Regards,
Rimantas
--
http://rimantas.com/
91a72b0ad3e43e3ef3a31816667ec694?d=identicon&s=25 bill walton (Guest)
on 2009-02-20 19:56
(Received via mailing list)
Hi,

On Fri, 2009-02-20 at 18:18 +0200, Rimantas Liubertas wrote:

> > The problem
> > I've run into is that it's difficult to decide what 'class' a thing
> > belongs to until you've got lots of other things to compare it to.  So
> > what I'm ending up doing in actual practice is to initially use id to
> > style elements as the UI emerges, then refactor to classes as the site
> > comes together.  It's turning out to be a non-trivial exercise.
>
> Maybe you just lack some practice?

Without question.

I responded, with what I'd point out was not positioned as a
recommendation, because I share the OP's experience having difficulty
finding clear, easy-to-follow guidelines WRT 'best practices' that lead
naturally to an easily maintained / modified, coherent set of CSS files,
Javascript files, and HTML produced by Rails code.  Links are always
appreciated.

Best regards,
Bill
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2009-02-21 07:20
Hassan Schroeder wrote:
>> To add a couple of point to this: First the name attribute is deprecated
>> because it turned out to be a mistake. It server the exact same purpose
>> as id and it redundant.
>
> Actually not redundant in forms -- e.g. radio button elements can
> be grouped by a shared name /and/ have unique IDs -- but...

From the W3C Specifications for XHTML
----------
4.10. The elements with 'id' and 'name' attributes

HTML 4 defined the name attribute for the elements a, applet, form,
frame, iframe, img, and map. HTML 4 also introduced the id attribute.
Both of these attributes are designed to be used as fragment
identifiers.

In XML, fragment identifiers are of type ID, and there can only be a
single attribute of type ID per element. Therefore, in XHTML 1.0 the id
attribute is defined to be of type ID. In order to ensure that XHTML 1.0
documents are well-structured XML documents, XHTML 1.0 documents MUST
use the id attribute when defining fragment identifiers on the elements
listed above. See the HTML Compatibility Guidelines for information on
ensuring such anchors are backward compatible when serving XHTML
documents as media type text/html.

Note that in XHTML 1.0, the name attribute of these elements is formally
deprecated, and will be removed in a subsequent version of XHTML.
----------------------------

Yes, the "name" attribute IS deprecated and is scheduled for removal
sometime in the future.

>> So given that there is not three identifiers there is just one, which is
>> id. The class attribute does not identify a DOM element.
>
> No, it doesn't identify a *unique* DOM element, but ...

Identifying something *unique* is my definition of an object/element
identity.

>> Notice that all id attributes are unique on the page and are used to
>> identify DOM elements. CSS class names describe the styling and are not
>> used to identify the DOM elements.
>
> ..e.g., you mentioned Prototype, which provides a convenient
>  getElementsByClassName() method which identifies a *set* of
> DOM elements. :-)

or $$('css_selector') works nicely for that in Prototype or just
$('css_selector') in jQuery.
Bee69cfed999cd13e3bff73d472a39ee?d=identicon&s=25 Hassan Schroeder (Guest)
on 2009-02-21 16:56
(Received via mailing list)
On Fri, Feb 20, 2009 at 10:20 PM, Robert Walker
<rails-mailing-list@andreas-s.net> wrote:

>> Actually not redundant in forms -- e.g. radio button elements can
>> be grouped by a shared name /and/ have unique IDs -- but...
>
> From the W3C Specifications for XHTML
> ----------
> 4.10. The elements with 'id' and 'name' attributes
>
> HTML 4 defined the name attribute for the elements a, applet, form,
> frame, iframe, img, and map.

> Note that in XHTML 1.0, the name attribute of these elements is formally
> deprecated, and will be removed in a subsequent version of XHTML.
> ----------------------------
>
> Yes, the "name" attribute IS deprecated

But *only* for the above listed elements, NOT for e.g. form elements
like INPUT.

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
6e96154e5c4f7b759d1c1c064ba4da42?d=identicon&s=25 Eric L. (Guest)
on 2009-02-22 00:17
(Received via mailing list)
I had the same question when I was starting out with CSS.  A lot of is
simply trial and error, and you figure out what is best.  Buy a good
book on CSS (I read Bullet Proof CSS design), and that will give you
some guidance as to what's the best class/id naming style.  In general
I follow these rules:

1. Use ID for unique element.
2. Use class for shared elements.
3. Scope CSS selector properly, so it's as specific as possible.  It's
a terrible thing to work on a code base where the previous developer
specified style on something generic like ".first", then everything in
the site that is of class "first" would be impacted by this style.
This topic is locked and can not be replied to.