system.log

SWFObject är den absolut enklaste, säkraste, kompatibla och tillgängliga lösningen.

Använd SWFObject i stället: http://blog.deconcept.com/swfobject/

Det finns ett par spöken i koden:

1. Ingen DOCTYPE.
2. Vad gör font-elementet där? Du har ju någorlunda semantisk kod i övrigt, och sen kommer <font class="rightblackboxheader"> i stället för till exempel h3.

Utseendet gillar jag :-).

Håller med Merovech om att DOM Scripting och The JavaScript Anthology är mycket bra. Jag har inte läst dem än, men jag blir förvånad om inte Beginning JavaScript (with DOM Scripting and AJAX) av Chris Heilmann och ppk on JavaScript av Peter-Paul Koch också är riktigt bra.

Instämmer. Ska man ha en enda bok som nybörjare är det den. Och det säger jag inte bara för att Ian är en himla trevlig kille :-).

Ja. Jag inser att det är meningslöst att fortsätta diskutera tabellfrågan... :eek:

Som sagt tror jag fortfarande att en bakgrundsbild är den bästa lösningen på ditt problem. Det kommer att fungera problemfritt med den enkla layout du har.

Det jag tänker på är det här: Problems with the Equal Height Columns method. Eftersom det är just "equal height columns" du är ute efter kanske det påverkar.

Då föreslår jag att du läser på lite mer. Det du säger är typiska motargument från personer som inte har lärt sig hantera CSS fullt ut. Det är faktiskt tvärtom, att genom att använda tabeller för layout blir man helt fastlåst i den layout man har byggt in i sin HTML-struktur.

1. Data som är logiskt strukturerad i rader och kolumner, med förklarande rad- och/eller kolumnöverskrifter.
2. Det är mer relevant att ta en titt i rekommendationen för HTML 4.01: "Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.".

Faux columns är både enklare att implementera och stabilare än One True Layout. Billigt med bakgrundsbild? Tja, kanske. Men inte lika billigt som att fuska med en tabell ;).

Det beror alldeles på vad du menar med "förträffligt". Om du vill pina besökare med skärmläsare till att lyssna på "table with seven columns and twelve rows" och så vidare, fine. Samma sak om du vill bygga en webbplats som går emot de råd som ges av alla tillgänglighetsriktlinjer, inklusive WCAG och Vägledningen 24-timmarswebben.

I verkliga livet går det alldeles utmärkt att bygga stora, avancerade och grafiskt tilltalade webbplatser helt och hållet utan tabeller för layout. Det handlar bara om att ha kunskaperna.

Om det är betoning man menar och inte fetstil, ja. Det betyder också att man använder tabeller för att märka upp tabulär data, inte för layout.

Jag är ledsen att göra dig besviken, men det är det inte.

För att återgå till ämnet. Vad menar du med att faux columns-tekniken inte skalas om du förstorar texten? Menar du att spaltindelningen hamnar snett eftersom hela bredden är satt med em? Något annat? Kika på Creating Liquid Faux Columns och se om inte det löser problemet.

En annan teknik du kan ta en titt på är One True Layout.

Ja, det stämmer att det är bara när man använder application/xhtml+xml det gäller. Men varför inte göra helt rätt när man ändå håller på? Om man använder numeriska teckenkoder fungerar det garanterat, både i HTML och XHTML.

Fast det allra bästa är förstås att få ordning på teckenkodningen som verkar bli ändrad någonstans på vägen. Det kan tyvärr vara riktigt snurrigt i TextMate som gärna byter teckenkodning från ISO-8859-1 till UTF-8 utan att säga till om det.

Du ska inte behöva konvertera åäö vare sig du använder ISO-8859-1 eller UTF-8.

Kan vara bra också att känna till att i XHTML finns ingen garanti för att named entities (ä och så vidare) fungerar. De enda som garanterat stöds är <, >, &, &apos; och ".

Fast det blir bättre så här (om du absolut måste öppna ett nytt fönster):

<a href="index.php" onclick="window.open('index.php', '_blank', 'width=600,height=600');return false;">villkoren</a>

Ännu bättre att flytta all JavaScript till en extern fil, men det kanske är överkurs.

Kollade lite snabbt på några sajter jag har byggt, och den enda lilla skillnad jag kan se (något bredare bokstäver i IE/Win än i Safari) gissar jag beror på olika sorters kantutjämning. Bokstäverna i sig är lika höga och radavståndet är samma.

Om du ser större skillnader kan det vara så att det beror på olika avrundningsmetoder i webbläsare. Hamnar den uträknade storleken mellan två pixelstorlekar kan det slå uppåt eller nedåt beroende på hur man har angett storleken (% + em). Det finns massor att läsa om det i Sane CSS sizes.

Att det ser ut som det gör, det vill säga att en del sajter inte fungerar, beror på att en stor del av de som bygger webbplatser är fullständigt inkompetenta. Det finns ingen annan förklaring. Att det skulle kosta mer att göra rätt är bara undanflykter - det handlar om att kunna sitt jobb och göra rätt från början.

Det finns en poäng i att mycket innehåll kommer från gamla system som sprutar ur sig HTML-liknande sörja, och det kan självklart försvåra. Men den grundliggande orsaken är att fel personer ges i uppgift att sköta gränssnittsprogrammeringen.

SpeedAbuser: Skillnad i textstorlek mellan operativsystem? Kan du möjligen ha använt pt som enhet? Det låter otroligt märkligt annars. Om du inte gått in och mätt med lupp förstås ;-).