Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

Variabler + CSS = Sant?

1 2
Skriv svar
Permalänk
Medlem
●

Jag tror ni närmar er botten på det semantiska havet. Åh titta en björnhäst! *blubb*

Visa signatur

i7 920 | 12GB DDR3 | GTX 480 | GA-X58A-UD7 | 160GB SSD X25-M G2 | 1TB F3 HD103SJ | W7 64-bit | Mac Mini
Webb: bluekitestudios.com

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av azoapes
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. ?

Vet inte riktigt, det går inte att svara på med så lite information tycker jag. Du säger att "ska se ut som en björnhäst", skulle björnhäst t.ex. vara starkt förknippad med någon färg (t.ex. om det skulle vara färgen beige säger du ju bara indirekt (typ) thisOneHasBeigeText) eller liknande? Om det är något sådant du menar tycker jag att det blir tillbaka till samma sak som tidigare nämnts många gånger, att klasserna inte ska beskriva utseendet (bl.a. p.g.a. det jag skrev i föregående inlägg).

Det är förstås den trevligaste lösningen, men det kan säkert finnas exempel där det behövs skräpmärkkod och/eller skräpklasser eftersom att det inte finns någon uppenbar lösning som undviker det. Detta fall när något omotiverat ska t.ex. byta färg kan vara något sådant (d.v.s. ändringen är endast dekorativ, eller i andra ord: saknar mening). Om det skulle finnas ett bättre svar på "varför?" så kanske det skulle vara möjligt att hitta på ett bättre namn.

Citat:

Ursprungligen inskrivet av azoapes
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.

Fast när du måste ändra namnet så blir det inget "slår igenom på alla tilldelningar". Därför tycker jag, fortfarande, att det är samma sak.

Senast redigerat
Visa signatur

Ännu en webbplats utan innehåll, fast den är ju ganska snygg att kolla på iallafall.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av cic
Vet inte riktigt, det går inte att svara på med så lite information tycker jag. Du säger att "ska se ut som en björnhäst", skulle björnhäst t.ex. vara starkt förknippad med någon färg (t.ex. om det skulle vara färgen beige säger du ju bara indirekt (typ) thisOneHasBeigeText) eller liknande? Om det är något sådant du menar tycker jag att det blir tillbaka till samma sak som tidigare nämnts många gånger, att klasserna inte ska beskriva utseendet (bl.a. p.g.a. det jag skrev i föregående inlägg).

Fast när du måste ändra namnet så blir det inget "slår igenom på alla tilldelningar". Därför tycker jag, fortfarande, att det är samma sak.

Nu tog jag bort din mellersta paragraf där, och den svarar väl egentligen på min fråga. Men jag vidareutvecklar lite ändå

Säg att en felmeddelandebox ska se ut som en björnhäst, men att en björnhäst är svår att få till med CSS. Klassen .bearhorse har 10 egenskaper som försöker få elementet att se ut som en björnhäst, men det "gnäggar" inte riktigt... det tar ett tag att få till utseendet. Men det är fortfarande en björnhäst. Så jag döper klassen till björnhäst redan från början, det enda syfte klassen har är att få något att se ut som en björnhäst, trots att det inte har något syfte annat än visuellt på webbsidan.

Då är du kanske mer med på vad jag menar; att döpa klassen till vad den försöker åstadkomma (att se ut på ett visst sätt) är det bästa i många lägen, istället för att döpa klassen till vad elementet är. För det är inget, eller allt, eller något däremellan. Någon som tittar på koden kommer bara undra vad klassen style832 gör, men om jag döper den till "bearhorse" kommer de genast att förstå att klassen försöker efterlikna en björnhäst. Jag behöver bara byta namn på den om jag ska försöka efterapa en nosbjörning istället, men då gör jag hellre en Search & Replace än att använda en klass som är döpt style832.

Visa signatur

På SoundCloud | Fästmöns galleri

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Citat:

Ursprungligen inskrivet av azoapes
Nu tog jag bort din mellersta paragraf där, och den svarar väl egentligen på min fråga. Men jag vidareutvecklar lite ändå

Säg att en felmeddelandebox ska se ut som en björnhäst, men att en björnhäst är svår att få till med CSS. Klassen .bearhorse har 10 egenskaper som försöker få elementet att se ut som en björnhäst, men det "gnäggar" inte riktigt... det tar ett tag att få till utseendet. Men det är fortfarande en björnhäst. Så jag döper klassen till björnhäst redan från början, det enda syfte klassen har är att få något att se ut som en björnhäst, trots att det inte har något syfte annat än visuellt på webbsidan.

Då är du kanske mer med på vad jag menar; att döpa klassen till vad den försöker åstadkomma (att se ut på ett visst sätt) är det bästa i många lägen, istället för att döpa klassen till vad elementet är. För det är inget, eller allt, eller något däremellan. Någon som tittar på koden kommer bara undra vad klassen style832 gör, men om jag döper den till "bearhorse" kommer de genast att förstå att klassen försöker efterlikna en björnhäst. Jag behöver bara byta namn på den om jag ska försöka efterapa en nosbjörning istället, men då gör jag hellre en Search & Replace än att använda en klass som är döpt style832.

Det som argumenteras är att man genom class="björnhäst" bestämmer att elementet ÄR en björnhäst, precis som att <h1> ÄR en rubrik -- detta står förvisso redan klart. Konflikten uppstår när en rent konkret klass sätts på ett konkret element, <h1 class="björnhäst"> -- är det en rubrik eller en björnhäst vi har fått?

Lustigt som det må vara förvirrar björnhästen mig, det är mycket enklare med ditt förra exempel med beigeText. Om vi har en <h1 class="beigeText"> så har vi helt tydligt bestämt att h1 är en rubrik OCH en beige text. Men är inte själva meningen med CSS att separera visuell presentation från logisk struktur? Vi kan jämföra med <em> och <i> som i princip alltid är likadant stylade i standardutförandet men rent semantiskt är helt olika då <i> säger att texten är kursiv medan <em> säger att texten är betonad. Ur denna synvinkel är <font color="beige"> inte mycket värre än class="beigeText" då bägge uttryckligen beskriver innehållet som beige. Vill man ändra färg till turkos står valet mellan att ha en beigeText som är grönblå eller att ändra i HTML-koden.

Visa signatur

Kom-pa-TI-bilitet

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av azoapes
Säg att en felmeddelandebox ska se ut som en björnhäst, men att en björnhäst är svår att få till med CSS. Klassen .bearhorse har 10 egenskaper som försöker få elementet att se ut som en björnhäst, men det "gnäggar" inte riktigt... det tar ett tag att få till utseendet. Men det är fortfarande en björnhäst. Så jag döper klassen till björnhäst redan från början, det enda syfte klassen har är att få något att se ut som en björnhäst, trots att det inte har något syfte annat än visuellt på webbsidan.

Det kan ju även bero på att det från början inte är någon vidare bra idé att bara byta t.ex. färg på en felmeddelandebox men har kvar alla andra i en annan färg. Det borde förvirra även användarna. Det finns säkerligen något bättre exempel på när något dekorativt ska skapas med enbart CSS och det smittar av sig i HTML-koden, men jag har just nu för lite tid och fantasi för att komma på något sådant.

Citat:

Ursprungligen inskrivet av azoapes
Då är du kanske mer med på vad jag menar; att döpa klassen till vad den försöker åstadkomma (att se ut på ett visst sätt) är det bästa i många lägen, istället för att döpa klassen till vad elementet är. För det är inget, eller allt, eller något däremellan.

Nej, det tycker jag inte, och hoppas inte det lät som att jag tyckte det heller. Det är det som får göras om ingen bättre lösning hittas är fortfarande det jag tycker.

Citat:

Ursprungligen inskrivet av azoapes
Någon som tittar på koden kommer bara undra vad klassen style832 gör, men om jag döper den till "bearhorse" kommer de genast att förstå att klassen försöker efterlikna en björnhäst. Jag behöver bara byta namn på den om jag ska försöka efterapa en nosbjörning istället, men då gör jag hellre en Search & Replace än att använda en klass som är döpt style832.

Vilken kod är det som inspekteras? HTML:en eller CSS:en? Om det är HTML:en är det väll det som händer när struktur och utseende separeras? D.v.s. att det blir svårt att säga något om utseendet bara genom att kolla på delen som ska beskriva strukturen? Om det är CSS:en så borde det inte vara några större problem genom att läsa innehållet i blocket förstå vad den sätter för egenskaper. T.ex. borde det inte vara svårare att se vad error gör än red:

.error {color:red}
.red {color:red}

Men error ger ytterligare information medan red endast upprepar vad som sagts i blocket. (Nu är inte style832 något bra namn och ingen har förslagit wysiwyg-namn heller såvitt jag kommer ihåg, det är mer utseende vs. struktur igen.)

Visa signatur

Ännu en webbplats utan innehåll, fast den är ju ganska snygg att kolla på iallafall.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av Teknocide
Lustigt som det må vara förvirrar björnhästen mig, det är mycket enklare med ditt förra exempel med beigeText.

Jo det exemplet håller jag med om att man kanske bör undvika. Så jag försökte hitta något bättre exempel istället, där det inte handlade om [en klass = en visuell ändring], utan snarare [en klass = en uppsättning ändringar mot ett visuellt mål].

Visa signatur

På SoundCloud | Fästmöns galleri

Redigera
Citera flera Citera
1 2
Skriv svar