Byggt en sida i XHTML Strict till en kund som kräver superclean kod.
Efter att ha visat arbetet och fått svaret "gediget bygge, clean markup och ren o lättnavigerad css", så fick jag även kommentaren "inte jätteförtjust i bruket att sätta width/height på alla bilder".

Hur ska jag tolka detta?
Hur brukar ni göra med width/height?
Jag har alltid satt width/height på bilder av den gamla anledningen att när en sida laddas, så har bilderna rätt proportioner redan innan bilderna laddats, så att inte bilderna/sidan "hoppar omkring" medan de intar rätt storlek när webbläsaren väl laddat bild med info.

Men hur är det med många bilder av samma storlek som laddas i en lång rad, t ex bilder som loopas ut från en databas? Ska man ta bort width/height-attributen för dessa bilder och sätta en gemensam klass för dessa i stylesheetet och i denna klass deklarera width/height?
Är det i så fall lika effektivt? Vid laddning av sidan (och då antar jag att man även ska tänka på användare av sämre uppkopplingshastighet), slipper man då att bilderna intar rätt storlek först när bilden har laddats?

Hur ska man göra?
Är det god kodning att sätta ut width/height alltid på bilder eller inte?

Självklart pratar jag inte om dynamiska bilder som kanske ska kunna växa på höjden och/eller bredden, där sätter jag ingen width/height.

Jag tycker det är bra att sätta ut storleken på bilden. Och varför inte, det är valid xhtml (1.1 tom). alternativet är ju att sätta storleken i cssen och det känns rätt bakvänt om det rör sig om bilder som variererar lite i storlek osv, tex som bilder i nyhetsartiklar, det är ju inte meningen att man ska behöva vara inne och ändra i cssen bara för att man uppdaterar en bild.

Dessutom så har det ju fördelen du talar om ovan... med att den får rätt proportioner. (vilket kan påverka hur resten av sidan visas sedan.).

Tack för ditt svar!

Du är inne på samma tankebana som mig. Skönt, då är vi iaf två ;)

Är det någon annan som har nåt att kommentera på mitt inlägg överst?
Jag vill ha tillräckligt med kött på benen innan jag "konfronterar" kunder... eller kanske viker mig för kundens önskemål (om man läste kundens mellan raderna).

Jag är normalt sett helt allergisk mot inline-styles förutom i fulhack-situationer, men just när det gäller höjd och bredd på bilder så finns det ju som sagt fördelar, så det tycker jag man kan förlåta.

Om man däremot har en mängd bilder i samma storlek, som t.ex. en produktlistning, så tycker jag att man bör göra en gemensam klass för dem. Det kan ju även vara smidigt om man kommer på att man t.ex. vill ha ramar runt alla bilder, eller ändra marginalerna eller vad man nu kan komma på.

Jag håller med de svar som du har fått och jag förstår din motivering.

Har du tagit diskussionen med kunden?

Berätta för kunden vilka fördelar du anser det är att specificera bilderna med width och height i koden.

Är det så att kunden trots allt inte vill ha det som du angivit så är det ju inte hela världen.

Är det dessutom snabbladdande bilder vi pratar om så kanske det inte ens blir märkbart utan width/height-specifiering.

Om kunden accepterar att sidan kan se lustig ut under "uppladdningen" så är det väl bara ta bort width & height?

Men en jävla löjlig kund var det väl?
=)

Vem pratade om inline styles? ..
Givetvis är det bättre om man har alla bilder lika stora att sätta den storleken i cssen.. det är ju klart smidigare och ger mindre markup. Men som sagt, om det är lite olika storlek på dem, eller förväntas kan bli det, så är det klart rättfärdigat att använda höjd och bredd attributen.

Jag råkade ta det för givet när Seattlegrunge skrev att han definierat höjd resp bredd i html-sidan. Men nu när jag tänker efter så har du givetvis rätt i att HTML/XHTML-attributen width och height fortfarande finns kvar. Tack för påpekandet. :)

Men i så fall tycker jag att det är noggrann kodning att ange XHTML-attributen width resp. height eftersom det anger en bilds verkliga storlek vs CSS som bara beskriver hur bilden ska renderas.

Jag vet inte vilken tillgång du har till olika komponenter på servern, men jag brukar göra så att jag alltid skriver höjd och bredd, även på dynamiskt skapade bilder.

Det är lite extra jobb med det, men det är snyggt och snabbladdat!

Jag är inte så duktig på css, och det kanske inte passar i din lösning...!?

XHTML Strict när kunden vill ha superclean kod? Är kunden medveten om att XHTML Strict tolkas som tag-soup av merparten av webbläsare, så tillvida man inte leverar XHTML med korrekt MIME type? XHTML är en del av XML och fördelarna ligger i att det tolkas som ett XML-dokument, men eftersom 99% av alla webbservrar skickar dokument skrivna i XHTML som text/html så läses koden som HTML. Börjar bli lite halv-trött på alla dessa glorifieringar av XHTML, enbart för att det är den senaste standarden som W3C pumat ut.

Vad Width och Height anbelangar, så är de inte att ses som metadata, det förser inte elementet med någon extra innebörd. Det är alltså presentationell mark-up, och enligt logikens alla regler hör det således hemma i CSS. Men, om du har en uppsjö av bilder blir en sådan fil till slut ohanterlig.

Dagens webbläsare känner för det mesta av Width och Height ganska bra, men betydligt äldre webbläsare kan faktiskt bryta ihop helt när Width respektive Height saknas. Antar att det är en sakfråga. Offra super-ren kod i utbyte mot 0,01% av besökarna.

Beroende på layout och CMS, kan ju i o f tänkas att man skapar en uppsättning klasser för bilder. Arbetar man med fast storlek för layouten så skapar man således några av de mest använda storlekarna. Det ger ju en ökad enhetlighet och blir lättare att hantera.

Härligt att läsa dessa rader.

Nu är det på det viset att Opera och Firefox klarar av att tolka xhtml om det är rätt mime-typ medan IE inte klarar av xhtml med korrekt mime-typ utan då öppnar ett pop-uppfönster för nedladning av en fil.

Ska man dra fördelar av xhtml får man känna av vilken webbläsare som efterfrågar sidan och skicka rätt mime-typ till t.ex. Opera och Firefox och skicka "fel" mime-typ till IE och i stället för doc-typ xhtml skicka html 4.01 strict.

Själv skriver jag xhtml och skickar doc-typ html 4.01 strict, för det är bättre att tala om vad som ska tolkas än att låta webbläsare gissa.

Förstod inte riktigt om det var härligt för att du håller med eller av andra orsaker, men...

<!--QuoteBegin--guran
Ska man dra fördelar av xhtml får man känna av vilken webbläsare som efterfrågar sidan och skicka rätt mime-typ till t.ex. Opera och Firefox och skicka "fel" mime-typ till IE och i stället för doc-typ xhtml skicka html 4.01 strict.[/quote]

Tvärtom är Content Negotiation ännu sämre. Gecko-baserade (Mozilla och Firefox) webbläsare lär ännu inte ha "incremental display" implementerat för XML-dokument. D v s, hela dokumentet läses in och visas sedan. (Källa: http://www.mozilla.org/docs/web-deve...aq.html#accept).

Content-Negotiation innebär också att man inte kan använda XML namnrymder (såsom MathML) eftersom det "Blå E:et" inte stödjer dessa ändå. Fördelarna med XML är icke-existerande i dagsläget, såvida man inte explicit servar en publik som använder Opera eller Mozilla och man har ett behov att blanda XML och HTML.

Bör tilläggas att XHTML fortfarande får jobbet gjort, och enligt specifikation kan man skicka XHTML som text/html om det är HTML-kompatibelt (ett bisarrt uttalande, eftersom ett HTML-kompatibelt XHTML-dokument är HTML). Men, rekommenderad MIME-typ är fortfarande application/xhtml+xml, och först då kan man använda unika funktioner för XHTML.

Hoppas detta inte uppfattas som spam, men kände mig tvungen att rätta mig själv innan jag blir halshuggen:

Jag menade givetvis XHTML.

Problemet är att om man anger rekommenderad mime-typ application/xhtm+xml så utesluter man alla IE-användare.

Det går alltid att roa sig med att skicka application/xhtm+xml och se vad som händer. I Opera och Firefox lär man inte se något, OM man inte har gjort ett fel i koden. Då reagerar de med att inte visa sidan utan visar i stället ett felmeddelande. Det finns inget överseende med fel i koden.

Vägverkets hemsida (kodan i xhtml, skickar mime-typ text/html) brukar slänga ett meddelande i huvudet på mig när jag använder mig av Opera, att min webbläsare inte är xhtml-kompatibel. Utvecklarna på Vägverket verkar dock tro att IE är det.

Det är just därför man alltid skall överväga innan använder XHTML :rolleyes:.