Variabler + CSS = Sant?

http://www.webmasterworld.com/forum83/5618.htm

Nej, går inte. Finns workarounds som folk påpekar i KurreKulas länk, men man tjänar knappast på det ändå.

Om inte annat kan du ju köra replace all? Brukar jag göra ifall jag ska ändra massvis i ett CSS-dokument

Nä, men om du skulle råka ha vitt till exempel, kommer du ju isf att ändra allt vitt till det du vill ändra vilket man inte kanske alltid vill. Men när man vill det kan man ju köra replace

Hoppas inte. Det är bara vettigt i utvecklingsfasen, när du väl lägger ut det kommer du ändå optimera bort det eftersom det kommer vara ett slöseri med prestanda. Sen är CSS inte riktigt uppbyggt för det heller.

Finns mycket annat som bör ha (och har) mycket högre prioritet; typ webfonts.

En skön fullösning är istället att utnyttja att man kan ha flera klasser på ett element.

CSS:

.white {
color: #fff
}

HTML:

<div class="content white">
Vit text
</div>

Nackdelen är förstås att om du utnyttjar detta till max försvinner en stor del av meningen med CSS. Det är bättre att lära sig om kaskad och arv i CSS så kanske du inte behöver skriva det på så många ställen?

.white {
color: #fff
}

<div class="content white">
Vit text
</div>

Hemskt. Du tar bort all semantik genom att göra så, det är lika bra att använda <font> och liknande i så fall.

klasser påverkar inte semantiken, inte ett dugg.

lösningen är inte elegant men det kommenterade guru meditation själv.

Jo. Klasser finns för att kunna klassificera element; en klass som heter "error" är semantiskt meningsfull, en klass som heter "red" är det inte. Use class with semantics in mind.

nej, jag kan inte hålla med.

olika klassnamn påverkar inte innehållet och således har de inte inget semantiskt värde. enkelt och tydligt uttryckt.

för utvecklare är det bättre - mycket bättre - med genomtänkta klassnamn som beskriver innehållet (comment, draggable etc) men det har ingenting med semantik att göra. och det är det länken di bifogade förtäljer. semantics i det sammanhanget är inte detsamma som semantics vad gäller taggarna bold eller strong.

Det har ju visst med semantik att göra, det är bara semantik på ett annat sätt. Element så som strong och em har en strukturell semantik som gör det enkelt för webbläsare/screenreaders/etc. att tolka materialet, medans semantiska klassnamn har en klassificeringssemantik som kan vara meningsfull för tolkar men även för utvecklaren.

Ponera att du har ett felmeddelande, som du vill ska vara rött. Du kan ju gå den enkla vägen och använda klassen red. Då har du ett problem när du vill byta ut färgen, och du tjänar inte direkt något på att använda sagda klassnamn. Det enda den säger är att där finns något rött. Använder du istället klassen error så vet du (och alla tolkar som läser din HTML) att det handlar om ett felmeddelande, om detta sedan är rött eller grönt eller kanske transparent är inte viktigt; det är fortfarande ett felmeddelande.

Tänk dig sedan att det finns något skript som vill använda din sida, och gärna se om den får ett felmeddelande. Den kommer (om den är någolunda bra skriven) att leta efter ett element med ovannämnda klass. Vad är då mest logiskt och framtidssäkert? Jo, error förstås! Bonus: om alla andra också använder semantiska klasser behöver detta skript knappt ens modifieras för att hitta felmeddelanden på andra sidor!

Klassnamn har en semantisk mening, om än inte lika stark som de semantiska HTML-elementen.

Hum, det finns ganska många exempel på när klasser används för att märka upp saker HTML 4.01 saknar stöd för t.ex. hCalendar & co. I övrigt håller jag nog med You men har inget att tillägga.

Det finns ju för övrigt (typ) CSS-"metaspråk". Som t.ex. Sass, där finns det stöd för bl.a. variabler. Har aldrig känt för att använda något sådant så vet inte om det är något att ha.

Man skulle kunna argumentera på samma sätt för själva elementen i HTML, men de är vi ju överens om att de har en semantik. Skillnaden mellan HTML-element och semantiska klassnamn är att HTML-elementen har en klart definierad semantik enligt gällande HTML-specifikation, medan klassnamn inte alltid har detta. I vissa fall, som cic påpekar, har man försökt skapa en klart definierad semantik för en grupp klassnamn, men oftast är det (som du egentligen säger) en lös, oklar semantik som kanske bara är vettig i utvecklarens ögon.

Ibland är det nästan nödvändigt att använda class="klass1 klass2" om man har väldigt många återupprepande objekt som ska fungera olika. Jag ser inget fel i att göra på det sättet, framför allt eftersom det fungerar och ger möjlighet att utveckla snabbare. Men semantiskt så är det inte det snyggaste som You påpekar.

Det är inte användningen av multipla klasser som är fel; sådant kan vara logiskt i många situationer. Det är namngivningen av en klass som är fel här. Klassnamn ska abstrahera objektet på något sätt; det är logiskt att ha ett element med klasserna låda och felmeddelande, men det är inte logiskt att elementet i fråga har klasserna röd och 5pxborder.

Jag förstår inte riktigt detta. Varför skulle det vara en ful lösning? Det är helt vanlig CSS... multipla klasser använder vi hela tiden för optimering av bandbredd och framförallt i kombination med JavaScript där interaktionen kan innebära t.ex. att en länk är markerad, har en högerklicksmeny och att dess bock är ikryssad. Jag är inte alls med på varför det multipla klasser vara dåligt.

Om man har 10 st olika sorters meddelanden - jämför koden, här med multipla klasser:

.message {
    /* Generella regler för .error */
}
.message.error {
    /* Avvikande regler för röda (fel)meddelanden */
}

/* ... */

.message.ok {
    /* Avvikande regler för gröna (OK-)meddelanden */
}

...och här nedan utan multipla klasser...

.errorMessage {
    /* Alla regler för röda (fel)meddelanden */
}

/* ... */

.okMessage {
    /* Alla regler för gröna (OK-)meddelanden */
}

Visst skulle man kunna wrappa meddelandet i ett extra element och använda inheritance istället, men varför i all världen då? Varför använda extra HTML (vilket f.ö. inte ger dig några plus i sökmotorer) istället för att utnyttja tekniken CSS erbjuder?

Men CSS handlar ju om visuella detaljer. Är inte då det mest semantiska att beskriva vad klassen innehåller för visuella detaljer, snarare än att försöka beskriva syftet eller elementet klassen sitter på?

Självklart, det är inte multipla klasser jag har problem med, det är klassnamnen jag tycker är dåliga i det exemplet.

Nej. Hela poängen med CSS är att helt separera innehåll och struktur. Klasserna är en del av strukturen. Du ska i princip kunna designa om en sida utan att ändra din HTML – det kan du inte om du har klasser som direkt beskriver hur elementen ser ut. Därför behöver man klasser som abstraherar elementen, som i ditt exempel ovan med message, error och ok.

ojsan här får man lära sig något nytt. här satt jag och trodde att w3c var ensamma om att
utfärda rekomendationer gällande html och relaterade teknologier.

ny information till trots: man kan argumentera om hcal verkligen är semantik. är det inte så att det är kombinationen och sammanhanget av klasserna som gör innehållet betydelsefullt? utan sammanhang kan exempelvis <span class="dtstart"> anges för att märka upp vad som helst.
<p> betyder alltid samma sak. <h1> likaså. det är en ohygglig skillnad anser pcman. måhända behöver det ges tid för nya kunskapen att sjunka in men fortfarande är jag av den åsikten att klassnamn inte påverkar informationen inom den omslutande taggen.

precis som du skriver: ingen spec - ingen semantik. sedan är jag fortsatt negativ till om klasser är semantiska enligt ovan. kanske är det jag behöver mer tid.

you beskriver det mycket bra men notera att syftet med klasser sträcker sig utöver grafisk presentation. de är även till för att deklarera beteende. och tydligen semantik.

Men det är ju för att semantiken hos <p> och <h1> är entydigt definierat. Jag skulle kunna skapa ett eget, XML-baserat märkspråk som också har element som heter p och h1 men där dessa element definieras som något annat; de kommer fortfarande ha en semantisk betydelse men enligt min egna standard så är det inte samma semantiska betydelse.

Det är nog det som gör det svårt att greppa semantik hos klasser; semantiken i HTML är entydigt bestämd, men det finns ingen entydigt bestämd semantik hos klasser – den beror på sammanhang, syfte och betraktare.

Skön fackla man spottade ur sig.

*tar fram popcornen*

Det låter konstigt i mina öron Klasser har ett enda syfte som jag känner till, och det är att agera selektorhjälp åt CSS, JavaScript och andra klienttekniker. Naturligtvis kan man döpa sina CSS-klasser bra eller dåligt, logiskt eller inte, klassnamn som har ett tydligt syfte eller inte, men det verkar inte vara det diskussionen handlar om?

Låt oss ta ett exempel. Du har byggt två exakt likadana moduler med en enda skillnad; textfärgen skiljer sig. Bara för variationens skull, det finns ingen egentlig poäng med skillnaden. Men du måste skilja dem åt. Hur göra? Man skulle kunna döpa den andra till "alternative", men hur förvirrande är inte det jämfört med "thisOneHasBeigeText" ?

Nej, det är nog inte riktigt det diskussionen handlar om. I korta drag handlar nog diskussionen om att jag försöker övertala pcman att klasser faktisk fyller ett större syfte än att bara agera selektorhjälp, vilket många webbutvecklare verkar glömma. Visst, det vi oftast använder klasser till är selektorhjälp, men om man namnger sina klasser på ett vettigt (semantiskt) sätt så kan det öppna upp för mycket mer, se t.ex. hCard, hCal, och alla andra klassbaserade mikroformat. Framför allt så vill jag nog få fram poängen att bara för att klasser inte råkar vara en del av ett mikroformat betyder inte det att man kan slänga ut semantiken genom fönstret; error har som sagt en betydligt djupare innebörd än t.ex. red box.

Det kan låta godtyckligt med alternative (eller typ variant, alt eller liknande), men det är fullt giltigt i det fallet IMO. Fördelen är ju som sagt att man separerar struktur och stil till en mycket högre grad.

thisOneHasBeigeText är sämre eftersom att när du senare vill byta ut färgen bör du även byta namn på klassen (annars, ja, då kan vi börja prata om förvirrande). Iochmed att du nu bytt namn på klassen måste du byta ut den på alla ställen den används, och det är jobbigt. Det blir inte bättre än att använda inline styles eller font imho. Eller vad skulle det vara för skillnad på <font color="beige">Hello World</font>, <span style="color:beige">Hello World</span> och <span class="thisOneHasBeigeText">Hello World</span>?

Visst förstår jag det, men exemplet belyste inte riktigt det problemet. Säg att det man egentligen försöker åstadkomma är att varianten ska se ut som en björnhäst, är det då inte mer logiskt och tydligt att döpa klassen till bearhorse än att ge den ett hokus-pokus-namn såsom "alt1" etc. ?

Font-tag och inline ger lokala tilldelningar, medan ändringar i egenskaperna för ett klassnamn slår igenom på alla tilldelningar. Tycker det är ologiskt att blanda in <font> mitt i alltihop, vi diskuterar ju klassnamnen.