it-swarm-id.com

Mengapa tidak menggunakan tabel untuk tata letak di HTML?

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 bagus untuk memisahkan konten dari tata letak
    Tapi ini 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 tabel kurang dapat dirawat? Saya pikir menggunakan tabel adalah lebih mudah daripada menggunakan divs dan CSS.

    Ngomong-ngomong ... mengapa menggunakan div atau rentang pemisahan 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 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.

  • Perbaikan 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 itu penyalahgunaan dari CSS.

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

665
Benno Richters

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

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

Itu sama sekali tidak salah karena HTML dirancang dengan sengaja. 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 elemen <table> hari ini, mungkin ada besok karena cara vendor browser menerapkan perlakuan khusus terhadap elemen tersebut. Setelah semua, mereka tahu bahwa "elemen <table> hanya untuk data tabular" dan mungkin menggunakan fakta ini untuk meningkatkan mesin rendering, dalam proses secara halus mengubah bagaimana perilaku <table>s, dan dengan demikian memecahkan kasus di mana ia 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 .

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[ kutipan diperlukan ]. Tabel itu adalah sebenarnya kurang dapat dipertahankan. Menggunakan tabel untuk tata letak berarti bahwa mengubah tata letak perusahaan pada kenyataannya berarti mengubah setiap halaman. Ini bisa sangat mahal. Di sisi lain, penggunaan bijaksana dari HTML bermakna bermakna dikombinasikan dengan CSS mungkin membatasi perubahan seperti 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.

<div>s yang bersarang sangat anti-pola seperti tata letak tabel. 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 masuk akal. 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.

497
Konrad Rudolph

Inilah jawaban programmer saya dari simliar thread

Semantik 101

Pertama lihat kode ini dan pikirkan 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 semantik salah. 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 yang dimaksud dari elemen <table>. Dalam kasus kedua, Anda tidak mempresentasikan data tabular - Anda (salah) menggunakan elemen <table> untuk mencapai tujuan presentasi.

Kesimpulan

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

290
Carl Camera

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.

104
erlando

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, diperlukan 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 adalah 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.

91
Joel Coehoorn

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.

54
James Curran

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 Nice. Untuk halaman cetak Anda dapat dengan tenang menekan navigasi tanpa harus membuat halaman yang ramah-printer, misalnya.

48
expedient

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

  • Ini IS BANYAK yang 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 (mis. 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]

45
Ben Scheirman

Ada baiknya memisahkan konten dari tata letak
Tapi ini argumen yang keliru; Berpikir Klise

Ini argumen yang keliru karena tabel HTML adalah tata letak! Konten adalah data dalam tabel, presentasi 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 div 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 hanya berfungsi.

Namun, kami memiliki audiensi yang sangat tertutup untuk produk kami (kami menjual perangkat keras dengan antarmuka web) dan masalah aksesibilitas tidak menjadi perhatian 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.

36
17 of 26

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 benar-benar 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 formulir 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 itu 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 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!

23
Tim Black

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 yang satu 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 menyediakan penempatan jaringan multi-sumbu 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.

21
needlestack

Menurut kepatuhan 508 (untuk pembaca layar untuk gangguan visual), tabel hanya boleh 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 div, Anda dapat menguliti semuanya bersama-sama menggunakan CSS. Mereka hanya sedikit lebih sakit untuk duduk seperti yang Anda inginkan.

19
Rob

Inilah bagian 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.

Hal lain untuk 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.

18
Ross

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 arti dari sudut pandang semantik .

14
Guido

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 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 secara drastis mengubah tata letak , dan pikirkan 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 merasa 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, lebih mudah untuk men-tweak hal-hal seperti jarak antara berbagai blok, dan ukuran relatifnya.

13
MB.

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 implementasi 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 membatalkan 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 perdebatan 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?

13
DLH

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 why, 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.

13
Radu094

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 lakukan peduli, dan mereka sama pentingnya dalam banyak situasi. Kode semantik lebih mudah bagi sistem non-cerdas untuk diuraikan dan diproses.

12
ceejayoz

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 kasus Edge, 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.

8
Kent Fredric

Fleksibilitas tata letak
Bayangkan Anda membuat halaman dengan banyak thumbnail.
DIVs:
Jika Anda menempatkan setiap thumbnail di DIV, melayang ke kiri, mungkin 10 di antaranya pas di 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. Tata letak secara otomatis akan menyesuaikan.
(TABEL: Tempel sel baru ke baris ketiga. ps! Sekarang ada terlalu banyak item 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.)

7
Nathan Long

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

7
Thomas Wagner

Juga, jangan lupa, tabel tidak cukup bagus di peramban seluler. Tentu, iPhone memiliki peramban yang cepat, 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 tag <div>, tetapi tidak berlebihan, 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.

5
Swati

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 tidak biasanya membutuhkan 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 yang baik tentang CSS 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/

5
Rimantas

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 perlu berhenti menyediakan 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.

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

Ini bukan tentang apakah 'div lebih baik daripada tabel untuk tata letak'. Seseorang yang mengerti CSS dapat menduplikasi desain apa pun menggunakan 'tabel layout' 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.

4
domgblackwell

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 dengan cara yang 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.

3
Patrick May

Tabel tidak secara umum lebih mudah atau lebih mudah dikelola daripada CSS. Namun, ada beberapa masalah tata letak spesifik di 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 waras yang akan berargumen bahwa font- tag lebih baik daripada menentukan tipografi dalam CSS, karena CSS memberi Anda kekuatan yang sama daripada font- tag, tetapi dengan cara yang jauh lebih bersih.

Masalah dengan tabel, bagaimanapun, pada dasarnya adalah bahwa model tata letak tabel dalam CSS tidak didukung di Microsoft Internet Explorer. Tabel dan CSS karenanya tidak setara dalam kekuasaan. Bagian yang hilang adalah perilaku seperti grid dari tabel, di mana tepi sel sejajar baik secara vertikal dan horizontal, sementara sel masih berkembang untuk mengandung kontennya. Perilaku ini tidak mudah dicapai dalam CSS murni tanpa hardcoding beberapa dimensi, yang membuat desain menjadi kaku dan rapuh (selama kami harus mendukung Internet Explorer - di browser lain ini mudah dicapai dengan menggunakan display: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 againt 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 dapat selalu membuat tata letak yang sama dengan CSS seperti pada tabel, mungkin saja membutuhkan lebih banyak pekerjaan.

3
JacquesB

Alat yang menggunakan tata letak tabel bisa menjadi sangat berat karena jumlah kode yang diperlukan untuk membuat tata letak. Netweaver Portal SAP secara default menggunakan TABLE untuk menata 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.

3
Mike Cornell

Manipulasi DOM sulit dalam tata letak berbasis tabel.

Dengan div semantik:

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

Dengan tabel:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

Sekarang, memang, contoh kedua agak bodoh, dan Anda selalu dapat menerapkan ID atau kelas ke tabel atau elemen td, tapi itu akan menambah nilai semantik, yang merupakan lawan tabel yang begitu keras menentang.

3
Chris Fletcher

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), sehingga 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 berguna 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 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 harus 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 itu dimaksudkan untuk tujuan itu?

3
Sylverdrag

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.

3
Chuck Le Butt
  1. Cobalah untuk menggabungkan/membagi 10/20 sesuatu deep colspan/rowspan. Lebih dari sekali aku harus menekan naluriku untuk memulai pertengkaran dengan seseorang. [?!]
  2. Cobalah untuk mengubah urutan kode sumber tanpa mengubah urutan yang terlihat. [SEO, kegunaan, ...]
  3. Halaman yang sangat (sangat sederhana) yang kami lihat adalah ~ 150K. Saya yakin hampir bisa dibelah dua menggunakan CSS yang tepat. [SEO (Ya, SEO, baca spesifikasi Google terbaru dll), perfo, ...]
  4. Cobalah membuat templat iterator yang dapat bekerja dengan lebar apa pun.
  5. Diskusi masalah dalam media berbasis tabel ini dari SO dapat menyebabkan singularitas dan menghancurkan kita semua
2
Halil Özgür

Masalah pemisahan presentasi dan konten secara ketat membuat saya merasa hampir analog dengan memisahkan file header dari file implementasi di C++. Masuk akal, tetapi bisa juga menyebalkan. Saksikan Java dan C # di mana kelas didefinisikan dalam satu file sumber. Para penulis bahasa yang lebih baru memperhatikan sesuatu yang menyebabkan sakit kepala programmer dan mereka menyingkirkannya. Tampaknya itulah inti dari diskusi ini. Satu sisi mengatakan CSS terlalu sulit, sisi lain mengatakan seseorang harus menjadi master CSS.

Untuk masalah tata letak yang sederhana mengapa tidak membengkokkan aturan yang mengatakan presentasi harus sepenuhnya terpisah? Bagaimana dengan tag baru (atau ekstensi ke tag div) yang memungkinkan kita untuk mengontrol presentasi secara langsung dalam HTML? Lagipula, bukankah kita sudah membocorkan presentasi ke dalam HTML? Lihatlah h1, h2 ... h6. Kita semua tahu presentasi kontrol ini.

Kemampuan membaca kode (dan HTML adalah kode) sangat penting. Gurus cenderung mengabaikan betapa pentingnya membuat lingkungan pemrograman sebanyak mungkin diakses oleh massa. Sangat picik untuk berpikir bahwa hanya programmer yang penting.

2
user825628

Masalah besar bagi saya adalah bahwa tabel, terutama tabel bersarang, membutuhkan waktu lebih lama untuk dibuat daripada implementasi css yang ditata dengan baik. (Anda bisa membuat css sama lambatnya).

Semua browser membuat css lebih cepat karena setiap div adalah elemen yang terpisah, sehingga layar dapat memuat saat pengguna membaca. (Untuk kumpulan data besar, dll). Saya telah menggunakan css bukan tabel dalam contoh itu bahkan tidak berurusan dengan tata letak.

Tabel bersarang (tabel di dalam sel, dll) tidak akan merender ke jendela browser sampai "/ tabel" terakhir ditemukan. Lebih buruk lagi - tabel yang tidak didefinisikan dengan baik suatu saat nanti bahkan tidak akan ditampilkan! Atau ketika itu terjadi, hal-hal buruk terjadi. (tidak colspanning dengan benar dengan "TD" dll.)

Saya menggunakan tabel untuk sebagian besar hal, tetapi ketika datang ke data besar dan keinginan untuk memiliki layar membuat cepat untuk pengguna akhir - saya mencoba yang terbaik untuk memanfaatkan apa yang ditawarkan CSS.

2
Tim Fischer

Saya harus melakukan situs dengan kedua cara itu, ditambah yang ketiga, tata letak "hibrid" yang ditakuti dengan tabel, div dan gaya: Divs/CSS menang, dengan mudah.

Anda harus membuat sarang tiga dalam untuk mencocokkan berat kode hanya satu sel tabel, langsung dari kelelawar. Efek itu berskala dengan tabel bersarang.

Saya juga lebih suka membuat satu perubahan tata letak, vs satu perubahan untuk setiap halaman di situs saya.

Saya memiliki kendali penuh atas setiap aspek presentasi dengan divs/css. Tabel mengacaukannya dengan cara yang mengerikan, terutama di IE, browser yang saya belum pernah memiliki opsi untuk tidak mendukung.

Waktu saya untuk pemeliharaan atau pendesainan ulang situs divs/css adalah sebagian kecil dari apa yang akan ada di tabel.

Akhirnya, saya dapat berinovasi banyak, tata letak yang dapat diubah dengan CSS dan hampir semua bahasa scripting. Itu tidak mungkin bagiku dengan meja.

Semoga beruntung dengan ROI Anda saat Anda membuat keputusan itu.

2
John Dunagan

Salah satu contoh: Anda ingin memusatkan area konten utama dari sebuah halaman, tetapi untuk mengandung float di dalamnya, itu harus melayang. Tidak ada "float: center" di CSS.

Itu bukan satu-satunya cara untuk "mengandung pelampung" di dalam elemen terpusat. Jadi, sama sekali bukan argumen yang bagus!

Di satu sisi, itu adalah premis palsu, hal "divs vs tables".

Pembagian halaman yang cepat dan kotor menjadi tiga kolom? Tabel adalah lebih mudah, jujur ​​saja. Tetapi tidak ada profesional yang menggunakannya lagi untuk tata letak, karena mereka mengunci posisi elemen halaman ke dalam halaman.

Argumen yang sebenarnya adalah "posisi dilakukan oleh CSS (mudah-mudahan dalam file jarak jauh)" sebagai lawan dari "posisi dilakukan oleh HTML di halaman". Tentunya semua orang dapat melihat manfaat dari yang pertama bertentangan dengan yang kedua?

  1. Ukuran - jika tata letak halaman Anda dalam HTML, di halaman, itu tidak bisa di-cache, dan itu harus diulang pada setiap halaman. Anda akan menghemat banyak bandwidth jika tata letak Anda ada dalam file CSS yang di-cache, bukan di halaman.
  2. Beberapa pengembang dapat bekerja pada halaman yang sama pada saat yang sama - saya bekerja pada HTML, yang lainnya bekerja pada CSS. Tidak diperlukan repositori, tidak ada masalah dengan penulisan berlebihan, penguncian file dll.
  3. Membuat perubahan lebih mudah - akan ada masalah dengan tata letak di browser yang berbeda, tetapi Anda hanya perlu memperbaiki satu file, file CSS, untuk memilahnya.
  4. Aksesibilitas, seperti yang disebutkan sebelumnya. Tabel menganggap tata letak dua dimensi berfungsi untuk semua orang. Itu bukan bagaimana beberapa pengguna melihat konten Anda dan itu bukan bagaimana Google melihat konten Anda.

Pertimbangkan ini:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

yang mewakili dua baris tabel dengan 6 sel. Seseorang yang dapat melihat tata letak tabel 2-D akan melihat keterangan di bawah setiap gambar. Tetapi menggunakan sintesis ucapan, atau PDA, dan untuk spider mesin pencari, itu

picture picture picture caption caption caption

dan hubungan, yang jelas dengan tabel di tempatnya, menghilang.

Apakah DIV dan CSS lebih baik untuk tugas hanya meletakkan persegi panjang pada halaman HTML untuk mencapai desain yang diberikan dalam waktu sesingkat mungkin? Tidak, mereka mungkin tidak. Tapi saya tidak dalam bisnis cepat menyusun empat persegi panjang untuk mencapai desain yang diberikan. Saya sedang memikirkan gambaran yang jauh lebih besar.

2
AmbroseChapel

Pemisahan antara konten dan tata letak membuatnya juga lebih mudah untuk menghasilkan tata letak ramah-printer atau hanya skin (gaya) yang berbeda untuk situs Anda, tanpa harus membuat file html yang berbeda. Beberapa browser (seperti Firefox) bahkan mendukung pemilihan stylesheet dari menu tampilan.

Dan saya pikir itu lebih mudah untuk mempertahankan tata letak yang tableless. Anda tidak perlu khawatir tentang rowspans, colspans, dll. Anda cukup membuat beberapa container-divs dan menempatkan konten di tempat yang Anda butuhkan. Dan itu mengatakan saya pikir itu juga lebih mudah dibaca (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).

Hanya sedikit 'trik' yang harus Anda pelajari (dan begitu Anda menguasai triknya, saya pikir itu lebih mudah dan lebih masuk akal).

2
Grad van Horck

Untuk menanggapi argumen "tabel lebih lambat" - Anda berpikir merender waktu, yang merupakan metrik yang salah. Sangat sering, pengembang akan menulis tabel besar untuk melakukan seluruh tata letak halaman - yang secara signifikan menambah ukuran halaman yang akan diunduh. Suka atau tidak, masih ada satu ton pengguna dialup di luar sana.

Lihat juga: terlalu banyak menggunakan kondisi tampilan

1
Greg Hurlman

Dari pengalaman masa lalu, saya harus memilih DIV. Bahkan dalam OOP, tujuan utamanya adalah untuk mengurangi kopling antar objek, sehingga konsep ini dapat diterapkan pada DIVS dan tabel. Tabel digunakan untuk menyimpan data, bukan untuk mengaturnya di sekitar halaman. DIV dirancang khusus untuk mengatur item di sekitar halaman, sehingga desain harus menggunakan DIV, tabel harus digunakan untuk menyimpan data.

Juga, mengedit situs web yang dibuat dengan tabel sangat sulit (menurut saya)

1
Richard

posisi div dan CSS memungkinkan desain yang lebih fleksibel, yang mengarah pada modifikasi dan templating halaman web Anda yang lebih mudah.

Yang mengatakan, jika Anda tidak tertarik pada fleksibilitas kemudian menggunakan tabel daripada beberapa div yang diubah menjadi tabel oleh CSS jelas jauh lebih mudah dan lebih cepat untuk mengetuk. Saya cenderung menggunakan tabel ketika mengetuk desain hanya untuk membuatnya tampak sedikit lebih cepat.

1
workmad3

Ketika saya mendesain tata letak saya menggunakan CSS, saya biasanya memberikan div bagian root (body level) sendiri, dan menggunakan posisi relatif/absolut untuk menempatkannya di tempat yang tepat. Ini sedikit lebih fleksibel daripada tabel, karena saya tidak terbatas pada pengaturan yang bisa saya wakili menggunakan baris dan kolom.

Selain itu, jika saya memutuskan bahwa saya ingin mengatur ulang tata letak (katakan saya ingin bilah navigasi berada di sebelah kanan sekarang), saya cukup pergi dan mengubah posisi elemen di satu tempat (file CSS) dan HTML tidak t harus berubah. Jika saya melakukan itu dengan tabel, saya harus masuk dan mencari informasi dan melakukan banyak atribut modding dan menyalin dan menempel untuk mendapatkan efek yang sama.

Bahkan, menggunakan CSS, saya bahkan dapat memiliki pengguna saya memilih bagaimana mereka ingin tata letak mereka bekerja. Selama ukuran umum area konten tidak berubah, saya sepenuhnya setuju dengan menggunakan sedikit skrip PHP untuk menampilkan CSS saya berdasarkan preferensi pengguna, dan memungkinkan mereka mengatur ulang situs untuk kesukaan mereka sendiri. Sekali lagi, mungkin dengan meja, tetapi jauh lebih sulit untuk dipelihara.

Akhirnya, CSS memungkinkan satu manfaat UTAMA yang tabel tidak akan pernah berikan: kemampuan untuk memformat ulang konten berdasarkan perangkat tampilan. CSS memungkinkan saya untuk menggunakan set gaya yang sama sekali berbeda (termasuk posisi, pemformatan, dll) untuk printer daripada yang saya gunakan untuk monitor. Ini juga dapat diperluas ke media lain, contoh yang bagus adalah Opera Show, yang memungkinkan halaman CSS yang dirancang dengan cerdas (dan sangat standar) untuk dilihat sebagai tampilan slide.

Jadi pada akhirnya, fleksibilitas dan manajemen adalah pemenang yang sebenarnya. Secara umum, CSS memungkinkan Anda untuk berbuat lebih banyak dengan tata letak. Tidak ada secara teknis tidak standar tentang tata letak berbasis tabel, tetapi mengapa Anda ingin membatasi diri?

1
Nicholas Flynt

Di masa lalu, pembaca layar dan perangkat lunak aksesibilitas lainnya mengalami kesulitan menangani tabel secara efisien. Sampai batas tertentu, hal ini ditangani pembaca layar oleh pembaca yang beralih antara mode "tabel" dan mode "tata letak" berdasarkan apa yang dilihatnya di dalam tabel. Ini sering salah, sehingga pengguna harus beralih mode secara manual saat menavigasi tabel. Bagaimanapun, tabel besar, sering bersarang tinggi itu, dan sebagian besar, masih sangat sulit dinavigasi melalui menggunakan pembaca layar.

Hal yang sama berlaku ketika divs atau elemen tingkat blok lainnya digunakan untuk membuat ulang tabel dan sangat bersarang. Tujuan dari divs adalah untuk digunakan sebagai elemen pembentuk dan tata letak, dan dengan demikian, dimaksudkan digunakan untuk menyimpan informasi yang serupa, dan meletakkannya di layar untuk pengguna visual. Ketika pembaca layar menemukan halaman, ia sering mengabaikan informasi tata letak apa pun, baik berbasis CSS, maupun berbasis atribut html (Ini tidak berlaku untuk semua pembaca layar, tetapi untuk yang paling populer, seperti JAWS, Windows Eyes, dan Orca untuk Linux itu).

Untuk tujuan ini, data tabular, yaitu data yang masuk akal logis untuk dipesan dalam dua dimensi atau lebih, dengan beberapa jenis header, paling baik ditempatkan dalam tabel, dan menggunakan div untuk mengelola tata letak konten pada halaman. (Cara lain untuk memikirkan apa "data tabular" adalah dengan mencoba menggambarnya dalam bentuk grafik ... jika Anda tidak bisa, kemungkinan itu tidak direpresentasikan dalam tabel)

Akhirnya, dengan tata letak berbasis tabel, untuk mencapai kontrol yang baik atas posisi elemen pada halaman, tabel yang sangat bersarang sering digunakan. Ini memiliki dua efek: 1.) Peningkatan ukuran kode untuk setiap halaman - Karena navigasi dan struktur umum sering dilakukan dengan tabel, kode yang sama dikirim melalui jaringan untuk setiap permintaan, sedangkan tata letak berbasis div/css menarik file css lebih dari sekali, dan kemudian gunakan div yang lebih sedikit. 2.) Tabel yang sangat bersarang membutuhkan waktu lebih lama bagi browser klien untuk diurai, yang mengarah ke waktu muat yang sedikit lebih lambat.

Dalam kedua kasus tersebut, peningkatan bandwidth "last mile", serta komputer pribadi yang jauh lebih cepat mengurangi faktor-faktor ini, tetapi tidak kalah pentingnya, mereka masih merupakan masalah yang ada di banyak situs.

Dengan semua ini dalam pikiran, seperti yang orang lain katakan, tabel lebih mudah, karena mereka lebih berorientasi pada grid, memungkinkan untuk kurang berpikir. Jika situs yang dimaksud tidak diperkirakan panjang, atau tidak akan dipertahankan, mungkin masuk akal untuk melakukan apa yang paling mudah, karena itu mungkin yang paling hemat biaya. Namun, jika userbase yang diantisipasi mungkin mencakup sebagian besar individu yang cacat, atau jika situs tersebut akan dipelihara oleh orang lain untuk waktu yang lama, menghabiskan waktu di depan untuk melakukan hal-hal secara ringkas, cara yang dapat diakses mungkin memberikan hasil lebih pada akhirnya.

1
cdeszaq

Saya masih tidak begitu mengerti bagaimana divs/CSS memudahkan untuk mengubah desain halaman ketika Anda mempertimbangkan jumlah pengujian untuk memastikan perubahan bekerja pada semua browser, terutama dengan semua peretasan dan sebagainya. Ini adalah proses yang sangat membuat frustrasi dan membosankan yang menghabiskan banyak waktu dan uang. Untungnya 508 undang-undang hanya berlaku untuk Amerika Serikat (tanah bebas - ya benar) dan karena saya berbasis di Inggris, saya dapat mengembangkan situs web dengan gaya apa pun yang saya pilih. Bertentangan dengan kepercayaan populer (AS), undang-undang yang dibuat di Washington tidak berlaku untuk seluruh dunia - syukurlah untuk itu. Itu pasti hari yang baik di dunia desain web saat undang-undang mulai berlaku. Saya pikir saya menjadi semakin sinis ketika saya semakin tua dengan 25 tahun di industri TI tetapi saya merasa yakin undang-undang semacam ini hanya untuk melindungi pekerjaan. Pada kenyataannya siapa pun dapat mengetuk halaman web yang masuk akal dengan beberapa tabel. Dibutuhkan lebih banyak upaya dan pengetahuan untuk melakukan ini dengan DIVs/CSS. Dalam pengalaman saya, mungkin butuh berjam-jam Googling untuk menemukan solusi untuk masalah yang cukup sederhana dan membaca artikel yang tidak bisa dipahami di forum yang penuh dengan fanatik idealistik, semuanya berdebat tentang cara yang 'benar' untuk melakukan sesuatu. Anda tidak bisa hanya mencelupkan kaki Anda ke dalam air dan membuat segala sesuatunya berfungsi dengan baik dalam setiap kasus. Bagi saya juga kelihatannya kurangnya panduan definitif untuk menggunakan DIVS/CSS "out of the box", yang berlaku untuk semua situasi, bekerja pada browser, dan ditulis menggunakan bahasa 'normal' tanpa ada geek yang berbicara, juga berbau seperti sedikit proteksionisme.
Saya seorang pengembang aplikasi dan saya akan mengatakan butuh hampir dua kali lebih lama untuk mencari tahu masalah tata letak dan menguji terhadap semua browser daripada untuk membuat aplikasi dasar, merancang dan mengimplementasikan objek bisnis, dan membuat database ujung belakang. Waktu saya = uang, baik untuk saya dan pelanggan saya sama, jadi saya minta maaf jika saya tidak menolak semua argumen pro DIV/CSS yang mendukung pemotongan biaya dan memberikan nilai uang untuk pelanggan saya. Mungkin ini cara para pengembang bekerja, tetapi bagi saya tampaknya lebih mudah untuk mengubah struktur tabel yang kompleks daripada memodifikasi DIVs/CSS. Untungnya sekarang tampak bahwa solusi untuk masalah ini sekarang tersedia - yang disebut WPF.

1
Tim Black

Saya pikir tidak ada yang peduli bagaimana sebuah situs web dirancang/diimplementasikan ketika berperilaku hebat dan bekerja cepat.

Saya menggunakan tag "table" dan "div"/"span" di markup HTML.

Biarkan saya memberi Anda beberapa argumen mengapa saya memilih div:

  1. untuk tabel Anda harus menulis setidaknya 3 tag (tabel, tr, td, thead, tbody), untuk desain yang bagus, kadang-kadang Anda memiliki banyak tabel bersarang

  2. Saya suka memiliki komponen di halaman. Saya tidak tahu bagaimana menjelaskan dengan tepat tetapi akan mencoba. Misalkan Anda memerlukan logo dan ini harus ditempatkan, hanya sebagian kecil, di atas konten halaman berikutnya. Menggunakan tabel Anda harus memotong 2 gambar dan memasukkannya ke dalam 2 TDs yang berbeda. Menggunakan DIV Anda dapat memiliki CSS sederhana untuk mengaturnya seperti yang Anda inginkan. Solusi mana yang paling Anda sukai?

  3. ketika lebih dari 3 tabel bersarang untuk melakukan sesuatu, saya berpikir untuk mendesain ulang menggunakan DIVs

TETAPI saya masih menggunakan tabel untuk:

  1. data tabular

  2. konten yang berkembang sendiri

  3. solusi cepat (prototipe), karena model kotak DIV berbeda di setiap browser, karena banyak generator menggunakan tabel, dll

1
Dani

Dengan masih menggunakan tabel untuk tata letak, kami kehilangan inovasi di sisi div.

Banyak yang datang dengan solusi yang membuat membuat layout untuk divs lebih mudah. Yang paling populer adalah arsitektur grid. Ada generator tata letak dinamis berdasarkan arsitektur ini. Lihat: 1) 960.gs dan (http://grids.heroku.com/) 2) cetak biru dan banyak yang terlambat.

Saya belum melihat banyak inovasi dalam hal arsitektur dan alat-alat dengan tata letak tabel.

Saya akan mengatakan, semua teori di samping, tata letak praktis dengan CSS dan divs lebih cepat. Sebaliknya inovasi dalam arah ini membuatnya lebih mudah daripada apa pun.

1
Pixelgrey

Tabel baik untuk HTML yang Anda buat bersama untuk sesuatu yang sederhana atau sementara. Jika Anda membangun situs web berskala besar, Anda harus menggunakan div dan CSS, karena akan lebih mudah untuk mempertahankannya seiring berjalannya waktu seiring perubahan situs web Anda.

1
Adam Rosenfield

1: Ya, pengguna Anda peduli. Jika mereka menggunakan pembaca layar, itu akan hilang. Jika saya menggunakan alat lain yang mencoba mengekstraksi informasi dari halaman, menemukan tabel yang tidak digunakan untuk mewakili data tabular menyesatkan.

Sebuah div atau rentang dapat diterima untuk memisahkan konten karena itulah arti elemen-elemen it. Ketika saya, mesin pencari, pembaca layar atau apa pun, menemukan elemen tabel, kami berharap ini berarti "berikut ini adalah data tabular, diwakili dalam tabel". Ketika kami menemukan div, kami berharap "ini adalah elemen yang digunakan untuk div ide konten saya menjadi bagian atau area yang terpisah.

2: Keterbacaan: Salah. Jika semua kode presentasi dalam css, saya bisa membaca html dan saya akan mengerti konten halaman. Atau saya bisa membaca css dan memahami presentasinya. Jika semuanya bercampur menjadi satu dalam html, saya harus secara mental mencabut semua bit yang berhubungan dengan presentasi sebelum saya bahkan dapat melihat konten apa dan apa yang tidak. Selain itu, saya takut bertemu dengan pengembang web yang tidak mengerti css, jadi saya benar-benar tidak berpikir itu masalah.

3: Tabel lebih lambat: Ya, benar. Alasannya sederhana: Tabel harus diurai sepenuhnya, termasuk isinya sebelum dapat dirender. Sebuah div dapat dirender ketika ditemui, bahkan sebelum isinya telah diuraikan. Itu artinya div akan muncul sebelum halaman selesai memuat.

Dan kemudian ada bonus, bahwa tabel jauh lebih rapuh, dan tidak akan selalu dirender sama di browser yang berbeda, dengan font dan ukuran font yang berbeda dan semua faktor lain yang dapat menyebabkan tata letak bervariasi. Tabel adalah cara yang sangat baik untuk memastikan bahwa situs Anda akan mati oleh satu atau dua piksel di browser tertentu, tidak akan skala dengan baik ketika pengguna mengubah ukuran font-nya, atau mengubah pengaturannya dengan cara lain.

Tentu saja # 1 adalah yang besar. Banyak alat dan aplikasi bergantung pada makna semantik suatu halaman web. Contoh biasa adalah pembaca layar untuk pengguna tunanetra. Jika Anda seorang pengembang web, Anda akan menemukan bahwa banyak perusahaan besar yang mungkin mempekerjakan Anda untuk bekerja di sebuah situs, wajib bahwa situs tersebut dapat diakses bahkan dalam kasus ini. Yang berarti Anda harus memikirkan makna semantik html Anda. Dengan web semantik, atau lebih relevan, Microformats, rss reader dan alat lainnya, konten halaman Anda tidak lagi dilihat secara eksklusif melalui browser.

1
jalf

Saya minta maaf atas bahasa Inggris saya tetapi inilah alasan lain:

Saya bekerja di beberapa organisasi pemerintah dan alasan nomor satu untuk tidak menggunakan TABLE, adalah untuk orang-orang cacat. Mereka menggunakan mesin untuk "menerjemahkan" halaman web.

Masalahnya adalah "mesin terjemahan" ini tidak dapat membaca situs web jika dilakukan oleh TABLE. Mengapa Karena TABLE adalah untuk DATAS.

pada kenyataannya, jika Anda menggunakan TABEL, untuk setiap SEL Anda harus menentukan beberapa informasi agar orang cacat mengetahui di mana mereka berada di TABEL. Bayangkan Anda memiliki meja besar dan harus memperbesar untuk melihat hanya 1 sel di layar: Anda harus tahu di baris/col mana Anda berada.

Jadi, DIV digunakan, dan orang cacat hanya dapat membaca teks, dan tidak mendapatkan beberapa informasi aneh tentang garis/cols ketika mereka tidak harus ada di sana.

Saya juga lebih suka TABLE untuk membuat templat yang cepat dan mudah, tapi saya sekarang terbiasa dengan CSS ... itu kuat, tetapi Anda benar-benar harus tahu apa yang Anda lakukan ... :)

1
RVeur23

Flex memiliki tag untuk meletakkan barang-barang di kolom vertikal. Saya tidak berpikir mereka memiliki seluruh tata letak/konten yang benar baik untuk jujur, tetapi setidaknya mereka telah menyelesaikan masalah itu.

Seperti banyak orang yang frustrasi dengan CSS, saya juga mencari jawaban yang mudah, ditipu untuk merasa gembira ketika saya pikir saya menemukannya, dan kemudian harapan saya hancur berkeping-keping ketika saya membuka halaman di Chrome. Saya jelas tidak cukup terampil untuk mengatakan itu tidak mungkin, tapi saya belum melihat ada yang menawarkan kode sampel untuk peer review yang membuktikan bahwa itu dapat dilakukan dengan andal.

Jadi bisakah seseorang dari sisi CSS di pulau ini merekomendasikan pola pikir/metodologi untuk meletakkan kolom vertikal? Saya sudah mencoba posisi absolut di baris kedua dan ketiga, tetapi saya berakhir dengan hal-hal yang tumpang tindih di mana-mana dan float memiliki masalah serupa jika halamannya menyusut.

Jika ada jawaban untuk ini saya akan senang - melakukan hal yang benar - Katakan saja sesuatu seperti, "Hei, sudahkah kamu mencoba ** flow: vertikal | horizontal" dan aku benar-benar kehabisan rambutmu.

1
Shanimal

Google memberikan prioritas yang sangat rendah untuk konten teks yang terkandung di dalam tabel. Saya memberikan beberapa saran SEO ke badan amal setempat. Dalam memeriksa situs web mereka itu menggunakan tabel untuk tata letak situs. Melihat setiap halaman, tidak peduli apa kata - atau kombinasi kata - dari halaman mereka yang saya gunakan di kotak pencarian Google, halaman tidak akan muncul di halaman pencarian teratas. (Namun, dengan menentukan situs dalam pencarian halaman dikembalikan.) Satu halaman dengan baik ditulis oleh standar normal untuk menghasilkan hasil yang baik dalam pencarian tetapi tetap tidak muncul di halaman pertama dari hasil pencarian yang dikembalikan . (Perhatikan teks ini berada di dalam tabel.) Saya kemudian melihat bagian teks pada halaman-halaman yang ada di dalam div daripada tabel. Kami menempatkan beberapa kata dari div itu di mesin pencari. Hasil? Itu datang di No.2 di hasil pencarian.

1
Simon Measures

Saya pernah belajar bahwa sebuah tabel dimuat sekaligus, dengan kata lain ketika koneksi lambat, ruang tempat tabel tetap kosong sampai seluruh tabel dimuat, div di sisi lain memuat dari atas ke bawah secepat data datang dan terlepas dari apakah semuanya sudah lengkap atau tidak.

1
Davy

Gunakan tabel ketika Anda perlu memastikan bahwa elemen harus tetap dalam hubungan fisik tertentu di tata letak. Untuk data, tabel umumnya elemen tata letak terbaik untuk digunakan karena Anda tidak ingin kolom Anda membungkus dengan cara yang tidak terduga dan membingungkan asosiasi.

Orang juga bisa berpendapat bahwa elemen non-data yang harus tetap dalam hubungan tertentu juga harus disajikan dalam tabel.

Layout css fleksibel bagus untuk konten yang cocok untuk perangkat seluler dan layar besar serta pencetakan dan jenis tampilan lainnya, tetapi kadang-kadang, konten hanya harus ditampilkan dengan cara yang sangat spesifik dan jika itu mengharuskan pembaca layar tidak dapat dengan mudah mengaksesnya, itu bisa dibenarkan.

1
Sal

Saya mencoba untuk menghindari TABEL sebanyak mungkin, tetapi ketika kami merancang bentuk kompleks yang mencampur beberapa jenis kontrol dan posisi teks yang berbeda dengan kontrol pengelompokan yang cukup ketat, menggunakan DIV tidak dapat diandalkan atau seringkali hampir tidak mungkin.

Sekarang, saya tidak akan berdebat bahwa formulir ini tidak dapat dirancang ulang untuk mengakomodasi tata letak berbasis DIV dengan lebih baik, tetapi bagi sebagian dari mereka pelanggan kami bersikeras untuk tidak mengubah tata letak yang ada dari versi sebelumnya (ditulis dalam ASP klasik) karena sejajar dengan bentuk kertas yang pengguna mereka kenal.

Karena penyajian formulir bersifat dinamis (di mana tampilan beberapa bagian didasarkan pada keadaan kasus atau izin pengguna), kami menggunakan set DIV bertumpuk, masing-masing berisi TABEL elemen formulir yang dikelompokkan secara logis. Setiap kolom dari TABEL dikelompokkan sehingga mereka dapat dikontrol oleh CSS. Dengan begitu kita bisa mematikan bagian yang berbeda dari formulir tanpa masalah tidak menjadi tabel untuk membungkus baris dalam DIVs.

1
CMPalmer

Saya meneliti masalah pembaca layar dan tabel beberapa tahun yang lalu dan muncul dengan informasi yang bertentangan dengan apa yang diyakini sebagian besar pengembang:

http://www.webaim.org/techniques/tables/

"Anda mungkin akan mendengar beberapa pendukung aksesibilitas mengatakan bahwa tabel tata letak adalah ide yang buruk, dan bahwa teknik tata letak CSS harus digunakan sebagai gantinya. Ada kebenaran dalam apa yang mereka katakan, tetapi, jujur ​​saja, menggunakan tabel untuk tata letak bukanlah yang terburuk hal yang dapat Anda lakukan dalam hal aksesibilitas. Orang-orang dengan segala jenis cacat dapat dengan mudah mengakses tabel, selama tabel dirancang dengan mempertimbangkan aksesibilitas. "

1
Rimian

Saya yakin ini adalah masalah yang berhubungan dengan masalah umum. Ketika HTML lahir tidak ada yang bisa meramalkan penggunaannya secara luas. Teknologi lain yang hampir runtuh di bawah bobot keberhasilannya sendiri. Ketika halaman HTML ditulis dalam vi pada terminal teks hijau TABEL adalah semua yang diperlukan untuk menyajikan data kepada pengunjung halaman, dan sebagian besar adalah data yang masuk akal dalam bentuk tabel.

Kita semua tahu bagaimana berbagai hal berevolusi. TABEL keluar dari mode relatif baru-baru ini, tetapi ada banyak alasan untuk lebih memilih tata letak berbasis DIV dan CSS (aksesibilitas bukan yang terakhir). Tentu saja saya tidak dapat menulis CSS untuk menyelamatkan hidup saya :-) dan saya pikir seorang ahli desain grafis harus selalu siap sedia.

Yang mengatakan ... ada banyak data yang harus disajikan dalam sebuah tabel bahkan di situs web modern.

1
Manrico Corazzi

Jika Anda mendukung sudut tabel dalam hal ini, temukan situs dengan tabel dan dapatkan pembaca layar - matikan pembaca layar dan matikan monitor Anda.

Kemudian cobalah dengan situs tata letak div Nice semantik yang benar.

Anda akan melihat perbedaannya.

Tabel tidak jahat jika data di dalamnya tabel untuk tidak menata halaman.

1
Allen Hardy

Sesuai pengetahuan saya tentang tabel, jika terlalu banyak tabel bersarang, ada overhead yang bagus untuk browser dalam merender halaman.

1 - Browser menunggu untuk membuat tampilan akhir menunggu sampai seluruh tabel dimuat.

2 - Algoritma untuk membuat tabel itu mahal dan tidak dalam sekali jalan. Browser, seperti dan ketika, mendapatkan konten, akan mencoba membuat render menghitung lebar dan tinggi konten. Jadi, jika Anda memiliki tabel bersarang, katakanlah, browser telah menerima baris pertama dan sel ke-1 memiliki jumlah konten yang besar dan lebar serta tinggi yang tidak ditentukan, ia akan menghitung lebar dan akan membuat baris pertama, dalam rata-rata saat mendapat baris ke-2 sel # 2 akan memiliki banyak konten! Sekarang akan menghitung lebar untuk sel baris kedua .. Bagaimana dengan yang pertama? Ini akan menghitung lebar secara rekursif. Itu buruk di sisi klien. (Untuk contoh situs) Sebagai seorang programmer, Anda akan mengoptimalkan hal-hal seperti waktu untuk mengambil data, struktur data yang dioptimalkan dan lain-lain. Anda mengoptimalkan hal-hal untuk diselesaikan di sisi server, katakan dalam 2 detik, tetapi pengguna akhir dalam mendapatkan tampilan akhir di 8 detik Apa yang salah di sini? 1. Mungkin jaringannya lambat! Bagaimana jika jaringan baik-baik saja? Apa jaringan mengirimkan konten dalam 1 detik berikutnya? Di mana tambahan 5 detik ini dikonsumsi? Hal yang perlu dikhawatirkan-- Peramban mungkin membutuhkan banyak waktu dalam memperkirakan dan membuat tabel!

Bagaimana cara mengoptimalkan tabel? Jika Anda menggunakan tabel, saya sarankan, selalu tentukan lebar untuk sel. Ini tidak menjamin bahwa browser hanya akan mengambil lebar ini secara membabi buta, tetapi akan sangat membantu browser dalam menentukan lebar awal.

Tetapi, pada akhirnya, div adalah cara yang bagus karena CSS dapat di-cache oleh browser; sementara tabel tidak di-cache!

1
Biranchi Panda

Tabel yang digunakan sebagai tata letak murni memang menimbulkan beberapa masalah untuk aksesibilitas (yang pernah saya dengar). Tapi saya mengerti apa yang ditanyakan di sini bahwa entah bagaimana Anda melumpuhkan web dengan menggunakan tabel untuk memastikan keselarasan yang benar dari sesuatu di halaman Anda.

Saya pernah mendengar orang berdebat sebelumnya bahwa label FORMULIR dan inputnya, pada kenyataannya, adalah data dan bahwa mereka harus diijinkan ke dalam tabel.

Argumen yang menggunakan tabel untuk memastikan beberapa elemen berbaris dengan benar menyebabkan peningkatan besar dalam kode ini cenderung mencakup contoh bagaimana DIV tunggal dapat memenuhi semua kebutuhan mereka. Mereka tidak selalu menyertakan 10 baris CSS dan peretas browser khusus yang harus mereka tulis untuk IE5, IE5.5, IE6, IE7 ...

Saya pikir itu tetap tentang menggunakan keseimbangan dalam desain Anda. Tabel ada di kotak alat, ingat saja untuk apa ...

0
HB

Tentunya OP adalah sedikit angin, argumen tampaknya begitu mudah dan mudah dilawan.

Halaman web adalah domain dari pengembang web, dan jika mereka mengatakan div & CSS lebih baik daripada tabel itu cukup baik untuk saya.

Jika tata letak dicapai oleh tabel yang dihasilkan oleh aplikasi server, maka tata letak baru berarti perubahan pada aplikasi, rekondisi dan redelpoy aplikasi, seperti yang diaplikasikan hanya pada perubahan pada file css.

Plus, aksesibilitas. Tabel yang digunakan untuk tata letak membuat situs web tidak dapat diakses, jadi jangan menggunakannya. Itu tidak punya otak, belum lagi ilegal.

0
Ian

Jawaban super singkat: mendesain situs web yang dapat dipelihara sulit dengan tabel, dan sederhana dengan cara standar untuk melakukannya.

Situs web bukan tabel, ini adalah kumpulan komponen yang saling berinteraksi. Menggambarkannya sebagai sebuah tabel tidak masuk akal.

0
Rich Bradshaw

Dalam hal pemeliharaan situs dan perombakan desain sambil mempertahankan konten (yang terjadi setiap saat, terutama di eCommerce):

Konten dan desain disatukan melalui tabel = memperbarui konten dan desain.

Konten terpisah dari desain = memperbarui desain dan mungkin sedikit konten.

Jika saya mau, saya akan menyimpan konten saya di PHP menghasilkan XML, dikonversi ke markup di XSLT dan dirancang dengan CSS dan Javascript untuk interaksi. Untuk sisi Java, JSP ke JSTL untuk menghasilkan markup.

0
mltorrefranca

Menggunakan DIV, Anda dapat dengan mudah beralih hal-hal. Misalnya, Anda bisa membuatnya:

Menu | Content

Content | Menu

Menu
----
Content

Mudah untuk mengubahnya dalam CSS, bukan dalam HTML. Anda juga dapat memberikan beberapa gaya (tangan kanan, tangan kiri, khusus untuk layar kecil).

Di CSS, Anda juga dapat menyembunyikan menu dalam lembar gaya khusus yang digunakan untuk mencetak.

Hal lain yang baik, adalah bahwa konten Anda selalu dalam urutan yang sama dalam kode (menu pertama, konten setelahnya) bahkan jika secara visual itu disajikan sebaliknya.

0
ofaurax