Jag har läst det nånstans, men kan inte riktigt förstå varför i så fall. Skulle W3C ha ett finger med i spelet?
Utskriftsvy
Jag har läst det nånstans, men kan inte riktigt förstå varför i så fall. Skulle W3C ha ett finger med i spelet?
Den rankar möjligen bättre på indirekta grunder. Logisk markup, och god separation gör att robotar och människor läser innehållet bättre. W3c har inget med saken att göra, i alla fall inte på det vis du nog avser här.Citat:
Ursprungligen postat av Frisse
Svaret är direkt nej. Om man jämför en optimalt optimerad sida med tabeller och en med div och samma innehåll så är det ingen skillnad. Det är bara struntprat från w3c elitister (som så mycket annat rörande fördelarna med css-p).
Finns även teorier gällande kod och innehåll "ratio". Dvs att man skall ha så lite kod som möjligt förhållande till innehållet. Om det stämmer eller ger några fördelar är dock svårt att säga.
Då det gäller "code to content ratio" så är det inga problem med tabeller så länge som man inte fastnar i layouter med massvis av nestade (skriver man nästade???) tabeller.
Jag har sett siter med tabell layout som fastnat i "filtret för liknande sidor", som verkar vara den lägsta graden av duplicate content, pga att alldeles för mycket kod var exakt likada på varje sida (de 30 000 första tecknena!), med undantag för title. Detta löstes genom att se till att varje sida hade helt unik meta keywords och meta description tag. Så man måste inte skippa tabelllayouten av denna anledning.
Dock är det en bra förutsättning för tillgänglighetsanpassning om man arbetar med div och css layout. Dessutom är tabeller inte menade att använda för layout. Och sist men inte minst är det enklare att skapa innehåll som fungerar i flera olika plattformar (alltså för mobil surfning mm mm..)
Själv började jag med div och css layout för snart 3 år sedan, och jag har inte ångrat det en enda sekund.
Väldigt intressant fråga! INga andra SEO-proffs som har något att säga om den saken??
Jag kan tänka mig att man har en ytterst marginell föredel med css mot tabeller.
Men varför då inte använda den fördelen, få snyggare kod och snabbare webbsidor utan onödiga ettor och nollor som skickas med.
CSS ja tack.
Skälet till att jag frågar är att jag en gång i tiden gjorde en site med tabell-layout och att den numera är på cirka 700 sidor. Den är gjord i Dreamweaver och alla sidorna är kopplade till en template.
Är det verkligen värt besväret att göra om hela siten :o ?
Det är vid dessa tillfällen det gäller att ha gjort jobbet rätt från början med hur man kopplar samman sidorna. varje enskild sida jag gör idag har bara sidans text och optimering i filen. Resten ligger i designen som går att ändra på 1 sekund.
Men krävs det mycket jobb skulle jag nog inte byta i ditt fall Frisse
Instämmer med per_r där. Ingen skillnad. Tar man sig tid och tittar på filstorleken och jämför mellan en tabellsida och en utan, kommer man se att den är mycket marginell. Näst intill försumbar. Samma mängd text i båda alternativen.
Sedan ang W3C så går det bra att använda tabeller för design, om man nu vill göra det, det är inte deras förslag på det som skall användas först men det står nämnt som ett alternativ.
Så ser ingen anledning för dig att bygga om 700 sidor.
Ok, tack. Det var det jag ville höra :D
Tänk på att sidor med CSS-layout brukar ha bättre användning av H1,H2,P osv. Jag gissar att i ditt fall så är detta dåligt. Med CSS-layout kan du dessutom styra vilken information som ska komma tidigt i källkoden. Detta är mycket krångligare att göra med tabeller och ofta behöver man trixa sig fram utan garanti på att det faktiskt går.
Jag var förut av åsikten att Code2Text-ratio var av betydelse, och är det lite fortfarande. Fast jag tror också att det beror just på följdeffekterna av hur man använder HTML-taggar när man går över till DIV.
Tyvärr används ofta CSS endast i det visuella syftet. Man använder t.ex "<div class='header1'>Header</div>" (dåligt) istället för "<h1>Header</h1>" och sen sätta global eller områdesformatering på H1. Gör man på det dåliga sättet så tappar man mycket.
Jag tror att du kommer tjäna på att göra om din sajt.
Finns idag många fördelar med html/css-desgin över en html/tabell-design som jag ser det.
1. Första tumregel vad jag förstått för en person som jobbar med SEO är att att viktigaste sakerna ska komma så tidigt som möjligt. Via html/css så kan man jobba med absolut-positionering och få h1-taggen att bli det första läses efter några få div-taggar. Och sedan då följa den med text, meny och sist alla bilder. En bra html/css som man tar bort css:en för blir en vit sida med ett långt snyggt textstycke med huvudrubrik, underrubriker och brödtext som alltså är det som sökmotorerna läser.
2. En tabell-design är svårare att underhålla vilket man märkte av problemet med 700 sidor.
3. Man kan via html/css återskapa mycket av vad många idag använder java-menyer till. Alltså att få grafiska fält att flyta fram och massa fina grejer som många sökmotorer har svårt att läsa länkar ur. Detta går dock att implementera i en tabell-design också så är inget negativt mot en sådan.
Däremot att göra om alla 700 sidorna verkar väldigt otympligt men jag skulle rekommendera det, om du är duktig på att koda och kan göra en spindel som spindlar ut länkstrukturen och innehållet och bygger dina rena upptaggade html-sidor åt dig. Något som säkerliggen inte är lätt men som nog inte tar lika lång tid som att göra om alla 700 sidorna från början. Om du fixar detta så kan du iaf känna dig stolt ;) , det hade jag gjort iaf.
Mycket av arbete med att göra store befintliga siter optimerade måste ju vara att man automatiserar arbetet med olika robotar/script som gör jobbet åt en och bara ger dig kontrollen ifall de får problem.
Nu är det ju inte så att han väljer mellan css och tabeller, utan mellan div-taggar (float, alt abosolute position) och tabeller. Detta är en konst i sig och vissa fall inte alls rekommenderat. Tabellernas element kan också ha stylesheet, detta är inget unikt för div-taggar.Citat:
Ursprungligen postat av Feldon
För att kommentera på dina punkter:
1. Jag har läst om samma saker som du, men jag tror de har en obetydlig påverkan. Det skadar inte att placera headern med absolute-position och lägga den i slutet av koden men lägg inte själva innehållet som absolute-position. De flesta använder fortfarande IE6 och en "bugg" i IE6 gör det omöjligt att markera texten om den är placerad med aboslute-position och väldigt många föredrar det när de läser en text för att lättare kunna följa med.
2. Varför skulle en tabell-design vara svårare att underhålla än en som är byggd på div-taggar?
3. Han har inte sagt att han inte använder CSS, Men jag antar att du missförstått detta :)
Själv blandar jag table/div när jag "utvecklar". Detta är väl främst för att jag tycker det är bökigt och ibland omöjligt att få en div-layout att se likadan ut i alla webbläsare.
Mitt tips är att jobba för att få innehållet så högt upp som möjligt i källkoden och unvik så mycket onödig källkod som du kan. Sträva alltid efter detta men känn dig inte tvingad att använda div-layout på grund av det.
Edit: Lite korrigeringar
För att förändringar i tabellbaserade layouter är mer komplexa att hantera, speciellt på större siter, än en struktur som helt separerats från presentationen.. se csszengarden för överväldigande exepel på vad jag menar.Citat:
Ursprungligen postat av FredrikMH
Ja i en tabellbaserad-layout räcker det inte att ändra i css för att få så radikala ändringar men jag har aldrig varit med om att det medfört ett problem. Jobbar man inte med templates så ser jag poängen med detta men i annat fall ser jag bara att man får presentationen samlad. Men jag köper det.Citat:
Ursprungligen postat av Björn
Detta är inget påhopp men: Det beror snarare på att du inte är tillräckligt duktig. Det är minst lika svårt att få sidor exakt likadana med TABLE (med eller utan css).Citat:
Ursprungligen postat av FredrikMH
Jag testar alltid med www. browsercam.com och det om något är ett ultimat sätt att testa på och jag har hittills aldrig stött på något som varit omöjligt. Jag tror att det är snarare de grundläggade begränsingarna i TABLE som man har i åtanke och därför inte ens försöker något experimentellt.
Sen är det faktiskt så att t.ex. <SPAN> och <P> kan bete sig annorlunda även om de har identiska CSS-attribut (och då menar jag att ALLA attribut är definierade). Detta gör att något som verkar "omöjligt" blir enkelt om man byter HTML-tag. Detta sista beror på webbläsarnas ibland dåliga stöd för CSS.
Vad gäller göra om 700 sidor så stämmer det nog inte riktigt. Det mesta går att göra med Search and Replace.
Hmm ser att Björn redan svarat på vad jag menade :)
Vad gäller table så är det min personliga åsikt att det är väldigt svårt att hålla tungan rätt i munnen när man nästlar och har colspans och rowspans att hålla reda på, utöver alla avstånd etc.
Och det dåliga stödet för css så är det väl bara IE som idag inte har bra stöd för det och de flesta som jobbar med css:er har idag en uppsättning IE-bugg-lösningar för att komma runt i stort sett alla buggar för IE. Ofta bygger man en IE-css och en css för alla andra.
Att ha en css per läsare är ett steg från browsersniffning imo.Citat:
Ursprungligen postat av Feldon
Hur kan du påstå att det är min kunskap som brister när du inte hört mig argumentera?Citat:
Ursprungligen postat av Marcin
Jag kan ett väldigt vanligt scenario där man vill att en div-tagg ska agera precis som en tabell gör men det misslyckas. Har du någon gång surfat in på en Wordpressblogg och funnit sidebar under/efter alla posts?
Du har två kolumner gjora av div-taggar och är placerad innuti en annan div-tagg med fast bredd och centrerad mitt på skärmen. Låt säga 768px vilket är optimalt för 800x600. Dessa två div-taggar har alltså 768pixlar att dela på och vi säger att den högra är en sidebar på 150 pixlar. den andra får vara övrig bredd vilket är 618px.
Om nu innehållet skulle bli bredare än 618 pixlar i den vänstra, hur får du båda divtaggarna att ligga bredvid varandra? Det var ett tag sedan jag undersökte det men ingen hade en bra lösning på det när jag undersökte det och jag har själv aldrig funnit en lösning.
Du definierar hur du vill hantera overflow i css:en. I det här fallet skulle jag välja att ha den på auto så div:en får en scrollbar. Går även att ställa in så denna alltid finns så man slipper att den "hoppar" fram.Citat:
Ursprungligen postat av FredrikMH
Man kan också ange att ord måste brytas om de är för långa.Citat:
Ursprungligen postat av Feldon
Men visst, det finns fall då grejjer hoppar omkring. Å andra sidan så handlar det om att de beter sig annorlunda än en tabell.
Jag tolkade dig som att det generellt är svårare att få till det med CSS.Citat:
Ursprungligen postat av FredrikMH
Måste säga att diskussionen spårat ur, frågan var om det rankar bättre att använda en div-design än en tabell-design och svaret är att skillnaden är troligen marginellt till fördel för en div-site och utöver att den rankar marginellt bättre är den lättare att underhålla.
Och ytterliggare en grej OT så går det att göra en flödande design med css. Alltså en design anpassad efter hur stor upplösning som besökare har och då använda sig av relativa avstånd etc. Använder man dessutom .svg formatet på sina bilder kan man nog åstadkomma väldigt vackra sidor (har inte testat svg speciellt mycket själv än men så här långt är jag imponerad).
Inte denna lösning som jag beskriver. Du ska få den yttre div-taggen att ge vika och göra sig större istället för att lägga scrollbars eller tvinga ner den högra div-taggen under den andra.Citat:
Ursprungligen postat av Feldon
Jag kan få en design att se precis ut som jag vill genom att inte använda en enda tabell men om jag inte har inflytande på innehållet vilket skulle kunna tvinga utrymmet det befinner sig i att göra sig större så förstörs allting och designen ser inte längre ut som det är tänkt. En tabell kan aldrig tvinga ner en kolumn på nästan rad då hela tabellen är ett element i sig, precis som en bild eller en enskild div-tagg.
Det finns lösningar på problemet men IE6 klarar det inte och då anser inte jag att det är en lösning. CSS är bra men det måste finnas ett bättre stöd. IE7 är väl en liten bit på rätt väg i alla fall.
Jag har hört att CSS-sidor ger mer betalande adsense annonser än annonser på tabell-sidor. Lite ifrån ämnet jag vet, men har ni hört nåt liknande?
Vad man ser skillnad på är ju den tidigare nämda semantic mark-up som helt enkelt strukturerar hela sidan innehåll och gör det enklare för sökmotorerna att förstå värdet mellan olika element. Så är det ju kanske inte tänkt för att hjälpa SEO men att se till så att exemplevis folk med nedsatt syn och som måste använda sig av screen readers för att få materialet uppläst. Absolut inget med SEO att göra men jag tycker mig se att det hänger ihop och jag ser ingen anledning att hålla sig fast i gammal teknik från 90 talet om det inte heller hjälper eller gör någon skillnad.
Min åsikt är att det hjälper för informationsstrukturen i sidan och därmed förenklar för sökmotorerna att se vad som är intressant.
semantic markup menas att man kodar sidorna och elementen för det koderna är avsatta för, h1 alltid första titlen, p alltid paragrafer för bröd text etc etc...
Precis som Spagetti säger fast jag vill tillägga just en sak gällande den lilla egenheten att div-sidor betalar sig bättre.
Med en div-sida så kan man utan manipulera Google's kod lägga deras annonser på ett sätt att man döljer faktumet att det är Google-annonser. Det är väldigt black hat men är nog ytterligare en anledning till att statistiken ser ut som den gör.
Feldon, äntligen är vi överens om något. hehe kul
intressant och jag har ju faktiskt testat det men inte lyckats få till det riktigt... är der margin-top:-1em; som fungerar... jag har inte lyckats trixa till det
Hehe ja ibland så :p
Jag har inte testat ens.
Men jag skulle föra en div med adsense i som jag placerar i en annan div och sedan gör jag den div som annons-diven ligger i mindre än annonsen och sedan positionerar jag annons-diven så att man bara får upp länkarna.
Typ...
Det här kanske inte har så mycket med tråden att göra eller möjligen är den väldigt intressant för kärnan i konceptet.
Mitt intryck är ju att åtminstone för allt annat än *långa* artiklar så är Google:s analys av materialet i hög utsträckning ändmålsänlig men inte särskilt avancerad. Jag föredrar t.ex. där att inte arbeta med h2 rubriker utan strong och menar att det ger mätbart mer i värde.
Så standarder o.s.v. Jag vet inte hur viktigt det är. Wordpress.com däremot är ju en elegant & troligen mycket värdefull källa för länkar för Google. Där liksom många andra fria bloggtjänster är rubriker strong.
Jag har suttit och tragglat html med tabeller sedan 1996 men gått över till xhtml 1.0 strict på allting jag producerar och det finns inget mer oslagbart fenomenalt än dessa underbara divar och anrda element. man kan i princip göra hur man vill.
Fördelen med just div och xhtml är att man styr allting med css, minskar storkelen på sidorna med upp till 80%, delar upp layout och information, skapar korrekta dokument med hänsyn till w3c samt till 90% styr hela sidans layout med just css.
Jag frågar mig fortfarande varför jag inte startade tidigare att slänga tabellerna i soppåsen. Tabeller är endast til lför Tabel Data, typ prislistor etc...
för att använda sig av xhtml och div måste man förstå hur det fungerar.
float:left;
display:inline;
ja det finns ju massor av prefekta verktyg för det som även tilltalar SEO när man lägger flash och SEO Bakom för att understödja en flash site.
Jag jämförde faktiskt lite med google accessible search med den vanliga för något år sedan och då gjorde xhtml siterna stor skillnad mot tabell sidorna i ranking på samma sök.
Till slut, nej siten kanske inte rankar bättre idag men google kommer kanske ändra sig och bara göra acccessible search tillgänglig, då vet vi vem som biter sig i skägget!
Är ni osäkra på xhtml ska ni definitivt besöka 456bereastreet.com
Michael
Jag kanske har det svårare, men dock lär mig mer, genom att få all design levererd till mig och jag fårr helt enkelt lösa layout problemet. det är vikigt för att ligga högt i kunskap med.Citat:
Ursprungligen postat av Feldon
Vad gäller bugg fix så låter tycker jag personligen inte att man ska försöka fuska med sånt. skapa designen för alla standardiseringar och gör det enklare för dig själv. det sägs att vi webbskapare egentligen aka ta hänyn till 11 standrad browers för att täcka alla typer av användare inkl, MAC och det går ju ganska bra om man följer standarder och gör som man ska.
Jag håller mig endast till xhtml 1.0 strict som fungerar utmärkt på mina siter.
Michael
Öppna samma siter i explorer 5 och 6 så kanske du märker vad jag syftar på (och inte att förglömma att större delen av alla användare använder fortfarande 6:an men rätt många kvar på 5:an och få som har gått över till 7:an). Ingen av dem ritar upp saker på samma sätt som övriga webbläsare och de har andra default-värden vilket gör att även något som validerar som en bra css/xhtml sida inte visas som det är tänkt. 7:an däremot verkar ha de flesta saker lösta, men det kvarstår några defaultvärden som är hej kom och hjälp mig framför allt bland margins och paddings som inte börjar på 0 vilket är irriterande.Citat:
Ursprungligen postat av spagetti
För att komma runt sådant så måste man ibland utnyttja små buggar i de webbläsarna som tvingar dem att göra som man vill.
Övriga webbläsare är nästan alla enhetliga och följer standard eller åtminstone så beter de sig som om de gjorde det.
En sak som kan underlätta är att "avformattera" hela default-rubbet med t ex: Eric Meyers CSS reset. Det blir desto mer att formattera själv, men ett säkrare slutresutat.
detdär verkade ju bra men det är väl konstigt att man ska nollställa alla värden innan man börjar göra siterna..
jag brukar bara köra med * margin:0; padding:0; och sedan får det vara bra.
Michael