Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Mellanrum i horisontell CSS-meny

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

Jag har gjort en horisontell meny. Varje menyelement är en css-box och har borders runt sig, och de ska hamna sida vid sida ungefär som elementen i navbaren här på 99:an (den med "Startsida, Forum, Dagens Diskussioner" osv).

Tyvärr vägrar boxarna att hamna sida vid sida i Firefox. Det blir några pixlars horisontellt mellanrum mellan varje box. Det funkar dock i IE6. Jag förstår inte var mellanrummen kommer ifrån, det är inte margins eller padding. Hjälp!

Här är ett minimalt exempel:

<html><head>
<style>
  #horzmenu {
    margin: 0px;
    padding: 0px;
  }
  #horzmenu ul {
    list-style-type: none;
  }
  #horzmenu ul li {
    border-style: solid;
    border-width: 1px;
    display: inline;
  }
</style>
</head>

<body>
  <div id="horzmenu">
    <ul>
      <li><a>Foo</a></li>
      <li><a>Bar</a></li>
      <li><a>Baz</a></li>
    </ul>
  </div>

</body></html>
Senast redigerat 2007-11-09 01:48

Funkar det i IE6 är det förmodligen fel någonstans, det är iallafall vad jag brukar utgå från.

Testa att byta ut display: inline till float: left istället - det ser rätt ut i Subethaedits webbpreview (Safari/Webkit) iallafall.

Pröva med att nolla margin & padding på #horzmenu ul li med.

Du behöver inte listan - du skapar dig dessutom dubbelt arbete eftersom du först måste ta bort listans egenskaper, effektivt göra om listan till motsvarande div:ar. Du behöver dock inte div:ar heller, du har ju a-element, och de duger gott som containers i sig själv. Jag har gjort detta många gånger, därför ska jag upplysa dig om en IE-bugg (troligen bara IE6, har inte testat detta i 7:an) som kan vara bra att veta när man stylar a-element. Om du hamnar i det läget där du t ex vill skifta bakgrundsbild (och kanske bakgrundsfärg, minns inte nu) vid hover så kommer det inte att funka om du gör detta via a-elementets ID. Gör det via inheritance selectors (som du gjort ovan) eller via class. En annan sak som kan vara bra att veta när du skissar, a-elementet beter sig olika i IE m fl om det saknar href, så sätt alltid in href (t ex <a href="#">foo</a>) redan när du skissar (Det är inte så konstigt egentligen eftersom <a name/> är ett ankare medans <a href></a> är en länk.)

ps- jag klistrar strax in lite kod

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict...">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style>
#horzmenu{padding:1px;}
#horzmenu a {
border:1px solid black;
}
#horzmenu a:hover {
border:1px solid red;
}
</style>
</head>

<body>

<div id="horzmenu">
<a href="#">Foo</a><a href="#">Bar</a><a href="#">Baz</a>
</div>

</body></html>

Satte doctype direkt - webbläsare renderar lite olika beroende på doctype.
Mellanrummen beror på mellanslag mellan a element (!).

(Det är faktiskt som det ska - vad webbläsaren anbelangar så är texten i ett a-element lika mycket text som löpande text i ett p-element, och så måste det vara, annars skulle länkar i en löpande text sakna mellanrum till omkringliggande ord.)

Jag fick sätta padding på div:en - annars visade inte IE all border. Om du inte använder border, eller om du löser det på annat sätt, så behövs ju inte det.

Du måste hålla med om att detta är ett superenkelt sätt att styla en meny..

Ps - för att visa vald sida finns ett enkelt sätt i detta sammanhang - byt ut en a-länk mot en span och styla den på samma sätt, t ex:

#horzmenu span {border:1px solid green;}

<a href="#">foo</a><span>bar</span><a href="#">baz</a>

Tackar!

Ninjamac: Jäpp, ser bra ut. Anledningen till att jag vill ha en bortstylad lista är för att det ska bli en vanlig 'bulleted' lista om CSS inte är tillgängligt. Är det rätt tänkt?

Tänkte helt och hållet inte alls på det där med <a>, men det är ju rätt självklart nu när du säger det

css inte tillgängligt?? Eller menar du på mobiltelefoner och enklare handhelds? Eller html mail?

Accessibility-folk brukar tycka att man ska använda listor för sånt som menyer och navigation, dels för att de går att hoppa över i screenreaders, dels för att det är mer semantiskt korrekt. (Det är ju en lista med länkar, inte vilka div-ar som helst efter varandra. Se tex <nav> i HTML5 som är tänkt att vara en ersättare.)

Men i praktiken är det oftast enklare att använda <div> istället för listelement.

Jag gillar för all del listelementen och jag förstår den semantiska aspekten. Man kan ju för all del använda listelement och nollställa dess specifika egenskaper - fast det blir ju inte lika slickt rent kodmässigt i och med att du har fler containers. Dessutom kan jag se ett annat argument för a-elementen: Man kan nog anta att alla screenreaders är programmerade att betrakta en lista med a-element (med eller utan andra omgivande taggar) som en meny av något slag, med tanke på att detta är den enda gemensamma semantiskt signifikativa signalen för en meny för majoriteten av webbsidor på nätet.

Personligen har jag velat se en annan XHTML-utveckling med mindre standardisering och mycket mer möjligheter för egna deklarationer. Jag har vid tillfälle byggt en liten språkprototyp via transformations. Peronligen skulle vilja definiera en meny ungefär så här:

head
define{
menu: semantic navigation list;
link: semantic navigation list item, data navigation location;
link target: logic navigation target;
}

body
<menu>
<link(news.html)>news</link>
<link(http://google.com/) target(new)>google</link>
</menu>

Gjorde en liten transformation decoder till ovanstående typ av kod (som en del av ett templatesystem-bygge). Vad jag inte grävt i är hur nära man kan komma detta via vanlig XML.

Man skulle kunna säga att det här var liiiitee OT...

Hehe.. såg det nu, så HTML5 propositionen publicerades alltså igår?

Grymt!

HTML5 har varit ute som draft ganska länge. Det jag länkade till är ett arbetsdokument så de uppdaterar lite då och då. Hade själv missat att det var så färskt.

Och precis, listor med <a> är precis sånt som screenreaders kan hoppa över. Sen finns det massa andra trix med interna länkar, accesskeys och sånt man ska tänka på om man ska vara helt tillgänglig.

Jag gillar tanken, men i praktiken så tycker jag det blir ganska grottigt med listor, eftersom man precis som du säger måste nollställa massa saker i CSS för att få dem att bete sig som man vill.

<nav>, äntligen, rätt tänkt imho. Gamla HTML skapades ju aldrig för den moderna webben.

Sidan jag gör är av "myndighetskaraktär" (whatever that means!) och ska därför vara så tillgänglig som möjligt. Jag siktar på åtminstone de fem största läsarna samt IE5 och Lynx. Sen vet jag att många universitet tvingar sina stackars doktorander att köra uråldriga SUN-system med mongoversioner av Netscape; skulle vara kul att få med dem också.

F.ö. har jag själv nästan alltid färg avstängt i Firefox; tycker att det är skitjobbigt med massa flashig design på siter - jag vill ha innehållet snabbt och enkelt, med svart bakgrund och grön text. Det enklaste sättet att göra det i Firefox stänger också av bakgrundsbilder och lite annat CSS. Detta har fått mig att tänka på tillgänglighet mer och mer. Det finns ju säkert någon annan stackare som har CSS avstängt för att han inte gillar det.

Ursprungligen av Imported Johannes:

Sidan jag gör är av "myndighetskaraktär" (whatever that means!) och ska därför vara så tillgänglig som möjligt. Jag siktar på åtminstone de fem största läsarna samt IE5 och Lynx. Sen vet jag att många universitet tvingar sina stackars doktorander att köra uråldriga SUN-system med mongoversioner av Netscape; skulle vara kul att få med dem också.

Tillgänglighet behöver inte nödvändigtvis betyda att det ser likadant ut i alla läsare, men det är du kanske redan med på? Jag skulle säga att det är viktigare att det funka bra i textbrowsers än att designen ser rätt ut i IE5 och liknande uråldriga browsers. Använder man en screenreader har man inte mycket till val, men att använda IE5 är förmodligen ett aktivt beslut (eller bara lathet). Men visst, det är högre krav om det är "myndighetskaraktär" på sidan. (Men använder iallafall inte Sun-slavarna Firefox vid det här laget?) Det finns ju också en del bra metoder att bara servera viss CSS till specifika IE-versioner.

Men ta och installera Google Analytics eller någon annan lösning för att ta reda på vilka browsers som faktiskt används - jag tycker inte det är någon mening med att anpassa efter versioner som ingen använder. Och man gör sig själv och användarna en björntjänst om man tex gör layouten med tables istället för bra HTML/CSS eftersom det i sig ger sämre tillgänglighet.

Ursprungligen av false messiah:

Tillgänglighet behöver inte nödvändigtvis betyda att det ser likadant ut i alla läsare, men det är du kanske redan med på? Jag skulle säga att det är viktigare att det funka bra i textbrowsers än att designen ser rätt ut i IE5

Absolut. Det är dock trevligt om det ser bra ut i alla läsare. Pixelperfekt likadant spelar inte så stor roll.

Ursprungligen av false messiah:

men att använda IE5 är förmodligen ett aktivt beslut (eller bara lathet)

Beslutet eller latheten ligger ofta hos systemadministratören (som själv bara kör KDE såklart). Hjälper inte ett företag att det är någon annans fel.

Ursprungligen av false messiah:

Men ta och installera Google Analytics eller någon annan lösning för att ta reda på vilka browsers som faktiskt används - jag tycker inte det är någon mening med att anpassa efter versioner som ingen använder.

Nja. Om sidan inte går att använda i vissa webläsare lär ju personer som använder dessa inte gå in på sidan speciellt ofta och därför inte hamna i statistiken. Bättre isåfall att kolla listor över mest använda webläsare (och givetvis kombinera med serverloggarna).

Ursprungligen av false messiah:

Och man gör sig själv och användarna en björntjänst om man tex gör layouten med tables istället för bra HTML/CSS eftersom det i sig ger sämre tillgänglighet.

Jäpp, men för att återvända till pudelns kärna - min fråga var ju just om det verkligen finns något sätt att göra en lika bra layout med bara CSS som den jag gjort med 99% CSS och 1% <table> ?

Om man bara plockar bort <table>-taggarna så funkar min sida fortfarande, men det blir ganska ful. Problemet är väl att webläsare kommer att plocka bort sakerna mellan <table>-taggarna... Oh well...

Senast redigerat 2007-11-09 15:43
Ursprungligen av Imported Johannes:

Absolut. Det är dock trevligt om det ser bra ut i alla läsare. Pixelperfekt likadant spelar inte så stor roll.

Jag tänkte iofs på större fel än att det inte stämmer på pixeln när (som det ändå inte gör om man inte serverar PDF eller Flash), snarare att navigation och sånt halkar snett, att bilder inte floatar som de ska, osv.

Citat:

Beslutet eller latheten ligger ofta hos systemadministratören (som själv bara kör KDE såklart). Hjälper inte ett företag att det är någon annans fel.

IE5 är så gammal vid det här laget att jag personligen tycker att man kan avskriva den i praktiken (och jag kan inte tänka mig något företag som fortfarande använder IE5 som måste). Sidor i ren HTML+CSS går ju att använda, det är mest att layouten kan bli skum.

Citat:

Nja. Om sidan inte går att använda i vissa webläsare lär ju personer som använder dessa inte gå in på sidan speciellt ofta och därför inte hamna i statistiken. Bättre isåfall att kolla listor över mest använda webläsare (och givetvis kombinera med serverloggarna).

Visst, det är alltid problem med att mäta, men det ger ju någon slags data att utgå ifrån.

Citat:

Jäpp, men för att återvända till pudelns kärna - min fråga var ju just om det verkligen finns något sätt att göra en lika bra layout med bara CSS som den jag gjort med 99% CSS och 1% <table> ?

Om man bara plockar bort <table>-taggarna så funkar min sida fortfarande, men det blir ganska ful. Problemet är väl att webläsare kommer att plocka bort sakerna mellan <table>-taggarna... Oh well...

Det går förmodligen att få sidan snygg med CSS, men det går inte att jobba lika pixelnära som med tables. Och det kräver förmodligen en hel del hack och ful-CSS om du vill att det ska se likadant ut överallt (jag svär ofta över alla de slumpvis bortvalda delarna av CSS som IE6 inte har med, sånt som > gör många saker betydligt lättare). Det är alltid en avvägning mellan hur rätt man vill göra enligt "reglerna" och hur det funkar i praktiken.

Men du.. om man stänger av css för att man inte vill se designen - varför skulle du då koda så att de som har css avstängt ser den, designen alltså..

(nu vet jag ju att det inte var det du menade..)

Så skämt åsido - det kan ju vara idé med en server side switcher som kan leverera lite olika dokument (främst ett par css-flavours men kanske alternativa html också). Kodar man rent och strikt, vilket jag ju sett att du gör, så behövs switchern bara mycket undantagsvis, men att göra på det viset befriar ju en från allt för mycket legacy-hänsyn i utvecklingen (vilket typiskt tar massor av tid om man försöker göra allt-i-ett). När man sedan börjar bli klar med jobbet brukar det vara ganska lätt gjort att skapa ett par simpla versioner för mindre bemedlade webbläsare och screenreaders.

Tycker jag i alla fall. Numera. Det fanns en tid när jag alltid envisades med att jag skulle klara av att bygga allt-i-ett men jag insåg att det var alltför tidskrävande.

Jag kan vid det här laget i o f s många knep för att hantera bångstyriga läsare.. t ex ett bjuder jag på nu: Om du har gjort en XHTML1.0Strict som funkar fint i Firefox et al och så testar du den i Mac IE5 - layouten kaosar ur.. Mac IE5 förstår XHTML1.0Strict mycket bra, fast den förstår inte doctypen, så sätt Doctype till HTML4.01Transitional när du serverar till just den browsern så funkar det oftast finfint. Fast det visste du kanske redan.

Så bara fråga om du undrar över något sånt eller så.

Jo, har försökt hålla mig borta från server-side av maintenanceskäl samt att jag gärna ska kunna lämna över sidan till någon annan, och serverside känns mer kluddigt. Men det får nog bli det snart, ska ändå få sidorna inbakade i en template engine.

Börjar misstänka mig själv för att en stor del av motivationen är att det är ganska kul att försöka trixa ihop en korskompatibel sida som validerar, lite knep och knåp och hjärngympa

Tack för hjälpen!

När jag blir världsdiktator ska jag stänga av hela Internet i ett år och tvinga alla inblandade att jobba dygnet runt på standardiseringsarbetet.

De här senaste kommentarerna om att det inte skulle gå att göra en sida lika "perfekt" med css som med tables fattar jag inte alls.. Och nu tänker jag även på ganska gamla/smala läsare. Det finns vissa saker inom css som tolkas med viss variation, men position har ju inte alls de problemen (främst padding, ibland margin samt att man måste hålla tungan rätt i mun med floats - dessa saker går ju dock att lösa med välskriven css). Fulhack inom css går jag inte i närheten av, ändå tycker jag att jag har enormt mycket mindre problem med css än med "old-school-html". Tvärtom kan man ju få en del problem med tables när det gäller "pixel-perfekt"..

I vissa fall funkar tables bättre/enklare och det är ju just täta tabeller med många celler. När jag gör sånt med css är det lustigt nog firefox jag har mest problem med..

Överlag tolkas tables mycket mer lika av browsers, även av riktigt stenålders sådana. Inte alls samma myller av halvimplementerade delar av CSS och buggar man har en tendens att råka ut oftare än man tror.

Utgår man från CSS och vad som går att göra där så går det att göra väldigt mycket, men har man en färdig design man ska implementera så kan det vara betydligt snårigare, speciellt om det hänger på att saker ska vara x antal pixlar breda, att man ska ha in bilder osv. Då kan man sitta och slita sitt hår för att få saker och ting att funka, eller för att det funkar i alla browsers utom en.

Ta bara sånt som att ha spalter som alla är lika höga - en baggis med tabeller, men kräver en hel del hyss med CSS. Få olika element att börja på samma höjd, dito. Få divar att inte kollapsa i vissa omständigheter - småhack behövs (overflow: hidden osv). Och så vidare.

Att tables funkar bättre för tabeller är inte så konstigt, det är ju precis sånt de är till för.

1
Bevaka tråden