DIV vs TABLEs o respingere vă rog

Există o mulțime de oameni care întreabă "de ce nu ar trebui să folosim tabele pentru structurarea codului nostru HTML" și în timp ce vine multe răspunsuri, rareori văd pe cineva care este convertit în lumea semanticii. Acestea fiind spuse, încă nu am văzut nici o respingere convingătoare care să susțină rațiunea pentru motivul pentru care ar trebui (sau ar putea) să folosim mese.

Oricine are grijă să ofere un raționament atunci când tabelele sunt marcări structurale valide?


7 noiembrie 2008

Având în vedere că această întrebare nu a dispărut, așa cum am crezut, ar fi bine să clarific întrebarea mea și să explic existența ei.

Prin frustrare, am citit argumentul "tabelele sunt mai ușoare" o dată prea multe ori după întrebarea "DIVs vs TABLEs", am vrut să expun întrebarea mai mult și să nu las iubitorii de masă să lase cârligul atât de ușor.

Fiecare dintre ei ar putea spune altcuiva, dar pentru totdeauna am dat o aplicatie pentru a pune pe site-urile noastre care au fost create de un dezvoltator de "tabele sunt mai usor", care arunca o bucata de HTML incorect in paginile mele si, ca sa fiu sincer, eu "Nu văd destul de mult iubitorii mesei ascultând argumentele.

Oricine folosește Mambo înapoi în acea zi? Oricine a trebuit să ia un bash la punerea unui design pe partea de sus a Sharepoint-ului Microsoft? A trebuia să te lupți cu toate prostiile astea din toaletă, și considerând că a fost scrisă de niște coderi sângeroși buni, te deranjează de mine. Marcajele semantice rezonabile au existat destul de mult timp încât nu ar trebui să existe nici un motiv ca dezvoltatorii să fie în continuare campioni "mesele sunt mai ușoare". Tabelele nu sunt mai ușoare - ele sunt leneșe!

Întrebarea mea a meritat repul negativ pentru modul negativ în care a fost prezentat, dar încă aștept ca oamenii să accepte că singurul motiv pentru care folosesc mesele este că NU Știu HTML. Pentru că dacă au făcut-o, atunci ar înțelege, așa cum spune jjrv, că tabelele sunt pentru date tabulare.

0
Adresați-vă întrebări care pot fi preluate, nu doar discutate (de pe pagina Întrebare la întrebare)
adăugat autor Peter Hilton, sursa
Am văzut acest lucru foarte mult de croazieră la nivel de întrebări de nivel inferior: întrebarea dvs. a inspirat răspunsuri mari (unele dintre care a ajuns până la +13), dar am conservat la -6. Te rog susține această problemă săracă!
adăugat autor Dan Rosenstark, sursa
Sunt de acord cu @AviewAnew - această întrebare este ciudată, având în vedere răspunsul dvs. la acest exact același subiect ieri.
adăugat autor delfuego, sursa

9 răspunsuri

Tabelele sunt destinate dezvoltatorilor care nu pot fi deranjați să cânte la orele cu CSS pentru a obține două diviziuni columnești adiacente pentru a extinde la înălțime și lățime de 100%, indiferent de conținut, și apoi pentru a obține hack pentru a lucra în toate browserele fără a adăuga împachetări extra div și apoi în cele din urmă în frustrare absolută pe care o apelează la remedierea de 5 secunde:

<table width="100%">
<tr><td valign="top">Left nav</td><td valign="top">Main content</td></tr>
</table>

Adevărul greu este că majoritatea utilizatorilor (cu excepția celor care utilizează ecranatori) într-adevăr nu le pasă cum este marcată pagina, atâta timp cât se încarcă rapid.

Dezvoltatorii au constrângeri bugetare și de timp, iar CSS "bun" și marcarea necesită timp.

Faptul că există o multitudine de resurse pe web, care explică în detaliu în detaliu cum puteți să aliniați două diviziuni pentru a înlocui acea masă simplă, îmi spune foarte clar că acest design este în mod inerent la fel de defect ca și tabelele. Câte tutoriale sunt necesare pentru a explica cum să adăugați un tabel cu două coloane la o pagină ?

HTML5 ar trebui să ne aducă niște sancțiuni cu noile etichete de antet, subsol, secțiune, nav și deoparte. Exemplu preluat din Nettuts +:

<div id="content">
    <div id="mainContent">
        
<!-- Blog post -->
 
        
<!-- Comments -->
 
        <form>
            <!-- Comment form -->
        </form>
    </div>
    
 
</div>

și apoi pentru CSS:

#content {
    display: table;
}

    #mainContent {
        display: table-cell;
        width: 620px;
        padding-right: 22px;
    }

    aside {
        display: table-cell;
        width: 300px;
    }

Aceia dintre voi cu un ochi fermei vor iubi sentimentul de ironie, atunci când observați că CSS are proprietățile: display: table; și display: cell-cell .

Mesele sunt înapoi copii! Snuck prin ușa din spate HTML5 -)

0
adăugat
afișarea: tabelul și afișarea: tabela de celule nu au nimic de a face cu HTML5 și au fost în jur de ceva timp (deși nu sunt bine implementate).
adăugat autor Matt Sach, sursa

Tabelele sunt valide atunci când aveți un tabel de date. Am văzut widget-uri interactive de rețea în cazul în care acestea merg din calea lor de a folosi o grămadă de divs pentru a evita tag-ul masă temut. Când este vorba de date tabulare, faceți-i un tabel.

O viziune mai controversată asupra mea este că atunci când aveți probleme cu rezolvarea problemelor legate de aspectul vertical în CSS, puteți folosi doar o masă și de multe ori o puteți rezolva imediat. Nu la fel de drăguț cum ar fi trebuit să fie, amestecând conținutul cu prezentarea, dar își face treaba și evită hack-urile CSS să ajungă în jurul IE.

0
adăugat

Tabelele sunt acceptate chiar și în browserele vechi HTML v1.0. Dacă piața dvs. țintă include oameni care utilizează browsere încorporate în telefoanele mobile din anii 1990, ar putea fi un motiv bun pentru a merge cu mesele.

O mulțime de metode existente care utilizează automat HTML utilizează tabele. Dacă codul dvs. trebuie să interacționeze sau să includă acele tabele, ar fi mai bine să mergeți pentru consecvență.

0
adăugat
Întregul punct al marcajului semantic și CSS este că pagina dvs. va avea încă sens, chiar și într-un vechi browser HTML v1 crud. Tabelele vă vor da inconsecvențe și coșmaruri. Nisipurile, paragrafele și altele asemenea vă vor oferi un tip frumos, structurat, care are sens perfect.
adăugat autor roryf, sursa
Tabelele nu au fost adăugate în HTML până la HTML 3.2.
adăugat autor Jim, sursa

Aș spune că jjrv are dreptate în tabelele care sunt excelente pentru datele tabulare, ieșind din calea de a face ceva "de lucru" ca o masă în loc să folosești doar o masă este întârziată la limită.

dacă vă interesează standardele și vă deplasați către o implementare solidă în toate browserele, atunci majoritatea marcajelor dvs. ar trebui să fie în layout-uri lichide fără tabel ... și datele dvs. tabulare sunt în ... ați ghicit tabelele!

dacă aveți nevoie să răspundeți la browsere într-adevăr vechi, adică înainte de tema ie6, atunci veți avea o mulțime de probleme în CSS și ținând cont de statisticile actuale de utilizare este foarte sigur să presupunem că toată lumea va avea un browser "modern" care acceptă layout-uri css.

toate acestea au spus și sunt momente când vă bate capul dvs. de perete pe un aspect și doriți/nu spun f___-l prin ea într-o masă și funcționează. Sper că aceasta este o practică depreciată, dar într-un final acest lucru nu oferă rezultate previzibile.

0
adăugat

Utilizarea marcajului semantic modern este mult mai ușoară atunci când adăugați caracteristici sau remediați bug-uri sau modificați aspectul unui site Web bazat pe date. Adăugarea caracteristicilor AJAX sau a oricărui tip de scripting interactiv va funcționa mult mai bine cu DIV și CSS decât cu TABLEs.

Deplasarea la un manager de conținut cum ar fi Drupal, Joomla, WordPress sau altele asemenea va fi mult mai ușor dacă deja sunteți organizat cu marcaj semantic.

Cele mai noi ediții ale browserului vor sprijini, de asemenea, marcajele moderne mai eficient și site-ul dvs. va fi afișat mai rapid. Rearanjarea tuturor tabelelor poate avea ca rezultat o perioadă de afișare lentă.

Pe de altă parte, mesele sunt aici pentru a rămâne. Unii oameni vor continua să le folosească și browserele vor continua să le afișeze. Nu există nimic în mod inerent greșit cu marcarea ne-semantică, dacă asta doriți. Un site complet static, care nu se va schimba niciodată, poate funcționa la fel ca și în cazul marcajelor moderne.

În ceea ce privește marcajul structural valid, există următoarele: Tabelele reprezintă o modalitate excelentă de a afișa date tabulare, cum ar fi tabele de baze de date sau tabele de calcul tabelar. Ele nu sunt marcaj valid pentru nimic altceva.

0
adăugat

Utilizați tabelele pentru cel mai mic numitor html sau pentru date tabulare în cazul în care este logic să se întindă între coloane sau rânduri. În caz contrar, layout-urile CSS sunt mult mai puțin verbose și mult mai ușor de întreținut odată ce tu ai atârnat-o.

0
adăugat

Bazele DIV suferă de limitări. Fără tabele, este în esență imposibil pentru a implementa un aspect de două coloane care crește în mod corespunzător în funcție de înălțimea conținutului.

0
adăugat

O notă interesantă este legată de aplicațiile JavaScript extrem de complexe. Dacă alegeți Gmail sau Google Calendar cu Firebug, veți vedea că tabelele sunt utilizate pe scară largă, chiar și pentru aspect. Cu toate acestea, acestea sunt generate de obicei dinamic, dar acest lucru arată că, în cazuri rare, unele interfețe interactive foarte complexe din punct de vedere vizual sunt extrem de dificil de construit folosind numai DIV-uri.

0
adăugat

RE: De ce tabele?

Deoarece unii oameni sunt (încă, după toți acești ani), frică de schimbare. Au auzit că folosirea HTML-ului semantic este un lucru bun (și, de obicei, nu înțelegeți complet conceptul). Deci, ei încearcă să pună împreună un aspect folosind CSS, fără a mai făcut-o înainte. Se întâlnesc cu câteva probleme (bine documentate și de obicei ușor de rezolvat), își aruncă mâinile în sus și se duc la mese.

Ei apoi decid că CSS este "prea consumator de timp" ("nu sunt dispus să-mi petrec timpul să-l învăț") sau "nu este practic" ("nu-l înțeleg, e prea greu") și că tabelele sunt singura cale adevărată. Prin încăpățânare și ignoranță, ei cred că își vor bate joc de ei și își vor convinge clienții și colegii.

Și lumea lor rămâne fericită și neschimbată, fading mai departe în trecut și mai adânc în uzură *

Și acesta este motivul pentru "mese". Sfarsit.

(* cu excepția faptului că sunt foarte potrivite pentru codarea e-mailurilor HTML)

0
adăugat