Mengapa orang membuat tabel dengan divs?


269

Dalam pengembangan web modern saya lebih sering menemukan pola ini. Ini terlihat seperti ini:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

Dan di CSS ada sesuatu seperti:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

* (Nama kelas hanya ilustratif; dalam kehidupan nyata itu adalah nama-nama kelas normal yang mencerminkan tentang elemen itu)

Saya bahkan baru-baru ini mencoba melakukan ini sendiri karena ... Anda tahu, semua orang melakukannya.

Tapi saya masih belum mengerti. Kenapa kita melakukan ini? Jika Anda membutuhkan meja, maka buatlah blasted <table>dan selesaikan saja. Ya, bahkan jika itu untuk tata letak. Itulah gunanya meja - menata barang dengan cara tabular.

Penjelasan terbaik yang saya miliki adalah bahwa sekarang semua orang telah mendengar mantra "jangan gunakan tabel untuk tata letak", sehingga mereka mengikutinya secara membabi buta. Tetapi mereka masih membutuhkan tabel untuk tata letak (karena tidak ada lagi yang memiliki kemampuan memperluas tabel), sehingga mereka membuat <div>(karena bukan tabel!) Dan kemudian menambahkan CSS yang membuatnya menjadi tabel.

Bagi seluruh dunia, bagi saya ini seperti menempatkan hambatan yang tidak perlu yang sewenang-wenang di jalan Anda dan kemudian melakukan pekerjaan ekstra untuk menghindarinya.

Argumen asli untuk pindah dari tabel untuk tata letak adalah sulit untuk memodifikasi tata letak tabel setelahnya. Tetapi memodifikasi tata letak "tabel palsu" sama sulitnya, dan untuk alasan yang sama. Bahkan, dalam praktiknya memodifikasi tata letak selalu sulit, dan hampir tidak pernah cukup untuk hanya mengubah CSS, jika Anda ingin melakukan sesuatu yang lebih serius daripada perubahan kecil. Anda akan perlu memahami dan mengubah struktur HTML untuk perubahan desain yang serius. Dan tabel tidak membuat pekerjaan lebih sulit atau lebih mudah daripada div.

Bahkan, satu-satunya cara saya melihat bahwa tabel dapat membuat tata letak sulit untuk dimodifikasi, adalah jika Anda ab menggunakannya dan menciptakan kekacauan yang tidak baik. Anda dapat melakukannya dengan div juga.

Jadi ... dalam upaya untuk mengubah ini dari kata-kata kasar menjadi pertanyaan yang masuk akal: apa yang saya lewatkan? Apa manfaat sebenarnya dari menggunakan "tabel palsu" di atas yang asli?

Tentang tautan duplikat: Ini bukan saran untuk menggunakan tag lain atau sesuatu. Ini adalah pertanyaan tentang menggunakan <table>vs display:table.


6
@JuhaUntinen: itu ... sepertinya tidak mungkin. Sumber?
Paul D. Waite

5
@ PaulD.Waite - Ini sebenarnya masih benar hari ini, saya pikir. Baca jawaban lainnya. Kecuali jika tabel sudah ada table-layout:fixed, ia harus memuat seluruhnya sebelum dapat ditampilkan. Dengan broadband modern, efek ini tidak terlalu terlihat.
Vilx-

4
@JuhaUntinen: Itu tidak sepenuhnya akurat. Mesin rendering tabel lebih lambat ketika Anda menggunakan persentase untuk lebar kolom karena seluruh tabel harus diunduh sebelum browser dapat mulai mencari tahu seberapa besar untuk membuat semuanya. Ini terlalu rumit oleh tabel bersarang. Namun, ada saat itu (dan masih ada) cara untuk membuat rendering tabel JAUH lebih cepat. Hanya sedikit dev yang susah-susah mempelajari kerajinan mereka dengan baik dan bukannya ikut-ikutan.
NotMe

4
Kembali pada hari-hari yang bahkan lebih tua, kita biasa meniru divs dengan tabel di sana.
Wyatt Barnett

4
Seseorang membaca bahwa mereka tidak seharusnya menggunakan tabel untuk tata letak dan menganggapnya berarti mereka tidak seharusnya menggunakan tabel sama sekali. Saya benci tren ini.
Casey

Jawaban:


120

Ini adalah pola umum untuk membuat tabel responsif. Data tabular sulit ditampilkan di ponsel karena halaman akan diperbesar untuk membaca teks, artinya tabel melenceng dari sisi halaman dan pengguna harus menggulir mundur dan maju untuk membaca tabel, atau halaman akan diperbesar , biasanya berarti bahwa tabel terlalu kecil untuk dapat dibaca.

Tabel responsif mengubah tata letak pada layar yang lebih kecil - kadang-kadang beberapa kolom disembunyikan atau kolom digabung, misalnya nama dan alamat email mungkin terpisah pada layar besar, tetapi runtuh menjadi satu sel pada layar kecil sehingga informasinya dapat dibaca tanpa harus menggulir.

<div>s digunakan untuk membuat tabel, bukan <table>tag karena beberapa alasan. Jika <table>tag digunakan maka Anda harus mengganti gaya dan tata letak default browser sebelum menambahkan kode Anda sendiri, jadi dalam hal ini <div>tag menyimpan banyak CSS boilerplate. Selain itu, versi IE yang lebih lama tidak memungkinkan Anda untuk menimpa gaya tabel default, jadi menggunakan <div>s juga memuluskan pengembangan lintas-browser.

Ada gambaran bagus tentang tabel responsif pada CSS-Trik .

Sunting: Saya harus menunjukkan bahwa saya tidak menganjurkan pola ini - itu jatuh ke dalam perangkap divitis dan bukan semantik - tapi ini sebabnya Anda akan menemukan tabel yang terbuat dari divs.


6
Saya menerima jawaban ini karena sepertinya tidak ada hal lain yang berguna yang masuk lagi. Ada jawaban yang lebih tinggi tetapi mereka pada dasarnya mengatakan "karena semantik" (dan satu-satunya alasan semantik yang dapat mereka berikan adalah pembaca layar, yang tidak meyakinkan saya). @ HorusKol menjawab responsif di depan Anda, tetapi jawaban Anda lebih penting. Jika jawaban yang lebih baik muncul di masa depan, saya akan mengubahnya menjadi yang diterima.
Vilx-

5
Ini konyol dan malas. Apa pun yang Anda lakukan dengan <div>"tabel" mungkin bisa dilakukan dengan yang biasa, jadi tidak ada alasan (selain versi IE lama dan kemalasan) untuk menggunakan elemen non-semantik untuk membangun tabel. Yang mengatakan, data tabular aktual tampaknya jarang di internet jadi mungkin ini bukan masalah.
Anda,

1
@Vilx: Pertanyaan yang Anda ajukan adalah "Mengapa orang membuat tabel dengan div", yang mana Anda mendapatkan jawaban. Misalnya Anda mungkin tidak peduli dengan pembaca layar, tetapi itu tidak mengubah aksesibilitas yang menjadi perhatian nyata bagi banyak orang, dan (bersama dengan mesin pencari) alasan utama banyak orang memilih HTML semantik.
JacquesB

13
Untuk semua maksud dan tujuan, ini jelas salah. Jika data Anda berbentuk tabel, maka akan ditampilkan dalam tabel. Mengklaim bahwa tabel berperilaku jahat pada perangkat seluler adalah BS. Anda bisa dengan mudah mengubah properti tampilan elemen tabel menjadi nilai non-tabel karena Anda dapat membuat elemen non-tabel memiliki nilai tabel.
cimmanon

8
Saya percaya jawaban ini sedikit menyesatkan. Tabel responsif adalah desain yang baik, tetapi tidak tergantung pada pertanyaan apakah Anda harus menggunakan <table> atau <div> - Anda dapat menggunakan salah satu dari efek visual yang sama. Memang, ini inti dalam ide pemisahan struktur dan presentasi. Memang benar bahwa versi IE yang lebih lama tidak memungkinkan mengesampingkan gaya tabel, tetapi versi IE yang lebih lama tidak mendukung tampilan: tabel juga, jadi Anda tidak bisa menggunakan tabel responsif dengan cara apa pun.
JacquesB

153

Pertanyaannya adalah apakah data semantik tabel (yaitu satu set data atau unit informasi yang disusun secara logis dalam dua dimensi) atau Anda hanya menggunakan kisi untuk tata letak visual, misalnya karena Anda ingin bilah sisi diperluas atau semacamnya.

Jika informasi Anda semantik tabel, Anda menggunakan <table>-tag. Jika Anda hanya ingin kisi untuk keperluan tata letak, Anda menggunakan beberapa elemen html lain yang sesuai dan digunakan display:tabledalam style sheet.

Kapan data semantik tabel? Ketika data diatur secara logis sepanjang dua sumbu. Jika masuk akal dengan header untuk baris atau kolom, maka Anda mungkin memiliki tabel semantik. Contoh dari sesuatu yang bukan semantik tabel adalah menyajikan teks dalam kolom seperti di koran. Ini bukan semantik tabel, karena Anda masih akan membacanya secara linear, dan tidak ada artinya akan hilang jika presentasi dihapus.


OK, mengapa tidak digunakan <table>untuk semuanya daripada hanya untuk sesuatu yang semantik tabel? Secara visual itu jelas sama (karena elemen tabel hanya ada display:elementdi style sheet standar).

Perbedaannya adalah bahwa informasi semantik dapat membantu agen pengguna alternatif. Misalnya pembaca layar mungkin memungkinkan Anda menavigasi dalam dua dimensi dalam tabel, dan membaca tajuk untuk sel untuk kedua sumbu jika Anda lupa di mana Anda berada. Ini hanya akan membingungkan jika tabel tidak semantik tabel tetapi hanya digunakan untuk tata letak visual.

The <table>vs display:tablediskusi hanya kasus prinsip yang lebih umum menggunakan markup semantik. Lihat misalnya: Mengapa orang repot-repot menandai dengan benar dan semantik? atau Mengapa markup semantik diberikan bobot lebih untuk mesin pencari?

Di beberapa tempat Anda mungkin benar-benar diminta secara hukum untuk menggunakan markup semantik untuk alasan aksesibilitas, dan dalam hal apa pun tidak ada alasan untuk sengaja membuat halaman Anda kurang dapat diakses.

Bahkan jika Anda tidak peduli dengan pengguna yang dinonaktifkan, presentasi yang terpisah dari konten memberi Anda manfaat. Misalnya, tata letak tiga kolom Anda dapat disajikan dalam satu kolom pada perangkat seluler menggunakan lembar gaya alternatif.


14
@ Vilx- mengapa menggunakan <em>dan <strong>bukannya <b>dan <i>? Karena <b>dan <i>bukan tentang semantik tag. <table>memiliki makna semantik . Menggunakannya untuk sesuatu yang bukan tabel membuatnya lebih sulit untuk memahami makna semantik dokumen.

22
@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. Memutar yang <i>terbaik akan salah karena itu berarti sesuatu yang berbeda dari <i>sekitar judul buku. Untuk lebih lanjut, lihat Mengapa <b>dan <i>tag tidak digunakan lagi? dan Apa perbedaan antara <b>dan <strong>, <i>dan <em>?

19
Jika Anda tidak peduli apa artinya konten Anda, saya sangat menyarankan Anda berhenti menggunakan elemen apa pun kecuali untuk bentuk dan div. Tambahkan saja kelas untuk menerapkan gaya dan perilaku.
Rich Remer

9
@ Vilx-: Ketika Anda mengatakan bahwa Anda peduli dengan pengalaman pengguna Anda, tampaknya Anda hanya bermaksud sebagian dari pengguna Anda. Alasan utama untuk menggunakan markup dengan benar seperti yang Anda gambarkan adalah untuk aksesibilitas, yang secara langsung berkaitan dengan pengalaman pengguna pengguna yang dinonaktifkan. Ini adalah orang-orang yang mendapat manfaat dari Anda melakukan hal dengan cara yang benar dan mengabaikan konvensi ini berarti membuat pengalaman web mereka lebih sulit.
rooby

31
@ Vilx-, ya, pembaca layar memperlakukan <table> sangat berbeda dari <div>. <div> sebagian besar diabaikan dan dibaca secara berurutan. Di dalam sebuah <table> ia harus menyediakan penekanan tombol / perintah navigasi yang berbeda ("Lompat ke sel ke kanan", "Baca kolom dan judul baris", dan seterusnya), dan menyuarakan informasi lokasi yang berbeda (ketika aliran bacaan memasuki tabel kelanjutannya seperti "Tabel 3, baris 1 kolom 1, Lorem Ipsum dolor ... ")
Euro Micelli

102

Sebenarnya, saya akan mengatakan bahwa penggunaan nama kelas seperti "tabel" dalam contoh Anda menunjukkan bagaimana orang tidak benar-benar memahami apa yang mereka lakukan ketika mencoba untuk markup semantik. Mereka mendapat nilai karena berusaha menunjukkan bahwa kontennya bukan data tabular , tetapi mereka kehilangan nilai karena nama kelas yang buruk.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Semua yang telah dilakukan pengembang ini adalah mereplikasi <table>markup asli dengan nama kelas CSS. Ini berarti begitu tata letak ini bukan tabel, nama kelas berselisih.

Apa yang seharusnya dilakukan pengembang ini adalah mempertimbangkan informasi apa yang ada di tabel - apakah itu galeri thumbnail? Baiklah kalau begitu:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Sekarang saya dapat membuat beberapa CSS adaptif:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Mengapa divs dan bukan tabel

Tabel berisi data tabular - penyajian tabel terkait erat dengan struktur tabel. Data tabular akan selalu harus dalam bentuk tabular di mana pun Anda meletakkan konten itu atau pada layar / perangkat apa yang Anda inginkan untuk ditampilkan.

Galeri thumbnail (atau banyak hal lainnya, seperti formulir pendaftaran, menu, dan lainnya) bukan data tabular. Mungkin disajikan seperti tabel dalam beberapa tata letak desain, tetapi dalam kasus lain, seperti layar ponsel sempit, Anda ingin menggunakan tata letak blok yang lebih tradisional. Atau mungkin Anda ingin menampilkan thumbnail di sidebar daripada di area konten utama.

Pilihan Anda sekarang adalah untuk menampilkan markup yang berbeda untuk konten layar lebar (tabel) dan konten sidebar atau layar sempit (div) - yang berarti skrip sisi server Anda harus mengetahui ke mana konten akan pergi jika Anda membuat ini secara terprogram - atau Anda memiliki skrip sisi server Anda menghasilkan markup yang sama (karena itu tidak peduli di mana Anda meletakkan ini) dan menggunakan aturan CSS yang berbeda untuk situasi yang berbeda.

Jadi, maka Anda memiliki pilihan untuk selalu menghasilkan tabel, dan kemudian mengesampingkan aturan tampilan tabel alami dengan blok (yang benar-benar harus menggiling beberapa roda gigi di kepala pengembang mana pun), atau menggunakan div yang diberi label dengan baik yang memungkinkan pendekatan styling yang lebih fleksibel.

Dan praktik terbaik selama beberapa tahun sekarang adalah menghindari tabel ketika tidak perlu menyajikan data tabel.


Nama-nama kelas sebenarnya hanya sebuah contoh. Dalam kehidupan nyata mereka kebanyakan deskriptif. Bagaimanapun, dalam contoh Anda, mengapa Anda menggunakan <div>bukan <table>? Apa manfaat yang ditawarkannya?
Vilx-

1
Hmm ... yah, dalam kasus Anda, Anda sebenarnya melakukan dua representasi berbeda dari HTML yang sama melalui kueri media. Oke, itu kasus penggunaan yang bagus. Tetapi jika ini bukan masalahnya, dan Anda akan tahu sebelumnya bahwa galeri thumbnail ini hanya akan ditampilkan di satu tempat dan hanya dalam format tabular - apakah Anda akan menggunakan <table>itu dulu atau nanti display:table? Karena, well, dengan cara itu adalah data tabular. Kecuali bahwa "data" adalah gambar, tapi tetap saja.
Vilx-

15
baik, tidak, itu bukan data tabular. Anda mempresentasikannya dalam kotak yang menyerupai tabel. Data tabular adalah statistik dan informasi komparatif - berpikir seperti spreadsheet. Apakah Anda akan mengatakan bahwa tampilan thumbnail dalam file explorer Windows adalah data tabular? Dan, apakah ini akan selalu disajikan seperti meja? Bagaimana jika Anda menginginkan gaya tampilan yang berbeda dalam 6 atau 12 bulan? Mengapa menerapkan pembatasan yang memiliki efek jangka panjang demi menjadi keras kepala dalam menghadapi praktik yang diterima secara luas?
HorusKol

12
Kecuali bahwa itu bukan data tabular, sama sekali. Tidak ada alasan lain selain keputusan tata letak yang sewenang-wenang bahwa konten ini menyerupai sebuah tabel. Ini bukan data terstruktur dalam kolom dan baris, ini daftar konten, ditata dalam kisi. - sunting: Apa yang dikatakan HorusKol.
Eric King

3
Baiklah, itu sedikit melebar. :) Baiklah, Anda telah memberi saya sesuatu untuk dipikirkan! Terima kasih untuk itu! Saya masih belum 100% yakin, tapi setidaknya itu adalah sesuatu untuk dilanjutkan. :)
Vilx-

11

Di masa lalu, mesin render tabel " muncul " lebih lambat ketika Anda menggunakan persentase untuk lebar kolom. Mesin pada dasarnya harus mengunduh seluruh kumpulan data sebelum kemudian mulai mencari tahu seberapa besar segalanya untuk menggambarnya di layar.

Mesin DIV berbeda. Ketika peramban menemukan DIV, peramban akan maju dan meletakkannya dan mulai mengisi konten secara inline. Tentu saja, div mungkin melompat ketika data selesai dimuat. Karenanya mengapa saya muncul dalam kutipan di atas. Kerangka waktu untuk penyelesaian keduanya adalah sama, namun tabel tidak ditarik sampai akhir yang berarti pengguna tidak yakin apakah memuat atau tidak untuk satu atau dua detik.

Ini menjadi lebih buruk karena meja bersarang.

Ada kemudian (dan masih ada) cara untuk membuat rendering tabel JAUH lebih cepat. Pada dasarnya dengan memberikan petunjuk bahwa ukuran kolom tidak berubah, maka browser mulai merender data tabular dengan segera. Pada akhirnya ini berarti bahwa tabel sebenarnya dapat ditampilkan dalam posisi yang benar lebih cepat daripada div yang memberi mereka penampilan yang lebih baik.

Tapi itu bukan keseluruhan cerita. Selebihnya adalah kebanyakan dev tidak perlu belajar kerajinan mereka dengan cukup baik untuk mengetahui hal ini. Sebagai gantinya mereka melompat pada berbagai kereta musik dan pergi dengan kode apa pun yang dapat mereka salin / tempel. Bahkan hari ini saya menemukan bahwa sangat sedikit pengembang web yang mengetahui perbedaan dari satu jenis dokumen ke yang lain - dan itu adalah alasan nomor satu mengapa berbagai situs memiliki segala macam solusi untuk mencakup berbagai browser.

Jadi, +1 kepada Anda untuk mengajukan pertanyaan.


Offtopik tentang DOCTYPE: Saya pikir, meskipun ada perbedaan teoretis (dan validator menganggapnya serius), dalam praktiknya browser tidak benar-benar membedakannya. OK, mungkin ada beberapa perubahan kecil antara rasa HTML / XHTML, tetapi versi dan informasi DTD setidaknya tidak digunakan. Itulah sebabnya HTML5 menjatuhkan semuanya dan pergi dengan adil <!DOCTYPE html>dan itulah sebabnya itu terjadi bahkan di browser lama seperti IE6. Apakah saya melewatkan sesuatu?
Vilx-

2
@Vilx: DOCTYPE menempatkan browser ke mode tertentu. Antara lain, ia mendefinisikan model kotak yang digunakan. Untuk sejumlah DOCTYPE browser tidak berbaris karena model kotak yang digunakan berbeda. Inilah sebabnya mengapa banyak pengembang mengeluh bahwa browser menunjukkan halaman secara berbeda dan alih-alih memperbaiki DOCTYPE, menggunakan lembar reset css besar. Namun, ada beberapa DOCTYPE di mana semua browser menggunakan model kotak yang sama - tetapi mereka tidak pernah default, Anda harus tahu mereka.
NotMe

@vilx: html 5 tidak menjatuhkan semuanya. Sebaliknya, sebuah DOCTYPE baru ditambahkan. Intinya adalah, baris pertama yang muncul di bagian atas dokumen html sangat penting dan jika Anda tidak mengerti apa yang dilakukannya dan bagaimana berbagai browser bereaksi terhadapnya maka Anda akan menghabiskan terlalu banyak waktu mencari tahu mengapa tata letak Anda "rusak" di browser tertentu.
NotMe

Tunggu, jadi ada yang doctype yang berbeda yang membuat dokumen yang sama membuat berbeda? Yang mana Pikiran Anda saya sedang berbicara tentang DOCTYPE berbeda, bukan DOCTYPE vs kurangnya DOCTYPE (alias quirksmode).
Vilx-

@Vilx: Ini sedikit lebih rumit, karena beberapa DOCTYPE memicu mode quirks (sama seperti tanpa DOCTYPE) dan beberapa DOCTYPE lain (termasuk DOCTYPE HTML5) memicu mode standar, dan bahkan ada beberapa DOCTYPE yang memicu ketiga "hampir-standar "mode di beberapa browser.
JacquesB

5

Jika saya bisa mendapatkan sedikit "meta" di sini, ini membawa dua masalah ke pikiran saya:

Satu: Seseorang mengusulkan aturan karena alasan yang baik, dan orang-orang benar-benar kehilangan titik dengan mengikuti surat teknis aturan sambil mengabaikan roh. Mereka menemukan beberapa cara untuk menyelesaikan semua hal-hal buruk yang berusaha dicegah oleh aturan tersebut, sementara secara teknis tetap mengikuti aturan tersebut sebagaimana dinyatakan.

Dua: Seseorang melihat masalah dan mengusulkan aturan untuk mencegahnya. Orang lain melihat nilai aturan ini. Kemudian mereka bersikeras pengabdian buta terhadap aturan ini tanpa memperhatikan masalah asli yang seharusnya diselesaikan dan / atau terlepas dari masalah apa yang diciptakannya. Saya telah melakukan banyak percakapan di mana seseorang berkata, "Anda harus melakukan X karena itulah aturannya", dan kemudian saya bertanya, "Tetapi mengapa kita harus melakukan X?", Dan mereka menatap saya dengan bingung dan putus asa dan berkata, "Tapi Aku baru saja memberitahumu! Karena itu aturannya! " Saya menjawab, "Tapi itu tampaknya menyebabkan lebih banyak masalah daripada menyelesaikannya. Saya pikir kita akan lebih baik melakukan Y." Dan kemudian orang itu berkata, "Tidak, lihat, akan saya tunjukkan. Lihat, ada di sini di buku ini. X adalah aturannya."

Dalam kasus ini, kami memiliki masalah: Tag tabel melakukan dua hal: Satu, ia mengontrol tata letak dokumen. Dua, itu menyampaikan gagasan bahwa data terlampir terdiri dari baris dan kolom angka atau data lainnya.

Begitu banyak orang yang mengusulkan solusinya: Jangan gunakan tag tabel untuk mengontrol tata letak hal-hal yang tidak secara logis "tabel". Gunakan CSS.

Tetapi ada masalah dengan solusi ini. Tag tabel dan subtaganya melakukan banyak fungsi tata letak yang sangat berguna yang tidak mudah dicapai dengan menggunakan CSS, dan ketika mereka dapat dicapai, kode yang diperlukan untuk melakukannya sering kali rumit - sulit dibaca dan sulit dipelihara. Mengapa kita harus melakukan hal-hal dengan cara yang canggung dan sulit ketika ada cara yang bersih dan mudah?

Secara pribadi, saya pikir kita akan lebih baik untuk hanya menyatakan, "Fakta bahwa ada sesuatu di dalam tag tabel tidak selalu berarti bahwa itu mewakili baris dan kolom angka." Ini tidak akan menjadi pernyataan keterlaluan. Saya belum pernah mendengar seseorang mengatakan bahwa tag "p" hanya dapat digunakan untuk hal-hal yang benar-benar merupakan paragraf dari kalimat bahasa Inggris yang benar secara tata bahasa, yang dibuat secara logis. Saya belum pernah mendengar seseorang mengatakan bahwa salah menggunakan tag "ul" untuk daftar yang memang masuk dalam urutan logis, hanya karena Anda menginginkan peluru dan bukan nomor urut. Dll


7
wrt ke paragraf terakhir - Anda telah membaca spesifikasi HTML5 untuk elemen-elemen itu, bukan? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / draft / html / master / semantics.html # the-ol-element - khususnya, jika pesanan memang penting, maka gunakan elemen ol (karena ini adalah bagian struktural) - Anda masih dapat menyajikannya sebagai daftar peluru menggunakan CSS
HorusKol

5
dan jika Anda melihat dua jawaban lain di sini, Anda akan melihat bahwa tidak ada yang mengatakan hanya "karena itu aturannya" - mereka berdua
menjabarkan

1
Hmm, sepertinya saya mengatakan sesuatu seperti: "Seseorang melihat masalah dan mengusulkan aturan untuk mencegahnya. Yang lain melihat nilai dari aturan ini. Kemudian mereka bersikeras pada pengabdian buta terhadap aturan ini tanpa memperhatikan masalah asli yang seharusnya untuk memecahkan dan / atau terlepas dari masalah apa yang diciptakannya. " Saya tidak menyangkal ada pemikiran yang masuk akal di balik aturan itu. Saya hanya tidak setuju dengan kesimpulannya. Tentunya saya bisa mengatakan, "Anda punya poin bagus di sana, tetapi saya tidak setuju." Dan tentunya Anda tidak menyangkal bahwa ada orang yang tidak memahami pro dan kontra dan berkata ...
Jay

1
... "karena itu aturannya". Saya telah melakukan sejumlah percakapan dengan orang-orang seperti itu selama bertahun-tahun, tentang masalah khusus ini dan banyak hal lainnya. Orang yang menolak untuk bahkan mendiskusikan pro dan kontra dari suatu aturan, karena itu adalah aturan, akhir dari diskusi.
Jay

Telah muncul gagasan malang bahwa desain HTML berakar pada beberapa bentuk abstrak dari rekayasa daripada seni. Dengan demikian, dalam nada itu, beberapa orang telah memutuskan bahwa harus ada aturan absolut analog dengan fisika, dan gravitasi yang harus dipatuhi, atau seseorang yang melanggar aturan semacam itu berangkat dari "keyakinan yang lebih murni." Kenyataannya adalah tidak ada peramban atau metafora desain yang sempurna. Berjalan hati-hati di sekitar mereka yang bersikeras sebaliknya.
David W

5

Sudah ada ton dari jawaban yang besar di sini. Tetapi saya ingin menambahkan bahwa tableelemen memiliki batasan render yang tidak ada untuk divelemen. Coba dan buat tabel yang melakukan pengguliran virtual (seperti: SlickGrid , DataTables , dan lainnya) dan Anda akan sangat kecewa. Itu tidak bekerja. Kebanyakan (Semua?) Grid Javascript modern menggunakan divs karena css memungkinkan rendering yang jauh lebih fleksibel.

Ada batasan lain juga. Aturan umum saya adalah bahwa jika saya akan melihat seluruh tabel pada satu layar, dan saya tidak ingin ada / banyak render kustom untuk itu saya menggunakan tableelemen, jika tidak saya akan menggunakan divs karena saya dapat mengontrol hasilnya jauh jauh lebih mudah.


3

HTML dan CSS telah mengembangkan tingkat fleksibilitas yang berarti bahwa bahkan elemen-elemen seperti "blok" secara konseptual <div>(bentuk konten blok tertua dan paling umum HTML) tidak perlu ditampilkan sebagai blok:

div { display: inline; }

Seperti yang Anda perhatikan, <div>dapat digunakan untuk meniru <table>dan sesama pelancong. Sebenarnya, kebanyakan tag bisa. Mengingat peran khusus mereka, saya yakin Anda bisa berguna remap tag makro seperti <html>, <head>, <body>, dan <script>, tapi tag "umum" seperti <div>, <p>, <b>, <em>, <span>, dan <pre>? Untuk diperebutkan. Buat blok inline tag, blok inline, aliran tag pra-format, yang stasioner mengambang. Gila, jika Anda suka!

Itu mungkin . Anda mungkin ingin berputar benang tentang bagaimana kita semua harus menggunakan "semantik markup" bla bla bla , atau percaya dengan Pythonistas bahwa "Harus ada satu - dan sebaiknya hanya satu - cara yang jelas untuk melakukannya." Namun Tim Toady adalah pria yang pintar dan ingin tahu. Diberi kebebasan, dia akan menjelajahi semuanya. Itu termasuk menggunakan fleksibilitas yang tersedia untuk melakukan pergantian. Beberapa bijaksana, beberapa akan terbukti sebaliknya. Tetapi percobaan, kesalahan, dan pengalaman adalah satu-satunya cara untuk mengetahuinya. Jadi ada cukup kondisi untuk substitusi.

Saya tidak berpikir terlalu berlebihan untuk mengatakan bahwa penggantian juga diperlukan. Minimal, ini sangat nyaman . Untuk waktu yang lama, HTML tidak memiliki <menu>, <section>atau <aside>elemen. Namun halaman web dan aplikasi di mana-mana memiliki menu, bagian, dan bilah sisi. Bagaimana? Karena elemen daftar HTML ( <ul>,, <ol>dan <li>) mudah digunakan kembali dan beberapa penggunaan diklasifikasikan kembali sebagai wadah menu dan bagian. <div>bisa berdiri di atas <article>, <section>, <aside>, <figure>, dan <summary>. HTML5 telah menyusul, dan menambahkan elemen khusus untuk beberapa kasus penggunaan yang sebelumnya tidak ditangani. Ini adalah pembaruan dan koreksi hebat untuk mengakomodasi penggunaan umum, dunia nyata.

Meski begitu, masih ada banyak idiom umum yang tidak memiliki tag atau model semantik . Hal-hal seperti halaman, catatan kaki, kutipan menarik, aliran komentar, avatar terkait, "suka," subjudul, dan subtitle yang saya dan banyak orang lain gunakan setiap hari. Apa yang harus kita lakukan? Apa yang kita bisa. Ulangi elemen "tutup tapi tidak eksak" dengan kelas dan id untuk berdiri dan mendukung pekerjaan kami selama lima atau sepuluh tahun ke depan atau sampai bertahun-tahun sampai HTML6 atau HTML7 menyusul. HTML / CSS "ya, ini sebuah X, secara teori, tapi kita akan menandainya dan bekerja dengannya sebagai Y" sangat nyaman. Sangat diperlukan, sungguh. Itu membuat konten Web fleksibel, dan tidak rapuh.

Lebih jauh lagi, "semantic markup" memiliki batasan yang tidak dapat direduksi . Itu berlaku untuk semua jenis struktur ketat yang dapat Anda bayangkan untuk konten.

Format standar tidak dapat mencakup seluruh kekayaan kebutuhan, keinginan, dan keragaman manusia. Mereka akan selalu "berada di belakang kurva" dari apa yang dilakukan orang sekarang . Bagaimana mereka berinovasi. Heck, HTML5 masih di belakang kurva pada catatan kaki, subjudul, dan inovasi pencetakan lainnya dari abad ke-17. Tidak memiliki fitur yang penting bagi banyak pekerja informasi dan pembuat konten. Jadi kami berimprovisasi.

Yang lebih tidak berubah adalah bahwa informasi tidak mematuhi satu set aturan. Tentu, ini dimulai sebagai sebuah tabel. Tapi mungkin Anda hanya menginginkan ringkasan - ucapkan judul untuk setiap baris, sebagai daftar. Mungkin itu memakan terlalu banyak ruang, dan Anda ingin itu sebagai daftar inline hemat-ruang. Mungkin Anda memiliki catatan yang hanya ingin judulnya, lalu jika Anda mengklik, Anda melihat detail yang mendasarinya. Atau Anda ingin item dalam daftar atau tabel kompleks dikelompokkan dan dikategorikan. Oh, sekarang Anda ingin mengubah dan mengategorikannya dengan cara yang berbeda. Atau nilai-nilai diplot sebagai bagan batang. Ini adalah hal-hal yang dilakukan setiap hari di aplikasi, spreadsheet, dan visualisasi data. Mereka adalah bagian tak terpisahkan dari lanskap informasi kita, dan apa yang kita inginkan dan perlu lakukan di web. Manusia terus-menerus mengatur ulang bentuk dan penyajian data kami. Bukan hanya satu hal, atau satu format / tata letak, atau satu konsep. Ini sepadan, dengan semantik tergantung pada keadaan dan pilihan yang dibuat pengguna secara interaktif. Ya, tandai teks sebagai "ditekankan" (<em>), tapi itu hanya sebuah konvensi. Saya telah mengerjakan dokumen dengan setidaknya setengah lusin jenis "penekanan." Kita harus dapat menyesuaikan dan memetakannya untuk penggunaan yang berbeda, interpretasi yang berbeda. Salah satu jenis penekanan HTML? Sangat reduksionistik. Membatasi. Rapuh. Hal yang sama berlaku untuk <table>, <p>, dll

Sangat menyenangkan memiliki tag / elemen yang membantu mengatur pemikiran seluruh komunitas tentang "apa yang terjadi di mana." Itu membantu membangun konvensi dan idiom, dan membuat kita secara kolektif lebih efisien. Tetapi kemampuan untuk memetakan hal-hal, untuk mendesain ulang dan menggunakan kembali struktur itu? Itulah bagian tak terpisahkan dari inklusifitas Web dan keberhasilannya.


4
bagaimana ini bisa mendekati menjawab pertanyaan?
HorusKol

2
IMO, ini membahas pertanyaan mendasar mengapa perancang, pengembang, dan pekerja konten memilih untuk menggunakan elemen generik ( <div>dan <span>) sebagai pengganti elemen yang dibuat khusus (misalnya <table>). Ini sedikit lebih meta daripada hanya tag-tag itu, tetapi tag itu berbicara langsung pada pola dan prinsip penggunaan.
Jonathan Eunice

@HorusKol Sebenarnya, dari semua jawaban di sini, jawaban ini paling konsisten dengan, dan mendukung, jawaban Anda. Saya akan mengatakan mereka bertautan dengan baik.
Jonathan Eunice

1
Saya tidak tahu apakah saya akan jauh kontras div(sebagai generik) dengan table(sebagai tujuan-dibangun). Mereka berdua tujuan-dibangun, untuk dua tujuan yang berbeda (belum mungkin sebagian tumpang tindih). Saya percaya ini adalah inti dari pertanyaan ini.
Eric King

@EricKing Adalah adil untuk mengatakan bahwa divmemiliki tujuan. Tetapi divdan spantidak memiliki sangat spesifik tujuan yang dimaksudkan itu table, thead, tddll lakukan. Tidak ada yang akan panik jika Anda menggunakan divelemen misc untuk sidebar, menarik tanda kutip, pengelompokan bagian, dll-- - cukup banyak di mana saja dalam dokumen, juga. Cobalah melakukan hal itu dengan unenclosed thead, tdatau li. Alih-alih "dibangun dengan tujuan," mungkin "bertujuan khusus" atau "dengan peran yang dimaksudkan khusus."
Jonathan Eunice

0

Gunakan kasus penting. Ada perbedaan besar antara tata letak / presentasi di halaman konten dan aplikasi. Dalam konten, semantik sangat penting untuk SEO-awareness dan kegunaan. Dalam kasus ini, menggunakan tabel untuk menyajikan data tabular secara umum adalah hal yang benar untuk dilakukan. Seperti yang telah dicatat orang lain, mesin pencari akan menghukum Anda dan Anda bahkan dapat melanggar undang-undang kegunaan jika Anda diharuskan oleh undang-undang untuk mematuhi pedoman kegunaan pemerintah.

Dalam aplikasi web, pengembang dapat memilih untuk membuat tampilan yang sepenuhnya terpisah untuk tujuan SEO dan kegunaan. Desain responsif telah membuat orang membangun pandangan yang dapat menangani tata letak desktop dan seluler, dan div lebih baik daripada tabel dalam kasus penggunaan tersebut.

Ambil situs e-commerce, misalnya. Melihat daftar produk dalam penelusuran atau hasil pencarian menunjukkan, secara umum, daftar produk dalam format tabular, tetapi pandangan tersebut mungkin dihasilkan menggunakan divs (yang menyediakan tata letak dan opsi penataan gaya yang lebih umum dan fleksibel) daripada tabel. Amazon dan eBay adalah contoh bagus dari pendekatan ini. Periksa hasil pencarian di kedua situs dan Anda akan melihat satu set div yang sangat bersarang.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.