Anders är en webbutvecklare och hårdrockare som gillar brädspel, kaffe och öl.

Detta är ett arkiverat inlägg, som importerats hit för referens. Det kan se konstigt ut och innehålla utdaterad information eller inaktuella åsikter.

Namnkonventioner

När jag skrev min blogg om organisation av CSS-filer trodde jag stenhårt på min dåvarande namnkonvention. Jag repeterar den kort:

  • ID skall skrivas i camelCase med inledande gemen
  • Klasser skall skrivas i CamelCase med inledande versal

Mycket lätta regler, kan tyckas. De är inspirerade av konventionerna i programspråket Java. Men de har enorma brister. Jag skall hålla det kort och berätta var bristerna går.

Jag har senaste månaderna varit mycket ivrig att döpa mina klasser till långa, beskrivande namn. Ett blockelement som innehåller andra flytande blockelement och använder sig av Asletts clearmetod har gått under namnet FloatingComponentsWrapper. Klasser som konverterar onumrerade listor till navigering, eller rättare sagt menyer, har gått under namnet VerticalMenu och HorizontalMenu.

Långa namn. Extremt långa, och ytterst lätta att felstava.

ID-attributets egentliga syfte

I takt med att jag ville göra något åt min divitis och spanmani upptäckte jag även, mest på slump, vad id-attributet egentligen skall användas till. Jag har använt attributet, precis som många andra noviser, till att ge element som h2#categoryListHeader och ul#categoryListItems önskade beteenden. Detta är felaktigt: ID-attributet skall ur semantisk synpunkt användas för tillgänglighet och användbarhet. En ankareffekt uppnås genom att döpa sektioner av en sida och sedan lägga till länkar till dessa i början av ett långt HTML-dokument.

Och vem sjutton vill komma åt en rubrik eller en oordnad lista, vars namn ändå är omöjliga att komma ihåg då de är så förskräckligt döpta?

Simpla, enkla namn

Lösningen är glasklart enkel. Ett enkelt scenario: En användare läser ett blogginlägg på en offentlig dator, och bestämmer sig för att invänta kommentarer och återvända senare under dagen för att debattera. Då han inte har sparat blogginlägget i sina bokmärken, vad är enklast för honom att minnas utav http://madr.se/blog/23#comments och http://madr.se/blog/23#blogCommentsWrapper ?

Jag föreställer mig att merparten skulle välja det första utav alternativen. Det är kort, enkelt att komma ihåg och tämligen beskrivande. Det andra alternativet, som jag skulle ha använt med min tidigare namnkonvention, är förvisso snyggt ur en programmerares synpunkt, men det hör inte hemma på webben.

ID-attribut skall agera som ankare. Alla element skall inte ha sådana, utan enbart sektioner som skall vara lättillgängliga för användare. Och för att uppnå hög tillgänglighet måste deras namn vara klokt valda.

Vad gäller ID-attributet har jag följande frågeställning tills vidare:

  1. Är namnet logiskt och självklart?
  2. Går det att göra ännu mer logiskt och självklart?
  3. Kan jag förkorta det?

CamelCase is no more!

CamelCase-eran är över i presentationssammanhang. Från och med nu skall allt skrivas i gemener, och aldrig eller ytterst sällan bestå av mer än 2-3 stavelser. Detta gäller mina ID-attribut såväl som mina klassnamn. Klassnamnen som VerticalMenu kan också ha namnet vnav. Inte lika tydligt för mig som programmerare, men likväl beskriver det klassen lika bra. Det är mer än omställning av vanor än något annat.

Framförallt skall jag sluta vara så kåt på att namnge allt och ha så mycket beteenden i klasser. Mycket kan göras med primitiva selektorer lika bra.

Och mer än någonsin tidigare har implementeringen av HTML störst betydelse. Ett korrekt utformad HTML-dokument, som använder styrkan i alla element, är det enklaste och mest underbara som finns när det är dags att skapa stilmallarna. Det har jag lärt mig på den hårda vägen.