webForumDet fria alternativet

style="bakground-image" bättre än background?

14 svar · 409 visningar · startad av bassebhu

bassebhuMedlem sedan nov. 20016 480 inlägg
#1

Tje!

Har tänkt att följa det här strict-grejset och fick warning på att background-attributet inte är godkänt.

Är det bättre att köra på style="background-image"? Om det inte är bättre så kan jag leva med att sidan inte blir godkänd i validatorn.

Jag har upptäckt att det verkar ta nån millisekund längre att få bilderna på plats om man kör på style-sättet. Kanske bara min webbläsare (safari).

Och en annan sak som den inte gillade var absmiddle konstigt nog. Den tyckte att jag skulle använda bara middle, men det ger ju inte samma resultat. Hur får jag absmiddle-funktionen i style-tagg? säkert jättelätt hehe.

Taxi!

zcorpanMedlem sedan dec. 20042 245 inlägg
#2

HTML handlar ju inte om hur saker ska presenteras egentligen, det använder man stilmallar till. Så ja, det är bättre att använda CSS. ;) (Helst också i en separat fil, inte med STYLE-attributet.)

Nu vet jag inte vad "absmiddle" är för nånting men om du förklarar hur du vill ha det eller kanske visar en bild så kanske vi kan hjälpa dig. Annars kanske du kan se om du hittar nåt intressant om background-egenskapen i specifikationen. :)

bassebhuMedlem sedan nov. 20016 480 inlägg
#3

style="vertical-align: middle;" ville inte heller fungera tillfredsställande.

Körde in det i tabeller i stället och löste det så.

Men still: är det dumt att köra alla backgroundbilder med style-inladdning?
Jag menar, attributet background har väl stöd längre bak i webbläsarhistoriken än style-varianten?

bassebhuMedlem sedan nov. 20016 480 inlägg
#4

zcorpan skrev:

Så ja, det är bättre att använda CSS. ;) (Helst också i en separat fil, inte med STYLE-attributet.)

Nu är det så att jag har massvis med små bilder som jag vill läsa in som cellbakgrunder. Att lägga all denna info i min externa css-fil känns bara klumpigt. Därav står valet mellan style="background-image" eller background="" i mina td-taggar.

zcorpanMedlem sedan dec. 20042 245 inlägg
#5

Nu blev jag lite nyfiken, men varför vill du ha dem som bakgrunder? Är bilderna del av "innehållet" eller är de bara dekorativa?

För isf. borde du använda IMG-elementet istället. ;)

Om du använder tabeller för layout så tror jag inte att det spelar så stor roll hur du gör, för då har du redan missat poängen med att separera struktur och presentation... Du kanske t.o.m. klarar dig bättre med en Transitional DOCTYPE. :)

GuffaMedlem sedan juni 2004533 inlägg
#6

Tänk framåt istället för bakåt. background-image finns i standarden, men inte background. Det betyder att stödet för background kommer att försvinna på sikt.

Visserligen stöds background bättre på mycket gamla webbläsare än background-image, men hur gamla webbläsare tror du att din webbsida egentligen fungerar i? Har du ens testat sidan i Netscape 2 eller Internet Explorer 3?

Att bilderna skulle visas snabbare med endare metoden är antingen inbillning, sammanträffanden, eller något webbläsar-specifikt.

martinMedlem sedan apr. 2000313 inlägg
#7

Eller för att säga saker på ett litet annat sätt:
Om du vill jobba med "modern" css-stilad browserkod, måste du tänka på ett helt annat sätt än om du jobbar med "gammaldags" tabell- och font-stilad kod. Detta är nåt man måste lära sig från grunden och det tar antagligen. När man väl kan jobba på det moderna sättet är det mycket enklare (med undantag av en del browserbuggar), snabbare och skönare på många sätt. När man börjar lära sig det sättet att jobba på löser sig en hel del med bakgrundsbilder och annat. Dessutom är det vansinnigt skoj.

En "style="background-image"" löser inte dina problem.

bassebhuMedlem sedan nov. 20016 480 inlägg
#8

Tänka framåt ja. MEN min poäng är att vi som sitter här och knackar har såklart de senaste läsarna. Jag känner däremot många som kör t ex senaste IE till mac (även jag själv emellanåt) och många stora siter fungerar inte bra alls i den läsaren. Allra helst sidor byggda med lager. Det finns också dem som sitter i OS 9 och Windows 95 och äldre och kör på stenålders-läsare.

Jag tror inte ens att det kommer en uppdatering av IE till mac så det kanske är dags att tänka lite framåt ändå och hoppas att det gamla dör ut snart.

Vad är era förslag då? Köra på det moderna och låta äldre läsare få möta kaos eller helt enkelt slussa dem vidare till en sida där det stå "tyvärr...". Att göra flera versioner av siten känns inte så lockande.

GuffaMedlem sedan juni 2004533 inlägg
#9

En välskriven webbsida fungerar i alla webbläsare.

Med "alla" så menar jag verkligen alla. Med "fungerar" menar jag att webbläsaren förmedlar informationen så bra den kan.

En grundläggande filosofi med xhtml är att sidans struktur ska vara uppbyggd med standard-taggar som fungerar i alla webbläsare, och allt lull-lull som bilder, färger, typsnitt och extra funktionalitet ska skötas med css och javascript. Genom att använda taggar till det som de var avsedda till från början och bestämma hur de ska se ut med css, så fungerar allting även om webbläsaren inte ens stöder css eller javascript, eller ens stöder grafik över huvud taget.

Ifall sidan är rätt uppbyggd så ska en blind person kunna navigera runt på den utan problem. Det kan vara bra att tänka på när man bygger sidan.

bassebhuMedlem sedan nov. 20016 480 inlägg
#10

Sant.

Men vad är vitsen med att ange doctype? Vad för info innehåller den taggen och hur används den?

Jag brukar köra på:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

...då dreamweaver sätter den automatiskt. Vad innebär den?

Jag har även sett sidor som har den här doctypen, vad innehåller den?:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Om jag har en sida som går igenom w3-valideringen men som använder tabeller vad bör jag använda för doctype då - och varför?

:)

zcorpanMedlem sedan dec. 20042 245 inlägg
#11

Den som söker han finner... ;)

HTML4 och XHTML1.0 innehåller exakt samma sak. Skillnaden är att XHTML är baserat på XML. XHTML1.0 är en omskrivning av HTML4 i XML.

Om du använder HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Om du använder XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

This is the HTML 4.01 Transitional DTD, which includes
presentation attributes and elements that W3C expects to phase out
as support for style sheets matures. Authors should use the Strict
DTD when possible, but may use the Transitional DTD when support
for presentation attribute and elements is required.

dAEkMedlem sedan feb. 20041 816 inlägg
#12

Guffa skrev:

Ifall sidan är rätt uppbyggd så ska en blind person kunna navigera runt på den utan problem. Det kan vara bra att tänka på när man bygger sidan.

Blinda kan[precis som du skriver] surfa runt på felaktigt uppbygda sidor men det är klart att det underlättar en hel del om kodaren lagt ner lite jobb på sidan. Att använda tabeller för layout är som bekant inte alls optimalt och inte speciellt rekommenderat men det krånglar heller inte till det speciellt mycket för en blind. En sida som använder rätt element, en genomtänkt struktur och ett noga urval av färger är enklare för alla att navigera, inte bara blinda. :)

-------------------

IE för mac är död, utvecklas inte mer...

Mitt råd är att köra med div's och css. Använd lämpliga element så kommer dem med gamla browsers inte möta kaos utan ett välstrukturerat textdokument.

Besökare som använder föråldrad teknik kan inte förvänta sig att sidorna skall fungera på samma sätt som i en modern browser. Problemet är bara att många tyvärr inte är medvetna om att de använder gamla browsers, eller att det är en browser de använder, men om man fortsätter koda sidorna för dessa besökare kommer dem ju aldrig få reda på att de använder utdaterad teknik och varför ska de uppdatera när det inte finns några skäl till det? Allt fungerar ju! ;)

bassebhuMedlem sedan nov. 20016 480 inlägg
#13

...men trots allt så känns det fortfarande mer kompitabelt att strukturera sidan med tabeller än med lager. Eller är det bara jag som har dåliga erfarenheter av lager som hänger med sen förr i tiden? ;)

Jag hoppar väl på div-strukturering med id'n i nästa produktion jag gör ;)

GuffaMedlem sedan juni 2004533 inlägg
#14

Tabeller är lite mer kompatibelt med webbläsare ifrån en viss period bakåt i tiden.

En välgjord sida i xhtml är däremot mer kompatibel med alla webbläsare innan den perioden, med alla framtida webbläsare (inom överskådlig tid) och med alla webbläsare som faller utanför ramen att visa sidan som grafik på skärmen.

Sökmotor-robotar är ett exempel på användare som söker efter information på din sida, men som är helt ointresserade av layouten. Att gå igenom en välstrukturerad xhtml-sida måste vara rena drömmen för en sökrobot, vilket naturligtvis gör att du har större chans att få sidan korrekt indexerad och därmed större chans för träffar i sökmotorerna.

dAEkMedlem sedan feb. 20041 816 inlägg
#15

bassebhu skrev:

...men trots allt så känns det fortfarande mer kompitabelt att strukturera sidan med tabeller än med lager. Eller är det bara jag som har dåliga erfarenheter av lager som hänger med sen förr i tiden? ;)

Jag hoppar väl på div-strukturering med id'n i nästa produktion jag gör ;)

Najs. :)

Det är lite krångligt i början men när du väl fått lite kött på benen och känner till de vanliga tricksen kommer du aldrig vilja designa med hjälp av tabeller igen!
Vad som är viktigt är att man använder rätt element för rätt uppgift, man kan koda med divvar och ändå få en enda stor soppa av det hela. Har man semantik med i bakhuvudet hela tiden borde det inte vara några problem, men det krävs att man tänker till lite eftersom det inte alltid är självklart vilket element som är bäst lämpat att använda. Med tiden blir det dock mer och mer logiskt. :)

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