CSS: Problem med borders i IE Wintendo™

Tråden skapades och har fått 28 svar. Det senaste inlägget skrevs .
1

Jättekonstigt problem med borders som försvinner i Wintendo™ IE...

Bifogar skärmdump, och källkod finns på http://filmstudion.com/adversus/filmstudion/temptest6.php...

Mvh Scooter

Senast redigerat 2004-08-30 10:11

Verkligen ingen som sett detta tidigare?

  • Medlem
  • Gävle
  • 2004-08-30 09:10

När du säger "ramar", menar du borders då? Eller menar du frames? (Tips: Använd engelsk nomenklatur så blir det ingen förvirring.)

Jag menar självklart borders, men det torde framgå av bifogad skärmdump

hmm... sitter å försöker leta vad det är.. men nått måste vara felkodat för previewfunktionen i bl.a dreamweaver visar sidan helt galet. Ska försöka gå igenom koden och kolla vad det beror på.

  • Medlem
  • Gävle
  • 2004-08-30 11:24
Ursprungligen av scooterbabe:

Jag menar självklart borders, men det torde framgå av bifogad skärmdump

Skärmdumpen avslöjar inte särskilt mycket, men hade jag kollat på sidan så hade det nog varit uppenbart.

Jag har sett och upplevt det där problemet många gånger; att borders ritas ut ok men lixom blir trasiga när man scrollar. Tyvärr kan jag inte säga exakt vad det beror på, eller under vilka omständigheter det händer, bara att det är ett vanligt problem med IE för Windows (tror inte någon annan webbläsare har problemet). Det handlar alltså om en bugg i IE!

Du kan "lösa" problemet genom att använda en bakgrundsbild istället (m. en pixel på vardera sida och vitt/transparens mellan), eller så kan du låta IE/Win-användarna lida lite och skita i't helt enkelt.

Jag har tidigare aldrig velat låta IE/Win-användare "lida", eftersom de är i majoritet, att deras problem blir mina problem förr eller senare, etc osv. Men, eftersom kampanjen att switcha bort från IE blivit ganska stor nu, och allmänheten börjat fått upp ögonen för att IE/Win har en del problem, så tycker jag numer att man faktiskt kan låta IE/Win-användare lida för denna typ av små och relativt obetydliga renderingsfel. Desto mer positivt överraskade blir de när de switchar till Firefox.

Ursprungligen av mrsandin:

nått måste vara felkodat för previewfunktionen i bl.a dreamweaver visar sidan helt galet.

Det beror snarare på Dreamweavers dåliga renderingsmotor.

Ursprungligen av tjogin:

Skärmdumpen avslöjar inte särskilt mycket, men hade jag kollat på sidan så hade det nog varit uppenbart.

Jepp, skulle tro det

Citat:

Jag har sett och upplevt det där problemet många gånger; att borders ritas ut ok men lixom blir trasiga när man scrollar. Tyvärr kan jag inte säga exakt vad det beror på, eller under vilka omständigheter det händer, bara att det är ett vanligt problem med IE för Windows (tror inte någon annan webbläsare har problemet). Det handlar alltså om en bugg i IE!

Din beskrivning av problemet är ackurat, och jag har också dragit slutsatsen att det är en IE-bugg (precis som att IE 6.x inte kan rita ut punktade borders om de är mindre än 2px tjocka)...

Citat:

Du kan "lösa" problemet genom att använda en bakgrundsbild istället (m. en pixel på vardera sida och vitt/transparens mellan), eller så kan du låta IE/Win-användarna lida lite och skita i't helt enkelt.

Tror inte jag kan lösa det på det sättet; jag använder redan bakgrundsbild i div:en, och bilden som sabbar kantlinjerna / border:na ändras dynamiskt och placeras oberoende på sidan...

Citat:

Jag har tidigare aldrig velat låta IE/Win-användare "lida", eftersom de är i majoritet, att deras problem blir mina problem förr eller senare, etc osv. Men, eftersom kampanjen att switcha bort från IE blivit ganska stor nu, och allmänheten börjat fått upp ögonen för att IE/Win har en del problem, så tycker jag numer att man faktiskt kan låta IE/Win-användare lida för denna typ av små och relativt obetydliga renderingsfel. Desto mer positivt överraskade blir de när de switchar till Firefox.

Det beror snarare på Dreamweavers dåliga renderingsmotor.

Precis min inställning också, men om det finns en workaround, är jag mer änn glad om jag kan ta del av den

/.scooter

testa att använda tables och göra en <td> cell som innehåller en transparent gif-bild som är 1x1px. sätt bakrunden i <td> taggen till valfri färg. På detta sätt får du en ram. Gör en <td> cell både på vänster och höger sida och en tabellrad uppe och nedan. ange endast bredd på de vertikala cellerna och endast höjd på de horisontella. Låt innehållet i tabellen styra storleken på sidan.

Visserligen måste du koda om sidan med detta sätt men det fungerar mig veterligen i alla webbläsare jag testat. använder uteslutande denna metod när jag ska ha en ram runt sidorna.

Vore schysst - jag har inte en idé...

Klagomålen på ikke-valid xhtml är inte mitt fel; kunden har varit inne och pysslat om själv... Det är även denne som lagt till "guldtacke"-effekt i loggan; jag svär mig fri från detta.

Jag vill helst undvika att layouta med tables; då får de hellre ha buggen i IE...

Men tack för tipset i alla fall!

  • Medlem
  • 2004-08-30 16:46

Layers är ett rent helvete och få att fungera bra på Internet Explorer och andra läsare, antingen så får man det att funka på IE men då funkar det inte på de andra eller tvärtom. Är klart bättre om du använder tables istället, oki lite jobbigare kanske för den ovana men man tjänar då oftast på det med klart mindre strul.

  • Medlem
  • Gävle
  • 2004-08-30 16:58
Ursprungligen av zero:

Layers är ett rent helvete och få att fungera bra på Internet Explorer och andra läsare, antingen så får man det att funka på IE men då funkar det inte på de andra eller tvärtom. Är klart bättre om du använder tables istället, oki lite jobbigare kanske för den ovana men man tjänar då oftast på det med klart mindre strul.

Layers har dock inget med detta att göra. Layers är/var en Netscape-specifik tag som, helt riktigt, inte fungerade i IE. Det var dock många år sedan.

scooterbabe har istället valt att layouta sin webbsida enligt W3Cs rekommendationer m.h.a. XHTML och CSS, vilket är det numer föredragna sättet att bygga webbsidor, då det ger större flexibilitet, går snabbare att utveckla, mycket snabbare att underhålla, ger lägre filstorlekar, bättre cachningsmöjligheter, bättre tillgänglighet (accessibility), är mer sökmotorvänligt, och ger mer snabbladdande sidor.

Tips till scooterbabe: lägg all CSS:en i en separat fil så kan besökarna cacha den filen och får på så vis en mer snabbladdad sida.

Tips 2 till scooterbabe: använd css-tabbar istället för tabeller när du gör menyn.

  • Medlem
  • Karlstad
  • 2004-08-30 16:59
Ursprungligen av zero:

Layers är ett rent helvete och få att fungera bra på Internet Explorer och andra läsare, antingen så får man det att funka på IE men då funkar det inte på de andra eller tvärtom. Är klart bättre om du använder tables istället, oki lite jobbigare kanske för den ovana men man tjänar då oftast på det med klart mindre strul.

Vad exakt menar du med "layers"?
"Layers" är normalt ett uttryck som förvirrar. Det har skapats av Macromedia genom Dreamweaver och som betyder "absolutely positoned divisions". Följaktligen är det nästan uteslutande DW-användare som svänger sig med begreppet, tror jag.
Eller menar du div-containers i största allmänhet?
Kanske bäst att förtydliga....?

EDIT:

Se! Nu kom Tjogins inlägg, och förvirringen kunde inte demonstreras bättre: Han nämner TAGGEN >layer> som kommer från Netscape. Jag menade BEGREPPET "layer" som kommer från Macromedia....puh....

  • Medlem
  • Gävle
  • 2004-08-30 17:04
Ursprungligen av Danne V:

Se! Nu kom Tjogins inlägg, och förvirringen kunde inte demonstreras bättre: Han nämner TAGGEN >layer> som kommer från Netscape. Jag menade BEGREPPET "layer" som kommer från Macromedia....puh....

Jag håller med om att "layers" är ett väldigt förvirrande uttryck, då det kan betyda både det ena och det andra. Oavsett vad man menar med "layers" så rör det sig iaf om en layout-teknik som inte är att rekommendera, varken Macromedia's "layers" eller Netscapes "layer"-tag.

  • Medlem
  • Karlstad
  • 2004-08-30 17:17
Ursprungligen av tjogin:

Jag håller med om att "layers" är ett väldigt förvirrande uttryck, då det kan betyda både det ena och det andra. Oavsett vad man menar med "layers" så rör det sig iaf om en layout-teknik som inte är att rekommendera, varken Macromedia's "layers" eller Netscapes "layer"-tag.

Jodå, om man känner till begränsningarna med Macromedia's "layers", dvs "absolutely positioned divisions", och rättar sin struktur därefter, så är det inga som helst problem. Om man INTE känner till begränsingarna blir det tjorvigt, däremot.

Men nu spårar tråden ur. Det handlar ju om babes kanter...

Tror inte jag använder mig av några layers; allt är straightforward xhtml, och jag tror inte jag använder mig av ett enda z-index.

Men som sagt; finns det inget sätt att lösa buggen på och fortfarande använda sig av <div>:ar för datan?

  • Medlem
  • 2004-08-30 18:19

Va kanske lite otydlig, men ja menade layers eller lager i största allmänhet, alltså även med <DIV> eller även om man använder det i en <IMG>, är iaf. va ja lagt märke till, tex. 323 pixlar är inte 323 pixlar i alla webläsare, medans kanske 325 pixlar är samma i de flesta, det har iofs. inget med lager eller tabeller då det problemet blir oavsätt va man kör med.

  • Medlem
  • 2004-08-30 18:45

Sen hur kan det bli 'helt plötsligt' bli att man ska köra med xhtml och css för att designa sina sidor då den ledande webläsaren inte har hänt något direkt med på de senaste 3 åren. (förrutom femtioelva säkerhetsfixar).

XHTML, CSS# mm utvecklas ständigt på de flesta webläsare (utom IE) för att uppnå än bättre W3C standard.

  • Medlem
  • Gävle
  • 2004-08-30 22:59
Ursprungligen av zero:

Sen hur kan det bli 'helt plötsligt' bli att man ska köra med xhtml och css för att designa sina sidor då den ledande webläsaren inte har hänt något direkt med på de senaste 3 åren. (förrutom femtioelva säkerhetsfixar).

Det är inte "helt plötsligt", dock har det tagit lång tid för webbutvecklare att anamma W3Cs rekommendationer, det är inte förrän nu anammandet börjar nå en kritisk massa.

Den senaste versionen av HTML-standarden (eller "rekommendationen" som det egentligen heter), version 4.01, kom i december 1999. Det var den sista och slutgiltiga versionen av HTML, det kommer inga fler. HTML:s efterföljare XHTML 1.0 kom i januari 2000. HTML är död, länge leve XHTML. Standarden om "HTML Techniques for Web Content Accessibility Guidelines" kom i november år 2000.

Detta med XHTML, CSS och accessibility är således inte nya påfund, utan snarare gammal skåpmat.

Många faktorer har dock hållit tillbaka anammandet av de "nya" standarderna, exempelvis tillkortakommanden i webbläsarna, dock har webbläsarna idag nått den nivå där användandet av XHTML och CSS för layout blivit möjligt i praktiken. Observera att jag då _inte_ menar de allra senaste webbläsarna, utan att folk har "hunnit" uppgradera till webbläsare som stödjer denna teknik, och lämnat de som inte gör det bakom sig (Netscape 4.x).

Därtill så skulle jag vilja skylla en hel del på webbutvecklare i allmänhet, de verkar lida av ett extremt fall av tunnelseende; de flesta webbutvecklare har inte ens tittat efter om det kanske, eventuellt, möjligtvis kommit nya rekommendationer eller specifikationer sedan de lärde sig HTML 4.01. De tror lixom att de är klara nu, att det inte _finns_ något nytt att lära sig om (x)HTML. De har fel, väldigt fel på den punkten. Det är dock inte något att vara bitter om, jag ser det som ett bra sätt att naturligt rensa ut de webbutvecklare som egentligen borde hålla på med något annat.

  • Medlem
  • 2004-08-31 06:43

Men va är skillnaden på xhtml och html förrutom att visa kommandon som <img> har en / på slutet <img src"nisse.jpg" />?

  • Medlem
  • Gävle
  • 2004-08-31 09:58
Ursprungligen av zero:

Men va är skillnaden på xhtml och html förrutom att visa kommandon som <img> har en / på slutet <img src"nisse.jpg" />?

Ja du, vad är det för skillnad på en Ferrari och en Fiat, förutom att Ferrarin är lite längre?

Allvarligt. Det är för stora skillnader för att det ska gå att rymmas i den här diskussionen (som redan nu är urspårad).

Detta är en mycket bra startpunkt för att lära sig mer om XHTML, och webbutveckling med standarder generellt:

http://www.456bereastreet.com/lab/webbutveckling_med_standarder/

Om man bara tittar på syntaxen så kan det verka som att den enda skillnaden är att man slänger på en "/" på IMG och BR, men isf har man stirrat sig blind på träden och missat skogen, XHTML är ett nytt tänk, ett nytt sätt, en ny metod. Kolla in ovanstående länk för mer information.

Tanken med xhtml är att (markup)språket ska användas till att tagga upp informationen/datan för att beskriva denna. Layouten styrs med CSS. För att ta det kort.

<h1> används till exempel inte för att göra stor eller fet text, utan för att säga att texten taggen omsluter är en rubrik av första graden. Hur den sedan representeras i en webbläsare bestäms av hur CSS:en ser ut för den aktuella sidan, alternativt av hur standard-CSS:en för browsern ser ut.

Men frågan var egentligen varför mina borders försvinner - ingen som har någon idé förutom att gå till tabellbaserad layout?

  • Medlem
  • Gävle
  • 2004-08-31 10:44
Ursprungligen av scooterbabeMen frågan var [i:

egentligen[/i] varför mina borders försvinner - ingen som har någon idé förutom att gå till tabellbaserad layout?

Förslaget med att använda tabeller innebar ju att wrappa containern i en tabell, du kan ju lika gärna wrappa containern i en div, som du ger en bakgrundsbild (se mitt tidigare tips). Skillnaden på mitt förra tips och detta tips är alltså att du istället för att sätta bakgrundsbilden direkt på den container som ska ha borden (som du inte kunde för att den redan har en bakgrundsbild) så sätter du en bakgrundsbild på en wrappande div. Eller, så kan du t.ex. sätta dess bakgrunsfärg till svart och ge den 1px padding, och sätta containern inutis bakgrundsfärg till vitt.

Alla dessa tips involverar ju dock någon form av "fula" tricks som egentligen inte hör hemma i XHTML/CSS-baserad utveckling, jag ville bara poängtera att det inte var användandet av tabeller som möjliggjorde lösningen, utan användandet av fula knep.

Allra bäst vore det nog att istället söka på Google, nån jäkel måste ju ha klurat ut exakt vad/när/hur denna bugg visar sig.

Har gjort lite framsteg i frågan genom att jag kommit fram till att jag har drabbats av en "Peek-a-boo"-bug - något som nästan uteslutande drabbar buggwebbläsaren IE med dess box model problems, floatproblem och marginalproblem...

Söker vidare.

  • Medlem
  • 2004-09-01 10:50

Lägger du in bakgroundsbilden i CSS istället som du gjort från början men av nån anledning komenterat bort å lagt bakgroundsbilden som en 'flytande bild' mitt i koden så funkar sidan.
Kolla på mitt exp. http://mac.myftp.org/Filmstudion.html (inga länkar funkar å alla bilder är direkt länkade från din server.) Men sidan funkar i både vad-som-helst och IE på PC.

Ursprungligen av zero:

Lägger du in bakgroundsbilden i CSS istället som du gjort från början men av nån anledning komenterat bort å lagt bakgroundsbilden som en 'flytande bild' mitt i koden så funkar sidan.
Kolla på mitt exp. http://mac.myftp.org/Filmstudion.html (inga länkar funkar å alla bilder är direkt länkade från din server.) Men sidan funkar i både vad-som-helst och IE på PC.

Anledningen till att det är bortkommenterat är att det kukade ur i Wintendo™ IE på vissa sidor; bakgrundsbilden smälte delvis ihop med texten när man gjorde mouseover... Effekten var som att det vita i giffen var transparent, och att loggan låg över texten... Försvann igen när man scrollade vill jag minnas...

Men jag har löst det nu; det var en peek-a-boo-bug, och det löstes genom att för IE Win sätta en höjd på 1% (marginellt liten höjd). IE Win overrular höjden om innehållet i elementet är större än dimensionen man satt (vilket inte sker för IE Mac varvid det måste kommenteras bort för macen).

Den som vill läsa mer om buggen, och hitta en länk till en sida hos M$ som ger mer klarhet i fenomenet, kan läsa här:

http://www.positioniseverything.net/articles/hollyhack.html#haslayout

Citat:

In fact there is an "interesting" page on the Microsoft website that seems to address this issue in a tangental way. This.page talks about something called layout but fails to explain what it is, or why such a thing exists in the first place. Apparently giving a dimension to a box is one of the ways to trigger "layout" in that box, so it's clear that Microsoft deliberately designed their browser to behave in this strange way. Regardless of the reasoning, when a box lacks layout it is vulnerable to many weird bugs, and when the box hasLayout it causes the browser to violate several W3C specifications. Considering that this "layout" thing is not part of the W3C specs, one wonders exactly what Microsoft is trying to accomplish.

  • Medlem
  • 2004-09-01 11:20

skumt, verkade ju vara ett mer riktigt sätt att göra det på... men men.. har du fått det å funka så är det ju huvudsaken.

Sen när du börjar bli klar måste du nog lägga in något javascript som varnar folk med äldre läsare om att sidan inte alls funkar, men det visste du nog redan.

(la märkte till det eftersom ja inte har IE till mac i OS X utan bara i OS 9.)

Ursprungligen av zero:

skumt, verkade ju vara ett mer riktigt sätt att göra det på... men men.. har du fått det å funka så är det ju huvudsaken.

Sen när du börjar bli klar måste du nog lägga in något javascript som varnar folk med äldre läsare om att sidan inte alls funkar, men det visste du nog redan.

Att den inte funkar har jag tagit för givet, men att skriva andra sidor / JS för dessa få är ekonomiskt oförsvarbart.

Men du, och alla andra, ska ha tusen tack för all input i fallet tills dags datum!

Hälsar:

/.scooter

  • Medlem
  • 2004-09-01 12:05

är ju sant va inte riktigt så avancerat ja menade, mest bara en litet JS som säger till att det kanske är dax att skaffa en nyare webläsare. Alla OS från ca 1998 och framåt har ju möjlighet att se sidan som den ska se ut, folk som kör med OS som är äldre än så, kan man ju inte göra något åt, det skulle som sagt va bli för mycket jobb.

1
Bevaka tråden