20 svar · 725 visningar · startad av AndreasC
av
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Ingenting funkar i IE 6.0 vad gäller css. Inte ens en så simpel sak som <div style="margin-left:30px"> funkar. Den ignoreras helt och hållet och innehållet i diven får inte alls någon marginal på 30 pixlar. Kan säga som så att ingenting är som innan implementationen. Allt är liksom förskjutet och ligger inte där det ska.
Vad har hänt?
Jag erkänner, det är jag som inte skriver rätt.
Jag skrev inte px men när jag gjorde det så hoppade det till rätt ställe. Det är bara att gå igenom och skriva rätt.
Har egentligen bara en fråga om detta då. Vad ska man använda sig av för character set på sidorna? Alltså man ska ju helst skriva den informationen i en <meta>-tag, men vet inte exakt vilken man ska använda sig av.
Jag rekommenderar utf-8, då kan du använda vilka tecken som helst. Dock får du se till att din texteditor kastar ut utf-8 också. :)
[edit]
Ang. vad som "har hänt", är att IE6 använder "standards mode" när du använder den DOCTYPEn. Då är det striktare regler som gäller. :)
[/edit]
zcorpan skrev:
Jag rekommenderar utf-8, då kan du använda vilka tecken som helst. Dock får du se till att din texteditor kastar ut utf-8 också. :)
Enklare är dock att använda ISO-8859-1 (väst-/nordeuropeisk 8-bitskod), som är den teckenkodning som brukar användas [per default] internt på de flesta svenska system.
Men jag kan använda UTF-8 som zcorpan säger lika gärna väl?
Absolut. Det går så fint så. Det kan i vissa fall bli lite bökigt, men det går att överkomma.
Vad kan bli bökigt?
"The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported."
Är det detta du tänker på?
Men varför funkar inte detta?
body
{
scrollbar-base-color:#000000;
scrollbar-track-color:#363636;
scrollbar-arrow-color:#898989;
scrollbar-shadow-color:#898989;
scrollbar-darkshadow-color:#000000;
scrollbar-highlight-color:#898989;
scrollbar-3dlight-color:#000000;
}
AndreasC skrev:
"The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported."
Är det detta du tänker på?
Ja, typ. Vissa program har inte skrivits så bra som de borde skrivits, och alla system är inte konfigurerade så bra som de borde vara, och förlitar sig på den lokala defaultkodningen. Det är inget stort problem, men jag kan inte påstå att jag ser någon direkt anledning till att välja UTF-8 framför ISO-8859-1 om man inte behöver (eller förväntar sig att komma behöva) kunna trycka in alla tänkbara tecken på sidan utan att koda dem med entiteter.
AndreasC skrev:
Men varför funkar inte detta?
[ ... ]
... för att MSIE vill ha de där definitionerna kopplade till html om du kör med en <!DOCTYPE som ställer den i "standards mode"...
Lösningen är alltså:
[b]html,[/b] body {
scrollbar-base-color:#000000;
scrollbar-track-color:#363636;
scrollbar-arrow-color:#898989;
scrollbar-shadow-color:#898989;
scrollbar-darkshadow-color:#000000;
scrollbar-highlight-color:#898989;
scrollbar-3dlight-color:#000000;
}
BTW - Jag kan intyga att det kan vara knöligt att gå över till UTF-8, speciellt om man har projekt igång samtidigt som behöver "ligga kvar" i ISO-8859-1...
Jag vet inte hur många gånger jag svurit över att den väletablerade redigerare jag använder alltid går upp i "default encoding" och på så sätt antingen manglar mina UTF-filer eller mina ISO-filer beroende på vad jag för tillfället har för default (istället för att helt enkelt känna av vad filerna innehåller och anpassa sig automatiskt :( ) - Men *tanken* med UTF-8 är nog god - tror jag :P
Man behöver inte ha med BOMen.
"Gamla webbläsare" i det här fallet är nog NN2 och IE1 kanske... NN4 och IE4 har inga problem med UTF-8.
Om man en dag skulle få för sig att blanda in tex lite japanska och lite koreanska i samma dokument skulle vi antingen behöva "escapa" alla specialtecken eller ha två teckenuppsättningar till (vilket inte går). Så är inte fallet med UTF-8, då den teckenuppsättningen täcker alla språk.
Man kan ställa in DW för att använda UTF-8, och det finns många gratis texteditorer som klarar av UTF-8. :)
zcorpan skrev:
Man kan ställa in DW för att använda UTF-8, och det finns många gratis texteditorer som klarar av UTF-8. :)
Duuuuuhh - menar du verkligen det ? :bla
Det finns, som sagt baserat på praktisk erfarenhet, inga garantier för att det inte uppstår nya problem när man väljer att gå över till UTF-8 - så det finns IMHO ingen anledning att rutinmässigt gå över bara för "sakens skull" - eller för att en massa webbtyckare propagerar sig blåa för det...
Så jag håller med spango
jag kan inte påstå att jag ser någon direkt anledning till att välja UTF-8 framför ISO-8859-1 om man inte behöver (eller förväntar sig att komma behöva) kunna trycka in alla tänkbara tecken på sidan utan att koda dem med entiteter.
UTF-8 framför ISO-8859-1
Jag använder det sistnämnda - MEN - jag märker att på vissa sidor (svenska) blir det problem att läsa texten därför att defaultläget visar märken istället för å ä ö. Ser ganska "kryptiskt" ut...faktiskt.... :l
A minor note on ISO-8859-1. Do not use it if your site contains any form of user input or input from yourself or other people. Those users will be able to submit win-1252 encoded characters to your site and you no longer validate. You could choose to make win-1252 the default encoding. However, it would be much wiser to use UTF-8 instead.
Hmm..
Oavsett om man kodar sina webbsidor i ISO-8859-1 eller UTF-8 så bör man aldrig någonsin acceptera inmatat data från ett formulär på en webbsida utan att kontrollera dess format (inklusive teckenkodningen för alla tecken).
Orsaken är att ingenting någonsin kan garanteras i formatväg när data kommer inpostat, eftersom man aldrig vet att det verkligen kommer från det formulär man skickade ut - det kan lika gärna komma från något som "låtsas" vara ditt formulär i form av ett verktyg, en spindel, en robot eller en hacker som försöker testa eller kartlägga din webbplats...
Och - som sagt - Man står inför samma problem oavsett om man kodar sina webbsidor i ISO-8859-1, WIN-1252 eller UTF-8, så det där citatet från herr vanKesteren är inte heller något heltäckande argument för att ett byte till UTF-8 automagiskt skulle vara "bättre" om man redan använder något som fungerar :P
Har inte lyckats hitta en enda vettig anledning till att inte använda UTF-8. Citat från jarvklo:
"Det finns, som sagt baserat på praktisk erfarenhet, inga garantier för att det inte uppstår nya problem när man väljer att gå över till UTF-8 - så det finns IMHO ingen anledning att rutinmässigt gå över bara för "sakens skull" - eller för att en massa webbtyckare propagerar sig blåa för det..."
Jarvklo nämner att det kan uppstå problem men väljer att inte specificera sig i frågan.
Vad som verkar bra är ju att man kan använda alla tecken utan speciell kodning, tycker det verkar innebära mer frihet att inte behöva bry sig om att tecken visas felaktigt.
Vad som känns mer oroväckande torde kanske vara att äldre applikationer inte har stöd för BOM.
Ser inga problem med att min texteditor skulle "mangla" mina dokument. Jag kör bara på ett projekt åt gången och det verkar dessutom som Notepad känner av väldigt bra att det är UTF-8 som gäller eftersom jag har sparat dokumentet i det formatet sen innan. Det räcker då för mig att bara göra en ändring och välja "spara..." så sparas det i UTF-8. Vari ligger problemet? Vill ha mera specifika svar på varför UTF-8 kan tillfoga problem för slutanvändaren.
Jag tror inte att det tillfogar några problem, men det kan vara jobbigt att konvertera många redan existerande dokument sparade i iso-8859-1 till utf-8, speciellt när man inte har något egentligt behov av att göra det. :)
Ok :) Måste kolla upp UTF-8 lite mer vad det innebär. Hursomhelst så litar jag på dig.
Har förövrigt redan konverterat till UTF-8 och kommer fortsätta med UTF-8 sålänge jag inte upptäcker att det ger några problem att ta hänsyn till.
AndreasC skrev:
Jarvklo nämner att det kan uppstå problem men väljer att inte specificera sig i frågan.
Ledsen om jag var otydlig - men jag syftade på mina problem med att mitt nuvarande verktyg har samma problem som några andra jag testat - nämligen att det inte automatiskt klarar av att känna skillnad mellan ISO-8859-1 och UTF-8 när man redigerar filer utan att man manuellt måste komma ihåg att ändra teckenkodning för att inte mangla t.ex. åäö i ledtexter osv (jag kör uteslutande mallbaserad webbpublicering, dvs jag redigerar sällan annat än dokument med blandad kod och ledtexter som representerar delar av olika webbsidor - vilket säkerligen bidrar till de problem jag har med mina verktyg)
Vari ligger problemet? Vill ha mera specifika svar på varför UTF-8 kan tillfoga problem för slutanvändaren.
Hmm..
Är du medveten om de potentiella problem som diskuterats i tråden, tror jag personligen inte du behöver oroa dig. Mitt "sprattlande" har mest berott på att jag velat belysa att man inte garanterat och automatiskt får allt att fungera bara för att man går över till UTF-8 och att det IMHO alltså varken finns något egenvärde i att "gå över" eller i att låta bli - bara man vet vad en ev. övergång innebär ;)
UTF-8 är IMHO helt enkelt inte någon lösning som automatiskt är att föredra över någon annan - men därmed är det inte heller sagt att det skulle vara något "dåligt" med att använda UTF-, eller att UTF-8 är "sämre" än något annat...
PEACE :birp
