webForumDet fria alternativet

bilddimensioner i css

9 svar · 477 visningar · startad av Tinwëlint

TinwëlintMedlem sedan maj 2004451 inlägg
#1

Är det bra eller dåligt att ange bilders width och height i css?

Om man till exempel har en sida med en massa bilder som är lika stora så kna det ju tyckas vara smidigt.

Poängen med att ange width och height för bilder är väl att det ska gå snabbare att ladda sidan genom att det skapas en "platshållare" innan bilden har laddats så att sidan slipper ritas om när den är laddad. Motverkar man det syftet om man placerar bilderna i en extern css-fil tro?

Jesper TMedlem sedan nov. 20017 144 inlägg
#2

Bildmåtten kan man väl med fördel lägga i CSS men bilderna skall du väl inte lägga där. Om de inte är bakgrunder villsäga... :)

TinwëlintMedlem sedan maj 2004451 inlägg
#3

Nej det förstår jag ;)

Såg på tal om det någon som påstod att <img>-taggen skulle tas bort och att alla bilder borde skötas med css eftersom de inte är innhåll utan utseende vilket ju är helt fel eftersom en bild mycket väl kan vara innehåll. Men jag brukar satsa på att till bilder som är innehåll använda <img> och till bilder som är utseende använda background.

SugarDaddyMedlem sedan apr. 20021 155 inlägg
#4

<Lite OT>
Jarvklo länkar på sin sida(http://xhtml.nu/) till http://www.sitepoint.com/article/1339 vilken är intressant och åskådliggör en hel del saker.
Personligen tycker jag nog inte att H1 används "semantiskt korrekt" i exemplet då jag tycker att H1 hör till rubriksättning/värdering av innehåll, inte till sidhuvudet, även om jag finner en viss charm i den icke-stylade sidan.
- Hm, *host, harkel* någon här och nu som fattar vad jag pratar om? :OO

jarvkloMedlem sedan juli 20013 378 inlägg
#5

Tinwëlint skrev:

Såg på tal om det någon som påstod att <img>-taggen skulle tas bort...

Det stämmer att det är på förslag att <img> skall tas bort - men det där med att den skulle ersättas av CSS stämmer inte...
Det det pratas om är alltså att <img> antagligen kommer att ersättas av <object> i xhtml 2.0.
Men xhtml 2.0 är mest troligt låååååååååååångt bort i tiden eftersom man ännu inte kunnat enas om vad som skall (eller inte skall ;)) ingå i den standarden såpass att det ens finns mer än några "working draft"-dokument (utkast) på w3c...

Däremot *kan* man redan nu lägga in bilder med hjälp av bara en <div> och lite CSS (height:, width: och background-image:url() )om man vill - men det är en annan historia ;)

jarvkloMedlem sedan juli 20013 378 inlägg
#6

Tinwëlint skrev:

Är det bra eller dåligt att ange bilders width och height i css?

Hmm...

Å ena sidan:
Varför skulle man egentligen vilja lägga bildens dimensioner någon annanstans än i <img>-taggen ?

Definitionen av <img /> innehåller ju både width och height även i både xhtml 1.0 Strict och xhtml1.1
(deklarationen nedan är från xhtml 1.0 Strict):

<!ELEMENT img EMPTY>
<!ATTLIST img
  %attrs;
  src         %URI;          #REQUIRED
  alt         %Text;         #REQUIRED
  longdesc    %URI;          #IMPLIED
[b]  height      %Length;       #IMPLIED
  width       %Length;       #IMPLIED[/b]
  usemap      %URI;          #IMPLIED
  ismap       (ismap)        #IMPLIED
  >

Väljer man att köra utan width och height som attribut, så är ju förresten följande <img/>-taggar helt ekvivalenta (utan att man behöver flytta ut dimensionerna i en extern fil):

<img src="bild.jpg" alt="En grön pryttel" width="200" height="80" />
<img src="bild.jpg" alt="En grön pryttel" style="width:200px;height:80px;" />

Det är tillochmed så att det i just jämförelsen mellan dessa två alternativ antagligen är "bättre" med det första alternativet eftersom attributet style på sikt antagligen kommer att utgå ur xhtml (det är "deprecated" i xhtml 1.1) + att koden för bilden blir några (få ;)) tecken kortare att skriva ;)

Dessutom kan man ju inte lägga bildens URL någonannanstans än i src-attributet, så varför inte grotta in dimensionerna i <img /> direkt på samma gång som man petar dit URL:en och alt-taggens värde? ;)

Å andra sidan
Om man bygger t.ex. ett bildgalleri som använder "tumnaglar" med en viss fixerad storlek, så spar man nog iallafall lite bandbredd på att lägga denna gemensamma bredd och höjd i ett externt CSS-dokument ;)

Bra eller dåligt i detta fall - Finns det ?

Beror väl hur man än ser på det, hur man jobbar med sin kod och på hur den skall underhållas framöver.

Har man bara en CSS-fil är det väl troligen minimal risk att man inte hittar bildens dimensioner om man skall byta bild längre fram, men har man ett tjog olika layout- och färg-"skins" lagda i ett gäng olika alternativa CSS-filer så kanske det kan bli "råddigt" att hitta igen alla ställen man har lagt deklarationer för en bild när man skall ändra den...

:bire

TinwëlintMedlem sedan maj 2004451 inlägg
#7

Min tanke var givetvis inte inline-css utan en fin extern stilmall där det redan finns flera egenskaper för just de här bilderna som är thumbnails i ett galleri. Fördelen kodmässigt känns då uppenbar. Jag funderade på om det kunde finnas några gömda fällor med det. Om till exempel css-filen skulle försvinna. men det är väl inte direkt farligt om en <img> inte har height och width angivna så då ska jag nog ta och sätta det i min stilmall då.

TinwëlintMedlem sedan maj 2004451 inlägg
#8

Personligen tycker jag nog inte att H1 används "semantiskt korrekt" i exemplet då jag tycker att H1 hör till rubriksättning/värdering av innehåll, inte till sidhuvudet, även om jag finner en viss charm i den icke-stylade sidan.

Ja, det kan ju diskuteras. Om man har samma sidhuvud på flera sidor där sitens namn (" Butterfly Watchers Association") står och på varje sida vill ha en rubrik med sidnamnet ("News", "Members" o.s.v.) så kan man ju fundera på om sidans namn eller sitens namn borde få vara h1. Och om man sedan på varje sida har flera rubriker: h2 eller h3 ??

En bra artikel var det också. Låter nästan roligt att sätta sig ner och försöka göra en tabelldesign.

SlarvpelleMedlem sedan mars 200459 inlägg
#9

Tinwëlint skrev:

jag brukar satsa på att till bilder som är innehåll använda <img> och till bilder som är utseende använda background.

För bilder till innehåll är det nog fortfarande enklast att använda IMG till i kombination med en lämplig ALT text. Man skulle kanske kunna använda CSS bakgrunder även till vissa innehållsbilder (beroende på motiv), under förutsättning att sidan dessutom innehåller vanlig text som motsvarar bildens hela innehåll (eller åtminstone vad som skulle varit dess ALT text), så att sidan fortfarande går att använda av människor med nedsatt syn eller webbläsare med bildvisning avstängd.

Enbart dekorativa bilder kan man också använda IMG till, men då med ett tomt ALT attribut. Att visa dekorationsbilder som CSS bakgrunder kan kanske vara fördelaktigt om man vill kunna avlägsna dem i framtiden utan att behöva ändra HTML koden, men det förutsätter förstås att man inte från början lagt in extra DIV element och liknande just för att kunna visa CSS bakgrundsbilden.

SlarvpelleMedlem sedan mars 200459 inlägg
#10

Tinwëlint skrev:

Personligen tycker jag nog inte att H1 används "semantiskt korrekt" i exemplet då jag tycker att H1 hör till rubriksättning/värdering av innehåll, inte till sidhuvudet, även om jag finner en viss charm i den icke-stylade sidan.

Ja, det kan ju diskuteras. Om man har samma sidhuvud på flera sidor där sitens namn (" Butterfly Watchers Association") står och på varje sida vill ha en rubrik med sidnamnet ("News", "Members" o.s.v.) så kan man ju fundera på om sidans namn eller sitens namn borde få vara h1. Och om man sedan på varje sida har flera rubriker: h2 eller h3 ??

Det där tycker jag är ett problem med HTML i stort. Tanken är väl att varje sida på Internet skall vara självständig, med sin egen TITLE, H1 och inkommande länkar från tex sökmotorer. Men såvitt jag vet finns det ingen mekanism för att definiera/avgränsa en hel webbplats, mer än diffusa saker som domännamn, navigeringsmenyer eller gemensamma layouter/dekorationer.

En lösning skulle kunna vara att använda tex

h1 {font: bold large sans-serif;}

<h1>Tydlig huvudrubrik</h1>

på "index sidan", medan övriga sidor får hålla tillgodo med en diskretare stylad H1, kanske i kombination med en synligare underrubrik:

h1 {font: normal small sans-serif;}
h2 {font: bold large sans-serif;}

<h1>Diskret huvudrubrik</h1>
<h2>Tydlig underrubrik</h2>

--det är ju ungefär så en tryckt bok fungerar, där titeln är skriven med stora bokstäver på omslaget medan titeln visas betydligt diskretare på toppen av varje sida. I en tryckt bok kan H2 motsvaras av en kapitelrubrik.

Vill man ha en logo på varje sida som i artikeln skulle man kanske kunna göra så här på "index sidan":

<h1><img src="logo" alt="Logo text"></h1>

medan övriga sidor får

h1 {font: normal small sans-serif;}

<p><img src="logo" alt="Logo text"></p>
<h1>Diskret huvudrubrik</h1>

Däremot tycker jag det är "fel" av författaren att lägga in en slogan som "They flutter we catch them" i H1 elementet --det skulle passa bättre i ett eget P element.

Tinwëlint skrev:

En bra artikel var det också. Låter nästan roligt att sätta sig ner och försöka göra en tabelldesign.

Jag tycker att artikeln är lite orättvis mot tabell layouter, även om jag själv föredrar ren CSS. Man måste inte välja mellan TABLE+FONT eller CSS, det går också utmärkt att använda en enkel tabell för kolumner eller rutmönster, och CSS för allt annat. En sådan "hybrid-layout" brukar innehålla betydligt mindre buggar än rena CSS layouter, plus att man slipper problemet med text som spiller utanför sin container om användaren tex ökat textstorleken (i en tabell expanderar ju cellen istället, vilket oftast fungerar bättre för användaren) --detta samtidigt som HTML koden ändå inte är alltför komplicerad. Däremot kan det fortfarande vara jobbigt att modifiera en sådan tabell på stora webbplatser. Bästa lösningen är förmodligen CSS "display: table-cell" och liknande, men de stöds ju tyvärr inte av IE.

Jag tycker också att det är lite fånigt av författaren att använda HTML4 till tabell versionen och XHTML1.0 till CSS versionen. Man skulle lika gärna kunnat göra tvärtom, då både TABLE och FONT ingår i XHTML1.0. ;)

132 ms totalt · 3 externa anrop · v20260731065814-full.0e50b1ef
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
130 ms — hämta tråd, inlägg och bilagor (db)