guides on css strategy
itsastickup
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.
Craig Demyanovich
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
itsastickup
On 18 Feb, 05:37, Craig Demyanovich <cdemyanov...@gmail.com> wrote:
> 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
>
>
>
>
>
>
> > 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
>
> - Show quoted text -
pabcas
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
bill walton
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
Hassan Schroeder
> 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.s...@gmail.com
Robert Walker
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.
--
Posted via http://www.ruby-forum.com/.
Hassan Schroeder
<rails-mai...@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. :-)
bill walton
On Wed, 2009-02-18 at 09:50 -0800, Hassan Schroeder wrote:
> On Wed, Feb 18, 2009 at 8:38 AM, bill walton <bwalt...@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
Hassan Schroeder
> 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*
Rimantas Liubertas
> 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/
bill walton
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
Robert Walker
>> 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.
Hassan Schroeder
<rails-mai...@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.
Eric L.
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.