Neden insanlar divs ile masa yapıyorlar?

Modern web gelişiminde bu kalıpla daha sık karşılaşıyorum. Bu gibi 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 bile bunu kendim yapmayı denedim, çünkü ... herkes biliyor.

Ama hala anlamadım. Bunu neden yapıyoruz? Bir masaya ihtiyacınız varsa, püskürtüldü <table>ve onunla bitirin . Evet, düzen için olsa bile. Masalar bunun için var - işleri tablo şeklinde yapmak.

Sahip olduğum en iyi açıklama, şimdiye kadar herkesin "düzen için tablo kullanmayın" mantrasını duymuş olması, bu yüzden bunu kör bir şekilde takip ediyorlar. Ancak yine de düzen için bir tabloya ihtiyaçları var (çünkü başka hiçbir şey bir tablonun genişleme yeteneklerine sahip değil), bu yüzden bir tablo <div>(çünkü bu bir tablo değil !) Ve sonra yine de tablo yapan bir CSS ekliyorlar.

Tüm dünya için bu, bana gereksiz gereksiz engeller koyup, sonra onları aşmak için ekstra çalışmalar yapmak gibi görünüyor.

Mizanpaj için tablolardan uzaklaşmanın orijinal argümanı, daha sonra tablo düzenini değiştirmenin zor olmasıydı. Ancak "sahte tablo" düzenini değiştirmek de aynı derecede zor ve aynı sebepten dolayı. Aslında, uygulamada bir yerleşimi değiştirmek her zaman zordur ve eğer küçük düzeltmelerden daha ciddi bir şey yapmak istiyorsanız, sadece CSS'yi değiştirmek neredeyse hiçbir zaman yeterli değildir. Sen edecektir anlamak ve ciddi tasarım değişiklikleri için HTML yapısını değiştirmeniz gerekir. Masalar da işi divlerden daha zor veya daha kolay hale getirmiyor.

Aslında, tablolar, değiştirmek için bir düzen zorlaştıracak görüyoruz tek yolu ise olan ab kullanmıştır ve dinsiz bir karışıklık yarattı. Bunu divs ile de yapabilirsiniz.

Yani ... bunu bir ranttan tutarlı bir soruya çevirme çabasında: Neyi özlüyorum? 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 kullanmanız için bir öneri değildir. Bu bir <table>vs kullanma hakkında bir soru display:table.

Bu, duyarlı tablolar yapmak için yaygın bir kalıptır. Tablo verilerinin cep telefonlarında gösterilmesi zordur, çünkü sayfa metni okumak için yakınlaştırılır, yani tablolar sayfanın yanından geçer ve kullanıcının tabloyu okumak için ileri ve geri kaydırması gerekir, ya da sayfa uzaklaştırılır , genellikle tablonun okuyamayacak kadar küçük olduğu anlamına gelir.

Yanıt veren tablolar daha küçük ekranlarda mizanpajı değiştirir - bazen bazı sütunlar gizlenir veya sütunlar birleştirilir; örneğin, ad ve e-posta adresi büyük ekranlarda ayrı olabilir, ancak küçük ekranlarda bir hücreye daraltılır, böylece bilgi kaydırılmadan okunabilir.

<div><table>Birkaç nedenden dolayı etiketleri yerine tabloları oluşturmak için kullanılır . Eğer <table>etiketler 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>etiketler çok fazla kazan plakası CSS'den tasarruf sağlar. Ek olarak, IE'nin eski sürümleri varsayılan tablo stillerini geçersiz kılmanıza izin vermez, bu nedenle <div>s kullanımı aynı zamanda tarayıcılar arası geliştirmeyi de kolaylaştırır.

CSS-Tricks'te duyarlı tabloların oldukça iyi bir özeti var .

Düzenleme: Bu modeli savunmadığımı ve divitis tuzağına düştüğümü ve anlamsız olmadığını belirtmeliyim - ancak bu yüzden divs den yapılmış masaları bulacaksınız .

Soru, verilerin semantik olarak bir tablo olup olmadığıdır (yani iki boyutta mantıksal olarak düzenlenmiş veri veya bilgi birimleri kümesi) veya sadece görsel düzen için ızgarayı kullanıyorsunuzdur;

Bilgileriniz anlamsal olarak bir tablo ise, bir <table>-tag kullanın . Mizanpaj amacıyla sadece bir ızgara istiyorsanız, diğer uygun html öğelerini kullanın display:tableve stil sayfasında kullanın .

Veriler anlamsal olarak ne zaman tablo olur? Veriler mantıksal olarak iki eksen boyunca düzenlendiğinde. Satırlar veya sütunlar için üstbilgilerle anlaşılırsa, semantik bir tablonuz olabilir. Anlamsal olarak tablo olmayan bir şeyin bir örneği, gazete gibi sütunlarda bir metin sunmaktır. Bu anlamsal bir tablo değildir, çünkü siz hala doğrusal olarak okuyorsunuz ve sunum kaldırılırsa anlam kaybedilmez.

Tamam, neden<table> sadece anlamsal olarak tablo olan bir şey yerine her şeyi kullanmıyorsun ? Görsel olarak açıkça aynı (tablo öğesi yalnızca display:elementvarsayılan stil sayfasında olduğu için).

Fark, anlamsal bilginin alternatif kullanıcı temsilcilerine yardımcı olabileceğidir. Ö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. Eğer tablo semantik olarak bir masa olmasaydı, sadece görsel yerleşim için kullanılıyorsa bu kafa karıştırıcı olurdu.

<table>Versus display:tabletartışma anlamsal biçimlendirme kullanarak daha genel ilke sadece bir durumdur. Örneğin bakınız: Neden biri düzgün ve anlamsal olarak işaretleme yapmıyor? veya Neden anlamsal biçimlendirme arama motorlarına daha fazla ağırlık veriyor?

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

Engellilere önem vermeseniz bile, sunumdan içerikten ayrı bir şekilde yararlanmak size yarar sağlar. Örneğin, üç sütun düzeniniz, alternatif bir stil sayfası kullanarak bir cep telefonundaki tek bir sütunda sunulabilir.

Aslında, örneğinizde "table" gibi sınıf adlarının kullanılmasının, insanların semantik biçimlendirme için çalışırken ne yaptıklarını gerçekten anlamadıklarını gösterdiğini söyleyebilirim. İçeriğin tablo verileri olmadığını göstermeye çalıştığı için puan alıyorlar , ancak hatalı sınıf adları için puan kaybediyorlar.

<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>işaretlemeyi CSS sınıf adlarıyla eşlemektir. Bunun anlamı, bu düzen bir tablo olmazsa sınıf isimlerinin oranının düşük olduğu anlamına gelir.

Bu geliştiricinin yapması gereken şey, tabloda hangi bilgilerin olduğunu düşünmektir - küçük resim galerisi midir? İ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'ler 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 divs ve tabloları değil

Bir tablo sekmeli veri içerir - bir tablonun sunumu bir tablonun yapısına ayrılmaz bir şekilde bağlıdır. Tablo verilerinin, içeriğin nereye koyduğuna veya hangi ekranda / cihazda görüntülenmesini istediğinize bakmaksızın, her zaman tablo şeklinde olması gerekir.

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

Seçiminiz şimdi geniş ekran içeriği (tablolar) ve kenar çubuğu ya da dar ekran içeriği (divs) için farklı işaretlemeler üretmektir - bu, sunucu tarafı komut dosyalarınızın, bunu programlı olarak oluşturuyorsanız içeriğin nereye gittiğini bilmesi gerektiği anlamına gelir - ya da sunucu tarafı komut dosyanızın aynı işaretlemeyi göstermesini sağlayın (çünkü bunu nereye koyduğunuza dikkat etmemelidir) ve farklı durumlar için farklı CSS kuralları kullanın.

Bu nedenle, her zaman tabloları çıktısını alma ve daha sonra doğal tablo görüntüleme kurallarını blokla (herhangi bir geliştirici kafasında bazı dişlileri gerçekten öğütmesi gerekir) geçersiz kılma) ya da stillendirmede daha esnek yaklaşımlara izin veren iyi etiketli divlerle geçme seçeneğiniz vardır.

Ve birkaç yıldır en iyi uygulamalar, tablo verilerini sunmak zorunda olmadığında tablolardan kaçınmak olmuştur.

Eski günlerde, tablo genişleme motoru yüzdeleri sütun genişlikleri için kullandığınızda "daha yavaş " göründü . Motor, temelde tüm verileri indirmek zorunda kaldı, daha sonra her şeyin ekranda ne kadar büyük olduğunu ortaya çıkarmaya karar verdi.

DIV motoru farklıydı. Tarayıcı bir DIV ile karşılaştığında, devam edip yerleştirip içeriği satır içi doldurmaya başlayacaktır. Tabii ki, div'ler veri yüklemeyi tamamlarken artabilir. Bu yüzden neden yukarıdaki alıntılarda göründüm. Her ikisinin de tamamlanması için zaman çerçevesi aynıydı, ancak tablolar, kullanıcının bir veya iki saniye boyunca yüklenip yüklenmediğinden emin olmadığı anlamına gelinceye kadar tablolar çizilmedi.

Tablolar yuvalandıkça daha da kötüleşti.

Daha sonra tablo işleme FAR FAR'ı daha hızlı hale getirmenin yolları vardı (ve hala var). Temelde sütun boyutlarının değişmediğine dair bir ipucu vererek, ardından tarayıcı anında tablo verilerini oluşturmaya başlar. Nihayetinde bu, tabloların divs'den daha hızlı bir şekilde doğru konumda görüntüleyebileceği ve daha iyi olmalarını sağladığı anlamına gelir .

Ama bütün hikaye bu değil. Bunun geri kalanı çoğu devin bunu bilecek kadar iyi bir şekilde öğrenmek için uğraşmadığıdır. Bunun yerine çeşitli bandwagonlara atlıyorlar ve kopyalayıp / yapıştırabilecekleri kodları kullanıyorlar. Bugün bile çok az sayıda web geliştiricisinin bir doktipten diğerine olan farkı bildiğini biliyorum - ve bu, çeşitli sitelerin çeşitli tarayıcıları kapsayacak şekilde her türlü geçici çözümlere sahip olmasının bir numaralı nedenidir.

Yani, soruyu sorduğun için sana + 1.

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

Bir: Biri iyi bir sebepten dolayı bir kural önerdi ve insanlar ruhu görmezden gelirken kuralın teknik harfini izleyerek bu noktayı tamamen özlüyorlar. Kuralı önlemeye çalıştığı tüm kötü şeyleri başarmanın bir yolunu bulmaya devam ederken, yine de teknik olarak ifadeyi uyguladı.

İki: Birisi bir problem görüyor ve önlenmesi için bir kural öneriyor. Diğerleri bu kuralın değerini görüyor. Ardından, çözmeleri beklenen orijinal sorundan bağımsız olarak ve / veya hangi sorunları yarattığından bağımsız olarak, bu kurala kör bağlılıkta ısrar ediyorlar. Birinin "X'i yapmalısın çünkü kural budur" dediği birçok konuşmam oldu ve sonra da "Peki neden X yapmalıyız?" Sana sadece söyledim! Çünkü kural bu! " "Ama çözdüğünden daha fazla soruna neden oluyor gibi görünüyor. Y'yi yapmak için daha iyi olacağımızı düşünüyorum." Sonra kişi, "Hayır, bak, sana göstereyim. Bakın, 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 veya sayı sütunları veya diğer verilerden oluştuğu fikrini iletir.

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

Ancak bu çözümle ilgili bir sorun var. Tablo etiketi ve alt etiketleri, CSS kullanarak elde edilmesi kolay olmayan birçok kullanışlı düzen işlevini kullanır ve elde edilebildiklerinde, yapılması gereken kod genellikle hantaldır - okunması zor ve bakımı zordur. Temiz, kolay bir yol varken neden işleri sakar, zor yoldan yapalım?

Şahsen, “Bir tablo etiketinin içinde bir şeyin olması, mutlaka sayıların satırlarını ve sütunlarını temsil ettiği anlamına gelmez” demesini açıklamaktan daha iyi olacağını düşünüyorum. Bu çok çirkin bir ifade olmazdı. Daha önce hiç kimsenin "p" etiketinin yalnızca dilbilgisi bakımından doğru olmayan, mantıksal olarak oluşturulmuş İngilizce cümle paragrafları olan şeyler için kullanılabileceğini söylediğini duymadım. Birisinin "sıra" etiketi kullanmanın yanlış olduğunu söylediğini hiç duymamıştım, aslında sıralı sayıları değil, madde işareti istediğiniz için, aslında mantıklı bir sıraya giren bir liste. Vb.

Burada zaten tonlarca harika cevap var. Ancak tableelementlerin var olmayan divelement kısıtlamalarının olduğunu da eklemek istedim . Sanal kaydırma yapan bir tabloyu deneyin ve deneyin (örneğin: SlickGrid , DataTables ve diğerleri) ve çok üzüleceksiniz. Sadece işe yaramıyor. Çoğu (Tümü?) Modern Javascript ızgaraları divs kullanır çünkü css çok daha esnek görüntülemeye izin verir.

Başka sınırlamalar da var. Genel kuralım, eğer bütün masayı tek bir ekranda göreceksem ve bunun için herhangi bir özel işlem yapmak istemiyorsam table, bir eleman kullanırım , aksi halde sonuçları çok fazla kontrol edebildiğim için divs ile giderim. çok daha kolay.

HTML ve CSS, bir dereceye kadar bir esneklik geliştirmiştir; bu da kavramsal olarak "blok" öğelerinin bile <div>(HTML'nin en eski ve en genel blok içeriği biçimi) blok olarak gösterilmesi gerekmediği anlamına gelir:

div { display: inline; }

Sizin de belirttiğiniz gibi, <div>taklit etmek <table>ve diğer yolcular için yeniden düzenlenebilir . Aslında, çoğu etiket olabilir. Onların özel rolleri göz önüne alındığında, sana yararlı gibi makro etiketleri yeniden eşleştirmek şüpheliyim <html>, <head>, <body>, ve <script>benzeri, ancak "ortak" etiketleri <div>, <p>, <b>, <em>, <span>, ve <pre>? Kapmak için yukarı. Satır içi etiket bloklarını, satır içi blokları, önceden biçimlendirilmiş etiketlerin akmasını sağlayın, durağan olanları süzün. İstersen deliye dön!

Bu mümkün . Hepimizin "semantik biçimlendirme" filan nasıl kullanmaları gerektiğini konusunda bir hikâye anlatmak isteyebilir vesaire o Pythonistas ile veya inanmak "tek olmalıdır - ve tercihen tek - bariz şekilde yapmak." Yine de Tim Toady akıllı ve meraklı bir adam. Serbest bir el verildiğinde hepsini keşfedecek. Bu ikame yapmak için mevcut esnekliği kullanmayı içerir. Bazıları akıllı, bazıları ise kanıtlanacak. Ancak deneme, yanılma ve tecrübe bunu anlamanın tek yoludur. Dolayısıyla, ikame için yeterli koşullar mevcuttur.

İkamenin de gerekli olduğunu söylemenin gereğinden fazla olduğunu sanmıyorum. En azından son derece uygun . Uzun bir süredir, HTML yoktu <menu>, <section>ya <aside>unsurları. Ancak her yerdeki web sayfaları ve uygulamaların menüleri, bölümleri ve kenar çubukları vardır. Nasıl? Çünkü HTML liste öğeleri ( <ul>, <ol>ve <li>) kolayca yeniden düzenlenir ve bazı kullanımlar menü kapları ve parçaları olarak yeniden sınıflandırılır. <div>için duramazdı <article>, <section>, <aside>, <figure>, ve <summary>. HTML5, daha önce bildirilmemiş bazı kullanım durumlarını yakaladı ve ısmarlama öğeler ekledi. Yaygın, gerçek dünya kullanımına uyum sağlamak için harika bir güncelleme ve düzeltmedir.

Buna rağmen, ısmarlama etiketlere veya anlamsal modellere sahip olmayan pek çok ortak deyim kalmıştır . Sayfalar, dipnotlar, alıntılar, yorum akışları, ilişkili avatarlar, "beğeniler" alt başlıkları ve ben ve başkalarının her gün kullandığı alt yazılar gibi şeyler. Ne yapıcaz? Ne yapabiliriz? HTML6 veya HTML7'yi yakalayana kadar önümüzdeki beş, on ya da birkaç yıl boyunca çalışmalarımızı desteklemek ve desteklemek için sınıfları ve kimlikleri olan "yakın ancak tam olmayan" öğeleri yeniden kullanın. HTML / CSS'nin "evet, bu bir X, teoride, ancak onu etiketleyeceğiz ve onunla bir Y olarak çalışacağız" yeteneği inanılmaz derecede uygun. Gerçekten vazgeçilmez. Web içeriğini esnek kılar ve kırılgan olmamasını sağlar.

Daha da ileri giderek, "semantik biçimlendirme" nin indirgenemez sınırlamaları vardır . 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 şu anda yaptıklarının "eğrinin arkasında" olacaklar . Nasıl yenilik yapıyorlar? Heck, HTML5 hala 17. yüzyılın dipnotları, alt başlıkları ve diğer baskı yeniliklerinde eğrinin gerisindedir. Birçok bilgi çalışanı ve içerik oluşturucu için gerekli özelliklerden yoksundur. Böylece doğaçlama yaparız.

Daha da fazla değişmeyen, bilginin bir kurallar kuralına uymadığıdır. Elbette, bir masa olarak başlar. Ama belki de sadece özeti istersiniz - her satırın başlığını liste olarak söyleyin. Belki de çok fazla yer kaplar ve yer tasarrufu sağlayan bir satır içi listesi olmasını istersiniz. Belki de sadece unvanını istediğiniz kayıtlarınız vardır, o zaman tıklarsanız temel detayları görürsünüz. Ya da karmaşık bir listedeki ya da tablodaki öğelerin gruplandırılıp kategorize edilmesini istersiniz. Oh, şimdi tercüme edilmesini ve farklı bir şekilde kategorize edilmesini istiyorsun. Veya çubuk grafik olarak çizilen değerler. Bunlar her gün uygulamalarda, elektronik tablolarda ve veri görselleştirmesinde yapılır. Bilgi alanımızın bir parçası ve parselleri, ne yapmak istediklerimiz ve web üzerinde ne yapmamız gerekiyor. İnsanlar verilerimizin şeklini ve sunumunu sürekli olarak yeniden düzenlerler. Bu sadece bir şey değil veya bir format / düzen, veya bir kavram. Durumlara bağlı olarak ve kullanıcıların etkileşimli olarak yaptıkları seçimlere göre anlambilimiyle elverişlidir. Evet, metni "vurgulandı" olarak işaretle (<em>) ama bu sadece bir kongre. En az yarım düzine farklı türde "vurgu" içeren belgeler üzerinde çalıştım. Biz ihtiyacımız özelleştirmek ve farklı kullanımlar, farklı yorumlara olduğunu yeniden eşleştirmek için muktedir. Bir tür HTML vurgusu? İnanılmaz derecede indirgemeci. Sınırlandırarak. Kırılgan. Aynı için de geçerlidir <table>, <p>vs.

Tüm topluluğun "neyin nereye gittiğini" düşünmesine yardımcı olacak etiketlere / öğelere sahip olmak harika. Bu, sözleşmelerin ve deyimlerin kurulmasına yardımcı olur ve toplu olarak daha verimli olmamızı sağlar. Fakat işleri yeniden biçimlendirme, yeniden tasarlama ve yeniden yapılandırma yeteneği mi? Bu, Web’in kapsayıcılığının ve başarısının bir parçasıdır.

Önemli durumlarda kullanın. Bir içerik sayfasındaki düzen / sunum arasında ve bir uygulamada büyük bir fark vardır. İçerik olarak, anlambilim SEO-farkındalık ve kullanılabilirlik için çok önemlidir. Bu durumlarda, tablo verilerini sunmak için tabloları kullanmak genel olarak yapılacak doğru şeydir. Diğerlerinin de belirttiği gibi, arama motorları sizi cezalandırır ve yasaların kullanılabilirlik kurallarına uyması gerekiyorsa, kullanılabilirlik yasalarını bile ihlal edebilirsiniz.

Bir web uygulamasında, geliştiriciler SEO ve kullanılabilirlik amaçları için tamamen ayrı görünümler oluşturmayı tercih edebilirler. Duyarlı tasarım, insanları masaüstü ve mobil düzenleri idare edebilecek görünümler oluşturmaya itmiştir ve divs bu kullanım durumlarındaki tablolardan daha iyidir.

Örneğin, e-ticaret sitelerini ele alalım. Bir ürün listesini bir göz atma veya arama sonucunda görüntülemek, genel olarak, tablo biçimindeki ürünlerin listesini gösterir, ancak bu görünümler tablolardan ziyade divs (daha genel ve esnek düzen ve stil seçenekleri sunan) kullanılarak oluşturulabilir. Amazon ve eBay bu yaklaşımın güzel örnekleridir. Her iki sitede de bir arama sonucu inceleyin; derinlemesine yuvalanmış divs kümesi görürsünüz.