[semantics] Standaard css classes and id's: wat gebruik jij?

[Verwijderd]

Ik zie de laatste maanden steeds meer standaardisatie in class en id naamgeving voor vaak terugkerende elementen in een web site.
Je kent het wel, je bouwt van scratch een simpel xhtml templatje met een stel div's. Een alles omvattende container, of wrapper, een menu, een header, een footer en een content veld.
Ik vraag me alleen af in hoe verre we nu allemaal niet de zelfde classes en id's gebruiken.
Kort gezegd, standaard semantische naamgeving voor het noemen van standaard terugkerende elementen.
Hoe doen jullie dit, gebruik je vaak de zelfde classes of id's en en hoe noem je ze voor welk gebruik ?
Stem je de naamgeving af op dingen die je eerder hebt verzonnen, of ergens anders bent tegen gekomen, etc etc.

Even voor de duidelijkheid, het gaat me alleen om top-level classes. dus de gene die altijd wel in een site voorkomen, zoals gezegd, header, container etc.

Ik probeer dus een discussie op gang te krijgen over standaard naamgeving binnen css, met semantiek als doel.

Microformats zijn zo'n mooi voorbeeld

[Rowanov]

Ik denk dat het geheel persoonlijk is wat je gebruikt, maar bij een id of class gaat het er wel om dat het een omschrijving is van wat het moet voorstellen, vooral op een div. Dat alles header, footer, content etc heet, heeft meer met de logische layout van een pagina te maken. Daarnaast is het voor jezelf en mogelijke collega's natuurlijk handig om te zien welk onderdeel wat moet voorstellen.

[André]

Eigenlijk doe ik het heel simpel: uit een naam moet ik kunnen afleiden wat voor element het is, dus bijvoorbeeld:

.header
.contentLink
.menuTitel

en niet:

.groeneBalk
.onderstreepteLink
.groteTitel

[Sappie]

Ik ben het eens met Andre en Rowanov.. er is dus mi niet zoiets als standaard naamgeving voor deze attributen. Hier nog een link naar wat het w3c erover te zeggen heeft:

http://www.w3.org/QA/Tips/goodclassnames

[Mithrandir]

Google heeft hier een aantal maanden geleden ook een onderzoek naar gedaan, maar ik kan het helaas niet meer vinden... Ik ga nog even op zoek.

[Verwijderd]

Ik ben het ook wel met andre eens, hoewel iedereen voor vaak dezelfde doeleinde net een andere id of classname gebruikt. De voordelen die de semantiek uiteindelijk met zich mee zou kunnen brengen is wel interresant, zoals ook wel duidelijk word met de microformats.

[chem]

http://code.google.com/webstats/2005-12/classes.html bedoel je?

[Verwijderd]

Mithrandir schreef op maandag 13 maart 2006 @ 11:29:
Google heeft hier een aantal maanden geleden ook een onderzoek naar gedaan, maar ik kan het helaas niet meer vinden... Ik ga nog even op zoek.

Mooie suggestie, got-it: http://code.google.com/webstats/2005-12/classes.html

Ik was net iets te laat

Toevoeging:
What's in the name en What's in the name p2 beide door Malarkey

[ Voor 29% gewijzigd door Verwijderd op 13-03-2006 11:35 ]

[André]

Mithrandir schreef op maandag 13 maart 2006 @ 11:29:
Google heeft hier een aantal maanden geleden ook een onderzoek naar gedaan, maar ik kan het helaas niet meer vinden... Ik ga nog even op zoek.

http://code.google.com/webstats/index.html

/edit: stelletje strevers

[ Voor 6% gewijzigd door André op 13-03-2006 11:33 ]

[Verwijderd]

een paar die ik eens poneerde: http://www.rikkertkoppes.com/thoughts/reinventing-the-wheel

verder zoveel mogelijk informatief gebruiken en niet je site er afhankelijk van maken (that is: zo min mogelijk classes en id's in je css stoppen)

[Verwijderd]

Verwijderd schreef op maandag 13 maart 2006 @ 11:32:
een paar die ik eens poneerde: http://www.rikkertkoppes.com/thoughts/reinventing-the-wheel

verder zoveel mogelijk informatief gebruiken en niet je site er afhankelijk van maken (that is: zo min mogelijk classes en id's in je css stoppen)

Wat bedoel je precies met "zo min mogelijk classes en id's in je css stoppen", in welke context bedoel je dit ?

[Verwijderd]

in de context van exchangability, zoveel mogelijk selecteren op element namen en gedefinieerde attributen (als dat zou werken in IE), dus je css zo unambigious (hoe heet dat in het nederlands) mogelijk maken

[Verwijderd]

Mee eens. Ik ben zeker een voorstander voor het op name attribuut selecteren, omdat dit eigelijk veel lochischer is. Helaas werkt dit dus nog niet (weet ook eerlijk gezegd niet in hoeverre ie7 hier verbetering in brengt), IE zuigt

Nu rijst bij mij de vraag, does all of this realy matter ??

Ik denk van wel, om de volgende redenen:
- Standaarden zijn goed, ze maken leven makkelijker.
- Als we allemaal de zelfde naamgevingen zouden gebruiken zou dit een redesign makkelijker maken
- Gebruikers kunnen makkelijker een "user stylesheet" maken
- Jij en je collega's werken allemaal hezelfde, uniformiteit

Meer voor en of nadelen ??

[Verwijderd]

Half off-topic:
Het valt me op dat in de classes de msoNormal class (een door ms office gegenereerde class met exporteren als webpagina) nog veel voorkomt, terwijl de font tag juist helemaal niet in de lijst met tags staat.
Uiteraard is de font tagop zijn retour, maar is helaar nog wel een veelgebruikte tag. Dacht ik zo ..

[addictive]

Verwijderd schreef op maandag 13 maart 2006 @ 12:15:
Mee eens. Ik ben zeker een voorstander voor het op name attribuut selecteren, omdat dit eigelijk veel lochischer is. Helaas werkt dit dus nog niet (weet ook eerlijk gezegd niet in hoeverre ie7 hier verbetering in brengt), IE zuigt

Nu rijst bij mij de vraag, does all of this realy matter ??

Ik denk van wel, om de volgende redenen:
- Standaarden zijn goed, ze maken leven makkelijker.
- Als we allemaal de zelfde naamgevingen zouden gebruiken zou dit een redesign makkelijker maken
- Gebruikers kunnen makkelijker een "user stylesheet" maken
- Jij en je collega's werken allemaal hezelfde, uniformiteit

Meer voor en of nadelen ??

ja, je geeft zelf het antwoord al. Een universele, makkelijk te lezen opmaak lijkt mij ideaal
Veel minder problemen om andermans code te ontcijferen; dus minder werk; dus minder kosten

[Superdeboer]

Verwijderd schreef op maandag 13 maart 2006 @ 12:15:
Mee eens. Ik ben zeker een voorstander voor het op name attribuut selecteren, omdat dit eigelijk veel lochischer is. Helaas werkt dit dus nog niet (weet ook eerlijk gezegd niet in hoeverre ie7 hier verbetering in brengt), IE zuigt

offtopic:
IE7 krijgt CSS 2.1 Selector support (child, adjacent, attribute, first-child etc.). Dat is al een grote stap vooruit natuurlijk, hoewel veel mensen zullen het wel betreuren dat niet ook support wordt opgenomen voor een aantal extra selectors uit de lijst van CSS3-selectors.

[Verwijderd]

Verwijderd schreef op maandag 13 maart 2006 @ 12:15:
Mee eens. Ik ben zeker een voorstander voor het op name attribuut selecteren, omdat dit eigelijk veel lochischer is. Helaas werkt dit dus nog niet (weet ook eerlijk gezegd niet in hoeverre ie7 hier verbetering in brengt), IE zuigt

dat zeg ik niet, op name attribuut selecteren werkt idd niet, maar waarom zou je dat in godsnaam willen? het is net zo ambigious als id of class (aangezien je zelf wat mag bedenken). Ik had het over element namen, zoals p, dl, table etc.

[Verwijderd]

In grote lijnen komt mijn manier van werken wel neer op wat eerder al genoemd is. Wat mophor al zei over zo min mogelijk id's vind ik idd wel prettig werken. Dus:

Cascading Stylesheet:

#newsBlock a
{
  background: some-sort-of-cool-bullet
}

in plaats van:

Cascading Stylesheet:

a.newLink
{
  background: some-sort-of-cool-bullet
}

Daarnaast geef ik heel consequent al mijn form elementen iig de classname gelijk aan het type attribuut, en wellicht nog extra classnames. Soms misschien overbodig maar je kunt elk soort input-element tenminste afzonderlijk pakken en over meerdere projecten heen werkt zo'n consequente aanpak wel erg prettig m.i.

Verder heb ik grofweg de neiging om alle structurele opbouw een id te geven als 'contentOuterBox', 'footerBox' enz. Maar als ik voor eoa achtergrondeffect een geneste div daarbinnen nodig heb noem ik doe ook gerust 'footerBox2' of 'contentInnerBox'. Semantisch zeker betwistbaar maar daarin kun je ook doorslaan vind ik. Praktisch & robuust is ook wat waard.

[Blaise]

Ik vind nederlandse namen voor classes leuk, zoals "wikkel" voor een container

[Angeloonie]

Mijn pagina's bestaan tegenwoordig bijna allemaal uit deze divjes:

#container

>#pageHeader

>#contentdiv
>>#content

>#footer

>#menuright (of left)
>>#menudivs
>>>#navigation

En altijd in die volgorde. (alles staat dus in #container, en alle >> divs staan weer in bovenstaande div)

Vindt het zelf overzichtelijk, en lekker makkelijk aanpassen, hup stylesheet van een oude pagina pakken en alles aanpassen

[JHS]

Voor een heel groot deel gaat het inderdaad altijd ongeveer hetzelfde. In pseudecode:

code:

body#[site] {
  p#header
  div#container {
    ul#nav {
      li#nav_[item]
      ...
    }
    div#content {
      h1
      div#content_[item] {
        h2
        p#content_meta
        p
        ...
      }
      ...
    }
    p#footer
  }
}

Verder ben ik het gedeeltelijk met /me eens. Aan de ene kant tracht ik het zo algemeen mogelijk te houden, maar voor de specifieke uitzonderingen per element hanteer ik o.a. om conflicten te voorkomen wel altijd een selectie in de trant van body#site div#container #div#content h1 . Levert ook nog 's mooie indenting op .

[ Voor 4% gewijzigd door JHS op 13-03-2006 18:33 ]

[Verwijderd]

Verwijderd schreef op maandag 13 maart 2006 @ 11:39:
... dus je css zo unambigious (hoe heet dat in het nederlands) ...

Ondubbelzinnig.

Verder duid met classes en ids zoveel mogelijk functie aan, en zo min mogelijk vorm. Soms lopen functie en plaats op de pagina wat door elkaar (header, footer), soms niet (mainContent, sideContent). Ik probeer altijd namen te kiezen die ik na een jaar meteen weer snap