Mengapa tidak menggunakan tabel untuk tata letak dalam HTML? [Tutup]

Tampaknya menjadi pendapat umum bahwa tabel tidak boleh digunakan untuk tata letak dalam HTML.

Mengapa?

Saya belum pernah (atau jarang jujur) melihat argumen bagus untuk ini. Jawaban yang biasa adalah:

• Ini baik untuk memisahkan konten dari tata letak
  Tapi ini adalah argumen yang keliru; Berpikir Klise . Saya kira memang benar bahwa menggunakan elemen tabel untuk tata letak tidak ada hubungannya dengan data tabular. Terus? Apakah bos saya peduli? Apakah pengguna saya peduli?
  
  Mungkin saya atau rekan pengembang yang harus menjaga perawatan halaman web ... Apakah tabelnya kurang dapat dikelola? Saya pikir menggunakan tabel lebih mudah daripada menggunakan divs dan CSS.
  
  Ngomong-ngomong ... mengapa menggunakan div atau rentang konten yang baik dari tata letak dan tabel tidak? Mendapatkan tata letak yang baik dengan hanya divs sering membutuhkan banyak divs bersarang.

• Keterbacaan kode
  saya pikir itu sebaliknya. Kebanyakan orang mengerti HTML, hanya sedikit yang mengerti CSS.

• Lebih baik untuk SEO tidak menggunakan tabel
  Mengapa? Adakah yang bisa menunjukkan bukti? Atau pernyataan dari Google bahwa tabel tidak disarankan dari perspektif SEO?

• Tabel lebih lambat.
  Elemen badan tambahan harus dimasukkan. Ini adalah kacang untuk browser web modern. Tunjukkan pada saya beberapa tolok ukur di mana penggunaan tabel secara signifikan memperlambat halaman.

• Perombakan tata letak lebih mudah tanpa tabel, lihat css Zen Garden .
  Sebagian besar situs web yang memerlukan peningkatan memerlukan konten baru (HTML) juga. Skenario di mana versi baru situs web hanya membutuhkan file CSS baru sangat tidak mungkin. Zen Garden adalah situs web yang bagus, tetapi sedikit teoretis. Belum lagi penyalahgunaan CSS.

Saya benar-benar tertarik pada argumen yang bagus untuk menggunakan divs + CSS, bukan tabel.

Saya akan membahas argumen Anda satu demi satu dan mencoba menunjukkan kesalahan di dalamnya.

Ini baik untuk memisahkan konten dari tata letak Tapi ini adalah argumen yang keliru; Berpikir Klise.

Sama sekali tidak keliru karena HTML sengaja dirancang. Penyalahgunaan suatu elemen mungkin tidak sepenuhnya dipertanyakan (bagaimanapun juga, idiom baru telah berkembang dalam bahasa lain) tetapi kemungkinan implikasi negatifnya harus diimbangi. Selain itu, bahkan jika tidak ada argumen yang menentang penyalahgunaan <table>elemen hari ini, mungkin ada hari esok karena cara vendor browser menerapkan perlakuan khusus pada elemen tersebut. Lagi pula, mereka tahu bahwa " <table>elemen hanya untuk data tabular" dan mungkin menggunakan fakta ini untuk meningkatkan mesin rendering, dalam prosesnya secara halus mengubah <table>perilaku, dan dengan demikian memecahkan kasus-kasus di mana sebelumnya disalahgunakan.

Terus? Apakah bos saya peduli? Apakah pengguna saya peduli?

Tergantung. Apakah bos Anda berambut runcing? Maka dia mungkin tidak peduli. Jika dia kompeten, maka dia akan peduli, karena pengguna akan melakukannya .

Mungkin saya atau rekan pengembang yang harus menjaga perawatan halaman web ... Apakah tabelnya kurang dapat dikelola? Saya pikir menggunakan tabel lebih mudah daripada menggunakan divs dan css.

Mayoritas pengembang web profesional tampaknya menentang Anda^{[ rujukan? ]} . Bahwa tabel yang sebenarnya kurang maintainable harus jelas. Menggunakan tabel untuk tata letak berarti mengubah tata letak perusahaan pada kenyataannya berarti mengubah setiap halaman. Ini bisa sangat mahal. Di sisi lain, penggunaan HTML semantik bermakna secara bermakna dikombinasikan dengan CSS dapat membatasi perubahan pada CSS dan gambar yang digunakan.

Ngomong-ngomong ... mengapa menggunakan div atau rentang konten yang baik dari tata letak dan tabel tidak? Mendapatkan tata letak yang baik dengan hanya divs sering membutuhkan banyak divs bersarang.

Sarang bersarang <div>adalah anti-pola seperti tata letak meja. Desainer web yang baik tidak membutuhkan banyak dari mereka. Di sisi lain, bahkan div bersarung dalam seperti itu tidak memiliki banyak masalah tata letak meja. Bahkan, mereka bahkan dapat berkontribusi pada struktur semantik dengan secara logis membagi konten menjadi beberapa bagian.

Keterbacaan kode saya pikir itu sebaliknya. Kebanyakan orang mengerti html, sedikit mengerti css. Lebih sederhana.

"Kebanyakan orang" tidak masalah. Masalah profesional. Untuk profesional, tata letak tabel menciptakan lebih banyak masalah daripada HTML + CSS. Ini seperti mengatakan saya tidak boleh menggunakan GVim atau Emacs karena Notepad lebih sederhana bagi kebanyakan orang. Atau saya tidak seharusnya menggunakan LaTeX karena MS Word lebih sederhana bagi kebanyakan orang.

Lebih baik SEO tidak menggunakan tabel

Saya tidak tahu apakah ini benar dan tidak akan menggunakan ini sebagai argumen tetapi itu akan logis. Mesin pencari mencari data yang relevan . Meskipun data tabular tentu saja relevan, jarang yang dicari pengguna. Pengguna mencari istilah yang digunakan dalam judul halaman atau posisi yang serupa. Oleh karena itu akan logis untuk mengecualikan konten tabel dari penyaringan dan dengan demikian memotong waktu pemrosesan (dan biaya!) Oleh faktor besar.

Tabel lebih lambat. Elemen badan tambahan harus dimasukkan. Ini adalah kacang untuk browser web modern.

Elemen tambahan tidak ada hubungannya dengan tabel menjadi lebih lambat. Di sisi lain, algoritma tata letak untuk tabel jauh lebih sulit, browser sering harus menunggu seluruh tabel untuk memuat sebelum dapat mulai menata konten. Selain itu, cache tata letak tidak berfungsi (CSS dapat dengan mudah di-cache). Semua ini telah disebutkan sebelumnya.

Tunjukkan pada saya beberapa tolok ukur di mana penggunaan tabel secara signifikan memperlambat halaman.

Sayangnya, saya tidak punya data patokan. Saya akan tertarik sendiri karena memang benar bahwa argumen ini tidak memiliki ketelitian ilmiah tertentu.

Sebagian besar situs web yang memerlukan peningkatan memerlukan konten baru (html) juga. Skenario di mana versi baru situs web hanya membutuhkan file css baru sangat tidak mungkin.

Tidak semuanya. Saya telah mengerjakan beberapa kasus di mana mengubah desain disederhanakan dengan pemisahan konten dan desain. Seringkali masih diperlukan untuk mengubah beberapa kode HTML tetapi perubahan akan selalu lebih terbatas. Selain itu, perubahan desain terkadang harus dilakukan secara dinamis. Pertimbangkan mesin templat seperti yang digunakan oleh sistem blogging WordPress. Layout tabel akan mematikan sistem ini. Saya telah mengerjakan kasus serupa untuk perangkat lunak komersial. Mampu mengubah desain tanpa mengubah kode HTML adalah salah satu persyaratan bisnis.

Hal lain. Tata letak tabel membuat penguraian situs web (pengikisan layar) otomatis menjadi jauh lebih sulit. Ini mungkin terdengar sepele karena, siapa yang melakukannya? Saya sendiri terkejut. Pengikisan layar dapat banyak membantu jika layanan tersebut tidak menawarkan alternatif WebService untuk mengakses datanya. Saya bekerja di bioinformatika di mana ini adalah kenyataan yang menyedihkan. Teknik web modern dan WebServices belum menjangkau sebagian besar pengembang dan seringkali, pengikisan layar adalah satu-satunya cara untuk mengotomatiskan proses mendapatkan data. Tidak heran bahwa banyak ahli biologi masih melakukan tugas-tugas seperti itu secara manual. Untuk ribuan set data.

Inilah jawaban programmer saya dari utas serupa

Semantik 101

Pertama lihat kode ini dan pikirkan tentang apa yang salah di sini ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

Masalahnya, tentu saja, sepeda bukanlah mobil. Kelas mobil adalah kelas yang tidak pantas untuk tur sepeda motor. Kode ini bebas kesalahan, tetapi secara semantik tidak benar. Itu mencerminkan buruk pada programmer.

Semantik 102

Sekarang terapkan ini untuk mendokumentasikan markup. Jika dokumen Anda perlu menyajikan data tabular, maka tag yang sesuai adalah <table>. Jika Anda menempatkan navigasi ke dalam tabel, maka Anda menyalahgunakan tujuan <table>elemen yang dimaksud. Dalam kasus kedua, Anda tidak mempresentasikan data tabular - Anda (salah) menggunakan <table>elemen untuk mencapai tujuan presentasi.

Kesimpulan

Akankah pengunjung memperhatikan? Tidak. Apakah bos Anda peduli? Mungkin. Apakah kita terkadang mengambil jalan pintas sebagai programmer? Tentu. Tetapi haruskah kita? Tidak. Siapa yang diuntungkan jika Anda menggunakan markup semantik? Anda - dan reputasi profesional Anda. Sekarang pergi dan lakukan hal yang benar.

Jawaban yang jelas: Lihat CSS Zen Garden . Jika Anda memberi tahu saya bahwa Anda dapat dengan mudah melakukan hal yang sama dengan tata letak berbasis tabel (ingat - HTML tidak berubah) maka tentu saja gunakan tabel untuk tata letak.

Dua hal penting lainnya adalah aksesibilitas dan SEO.

Keduanya peduli tentang bagaimana informasi pesanan disajikan. Anda tidak dapat dengan mudah menyajikan navigasi Anda di bagian atas halaman jika tata letak berbasis tabel Anda menempatkannya di sel ke-3 dari baris ke-2 dari tabel bersarang ke-2 pada halaman.

Jadi jawaban Anda adalah rawatan, aksesibilitas, dan SEO.

Jangan malas. Lakukan hal-hal dengan cara yang benar dan tepat bahkan jika itu agak sulit untuk dipelajari.

Lihat pertanyaan rangkap ini.

Satu item yang Anda lupa ada aksesibilitas. Layout berbasis tabel tidak menerjemahkan juga jika Anda perlu menggunakan pembaca layar, misalnya. Dan jika Anda bekerja untuk pemerintah, mendukung browser yang dapat diakses seperti pembaca layar mungkin diperlukan .

Saya juga berpikir Anda meremehkan dampak dari beberapa hal yang Anda sebutkan dalam pertanyaan. Misalnya, jika Anda adalah perancang dan pemrogram, Anda mungkin tidak memiliki apresiasi penuh tentang seberapa baik memisahkan presentasi dari konten. Tapi begitu Anda masuk ke toko di mana mereka dua peran yang berbeda, keuntungan mulai menjadi lebih jelas.

Jika Anda tahu apa yang Anda lakukan dan memiliki alat yang bagus, CSS benar-benar memiliki kelebihan signifikan dibandingkan tabel untuk tata letak. Dan sementara masing-masing item dengan sendirinya mungkin tidak membenarkan meninggalkan tabel, secara bersama-sama itu layak dilakukan.

Sayangnya, CSS Zen Garden tidak lagi dapat digunakan sebagai contoh desain HTML / CSS yang baik. Hampir semua desain terbaru mereka menggunakan grafik untuk heading bagian. File-file grafik ini ditentukan dalam CSS.

Oleh karena itu, sebuah situs web yang bertujuan untuk menunjukkan keuntungan dari menjaga desain dari konten, sekarang secara teratur melakukan SIN yang TIDAK TERPASANG untuk menempatkan konten ke dalam desain. (Jika judul bagian dalam file HTML berubah, judul bagian yang ditampilkan tidak akan).

Yang hanya menunjukkan bahwa bahkan mereka yang mendukung agama DIV & CSS yang ketat, tidak dapat mengikuti aturan mereka sendiri. Anda dapat menggunakannya sebagai pedoman seberapa dekat Anda mengikuti mereka.

Ini bukan argumen definitif, dengan cara apa pun, tetapi dengan CSS Anda dapat mengambil markup yang sama dan mengubah tata letak tergantung pada media, yang merupakan keuntungan yang bagus. Untuk halaman cetak, Anda dapat dengan tenang menekan navigasi tanpa harus membuat halaman yang ramah-printer, misalnya.

Satu meja untuk tata letak tidak akan seburuk itu. Tapi Anda tidak bisa mendapatkan tata letak yang Anda butuhkan hanya dengan satu meja sebagian besar waktu. Segera Anda memiliki 2 atau tiga tabel bersarang. Ini menjadi sangat rumit.

• BANYAK lebih sulit dibaca. Itu tidak terserah pendapat. Hanya ada lebih banyak tag bersarang tanpa tanda pengenal pada mereka.

• Memisahkan konten dari presentasi adalah hal yang baik karena memungkinkan Anda untuk fokus pada apa yang Anda lakukan. Menggabungkan kedua mengarah ke halaman yang membengkak yang sulit dibaca.

• CSS untuk gaya memungkinkan browser Anda untuk melakukan cache file dan permintaan berikutnya jauh lebih cepat. Ini BESAR.

• Tabel mengunci Anda ke dalam desain. Tentu, tidak semua orang membutuhkan fleksibilitas CSS Zen Garden, tetapi saya belum pernah bekerja di situs di mana saya tidak perlu mengubah desain sedikit pun di sana-sini. Jauh lebih mudah dengan CSS.

• Tabel sulit untuk ditata. Anda tidak memiliki banyak fleksibilitas dengan mereka (yaitu Anda masih perlu menambahkan atribut HTML untuk sepenuhnya mengontrol gaya tabel)

Saya belum pernah menggunakan tabel untuk data non-tabular mungkin dalam 4 tahun. Saya belum melihat ke belakang.

Saya benar-benar ingin menyarankan membaca Penguasaan CSS oleh Andy Budd. Fantastis.

Gambar di ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2.204.203.200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

Ini baik untuk memisahkan konten dari tata letak
Tapi ini adalah argumen yang keliru; Berpikir Klise

Ini argumen yang keliru karena tabel HTML adalah tata letak! Konten adalah data dalam tabel, penyajiannya adalah tabel itu sendiri. Inilah sebabnya mengapa memisahkan CSS dari HTML terkadang sangat sulit. Anda tidak memisahkan konten dari presentasi, Anda memisahkan presentasi dari presentasi! Setumpuk div bersarang tidak berbeda dengan tabel - hanya set tag yang berbeda.

Masalah lain dengan memisahkan HTML dari CSS adalah bahwa mereka membutuhkan pengetahuan intim satu sama lain - Anda benar-benar tidak dapat memisahkan mereka sepenuhnya. Tata letak tag di HTML sangat erat dengan file CSS tidak peduli apa yang Anda lakukan.

Saya pikir tabel vs divs turun ke kebutuhan aplikasi Anda.

Dalam aplikasi yang kami kembangkan di tempat kerja, kami membutuhkan tata letak halaman di mana potongan-potongan itu akan secara dinamis mengukur sendiri konten mereka. Saya menghabiskan waktu berhari-hari untuk mencoba ini bekerja lintas-browser dengan CSS dan DIV dan itu adalah mimpi buruk yang lengkap. Kami beralih ke tabel dan semuanya bekerja .

Namun, kami memiliki audiens yang sangat tertutup untuk produk kami (kami menjual perangkat keras dengan antarmuka web) dan masalah aksesibilitas bukan masalah bagi kami. Saya tidak tahu mengapa pembaca layar tidak bisa menangani tabel dengan baik, tapi saya kira jika memang seperti itu maka pengembang harus menanganinya.

CSS / DIV - itu hanya pekerjaan untuk anak laki-laki desain, bukan. Ratusan jam yang saya habiskan untuk debugging masalah DIV / CSS, mencari di internet untuk mendapatkan beberapa bagian dari markup bekerja dengan browser yang tidak jelas - itu membuat saya marah. Anda membuat satu perubahan kecil dan seluruh tata letak menjadi sangat salah - di mana pada dasarnya adalah logika. Menghabiskan berjam-jam memindahkan sesuatu 3 piksel dengan cara ini maka yang lain 2 piksel lainnya untuk membuat mereka semua berbaris. Ini sepertinya salah bagi saya. Hanya karena Anda seorang purist dan sesuatu adalah "bukan hal yang tepat untuk dilakukan" tidak berarti Anda harus memanfaatkannya sampai tingkat ke-n dan dalam semua keadaan, terutama jika itu membuat hidup Anda 1000 kali lebih mudah.

Jadi saya akhirnya memutuskan, murni berdasarkan alasan komersial, meskipun saya tetap menggunakan seminimal mungkin, jika saya mengantisipasi 20 jam kerja untuk mendapatkan DIV yang ditempatkan dengan benar, saya akan tetap di meja. Itu salah, itu mengganggu kaum puritan, tetapi dalam banyak kasus harganya lebih murah dan lebih murah untuk dikelola. Saya kemudian dapat berkonsentrasi untuk membuat aplikasi berfungsi seperti yang diinginkan pelanggan, daripada menyenangkan para puritan. Mereka memang membayar tagihan dan argumen saya kepada manajer yang menegakkan penggunaan CSS / DIV - Saya hanya akan menunjukkan bahwa pelanggan membayar gajinya juga!

Satu-satunya alasan semua argumen CSS / DIV ini terjadi adalah karena kekurangan CSS di tempat pertama dan karena browser tidak kompatibel satu sama lain dan jika mereka, setengah desainer web di dunia akan keluar dari pekerjaan .

Ketika Anda mendesain bentuk windows Anda tidak mencoba memindahkan kontrol setelah Anda meletakkannya jadi saya agak berpikir itu aneh bagi saya mengapa Anda ingin melakukan ini dengan formulir web. Saya tidak bisa mengerti logika ini. Dapatkan tata letak yang benar untuk memulai dan apa masalahnya. Saya pikir itu karena desainer suka bermain-main dengan kreativitas, sementara pengembang aplikasi lebih peduli untuk benar-benar membuat aplikasi bekerja, membuat objek bisnis, menerapkan aturan bisnis, mencari tahu bagaimana bit data pelanggan berhubungan satu sama lain, memastikan hal itu memenuhi pelanggan persyaratan - Anda tahu - seperti hal-hal dunia nyata.

Jangan salah paham, kedua argumen ini valid, tapi tolong jangan kritik pengembang karena memilih pendekatan yang lebih mudah, lebih logis untuk merancang formulir. Kita sering memiliki hal-hal yang lebih penting untuk dikhawatirkan daripada semantik yang benar dari menggunakan tabel di atas div.

Contohnya - berdasarkan diskusi ini saya mengkonversi beberapa tds dan trs ke divs. 45 menit main-main dengan itu mencoba untuk mendapatkan segalanya untuk berbaris di samping satu sama lain dan saya menyerah. TD kembali 10 detik kemudian - berfungsi - langsung - di semua browser, tidak ada lagi yang bisa dilakukan. Tolong coba buat saya mengerti - pembenaran apa yang mungkin Anda miliki karena ingin saya melakukannya dengan cara lain!

Tata letak harus mudah. Fakta bahwa ada artikel yang ditulis tentang cara mencapai tata letak tiga kolom dinamis dengan header dan footer di CSS menunjukkan bahwa itu adalah sistem tata letak yang buruk. Tentu saja Anda bisa membuatnya berfungsi, tetapi ada ratusan artikel online tentang cara melakukannya. Hampir tidak ada artikel seperti itu untuk tata letak yang mirip dengan tabel karena sudah jelas jelas. Tidak peduli apa yang Anda katakan terhadap tabel dan mendukung CSS, fakta ini membatalkan semuanya: tata letak tiga kolom dasar dalam CSS sering disebut "Cawan Suci".

Jika itu tidak membuat Anda mengatakan "WTF" maka Anda benar-benar harus meletakkan bantuan kool sekarang.

Saya suka CSS. Ini menawarkan opsi gaya luar biasa dan beberapa alat penentuan posisi keren, tetapi sebagai mesin tata letak itu kurang. Perlu ada beberapa jenis sistem penentuan posisi grid dinamis. Cara mudah untuk menyelaraskan kotak pada beberapa sumbu tanpa mengetahui ukurannya terlebih dahulu. Saya tidak peduli jika Anda menyebutnya <table> atau <gridlayout> atau apa pun, tetapi ini adalah fitur tata letak dasar yang hilang dari CSS.

Masalah yang lebih besar adalah bahwa dengan tidak mengakui ada fitur yang hilang, para fanatik CSS telah menahan CSS dari semula. Saya akan sangat senang untuk berhenti menggunakan tabel jika CSS memberikan posisi grid multi-axis yang layak seperti pada dasarnya setiap mesin tata letak lainnya di dunia. (Anda menyadari masalah ini telah dipecahkan berkali-kali dalam banyak bahasa oleh semua orang kecuali W3C, bukan? Dan tidak ada orang lain yang menyangkal bahwa fitur seperti itu berguna.)

Mendesah. Ventilasi yang cukup. Silakan dan tancapkan kembali kepala Anda ke pasir.

Menurut kepatuhan 508 (untuk pembaca layar untuk gangguan visual), tabel seharusnya hanya digunakan untuk menyimpan data dan bukan untuk tata letak karena menyebabkan pembaca layar menjadi panik. Atau begitulah saya diberitahu.

Jika Anda menetapkan nama untuk masing-masing divs, Anda dapat menguliti semuanya bersama-sama menggunakan CSS juga. Mereka hanya sedikit lebih sakit untuk duduk seperti yang Anda inginkan.

Berikut adalah bagian dari html dari proyek terbaru:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

Dan ini kode yang sama dengan tata letak berbasis tabel.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

Satu-satunya kebersihan yang saya lihat dalam tata letak berdasarkan tabel adalah kenyataan bahwa saya terlalu bersemangat dengan lekukan saya. Saya yakin bahwa bagian konten akan memiliki dua tabel disematkan lebih lanjut.

Satu hal yang perlu dipikirkan: filesizes . Saya telah menemukan bahwa tata letak berbasis tabel dua kali ukuran rekan CSS mereka biasanya. Pada broadband berkecepatan tinggi kami, ini bukan masalah besar, tetapi pada mereka yang menggunakan modem dial up.

Saya ingin menambahkan bahwa tata letak berbasis div lebih mudah untuk menjaga, berevolusi, dan refactor. Hanya beberapa perubahan dalam CSS untuk menyusun ulang elemen dan itu dilakukan. Dari pengalaman saya, mendesain ulang tata letak yang menggunakan tabel adalah mimpi buruk (apalagi jika ada tabel bersarang).

Kode Anda juga memiliki makna dari sudut pandang semantik .

Tidak ada argumen yang mendukung DIV dari saya.

Saya akan mengatakan: Jika sepatu itu pas, kenakan.

Perlu dicatat bahwa sulit jika bukan tidak mungkin untuk menemukan metode DIV + CSS yang baik dalam merender konten dalam dua atau tiga kolom, yang konsisten pada semua browser, dan masih terlihat seperti yang saya maksudkan.

Ini tips keseimbangan sedikit ke arah tabel di sebagian besar tata letak saya, dan meskipun saya merasa bersalah menggunakannya (dunny mengapa, orang hanya mengatakan itu buruk jadi saya mencoba mendengarkannya), pada akhirnya, pandangan pragmatis itu hanya lebih mudah dan lebih cepat bagi saya untuk menggunakan TABLE. Saya tidak dibayar per jam, jadi meja lebih murah bagi saya.

Layout CSS umumnya jauh lebih baik untuk aksesibilitas, asalkan konten datang dalam urutan alami dan masuk akal tanpa stylesheet. Dan bukan hanya pembaca layar yang kesulitan dengan tata letak berbasis tabel: mereka juga mempersulit browser seluler untuk membuat halaman dengan benar.

Juga, dengan tata letak berbasis div Anda dapat dengan mudah melakukan hal-hal keren dengan lembar gaya pencetakan seperti tidak termasuk header, footer dan navigasi dari halaman yang dicetak - Saya pikir itu tidak mungkin, atau setidaknya jauh lebih sulit, untuk melakukannya dengan tata letak berbasis tabel.

Jika Anda ragu bahwa pemisahan konten dari tata letak lebih mudah dengan div daripada dengan tabel, lihat HTML berbasis div di CSS Zen Garden , lihat bagaimana mengubah stylesheet dapat mengubah tata letak secara drastis, dan memikirkan apakah Anda bisa mencapai variasi tata letak yang sama jika HTML berbasis tabel ... Jika Anda melakukan tata letak berbasis tabel, Anda tidak mungkin menggunakan CSS untuk mengontrol semua spasi dan bantalan dalam sel (jika Anda, Anda hampir pasti akan lebih mudah untuk menggunakan divs mengambang dll di tempat pertama). Tanpa menggunakan CSS untuk mengontrol semua itu, dan karena fakta bahwa tabel menentukan urutan kiri-ke-kanan dan atas-ke bawah dalam HTML, tabel cenderung berarti bahwa tata letak Anda menjadi sangat banyak diperbaiki dalam HTML.

Secara realistis saya pikir sangat sulit untuk sepenuhnya mengubah tata letak desain berbasis div-dan-CSS tanpa mengubah sedikit divs. Namun, dengan tata letak berbasis div-dan-CSS, akan lebih mudah untuk mengubah hal-hal seperti jarak antara berbagai blok, dan ukuran relatifnya.

Fakta bahwa ini adalah pertanyaan yang hangat diperdebatkan adalah bukti kegagalan W3C untuk mengantisipasi keragaman desain tata letak yang akan dicoba. Menggunakan divs + css untuk tata letak yang ramah semantik adalah konsep yang bagus, tetapi detail implementasinya sangat cacat sehingga mereka sebenarnya membatasi kebebasan kreatif.

Saya mencoba untuk mengubah salah satu situs perusahaan kami dari tabel ke divs, dan itu adalah sakit kepala sehingga saya benar-benar membuang jam kerja yang telah saya tuangkan ke dalamnya dan kembali ke meja. Mencoba untuk bergulat dengan div saya untuk mendapatkan kendali atas penyelarasan vertikal telah mengutuk saya dengan masalah psikologis utama yang saya tidak akan pernah goyangkan selama debat ini terus berlangsung.

Fakta bahwa orang harus sering menemukan solusi yang kompleks dan jelek untuk mencapai tujuan desain sederhana (seperti penyelarasan vertikal) sangat menunjukkan bahwa aturannya hampir tidak cukup fleksibel. Jika spesifikasi cukup, lalu mengapa situs profil tinggi (seperti SO) merasa perlu untuk membengkokkan aturan menggunakan tabel dan solusi lain?

Saya kira memang benar bahwa menggunakan elemen tabel untuk tata letak tidak ada hubungannya dengan data tabular. Terus? Apakah bos saya peduli? Apakah pengguna saya peduli?

Google dan sistem otomatis lainnya sangat peduli, dan mereka sama pentingnya dalam banyak situasi. Kode semantik lebih mudah bagi sistem non-cerdas untuk diuraikan dan diproses.

Setelah harus bekerja dengan situs web yang melibatkan 6 lapisan tabel bersarang yang dihasilkan oleh beberapa aplikasi, dan setelah itu menghasilkan HTML yang tidak valid, sebenarnya itu adalah pekerjaan 3 jam untuk memperbaikinya karena ada perubahan kecil.

Ini tentu saja tepi kasus, tetapi desain berbasis tabel tidak dapat dipertahankan. Jika Anda menggunakan css, pisahkan gaya tersebut sehingga saat memperbaiki HTML Anda tidak perlu terlalu khawatir untuk memecahnya.

Juga, coba ini dengan JavaScript. Memindahkan sel tabel tunggal dari satu tempat ke tempat lain di tabel lain. Agak rumit untuk melakukan di mana div / span hanya akan berfungsi copy-paste-bijaksana.

"Apakah bos saya peduli"

Jika aku bosmu. Kamu akan peduli. ;) Jika Anda menghargai hidup Anda.

Fleksibilitas tata letak
Bayangkan Anda membuat halaman dengan sejumlah besar thumbnail.
DIVs :
Jika Anda menempatkan setiap thumbnail di DIV, melayang ke kiri, mungkin 10 di antaranya pas pada satu baris. Buat jendela lebih sempit, dan BAM - 6 berturut-turut, atau 2, atau berapa banyak cocok.
TABEL:
Anda harus secara eksplisit mengatakan berapa banyak sel dalam satu baris. Jika jendela terlalu sempit, pengguna harus menggulir secara horizontal.

Maintainability
Situasi yang sama seperti di atas. Sekarang Anda ingin menambahkan tiga thumbnail ke baris ketiga.
DIVs:
Tambahkan mereka. Tata letak akan secara otomatis menyesuaikan.
TABEL: Tempel sel baru ke baris ketiga. Ups! Sekarang ada terlalu banyak barang di sana. Potong beberapa dari baris itu dan letakkan di baris keempat. Sekarang ada terlalu banyak barang di sana. Potong beberapa dari baris itu ... (dll)
( Tentu saja, jika Anda membuat baris dan sel dengan skrip sisi server, ini mungkin tidak akan menjadi masalah. )

Saya pikir perahu itu telah berlayar. Jika Anda melihat arah yang diambil industri, Anda akan melihat bahwa CSS dan Standar Terbuka adalah pemenang dari diskusi itu. Yang pada gilirannya berarti untuk sebagian besar pekerjaan html, dengan pengecualian bentuk, desainer akan menggunakan div bukan tabel. Saya mengalami kesulitan dengan itu karena saya bukan seorang guru CSS tetapi itulah caranya.

Juga, jangan lupa, tabel tidak cukup bagus di peramban seluler. Tentu, iPhone memiliki peramban yang hebat, tetapi semua orang tidak memiliki iPhone. Perenderan tabel bisa menjadi kacang untuk browser modern, tetapi ini adalah sekelompok semangka untuk browser seluler.

Saya pribadi telah menemukan bahwa banyak orang menggunakan terlalu banyak <div>tag, tetapi dalam jumlah sedang, ini bisa sangat bersih dan mudah dibaca. Anda menyebutkan bahwa orang lebih sulit membaca CSS daripada tabel; dalam hal 'kode' yang mungkin benar; tetapi dalam hal membaca konten (view> source) itu jauh lebih mudah untuk memahami struktur dengan stylesheet daripada dengan tabel.

Sepertinya Anda hanya terbiasa dengan tabel dan hanya itu. Menempatkan tata letak dalam tabel membatasi Anda hanya untuk tata letak itu. Dengan CSS Anda dapat memindahkan bit, lihat http://csszengarden.com/ Dan tidak, tata letak biasanya tidak memerlukan banyak div bersarang.

Tanpa tabel untuk tata letak dan semantik HTML yang benar jauh lebih bersih, maka lebih mudah dibaca. Mengapa seseorang yang tidak dapat memahami CSS mencoba membacanya? Dan jika seseorang menganggap dirinya sebagai pengembang web maka pemahaman CSS yang baik adalah suatu keharusan.

Manfaat SEO berasal dari kemampuan untuk memiliki konten paling penting di bagian atas halaman dan memiliki rasio konten-ke-markup yang lebih baik.

http://www.hotdesign.com/seybold/

• 508 Compliance - kemampuan screenreader untuk memahami markup Anda.
• Menunggu render - tabel tidak di-render di browser sampai mencapai akhir </table>elemen.

Seluruh ide seputar markup semantik adalah pemisahan markup dan presentasi, yang mencakup tata letak.

Div tidak mengganti tabel, mereka memiliki kegunaannya sendiri dalam memisahkan konten menjadi blok konten terkait (,). Ketika Anda tidak memiliki keterampilan dan mengandalkan tabel, Anda harus memisahkan konten Anda ke sel untuk mendapatkan tata letak yang diinginkan, tetapi Anda tidak perlu menyentuh markup untuk mencapai presentasi ketika menggunakan markup semantik. Ini sangat penting ketika markup dihasilkan daripada halaman statis.

Pengembang harus berhenti memberikan markup yang menyiratkan tata letak sehingga mereka yang memiliki keterampilan untuk menyajikan konten dapat melanjutkan pekerjaan kami, dan pengembang tidak harus kembali ke kode mereka untuk membuat perubahan saat presentasi perlu diubah.

Ini bukan tentang apakah 'div lebih baik daripada tabel untuk tata letak'. Seseorang yang mengerti CSS dapat menduplikasi desain apa pun menggunakan 'tabel tata letak' dengan cukup mudah. Kemenangan sebenarnya menggunakan elemen HTML untuk apa mereka ada di sana. Alasan Anda tidak akan menggunakan tabel untuk data non-tablular adalah alasan yang sama Anda tidak menyimpan bilangan bulat sebagai karakter string - teknologi bekerja jauh lebih mudah ketika Anda menggunakannya untuk tujuan yang desgined. Jika memang pernah diperlukan untuk menggunakan tabel untuk tata letak (karena kekurangan browser pada awal 1990-an) tentu tidak sekarang.

Alat yang menggunakan tata letak tabel dapat menjadi sangat berat karena jumlah kode yang diperlukan untuk membuat tata letak. Netweaver Portal SAP secara default menggunakan TABLE untuk mengatur tata letak halaman mereka.

Portal produksi SAP di pertunjukan saya saat ini memiliki halaman rumah yang HTML-nya lebih dari 60K dan masuk tujuh tabel, tiga kali dalam halaman. Tambahkan Javascript, penyalahgunaan 16 iframe dengan masalah tabel serupa di dalamnya, CSS yang terlalu berat dll, dan halaman tersebut memiliki berat lebih dari 5MB.

Meluangkan waktu untuk menurunkan berat halaman sehingga Anda dapat menggunakan bandwidth Anda untuk melakukan aktivitas menarik dengan pengguna sepadan dengan usaha.

Layak mencari tahu CSS dan divs sehingga kolom konten pusat memuat dan merender sebelum bilah sisi dalam tata letak halaman. Tetapi jika Anda kesulitan menggunakan div mengambang untuk meluruskan logo secara vertikal dengan beberapa teks sponsor, cukup gunakan tabel dan lanjutkan dengan kehidupan. Agama taman Zen tidak banyak menghasilkan uang.

Ide memisahkan konten dari presentasi adalah untuk mempartisi aplikasi sehingga berbagai jenis pekerjaan mempengaruhi blok kode yang berbeda. Ini sebenarnya tentang manajemen perubahan. Tetapi standar pengkodean hanya dapat memeriksa keadaan kode saat ini secara dangkal.

Log perubahan untuk aplikasi yang tergantung pada standar pengkodean untuk "memisahkan konten dari presentasi" akan menunjukkan pola perubahan paralel di silo vertikal. Jika perubahan ke "konten" selalu disertai dengan perubahan ke "presentasi", seberapa sukses partisi?

Jika Anda benar-benar ingin mempartisi kode Anda secara produktif, gunakan Subversion dan tinjau log perubahan Anda. Kemudian gunakan teknik pengkodean paling sederhana - divs, tabel, JavaScript, termasuk, fungsi, objek, lanjutan, apa pun - untuk menyusun aplikasi sehingga perubahan sesuai dengan cara yang sederhana dan nyaman.

Karena NERAKA untuk memelihara situs yang menggunakan tabel, dan membutuhkan BANYAK lebih lama untuk kode. Jika Anda takut divs mengambang, ikuti kursus di dalamnya. Mereka tidak sulit untuk dipahami dan mereka sekitar 100 kali lebih efisien dan satu juta kali lebih sedikit rasa sakit di pantat (kecuali jika Anda tidak mengerti mereka - tapi hei, selamat datang di dunia komputer).

Siapa pun yang mempertimbangkan melakukan tata letak mereka dengan meja lebih baik tidak mengharapkan saya untuk mempertahankannya. Ini adalah cara paling terbelakang untuk membuat situs web. Terima kasih Tuhan kami punya alternatif yang jauh lebih baik sekarang. Saya tidak akan pernah kembali.

Sangat menakutkan bahwa beberapa orang mungkin tidak menyadari waktu dan manfaat energi dari membuat situs menggunakan alat modern.

Tabel secara umum tidak lebih mudah atau lebih mudah dikelola daripada CSS. Namun, ada beberapa yang spesifik masalah tata letak mana tabel memang solusi paling sederhana dan paling fleksibel.

CSS jelas lebih disukai dalam kasus-kasus di mana markup presentasi dan CSS mendukung jenis desain yang sama, tidak ada orang yang berpikiran sehat akan berpendapat bahwa font-tag lebih baik daripada menentukan tipografi dalam CSS, karena CSS memberi Anda kekuatan yang sama daripadafont -tag, tetapi dalam cara yang jauh lebih bersih.

Masalah dengan tabel, bagaimanapun, pada dasarnya adalah bahwa model tata letak tabel di CSS tidak didukung di Microsoft Internet Explorer. Tabel dan CSS karenanya tidak setara dalam kekuasaan. Bagian yang hilang adalah perilaku tabel seperti grid , di mana tepi sel sejajar baik secara vertikal dan horizontal, sementara sel masih berkembang untuk mengandung konten mereka. Perilaku ini tidak mudah dicapai dalam CSS murni tanpa hardcoding beberapa dimensi, yang membuat desain menjadi kaku dan rapuh (selama kita harus mendukung Internet Explorer - di browser lain ini mudah dicapai dengan menggunakandisplay:table-cell ).

Jadi sebenarnya bukan pertanyaan apakah tabel atau CSS lebih disukai, tetapi ini adalah pertanyaan untuk mengenali kasus-kasus tertentu di mana penggunaan tabel dapat membuat tata letak lebih fleksibel.

Alasan paling penting untuk tidak menggunakan tabel adalah aksesibilitas. Pedoman Aksesibilitas Konten Web http://www.w3.org/TR/WCAG10/ saran untuk menggunakan tabel untuk tata letak. Jika Anda khawatir tentang aksesibilitas (dan dalam beberapa kasus Anda mungkin secara hukum wajib), Anda harus menggunakan CSS bahkan jika tabel lebih sederhana. Perhatikan bahwa Anda selalu dapat membuat tata letak yang sama dengan CSS seperti dengan tabel, mungkin hanya membutuhkan lebih banyak pekerjaan.

Saya terkejut melihat beberapa masalah belum dibahas, jadi inilah 2 sen saya, di samping semua poin yang sangat valid yang dibuat sebelumnya:

.1. CSS & SEO:

a) CSS digunakan untuk memiliki dampak yang sangat signifikan pada SEO dengan memungkinkan untuk memposisikan konten di halaman di mana pun Anda inginkan. Beberapa tahun yang lalu, Mesin Pencari memberi penekanan signifikan pada faktor "di halaman". Sesuatu di bagian atas halaman dianggap lebih relevan dengan halaman daripada sesuatu yang terletak di bagian bawah. "Bagian atas halaman" untuk seekor laba-laba berarti "di awal kode". Dengan menggunakan CSS, Anda dapat mengatur konten yang kaya kata kunci di awal kode, dan tetap memposisikannya di mana pun Anda suka di halaman. Ini masih agak relevan, tetapi faktor halaman kurang dan kurang penting untuk peringkat halaman.

b) Ketika tata letak dipindahkan ke CSS, halaman HTML lebih ringan dan karenanya memuat lebih cepat untuk spider mesin pencari. (spider tidak perlu repot mengunduh file css eksternal). Halaman pemuatan cepat adalah pertimbangan peringkat penting untuk beberapa mesin pencari, termasuk Google

c) Pekerjaan SEO seringkali membutuhkan pengujian dan perubahan hal-hal, yang jauh lebih nyaman dengan tata letak berbasis CSS

.2. Konten yang dihasilkan:

Tabel jauh lebih mudah dihasilkan secara program dari pada tata letak CSS yang setara.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

Membuat tabel sederhana dan aman. Itu mandiri dan terintegrasi dengan baik dalam template apa pun. Untuk melakukan hal yang sama dengan CSS jauh lebih sulit dan mungkin tidak bermanfaat sama sekali: sulit untuk mengedit lembar gaya CSS pada penerbangan, dan menambahkan inline gaya tidak berbeda dari menggunakan tabel (konten tidak terlepas dari tata letak).

Selanjutnya, ketika sebuah tabel dihasilkan, konten (dalam variabel) sudah dipisahkan dari tata letak (dalam kode), membuatnya mudah untuk dimodifikasi.

Ini adalah salah satu alasan mengapa beberapa situs web yang dirancang dengan sangat baik (misalnya SO) masih menggunakan tata letak tabel.

Tentu saja, jika hasilnya perlu ditindaklanjuti melalui JavaScript, divs sepadan dengan masalahnya.

.3. Pengujian konversi cepat

Saat mencari tahu apa yang berfungsi untuk audiens tertentu, akan bermanfaat untuk dapat mengubah tata letak dengan berbagai cara untuk mencari tahu apa yang mendapatkan hasil terbaik. Layout berbasis CSS membuat segalanya jauh lebih mudah

.4. Solusi berbeda untuk masalah yang berbeda

Tabel tata letak biasanya tidak disetujui karena "semua orang tahu divs & CSS" adalah cara yang harus dilakukan.

Namun faktanya tetap bahwa tabel lebih cepat untuk dibuat, lebih mudah dipahami dan lebih kuat daripada kebanyakan tata letak CSS. (Ya, CSS bisa sekuat itu, tetapi pandangan cepat melalui internet pada browser yang berbeda dan resolusi layar menunjukkan itu tidak sering terjadi)

Ada banyak kerugian pada meja, termasuk perawatan, kurangnya fleksibilitas ... tetapi jangan membuang bayi dengan air mandi. Ada banyak kegunaan profesional untuk solusi yang cepat dan dapat diandalkan.

Beberapa waktu yang lalu, saya harus menulis ulang tata letak CSS yang bersih dan sederhana menggunakan tabel karena sebagian besar pengguna akan menggunakan versi IE yang lebih lama dengan dukungan yang sangat buruk untuk CSS

Saya, misalnya, sakit dan lelah dengan reaksi spontan itu, "Oh, tidak! Meja untuk tata letak!"

Adapun "itu tidak dimaksudkan untuk tujuan itu dan karena itu Anda tidak boleh menggunakannya dengan cara ini" kerumunan, bukankah itu kemunafikan? Apa pendapat Anda tentang semua trik CSS yang harus Anda gunakan untuk membuat darn berfungsi di sebagian besar browser? Apakah mereka dimaksudkan untuk tujuan itu?