it-swarm.asia

İnsanlar neden div'lerle masa yapıyorlar?

Modern web geliştirmede bu model ile daha sık karşılaşıyorum. Şöyle görünüyor:

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

Ve CSS'de şöyle bir şey var:

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

* (Sınıf adı yalnızca açıklama amaçlıdır; gerçek hayatta bunlar öğenin ne hakkında olduğunu yansıtan normal sınıf adlarıdır)

Son zamanlarda bunu kendim bile denedim çünkü ... biliyorsun, herkes yapıyor.

Ama hala anlamıyorum. Bunu neden yapıyoruz? Bir masaya ihtiyacınız varsa, sadece püskürdü <table> ve onunla yapılabilir. Evet, düzen için olsa bile. Tablolar bunun için - tablo biçiminde şeyler düzenlemek.

Sahip olduğum en iyi açıklama, şimdiye kadar herkesin "düzen için tablo kullanmayın" mantrasını duymasıdır, bu yüzden körü körüne takip ederler. Ancak yine de düzen için bir tabloya ihtiyaç duyarlar (çünkü başka hiçbir şey tablonun genişletme yeteneklerine sahip değildir), bu nedenle <div> (çünkü değil bir tablo!) ve sonra yine de bir tablo haline getiren CSS ekleyin.

Tüm dünya için bu bana yolunuza gelişigüzel gereksiz engeller koymak ve sonra bunları atlatmak için ekstra iş yapmak gibi görünüyor.

Mizanpaj için tablolardan uzaklaşmanın orijinal argümanı, daha sonra tablo şeklindeki bir düzeni değiştirmenin zor olmasıydı. Ancak, bir "sahte tablo" düzenini değiştirmek de aynı derecede zordur. Aslında, pratikte bir düzeni değiştirmek her zaman zordur ve küçük ayarlardan daha ciddi bir şey yapmak istiyorsanız, neredeyse hiç CSS'yi değiştirmek yeterli değildir. Ciddi tasarım değişiklikleri için HTML yapısını anlamanız ve değiştirmeniz gerekir will. Ve tablolar işi div'den daha zor veya kolay yapmaz.

Aslında, tabloların bir düzeni değiştirmeyi zorlaştırabildiğini görmenin tek yolu, abonları kullandı ve rahat bir karmaşa yarattı. Bunu div ile de yapabilirsiniz.

Yani ... bunu tutarlı bir soruya dönüştürmek için: eksik olan ne? Gerçek bir tablo üzerinde "sahte tablo" kullanmanın gerçek faydaları nelerdir?

Yinelenen bağlantı hakkında: Bu, başka bir etiket veya başka bir şey kullanmak için bir öneri değildir. Bu _ <table> vs display:table.

278
Vilx-

Bu, duyarlı tablolar oluşturmak için yaygın bir kalıptır. Sayfa metnini okumak için yakınlaştırılacağından tabloların sayfanın kenarından çıkacağı ve kullanıcının tabloyu okumak için ileri ve geri kaydırması gerektiği veya sayfa uzaklaştırılacağı için, sekmeli veriler cep telefonlarında görüntülenmesi zordur. , genellikle tablonun okunamayacak kadar küçük olduğu anlamına gelir.

Duyarlı tablolar daha küçük ekranlarda düzeni değiştirir - bazen bazı sütunlar gizlenir veya sütunlar birleştirilir; ad ve e-posta adresi büyük ekranlarda ayrı olabilir, ancak küçük ekranlarda bir hücreye daraltılabilir, böylece bilgiler kaydırılmak zorunda kalmadan okunabilir.

<div> S, birkaç nedenden dolayı <table> Etiketleri yerine tablolar oluşturmak için kullanılır. <table> Etiketleri kullanılıyorsa, kendi kodunuzu eklemeden önce tarayıcının varsayılan stillerini ve düzenini geçersiz kılmanız gerekir, bu durumda <div> Etiketleri çok sayıda kaynak plakası CSS'sine kaydedilir. Ayrıca, IE eski sürümleri varsayılan tablo stillerini geçersiz kılmanıza izin vermez, bu nedenle <div> S kullanıldığında tarayıcılar arası geliştirme de sorunsuz olur.

Oldukça iyi bir CSS-Tricks'teki duyarlı tablolara genel bakış .

Düzenleme: Bu kalıbı savunmamaya dikkat etmeliyim - divit tuzağına düşüyor ve anlamsal değil - ama bu yüzden divs'den yapılmış tabloları bulacaksınız.

122
whostolemyhat

Soru, verilerin anlamsal olarak bir tablo (yani mantıksal olarak iki boyutta düzenlenmiş bir veri kümesi veya bilgi birimleri) olması veya ızgarayı görsel düzen için (ör. çünkü bir kenar çubuğunun genişlemesini veya bunun gibi bir şeyi istiyorsunuz.

Bilgileriniz anlamsal olarak bir tablo ise, _ <table>-etiket. Sadece düzen amacıyla bir ızgara istiyorsanız, diğer bazı uygun html öğelerini ve display:table stil sayfasında.

Veriler anlamsal olarak bir tablo olduğunda ? Veriler mantıksal olarak iki eksen boyunca düzenlendiğinde. Satırlar veya sütunlar için üstbilgilerle mantıklıysa, semantik bir tablonuz olabilir. Anlamsal olarak tablo olmayan bir şey örneği gazete gibi sütunlarda bir metin sunmaktır. Bu, semantik olarak bir tablo değildir, çünkü yine de doğrusal olarak okuyabilirsiniz ve sunum kaldırılırsa hiçbir anlam kaybolmaz.


Tamam, neden <table> sadece semantik bir tablo olan bir şey yerine her şey için? Görsel olarak aynıdır (tablo öğesinin sadece display:element (varsayılan stil sayfasında).

Fark, semantik bilginin alternatif kullanıcı aracılarına yardımcı olabilmesidir. Örneğin bir ekran okuyucu, tabloda iki boyutta gezinmenize ve nerede olduğunuzu unutursanız her iki eksen için bir hücrenin başlıklarını okumanıza izin verebilir. Tablonun anlamsal olarak bir tablo olmaması, sadece görsel yerleşim için kullanılması bu kafa karıştırıcı olacaktır.

<table> karşı display:table tartışma, semantik işaretleme kullanma konusunda daha genel bir ilkedir. Örneğin bakınız: Neden düzgün ve anlamsal olarak işaretleme zahmetine girsin ki? veya Semantik işaretlemeye neden arama motorları için daha fazla ağırlık verilir?

Bazı yerlerde erişilebilirlik nedenleriyle anlamsal işaretleme kullanmanız yasal olarak istenebilir ve her durumda sayfanızı daha az erişilebilir hale getirmek için hiçbir neden yoktur.

Engelli kullanıcıları önemsemeseniz bile, içerikten ayrı sunuma sahip olmanız size fayda sağlar. Örneğin. üç sütun düzeniniz alternatif bir stil sayfası kullanılarak mobil cihazlarda tek bir sütun halinde sunulabilir.

154
JacquesB

Aslında, örneğinizde "table" gibi sınıf adlarının kullanılmasının insanların anlamsal işaretleme denediklerinde gerçekte ne yaptıklarını nasıl anlamadıklarını gösterdiğini söyleyebilirim. içeriğin tablo verileri değil olduğunu göstermeye çalıştıkları için not alırlar, ancak kötü sınıf adları için not kaybederler.

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

Bu geliştiricinin yaptığı tek şey orijinal <table> CSS sınıf adları ile işaretleme. Bu, bu düzen bir tablo olmadığında, sınıf isimlerinin olasılıkta olduğu anlamına gelir.

Bu geliştiricinin yapması gereken şey, tabloda hangi bilgilerin olduğunu düşünmektir - küçük resim galerisi mi? İyi o zaman:

<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>

Şimdi bazı uyarlanabilir CSS oluşturabilirim:

@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%;
  }
}

Neden div değil tablolar

Bir tablo sekmeli veriler içerir - bir tablonun sunumu, tablonun yapısına ayrılmaz bir şekilde bağlıdır. Tablo içeriği, içeriği nereye yerleştirdiğiniz veya hangi ekranda/cihazda görüntülemek istediğinize bakılmaksızın her zaman tablo şeklinde olmalıdır.

Bir küçük resim galerisi (veya bir kayıt formu, bir menü ve daha pek çok şey) tablo verileri değildir. Bazı tasarım düzenlerinde bir tablo gibi sunulabilir, ancak diğer durumlarda, dar telefon ekranları gibi, daha geleneksel blok düzenleri kullanarak istersiniz. Veya küçük resimleri ana içerik alanı yerine kenar çubuğunda görüntülemek isteyebilirsiniz.

Seçiminiz artık geniş ekran içeriği (tablolar) ve kenar çubuğu veya dar ekran içeriği (divs) için farklı işaretleme çıktısıdır; bu, sunucu tarafı komut dosyalarınızın bu programı programlı olarak oluşturuyorsanız içeriğin nereye gittiğinin farkında olması gerektiği anlamına gelir. - veya sunucu tarafı komut dosyanız aynı biçimlendirme çıktısına sahipse (bunu nereye koyduğunuz umurumda olmamalıdır) ve farklı durumlar için farklı CSS kuralları kullanırsınız.

Böylece, her zaman tabloları çıktılama seçeneğiniz vardır ve daha sonra doğal tablo görüntüleme kurallarını blokla geçersiz kılarsınız (bu, herhangi bir geliştiricinin kafasında bazı dişlileri öğütmelidir) veya stil için daha esnek yaklaşımlara izin veren iyi etiketlenmiş div'lerle devam eder.

Ve birkaç yıldır en iyi uygulamalar , tablo verilerinin sunulmasına gerek olmadığında tablolardan kaçınmak oldu.

102
HorusKol

Eski günlerde, sütun genişlikleri yüzdeleri kullandığınızda tablo oluşturma motoru "" daha yavaş göründü. Motor temel olarak tüm veri setini indirmek zorunda kaldı ve daha sonra her şeyi ekranda çizmek için ne kadar büyük olduğunu bulmaya başladı.

DIV motoru farklıydı. Tarayıcı bir DIV ile karşılaştıkça devam edip yerleştirir ve içeriği satır içi doldurmaya başlar. Tabii ki, veri yüklemesi bittiğinde div'ler atlayabilir. Bu yüzden yukarıdaki alıntılarda neden yer aldım. Her ikisinin de tamamlanması için zaman çerçevesi aynıydı, ancak tablolar sonuna kadar çizilmedi, bu da kullanıcının bir iki saniye boyunca yüklenip yüklenmediğinden emin olmadığı anlamına geliyordu.

Tablolar iç içe geçtikçe bu daha da kötüleşti.

O zaman tabloyu FAR FAR'ı daha hızlı hale getirmenin (ve hala mevcut) yolları vardı. Temel olarak, sütun boyutlarının değişmediğine dair bir ipucu vererek, tarayıcı hemen sekmeli verileri oluşturmaya başlar. Sonuçta bu, tabloların gerçekte doğru konumda div'den daha hızlı gösterilebileceği anlamına gelir.

Ama hikayenin tamamı bu değil. Geri kalanı, çoğu geliştiricinin zanaatlarını bunu bilecek kadar iyi öğrenmeye zahmet etmemesidir. Bunun yerine çeşitli bandwago'lara atlarlar ve kopyalayabilecekleri/yapıştırabilecekleri herhangi bir kodla giderler. Bugün bile, çok az sayıda web geliştiricisinin bir öğretiden diğerine farkı bildiğini görüyorum - ve çeşitli sitelerin çeşitli tarayıcıları kapsamak için her türlü geçici çözümlere sahip olmasının bir numaralı nedeni budur.

Yani, soruyu sorduğunuz için + 1'leyin.

11
NotMe

Burada biraz "meta" alabilirsem, bu iki aklıma getiriyor:

Bir: Birisi iyi bir nedenden dolayı bir kural öneriyor ve insanlar ruhu görmezden gelirken kuralın teknik harfini takip ederek noktayı tamamen kaçırıyorlar. Kuralı teknik olarak kurallı olarak takip ederken, kuralın önlemeye çalıştığı tüm kötü şeyleri başarmanın bir yolunu buluyorlar.

İki: Birisi bir sorun görür ve bunu önlemek için bir kural önerir. Diğerleri bu kuralın değerini görür. Daha sonra çözmesi gereken orijinal sorun ve/veya yarattığı diğer sorunlardan bağımsız olarak bu kurala kör bağlılık konusunda ısrar ediyorlar. Birisinin "X'i yapmalısın çünkü kural budur" diyen birçok konuşmam oldu ve sonra "Ama neden X yapmalıyız?" Sana söyledim! Çünkü kural bu! " "Ama çözdüğünden daha fazla soruna yol açıyor gibi görünüyor. Sanırım Y yapmaktan daha iyi olacağız." Ve sonra kişi "Hayır, bak, sana göstereceğim. Bak, işte tam burada bu kitapta. X kuraldır."

Bu durumda, bir sorunumuz var: Tablo etiketi iki şey yapar: Birincisi, belgenin düzenini kontrol eder. İkincisi, ekteki verilerin satır ve sütunlardan ya da diğer verilerin sütunlarından oluştuğu fikrini aktarır.

Pek çok kişi çözümü önerdi: Mantıksal olarak "tablo" olmayan şeylerin düzenini kontrol etmek için tablo etiketleri kullanmayın. CSS kullanın.

Ancak bu çözümde bir sorun var. Tablo etiketi ve alt etiketleri, CSS kullanarak elde edilmesi kolay olmayan birçok kullanışlı düzen işlevi gerçekleştirir ve elde edilebildiğinde, bunu yapmak için gereken kod genellikle zahmetlidir - okunması zor ve bakımı zordur. Temiz, kolay bir yol varken neden işleri beceriksiz ve zor bir şekilde yapalım?

Şahsen, "Tablo etiketinin içindeki bir şeyin olması, satırların ve sayı sütunlarının temsil edildiği anlamına gelmez." Bu çirkin bir açıklama olamazdı. Hiç kimsenin "p" etiketinin sadece dilbilgisi açısından doğru, mantıksal olarak oluşturulmuş İngilizce cümlelerin paragrafları olan şeyler için kullanılabileceğini söylediğini duymadım. Hiç kimsenin, mermi sırasına göre sıra numarası istemediğiniz için, mantıklı bir sırayla gelen bir liste için "ul" etiketi kullanmanın yanlış olduğunu söylediğini hiç duymadım. Vb.

5
Jay

Burada zaten ton büyük cevap var. Ancak table öğelerinin div öğeleri için var olmayan oluşturma sınırlamaları olduğunu eklemek istedim. Sanal kaydırma yapan bir tablo yapmayı deneyin (örneğin: SlickGrid , DataTables ve diğerleri) ve hayal kırıklığına uğrayacaksınız. Sadece işe yaramıyor. Çoğu (Tümü?) Modern Javascript ızgaraları divs kullanır çünkü css çok daha esnek bir işleme olanak tanır.

Başka sınırlamalar da var. Genel kuralım, tüm tabloyu tek bir ekranda göreceğim ve bunun için herhangi bir/çok özel oluşturma istemediğimde bir table öğesi kullanıyorum, aksi takdirde div'lerle gidiyorum Sonuçları çok daha kolay kontrol edebilirim.

5
Crisfole

HTML ve CSS bir derece esneklik geliştirmiştir; bu, <div> (HTML'nin en eski ve en genel blok içeriği biçimi) gibi kavramsal olarak "engelleme" öğelerinin bile blok olarak görüntülenmesine gerek olmadığı anlamına gelir:

div { display: inline; }

Belirttiğiniz gibi, <div> Ve <table> Ve diğer gezginlerini taklit etmek için yeniden kullanılabilir. Aslında, çoğu etiket olabilir. Özel rolleri göz önüne alındığında, <html>, <head>, <body> Ve <script> Gibi makro etiketlerini yararlı bir şekilde yeniden eşleyebileceğinizden şüpheliyim, ancak <div>, <p>, <b>, <em>, <span> Ve <pre>? Kapmak için yukarı. Satır içi etiketleri bloklar, satır içi satırlar, önceden biçimlendirilmiş etiketler akışı, sabit olanları yüzer hale getirin. İstersen delir!

mümkün . Hepimizin "semantik biçimlendirme" yi nasıl kullanmamız gerektiği konusunda bir iplik döndürmek isteyebilirsiniz blah veya Pythonistas'a “Bir - ve tercihen sadece bir - bariz bir yol olmalı” yap." Yine de Tim Toady akıllı ve meraklı bir adam. Serbest bir el verildiğinde hepsini keşfedecek. Bu, oyuncu değişikliği yapmak için mevcut esnekliğin kullanılmasını içerir. Bazıları akıllıca, bazıları aksi kanıtlanacaktır. Ancak bunu öğrenmenin tek yolu deneme, hata ve deneyimdir. Dolayısıyla, ikame için yeterli koşullar mevcuttur.

Yerine koymanın da gerekli olduğunu söylemenin aşırı olduğunu düşünmüyorum. En azından son derece kullanışlıdır . Uzun zamandır HTML'de <menu>, <section> Veya <aside> Öğeleri yoktu. Yine de her yerde web sayfaları ve uygulamaların menüleri, bölümleri ve kenar çubukları vardır. Nasıl? HTML listesi öğeleri (<ul>, <ol> Ve <li>) Kolayca yeniden yerleştirildi ve bazı kullanımlar menü kapları ve parçaları olarak yeniden sınıflandırıldı. <div>, <article>, <section>, <aside>, <figure> Ve <summary> İçin kullanılabilir. HTML5, daha önce hiç kullanılmamış bazı kullanım durumlarını yakaladı ve ısmarlama öğeler ekledi. Ortak, gerçek dünyadaki kullanım için mükemmel bir güncelleme ve düzeltme.

Buna rağmen, ısmarlama etiketleri veya semantik modelleri olmayan birçok yaygın deyim kalır . Ben ve diğerlerinin her gün kullandığı sayfalar, dipnotlar, alıntılar, yorum akışları, ilişkili avatarlar, "beğeniler", alt başlıklar ve altyazılar gibi şeyler. Ne yapacağız? Ne yapabiliriz. HTML6 veya HTML7 yakalayana kadar çalışmamızı önümüzdeki beş veya on veya yıllarca desteklemek için sınıflar ve kimliklerle "yakın ama hatalı" öğeleri yeniden kullanın. HTML/CSS'nin "evet, bu bir X, teorik olarak, ama onu etiketleyeceğiz ve onunla Y olarak çalışacağız" yeteneği inanılmaz derecede kullanışlı. Gerçekten vazgeçilmez. Web içeriğini esnekleştirir ve kırılgan olmaz.

Daha ileriye gitmek gerekirse, "anlamsal işaretleme" indirgenemez sınırlamalara sahiptir . Bu, içerik için hayal edebileceğiniz her türlü titiz yapı için geçerlidir.

Standart formatlar, tüm insani ihtiyaç, arzu ve çeşitlilik zenginliğini kapsayamaz. Her zaman insanların yaptıklarının "eğrisinin arkasında" olacaklar şimdi. Nasıl yenilik yapıyorlar. Heck, HTML5 hala dipnotlar, alt başlıklar ve 17. yüzyılın diğer baskı yeniliklerindeki eğrinin arkasında. Birçok bilgi çalışanı ve içerik oluşturucu için gerekli özelliklere sahip değildir. Yani doğaçlama yapıyoruz.

Daha da değişmeyen, bilginin bir kurallar kuralına uymamasıdır. Tabii, bir tablo olarak başlar. Ama belki sadece özeti istersiniz - her satırın başlığını liste olarak söyleyin. Belki çok fazla yer kaplar ve yerden tasarruf sağlayan satır içi liste olmasını istersiniz. Belki sadece unvanını istediğiniz kayıtlarınız vardır, o zaman tıklarsanız, alttaki ayrıntıları görürsünüz. Veya karmaşık bir listedeki veya tablodaki öğelerin gruplanmasını ve kategorilere ayrılmasını istersiniz. Oh, şimdi farklı bir şekilde aktarılmasını ve sınıflandırılmasını istiyorsunuz. Veya çubuk grafik olarak çizilen değerler. Bunlar her gün uygulamalarda, e-tablolarda ve veri görselleştirmede yapılan şeylerdir. Bunlar, bilgi ortamımızın ve web'de ne yapmak istediğimiz ve yapmamız gereken bir parçadır. İnsanlar sürekli olarak verilerimizin biçimini ve sunumunu yeniden düzenlerler. Sadece bir şey, bir biçim/düzen ya da bir kavram değil. Koşullara ve kullanıcıların etkileşimli olarak yaptıkları seçimlere bağlı olarak anlambilim ile telafi edilebilir. Evet, metni "vurgulanmış" olarak işaretleyin (<em>), Ancak bu sadece bir kural. En az yarım düzine farklı “vurgu” içeren belgeler üzerinde çalıştım. Farklı kullanımlar, farklı yorumlar için özelleştirebilmemiz ve yeniden eşleştirebilmemiz için ihtiyacımız var. Bir tür HTML vurgusu mu? Dayanılmaz derecede indirgemeci. Sınırlandırarak. Kırılgan. Aynı şey <table>, <p> Vb. İçin de geçerlidir.

Tüm topluluğun "nereye gidiyor" hakkındaki düşüncesini düzenlemeye yardımcı olan etiketlere/öğelere sahip olmak harika. Bu, sözleşmeler ve deyimler oluşturmaya yardımcı olur ve bizi toplu olarak daha verimli hale getirir. Ama şeyleri yeniden yapma, bu yapıları yeniden tasarlama ve yeniden yerleştirme yeteneği? Bu, Web'in kapsayıcılığının ve başarısının bir parçası ve parselidir.

3
Jonathan Eunice

Kullanım durumları önemlidir. İçerik sayfasındaki ve uygulamadaki düzen/sunum arasında büyük bir fark vardır. İçerik olarak, anlambilim SEO bilinci ve kullanılabilirliği için çok önemlidir. Bu durumlarda, tablo verilerinin sunulması için tabloların kullanılması genel olarak doğru olan şeydir. Diğerlerinin de belirttiği gibi, arama motorları sizi cezalandıracak ve eğer yasa tarafından kullanılabilirlik yönergelerine uymanız gerekiyorsa, kullanılabilirlik yasaları üzerinde bile çalışabilirsiniz.

Bir web uygulamasında, geliştiriciler SEO ve kullanılabilirlik amaçları için tamamen ayrı görünümler oluşturmayı seçebilirler. Duyarlı tasarım, kullanıcıların masaüstü ve mobil düzenleri işleyebilecek görünümler oluşturmasına yol açtı ve div, bu kullanım durumlarındaki tablolardan daha iyidir.

Örneğin, e-ticaret sitelerini ele alalım. Göz atma veya arama sonucundaki ürünlerin bir listesini görüntülemek genel olarak tablo biçimindeki ürünlerin bir listesini gösterir, ancak bu görünümler tablolar yerine div'ler (daha genel ve esnek düzen ve stil seçenekleri sağlayan) kullanılarak oluşturulabilir. Amazon ve eBay bu yaklaşımın güzel örnekleridir. Her iki sitede de bir arama sonucu inceleyin ve derin yuvalanmış bir div grubu görürsünüz.

0
Robert Munn