Le div sono meglio per tantissimi motivi (che il mio grafico conosce anche meglio di me ).

Per esempio "a parità di contenuti" come dici tu, la percentuale fra codice e testo, utilizzando div e css in modo opportuno propende decisamente a favore dei contenuti e questo aiuta il crowling e i tempi di scansione. Particolari da non sottovalutare.

Un sito con div & css può essere modificato graficamente senza troppi problemi, garden zen docet.

Se esistono degli standard (w3c) e dei tag deprecati, significa anche prima o poi i browser non interpreteranno più allo stesso modo le table, o meglio non le table utilizzate come struttura del sito.

....

Insomma ci sono davvero tanti motivi, questi sono i primi che mi vengono in mente.

Concordo in pieno il tuo pensiero, anche se purtroppo i browser non si comportano affatto allo stesso modo nei confronti di css. Si spera che prima o poi avremo dei comandi universali, che non ci facciano "bacare" nel controllare sempre la visualizzazione dei siti con firefox, opera, safari e le mille versioni del bad IE.

Ti dico, noi spesso per IE scriviamo un foglio di stile apposta

Anche io, si fa molto prima che smanettare per trovare lo stile che funziona con tutti i browser...

Le tabelle "table" non sono deprecate ma finalmente utilizzate per il loro scopo, e non per creare lastruttura di un sito; in questo c'entra la semantica dato che ne esiste una anche per un metalinguaggio come lo (x)html.
Se usi le tabelle le devi usarle solo per inserire in una pagina dei dati tabellari come ad esempio una tabella di voti, una pagella per capirsi o la classifica di calcio.
I motori di ricerca come Google sanno cos'è una tabella e si comportano di conseguenza, dato che non è detto che tra contenuto ed elementi del linguaggio ci sia più o meno differenza percentuale devono comunque discernere dal tipo di dato presentato.
Una tabella contenente immagini e link non necessariamente contiene una semantica errata, se ad esempio si tratta che so di dati anagrafici con la foto della persona rappresentata con un link ad una scheda riassuntiva (vedi ad esempio il factbook della CIA riguardo i dati delle nazioni di tutto il mondo) è semanticamente corretto inserirli in una tabella anche se a priori il codice prodotto propenderà per una percentuale maggiore di codice rispetto ai contenuti.
Quindi una tabella ci può stare, dipende dalla contesto e dalla semantica, in Google dicono che sanno distinguere i casi, io non saprei se questo dato è esatto ma nemmeno se sia del tutto errato, quindi nel dubbio mi attengo al codice.

m.

Bè, si, giusto, l'importante è usare una buona semantica nel codice... infatti io intendevo l'utilizzo di tabelle per la creazione della struttura del sito-layout.

@MarcoGrazia said:

Se usi le tabelle le devi usarle solo per inserire in una pagina dei dati tabellari come ad esempio una tabella di voti, una pagella per capirsi o la classifica di calcio.
I motori di ricerca come Google sanno cos'è una tabella e si comportano di conseguenza, dato che non è detto che tra contenuto ed elementi del linguaggio ci sia più o meno differenza percentuale devono comunque discernere dal tipo di dato presentato.

Sì, completamente daccordo.
Forse utilizzando le parole "deprecati" e "tabelle" in uno stesso contesto ho generato un po' di confusione, non era mia intenzione dire che sono un tag deprecato.

Ciao Antonico,

anche io sono decisamente a favore dei div e css per tantissimi motivi.

Inanzitutto la pulizia e semplicità nel codice, secondo me, favoriscono ed aiutano una migliore indicizzazione da parte del motore.

Non so dire con certezza se un sito con div si posizioni meglio... sopratutto, analizzando alcune serp dove ai primi posti vi sono siti obsoleti che però magari hanno una certa anzianità, un trust elevato ed una grande popolarità.

Sicuramente io per i miei nuovi progetti li sto usando e sto anche validando il codice ( magari la validazione W3C non ti aiuta a posizionare meglio un sito, ma è una garanzia sulla pulizia e la correttezza del tuo codice).

per i miei nuovi progetti li sto usando e sto anche validando il codice
Ciao Paco,
anche io sto utilizzando solo div e css esterno.... tra l'altro da qualche tempo si potrebbero anche non chiudere alcuni tag html, come <p><li><head><html>. Avete visto il codice delle pagine della privacy di google ad esempio?
Dicesi che in alcune pagine siu può risparmiare il 20% di dimensione e, quindi, aumentare la velocità di scancione del bot. (prima che questo influisca davvero nel posizionamento, secondo me, troppe altre cose devono essere fatte... poi dipende dai casi)

@antonico said:

Ciao Paco,
anche io sto utilizzando solo div e css esterno.... tra l'altro da qualche tempo si potrebbero anche non chiudere alcuni tag html, come <p><li><head><html>. Avete visto il codice delle pagine della privacy di google ad esempio?

No che non si può! Il fatto che in Google queste pagine sembrino più veloci a leggerle non è assolutamente certo, è solo un'affermazione estiva riportata da alcuni blog.
Diciamo ad esempio che l'home page di google è quanto di più lontano possa esistere da uno standard, non ha una doctype, anzi, ha qualcosa che proprio non comprendo a cosa serva se non pensando a quanto da te detto, copiarla sarebbe assurdo, Google è Google, vorrei vedere che non si indicizzassero semmai quella pagina è leggibile da molti user agent proprio in virtù della sua costruzione.
Ma le pagine interne sono altra cosa, in genere adottano xhtml strict e ne seguono lo standard.
Se vuoi fare come dici usa pure (x)html loose, è sempre una buona cosa seguire uno standard.

Dicesi che in alcune pagine siu può risparmiare il 20% di dimensione e, quindi, aumentare la velocità di scancione del bot. (prima che questo influisca davvero nel posizionamento, secondo me, troppe altre cose devono essere fatte... poi dipende dai casi)
Ovvio se togli elementi nel codice le pagine si accorciano, ma il 20% la vedo dura a meno che nella pagina non ci siano molti paragrafi, in genere però è meglio non esagerare con questi se no chi li legge gli ultimi?
Poi un BOT ci mette il tempo che vuole a leggere la pagina, ma chi gli mette fretta?

No che non si può! Il fatto che in Google queste pagine sembrino più veloci a leggerle non è assolutamente certo, è solo un'affermazione estiva riportata da alcuni blog.
Non penso sia un'affermazione estiva... credete davvero che gli ingegneri di google facciano le cose tanto per farle? Visti i risultati penserei proprio di no.
http://code.google.com/speed/articles/optimizing-html.html

Torno a ripetere, prima che nel posizionamento influisca la velocità di scansione del bot, troppe altre cose devono essere fatte.. e fondamentalmente non sono daccordo con la "non chiusura" dei tags.

Poi un BOT ci mette il tempo che vuole a leggere la pagina, ma chi gli mette fretta?

Il tempo è denaro, tanto denaro, specialmente per google che ha milioni di siti internet da scansionare e tenere in archivio.
Ipotesi ridicola: google dice che posizionerà meglio le pagine che hanno i tag <li><p> non chiusi perchè crede che il superfluo sia inutile. Cosa fai, rispetti le regole standard, o ti adatti per stare dietro a quel giochino che genera più dell'80% del traffico internet mondiale?

@antonico said:

Non penso sia un'affermazione estiva... credete davvero che gli ingegneri di google facciano le cose tanto per farle? Visti i risultati penserei proprio di no.
[link omesso so io perché ]

Torno a ripetere, prima che nel posizionamento influisca la velocità di scansione del bot, troppe altre cose devono essere fatte.. e fondamentalmente non sono d'accordo con la "non chiusura" dei tags.

Ho letto l'articolo di cui parlavi e allora non è proprio quello che ho letto io che si riferiva proprio a codice scritto male, secondo il quale Google lo indicizzerebbe meglio.
Quello che hai postato tu è sì interessante, ma si riferisce ad alcuni tag dell'HTML4 e infatti sotto il filmato c'è scritto chiaramente quali tag si possono omettere e a quali condizioni.

HTML - as opposed to XHTML, even when delivered with the MIME type text/html - allows authors to omit certain tags. According to the HTML 4 DTD, you can omit the following tags (tags of so-called "void" - empty - elements are marked as strikethrough):
*HTML - contrariamente a XHTML, anche se espresso con il tipo MIME text / html - consente agli autori di omettere alcuni tag. Secondo la DTD HTML 4, è possibile omettere i seguenti tag (gli elementi contrassegnati come barrato si possono omettere):*Quindi segue una lista di elementi di cui si possono o si devono, omettere i tag di chiusura.
Riporto per semplicità solo quelli da omettere e cioè: /area, /base, /br, /col, /hr, /img, /input, /link, /meta, /param.
Sono elementi che non hanno chiusura in HTML4, come riportato nella guida del W3C, qui tradotta in italiano: diodati.org/w3c/html401/struct/objects.html#edef-AREA dove si dice chiaramente che i marcatori AREA e MAP non vanno chiusi, e questo lo sapevamo, poi segue la lista, che non riporto più, di quegli elementi la cui chiusura è opzionale, come i paragrafi per esempio. Quella paginetta è pleonastica, dice cose che già sapevamo: alcuni tag si possono lasciare aperti ma solo e soltanto in HTML4, in XHTML i tag vanno sempre chiusi, in alternativa usa HTML5.

Il tempo è denaro, tanto denaro, specialmente per google che ha milioni di siti internet da scansionare e tenere in archivio.
A sì non c'è dubbio, ma quel video in pratica ci sta semplicemente dicendo che non dobbiamo usare XHTML ma addirittura HTML 4 e che meglio sarebbe usare HTML5 che è più breve. Io non aggiungo altro!
Prova a vedere cosa esce con il validatore HTML5 sul sito del W3C a proposito della pagina principale di Google.
html5.validator.nu/?doc= prova e vedrai che schifezza.

Ipotesi ridicola: google dice che posizionerà meglio le pagine che hanno i tag <li><p> non chiusi perchè crede che il superfluo sia inutile. Cosa fai, rispetti le regole standard, o ti adatti per stare dietro a quel giochino che genera più dell'80% del traffico internet mondiale?No, non dice affatto che si posizionerà meglio, dice solo, e non è poco, che potresti risparmiare anche il 20% nella dimensione dei tuoi file e che gli utenti troveranno più facilmente ciò che cercano nel tuo sito, in pratica ti hanno già trovato, solo che cercano qualcosa all'interno del tuo sito, il chen on è cosa da poco, ma è ben lontano dal discorso dell'indicizzazione.
Inoltre parla di codice più pulito

If you combine all these methods together you should be able to save 10-20% in file size (and even more markup), depending on your coding style and the amount of text content in your pages. Your code will look much cleaner, and your site's visitors will get to your content faster. We applied many of these techniques in our Privacy Centers, saving about 20% of the original file size.
Se si combinano insieme tutti questi metodi si dovrebbe essere in grado di risparmiare il 10-20% nelle dimensioni del file (e ancor più di markup [e certo, praticamente ti sta dicendo di togliere proprio il markup, nota mia]), a seconda del vostro stile di codifica e la quantità di testo contenuto nelle tue pagine. Il codice sarà molto più pulito [ma che cacchio dice, e certo se scrivo male il codice farà schifo comunque sia la codifica che scelgo di usare* :D], e nel tuo sito i visitatori riusciranno a trovare più rapidamente i tuoi contenuti [questa parte non chiarissima ma è colpa della traduzione ne sono certo]. Abbiamo applicato molte di queste tecniche nei nostri Privacy Centers, il salvataggio di circa il 20% delle dimensioni del file originale.*
Ho provato il codice del Privacy Centers di cui mette il link nella paginetta che hai postato tu, l'ho provato col validatore del W3C ed è uscito che è valido per HTML5 + ARIA oh bene!
Ma noi ci stiamo girando intorno ad una pagina che sostanzialmente dice solo di usare HTML 5 che è bello, che è figo, che fa risparmiare tempo e denaro e soprattutto ci stiamo lavorando sodo, che non è poco.
Uno dei coordinatori del progetto HTML5 è un certo Ian Hickson, inventore dei test Acid1 e Acid3, sviluppatore tra l'altro proprio di HTML5, dice chiaramente di non usare HTML5 per progetti, ma lo sapevamo già! Solo perché HTML5 non è ancora uno standard e quando lo diverrà moltissime cose potrebbero cambiare.
Dato che non posso mettere links... w3.org/QA/2009/05/_watching_the_google_io.html Qui dicono chiaramente che in Google devono smetterla di parlare di HTML5 standard, perché non lo è ancora.
Insomma, aspetta, non ti entusiasmare troppo, quella pagina è la pubblicità di un prodotto che verrà, dice un sacco di cose ovvie e di corbellerie, ma sostanzialmente dice che Google sta spendendo molto su HTML5 e che quindi anche voi, noi, dobbiamo usarlo e che se lo facciamo, quei lumaconi del W3C lo faranno uscire finalmente. E che cavolo!
Ma nel W3C non sono lumaconi, semplicemente non basano le loro scelte su un solo gruppo di lavoro che spinge per un'uscita solo e soltanto perché fa comodo a lui; l'hanno fatto in passato, vedi Netscape e Microsoft e non vogliono commettere gli stessi errori, a me sembra più che giusto.
I fogli di stile esistono da anni, più di dieci, ma grazie all'idea che table fosse un'implementazione per formattare il layout di pagina solo di recente ci siamo resi conto che ad usare pesantemente i fogli di stile porta a indubbi vantaggi.
E table è stata un'idea spinta e voluta fortemente da Netscape, vogliamo ripetere gli stessi errori solo perché con l'attuale estensione di HTML5 Google risparmia suoi soldi? Ma scherziamo?