HTML'de mizanpaj için tabloları neden kullanmıyorsunuz? [kapalı]

Tabloların HTML'deki düzen için kullanılmaması gerektiği genel bir görüş gibi görünmektedir .

Neden?

Bunun için asla iyi argümanlar görmedim (veya nadiren dürüst olmak gerekirse). Genel cevaplar:

• İçeriği mizanpajdan ayırmak iyidir
  Ama bu yanlış bir argüman; Klişe Düşünme . Düzen için tablo öğesini kullanmanın tablo verileriyle çok az ilgisi olduğunu tahmin ediyorum. Ne olmuş yani? Patronum umursuyor mu? Kullanıcılarım umurunda mı?
  
  Belki ben veya bir web sayfası bakımı yapmak zorunda olan geliştiricilerim ... Bir tablo daha az bakım yapılabilir mi? Bir tablo kullanmak div ve CSS kullanmaktan daha kolay olduğunu düşünüyorum .
  
  Bu arada ... neden div veya span aralığı içeriğin mizanpajdan ve tablodan iyi bir şekilde ayrılıyor? Yalnızca div'lerle iyi bir düzen elde etmek çoğu zaman çok sayıda iç içe div gerektirir.

• Kodun okunabilirliği
  başka bir yol olduğunu düşünüyorum. Çoğu insan HTML'yi, birkaçı CSS'yi anlar.

• SEO'nun tablo kullanmaması daha iyidir
  Neden? Herkes bunun olduğuna dair bir kanıt gösterebilir mi? Veya Google'dan, tabloların SEO perspektifinden vazgeçtiğine dair bir açıklama mı?

• Tablolar daha yavaştır.
  Fazladan bir tbody elemanı yerleştirilmelidir. Bu modern web tarayıcıları için fıstık. Tablo kullanımının sayfayı önemli ölçüde yavaşlattığı bazı ölçütleri göster.

• Tablolar olmadan düzen revizyonu daha kolaydır, bkz. Css Zen Garden .
  Yeni sürüme geçiş gerektiren web sitelerinin çoğunun da yeni içeriğe (HTML) ihtiyacı vardır. Bir web sitesinin yeni bir sürümünün yalnızca yeni bir CSS dosyasına ihtiyaç duyduğu senaryolar pek olası değildir. Zen Garden güzel bir web sitesi ama biraz teorik. CSS'yi kötüye kullanmasından bahsetmiyorum bile .

Tablolar yerine divs + CSS kullanmak için iyi argümanlarla gerçekten ilgileniyorum.

Argümanlarınızı birbiri ardına inceleyeceğim ve içindeki hataları göstermeye çalışacağım.

İçeriği mizanpajdan ayırmak iyidir Ama bu yanlış bir argüman; Cliché Düşünme.

HTML kasıtlı olarak tasarlandığı için hiç yanlış değil. Bir öğenin kötüye kullanılması tamamen söz konusu olmayabilir (sonuçta, diğer dillerde de yeni deyimler geliştirilmiştir), ancak olası olumsuz etkilerin dengelenmesi gerekir. Ayrıca, <table>bugün öğeyi kötüye kullanmayla ilgili herhangi bir argüman olmasa bile , tarayıcı satıcılarının öğeye özel muamele uygulama şekli nedeniyle yarın olabilir. Sonuçta, “ <table>elemanlar sadece tablo verileri içindir” ve bu gerçeği renderleme motorunu iyileştirmek için kullanabilirler <table>.

Ne olmuş yani? Patronum umursuyor mu? Kullanıcılarım umurunda mı?

Bağlı olmak. Patronun sivri saçlı mı? O zaman umursamayabilir. Eğer yetkinse, o zaman umursar, çünkü kullanıcılar yapacak .

Belki ben veya bir web sayfası bakımı yapmak zorunda olan geliştiricilerim ... Bir tablo daha az bakım yapılabilir mi? Bir tablo kullanmak div ve css kullanmaktan daha kolay olduğunu düşünüyorum.

Profesyonel web geliştiricilerinin çoğu size karşı çıkıyor gibi görünüyor^{[ alıntı gerekli ]} . Tablolar That olan aslında daha az sürdürülebilir açık olmalı. Düzen için tablo kullanmak, şirket düzenini değiştirmenin aslında her bir sayfayı değiştirmek anlamına geleceği anlamına gelir. Bu çok pahalı olabilir. Öte yandan, CSS ile kombine semantik olarak anlamlı HTML akıllıca kullanılması olabilir CSS değişiklikleri ve kullanılan resimler sınırlandırmak.

Bu arada ... neden div veya span aralığı içeriğin mizanpajdan ve tablodan iyi bir şekilde ayrılmıyor? Yalnızca div'lerle iyi bir düzen elde etmek çoğu zaman çok sayıda iç içe div gerektirir.

Derin iç içe yerleştirilmiş <div>s, tıpkı masa düzeni gibi bir anti-desendir. İyi web tasarımcılarının çoğuna ihtiyaç yoktur. Öte yandan, böyle derin iç içe divlar bile tablo düzenlerinin sorunlarının çoğuna sahip değildir. Aslında, içeriği mantıksal olarak parçalara bölerek anlamsal bir yapıya bile katkıda bulunabilirler.

Kodun okunabilirliği başka bir yol olduğunu düşünüyorum. Çoğu insan html, az css anlıyorum. Daha basit.

“Çoğu insan” önemli değil. Profesyoneller önemlidir. Profesyoneller için tablo düzenleri HTML + CSS'den çok daha fazla sorun yaratır. Bu, GVim veya Emacs kullanmamam gerektiğini söylemek gibi çünkü Not Defteri çoğu insan için daha basit. Ya da LaTeX kullanmamam gerektiğini çünkü MS Word çoğu insan için daha basit.

SEO'nun tablo kullanmaması daha iyidir

Bunun doğru olup olmadığını bilmiyorum ve bunu bir argüman olarak kullanmayacak mıyım ama mantıklı olacaktı. Arama motorları ilgili verileri arar . Sekmeli veriler elbette alakalı olsa da, nadiren kullanıcıların aradığı şey budur. Kullanıcılar sayfa başlığında kullanılan terimleri veya benzer şekilde öne çıkan konumları arar. Bu nedenle, sekmeli içeriğin filtrelenmesini engellemek ve böylece işlem süresini (ve maliyetleri!) Büyük bir faktörle kesmek mantıklı olacaktır.

Tablolar daha yavaştır. Fazladan bir tbody elemanı yerleştirilmelidir. Bu modern web tarayıcıları için fıstık.

Ek öğenin tabloların daha yavaş olmasıyla hiçbir ilgisi yoktur. Öte yandan, tablolar için düzen algoritması çok daha zordur, tarayıcı genellikle içeriği düzenlemeye başlamadan önce tüm tablonun yüklenmesini beklemek zorundadır. Ayrıca, düzenin önbelleğe alınması çalışmaz (CSS kolayca önbelleğe alınabilir). Bütün bunlar daha önce de belirtilmişti.

Tablo kullanımının sayfayı önemli ölçüde yavaşlattığı bazı ölçütleri göster.

Ne yazık ki, herhangi bir karşılaştırma verim yok. Kendimle ilgileneceğim çünkü bu argümanın belirli bir bilimsel titizlikten yoksun olması doğru.

Yeni sürüme geçiş gerektiren web sitelerinin çoğunun da yeni içeriğe (html) ihtiyacı vardır. Bir web sitesinin yeni bir sürümünün yalnızca yeni bir css dosyasına ihtiyaç duyduğu senaryolar pek olası değildir.

Bir şey değil. Tasarımı değiştirmenin içerik ve tasarımın ayrılmasıyla basitleştirildiği birkaç durum üzerinde çalıştım. Bazı HTML kodlarını değiştirmek genellikle gereklidir, ancak değişiklikler her zaman çok daha kısıtlı olacaktır. Ayrıca, tasarım değişiklikleri zaman zaman dinamik olarak yapılmalıdır. WordPress blog sistemi tarafından kullanılan şablon motorlarını düşünün. Tablo düzenleri tam anlamıyla bu sistemi öldürür. Ticari bir yazılım için benzer bir vaka üzerinde çalıştım. HTML kodunu değiştirmeden tasarımı değiştirebilmek iş gereksinimlerinden biriydi.

Başka bir şey. Tablo düzeni, web sitelerinin otomatik olarak ayrıştırılmasını (ekran kazıma) çok daha zor hale getirir. Bu önemsiz gelebilir, çünkü sonuçta, kim yapar? Kendime şaşırdım. Söz konusu hizmet, verilerine erişmek için bir WebServis alternatifi sunmuyorsa ekran kazıma çok yardımcı olabilir. Bunun üzücü bir gerçek olduğu biyoinformatik alanında çalışıyorum. Modern web teknikleri ve WebServices çoğu geliştiriciye ulaşmadı ve çoğu zaman ekran kazıma veri alma işlemini otomatikleştirmenin tek yoludur. Birçok biyologun hala bu tür görevleri manuel olarak gerçekleştirmesine şaşmamak gerek. Binlerce veri seti için.

İşte benim programcı bir simliar iş parçacığından cevap

Anlambilim 101

Önce bu koda bir göz atın ve burada neyin yanlış olduğunu düşünün ...

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

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

Sorun, elbette, bir bisikletin bir araba olmamasıdır. Araba sınıfı, bisiklet örneği için uygun olmayan bir sınıftır. Kod hatasız, ancak anlamsal olarak yanlış. Programcıya kötü yansır.

Anlambilim 102

Şimdi bunu belge biçimlendirmesine uygulayın. Belgenizin sekmeli veriler sunması gerekiyorsa, uygun etiket olur <table>. Ancak gezinmeyi bir tabloya yerleştirirseniz, <table>öğenin amaçlanan amacını kötüye kullanırsınız . İkinci durumda, tablo verileri sunmuyorsunuz - <table>sunumu hedeflemek için öğeyi kullanıyorsunuz .

Sonuç

Ziyaretçiler fark edecek mi? Hayır. Patronun umurunda mı? Olabilir. Bazen programcı olarak köşeleri keser miyiz? Elbette. Ama yapmalı mıyız? Hayır. Anlamsal işaretleme kullanırsanız kim yararlanır? Siz - ve profesyonel itibarınız. Şimdi git ve doğru olanı yap.

Açık cevap: Bkz. CSS Zen Bahçesi . Bana aynı şeyi tablo tabanlı bir mizanpaj ile kolayca yapabileceğinizi söylerseniz (unutmayın - HTML değişmez), o zaman elbette mizanpaj için tabloları kullanın.

Diğer iki önemli şey erişilebilirlik ve SEO.

Her ikisi de hangi sipariş bilgilerinin sunulduğunu önemser. Tablo tabanlı mizanpajınız, sayfada 2. iç içe tablonun 2. satırının 3. hücresine yerleştirirse, gezinmenizi sayfanın üst kısmında kolayca sunamazsınız.

Cevaplarınız sürdürülebilirlik, erişilebilirlik ve SEO.

Tembel olma. Öğrenmesi biraz zor olsalar bile işleri doğru ve doğru bir şekilde yapın.

Bu yinelenen soruya bakın.

Unuttuğunuz bir öğe erişilebilirliktir. Örneğin bir ekran okuyucu kullanmanız gerekiyorsa, tablo tabanlı mizanpajlar da çevrilmez. Hükümet için çalışıyorsanız, ekran okuyucular gibi erişilebilir tarayıcıları desteklemeniz gerekebilir .

Ayrıca, soruda bahsettiğiniz bazı şeylerin etkisini de hafife aldığınızı düşünüyorum. Örneğin, hem tasarımcı hem de programcıysanız, sunumu içerikten ne kadar iyi ayırdığına dair tam bir takdiriniz olmayabilir. Ancak iki farklı rolün olduğu bir dükkana girdikten sonra avantajlar daha net olmaya başlar.

Ne yaptığınızı biliyorsanız ve iyi araçlara sahipseniz, CSS'nin düzen tablolarına göre gerçekten önemli avantajları vardır. Ve her bir madde tek başına terk edilmiş tabloları haklı göstermeyebilirken, birlikte alındığında genellikle buna değer.

Ne yazık ki, CSS Zen Garden artık iyi HTML / CSS tasarımının bir örneği olarak kullanılamaz. Hemen hemen tüm tasarımları bölüm başlığı için grafikler kullanır. Bu grafik dosyaları CSS'de belirtilmiştir.

Bu nedenle, amacı tasarımı içerikten uzak tutma avantajını göstermek olan bir web sitesi, artık düzenli olarak içeriği tasarıma sokmak için UNSPEAKABLE SIN'i taahhüt etmektedir. (HTML dosyasındaki bölüm başlığı değişecek olsaydı, görüntülenen bölüm başlığı değişmez).

Bu sadece katı DIV ve CSS dinini savunanların bile kendi kurallarına uymadığını göstermektedir. Bunu, onları ne kadar yakından takip ettiğinizde bir rehber olarak kullanabilirsiniz.

Bu kesin bir argüman değildir, ancak CSS ile aynı işaretlemeyi alabilir ve ortama bağlı olarak düzeni değiştirebilirsiniz, bu hoş bir avantajdır. Bir yazdırma sayfası için, örneğin yazıcı dostu bir sayfa oluşturmak zorunda kalmadan navigasyonu sessizce engelleyebilirsiniz.

Düzen için bir tablo o kadar da kötü olmazdı. Ancak çoğu zaman tek bir tablo ile ihtiyacınız olan düzeni elde edemezsiniz. Çok yakında 2 veya üç iç içe tablonuz var. Bu çok hantal bir hal alıyor.

• Okuması çok daha zor. Bu görüşe bağlı değil. Üzerinde tanımlayıcı işaret olmayan daha fazla iç içe etiket var.

• İçeriği sunumdan ayırmak iyi bir şeydir çünkü yaptığınıza odaklanmanıza izin verir. İki ucu karıştırmak zor okunan sayfalara yönlendirir.

• Stiller için CSS, tarayıcınızın dosyaları önbelleğe almasını sağlar ve sonraki istekler çok daha hızlıdır. Bu cok büyük.

• Tablolar sizi bir tasarıma kilitler. Elbette, herkesin CSS Zen Garden'ın esnekliğine ihtiyacı yoktur, ancak tasarımı burada ve orada biraz değiştirmem gerekmediğim bir sitede hiç çalışmadım. CSS ile çok daha kolay.

• Tabloları şekillendirmek zordur. Onlarla çok fazla esnekliğiniz yok (yani, tablonun stillerini tam olarak kontrol etmek için HTML nitelikleri eklemeniz gerekiyor)

Muhtemelen 4 yıldır tablo olmayan veriler için tablo kullanmadım. Geriye bakmadım.

Andy Budd'ın CSS Mastery'lerini okumayı gerçekten öneririm . O fantastik.

Ecx.images-amazon.com adresindeki resim http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

İçeriği mizanpajdan ayırmak iyidir
Ama bu yanlış bir argüman; Klişe Düşünme

Bu yanlış bir argüman çünkü HTML tabloları düzen! İçerik tablodaki verilerdir , sunum tablonun kendisidir. Bu nedenle CSS'yi HTML'den ayırmak bazen çok zor olabilir. İçeriği sunumdan ayırmıyorsunuz, sunumu sunumdan ayırıyorsunuz! İç içe div yığını, tablodan farklı değildir - yalnızca farklı bir etiket kümesidir.

HTML'yi CSS'den ayırmanın bir diğer problemi, birbirleriyle ilgili samimi bilgiye ihtiyaç duymalarıdır - onları tamamen ayıramazsınız. HTML'deki etiket düzeni, ne yaparsanız yapın CSS dosyasıyla sıkı bir şekilde eşleştirilir.

Bence tablolar vs divs uygulamanızın ihtiyaçlarına geliyor.

İş yerinde geliştirdiğimiz uygulamada, parçaların dinamik olarak içeriklerine göre boyutlandırılacağı bir sayfa düzenine ihtiyacımız vardı. CSS ve DIV'lerle çapraz tarayıcı çalışması için günler geçirmeye çalıştım ve tam bir kabus oldu. Biz tablolara geçti ve hepsi sadece çalıştı .

Bununla birlikte, ürünümüz için çok kapalı bir kitleye sahibiz (web arayüzü ile bir parça donanım satıyoruz) ve erişilebilirlik sorunları bizim için bir endişe değildir. Ekran okuyucularının neden tablolarla iyi başa çıkamayacağını bilmiyorum, ama sanırım geliştiriciler bununla başa çıkmak zorunda.

CSS / DIV - sadece tasarım erkekleri için işler, değil mi? Yüzlerce saat DIV / CSS sorunlarını ayıklamak için harcadım, biçimlendirmenin bir kısmını belirsiz bir tarayıcıyla çalışmak için İnternet'te aradım - bu beni deli ediyor. Küçük bir değişiklik yaparsınız ve tüm düzen korkunç bir şekilde yanlış gider - bunun altında mantık nerede. Saatleri 3 piksel bu şekilde hareket ettirerek geçirin, sonra başka bir şey 2 piksel diğerini hizalayın. Bu benim için bir şekilde yanlış görünüyor. Sadece sade biri olmanız ve bir şeyin "yapılması gereken doğru şey olmaması" nı, nihayetinde ve her koşulda kullanmanız gerektiği anlamına gelmez, özellikle de hayatınızı 1000 kat kolaylaştırırsa.

Sonunda, sadece ticari nedenlerle karar verdim, her ne kadar minimum düzeyde kullanmaya devam etsem de, bir DIV'nin doğru yerleştirilmesi için 20 saat çalışmayı tahmin edersem, bir masaya yapışacağım. Yanlış, safları üzüyor, ancak çoğu durumda daha az zaman alıyor ve yönetilmesi daha ucuz. Daha sonra uygulamayı, sahtekarları memnun etmek yerine, müşterinin istediği gibi çalıştırmaya konsantre olabilirim. Sonuçta faturaları ödüyorlar ve CSS / DIV kullanımını zorlayan bir menajere yaptığım argüman - sadece müşterilerin maaşını da ödediğine işaret ediyorum!

Tüm bu CSS / DIV argümanlarının ortaya çıkmasının tek nedeni, CSS'nin ilk etapta eksik olması ve tarayıcıların birbirleriyle uyumlu olmaması ve eğer olsaydı, dünyadaki web tasarımcılarının yarısının işsiz kalmasıdır. .

Bir pencere formu tasarladığınızda, denetimleri yerleştirdikten sonra hareket ettirmeyi denemezsiniz, bu yüzden bunu neden bir web formu ile yapmak isteyeceğinizi düşünüyorum. Bu mantığı anlayamıyorum. Düzeni en doğru şekilde yapın ve sorunun ne olduğunu görün. Bence tasarımcılar yaratıcılıkla flört etmeyi severken, uygulama geliştiricileri uygulamanın gerçekte çalışmasını, iş nesnelerini oluşturmayı, iş kurallarını uygulamayı, müşteri verilerinin parçalarının birbiriyle nasıl ilişkilendiğini, şeyin müşterilerle buluşmasını sağlamakla daha çok ilgileniyorlar. Gereksinimler - bilirsiniz - gerçek dünyadaki şeyler gibi.

Beni yanlış anlamayın, her iki argüman da geçerlidir, ancak lütfen geliştiricilerin formları tasarlamak için daha kolay ve daha mantıklı bir yaklaşım seçtikleri için eleştirmeyin. Endişelenecek sık sık, div üzerinde tablo kullanmanın doğru anlamlarından daha önemli şeylerimiz vardır.

Vakaya göre - bu tartışmaya dayanarak birkaç mevcut tds ve tr'i div'e dönüştürdüm. 45 dakika yan yana dizmek için her şeyi almaya çalışırken onunla uğraşmak ve pes ettim. TD'ler 10 saniye sonra geri dönüyor - hemen çalışıyor - tüm tarayıcılarda çalışıyor, yapacak başka bir şey yok. Lütfen beni anlamaya çalışın - başka bir şekilde yapmamı istemek için ne gibi bir gerekçeniz var!

Düzen kolay olmalıdır. CSS'de üstbilgi ve altbilgi ile dinamik üç sütunlu bir düzenin nasıl elde edileceğine dair yazılı makaleler olması, bunun kötü bir düzen sistemi olduğunu gösterir. Tabii ki çalıştırabilirsiniz, ancak kelimenin tam anlamıyla nasıl yapılacağı hakkında yüzlerce makale var. Patentli olarak açık olduğu için tablolarla benzer bir düzen için hemen hemen hiç böyle makale yok. Tablolara karşı ve CSS lehine ne söylerseniz söyleyin, bu gerçek her şeyi geri alır: CSS'deki temel üç sütun düzeni genellikle "Kutsal Kase" olarak adlandırılır.

Bu size "WTF" dememenizi sağlamazsa, şimdi kool-yardımını şimdi bırakmanız gerekir.

CSS'yi seviyorum. İnanılmaz stil seçenekleri ve bazı harika konumlandırma araçları sunar, ancak bir düzen motoru olarak eksiktir. Bir çeşit dinamik ızgara konumlandırma sistemi olması gerekir. Önce boyutlarını bilmeden çoklu eksen üzerindeki kutuları hizalamanın basit bir yolu. <table> ya da <gridlayout> ya da her neyse denir, ama bu CSS'de eksik olan temel bir düzen özelliğidir.

Daha büyük sorun, eksik özellikler olduğunu kabul etmeyerek, CSS zealotlarının CSS'yi olabildiğince geri tutmasıdır. CSS, dünyadaki diğer tüm yerleşim motorları gibi iyi çok eksenli ızgara konumlandırması sağladıysa, tabloları kullanmayı bırakmaktan memnuniyet duyarım. (Bu sorunun W3C dışındaki herkes tarafından birçok dilde zaten birçok kez çözüldüğünün farkındasınız, değil mi? Ve kimse böyle bir özelliğin yararlı olduğunu reddetmedi.)

İç çekmek. Yeterli havalandırma. Devam et ve başını kuma sok.

508 uyumluluğuna göre (görsel olarak ifade edilen ekran okuyucular için), ekran okuyucularının çıldırmasına neden olduğu için tablolar yalnızca verileri tutmak için kullanılmalıdır. Yoksa bana söylendi.

Div'lerin her birine ad atarsanız, CSS kullanarak da hepsini kaplayabilirsiniz. İhtiyacınız olan şekilde oturmak için biraz daha acı veriyorlar.

İşte son zamanlardaki bir projeden html'nin bir bölümü:

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

Ve işte tablo tabanlı bir düzen ile aynı kod.

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

Bu tablo tabanlı düzende gördüğüm tek temizlik, girintim ile aşırı hevesli olduğum gerçeğidir. İçerik bölümünün iki gömülü tablonun daha olacağından eminim.

Düşünülmesi gereken başka bir şey: dosya boyutları . Tablo tabanlı mizanpajların genellikle CSS muadillerinin iki katı büyüklüğünde olduğunu gördüm. Yüksek hızlı genişbantımızda bu çok büyük bir sorun değil, ancak çevirmeli modem kullananlarda.

Div tabanlı mizanpajların mantain, evrim ve refactor için daha kolay olduğunu eklemek isterim. Sadece öğeleri yeniden düzenlemek için CSS bazı değişiklikler ve yapılır. Deneyimlerime göre, tabloları kullanan bir düzeni yeniden tasarlamak bir kabus (iç içe geçmiş tablolar varsa daha fazla).

Kodunuzun anlambilimsel açıdan da bir anlamı vardır .

DIV'lerde hiçbir tartışma benden yana değil.

Şunu söyleyebilirim: Eğer ayakkabı uygunsa, giyin.

İki veya üç sütunda içerik oluşturmak için iyi bir DIV + CSS yöntemi bulmak imkansız değilse de zor, bu da tüm tarayıcılarda tutarlı ve yine de istediğim gibi görünüyor.

Bu, düzenlerimin çoğunda tablolara doğru dengeyi biraz ipuçları ve onları kullanmaktan suçlu olmama rağmen (dunny neden, insanlar sadece kötü olduğunu söylüyor, onları dinlemeye çalışıyorum), sonunda, pragmatik görünüm sadece TABLOları kullanmam daha kolay ve hızlı. Saat tarafından ödenmiyorum, bu yüzden tablolar benim için daha ucuz.

İçeriğin doğal bir sırayla gelmesi ve bir stil sayfası olmadan anlamlı olması koşuluyla, CSS mizanpajları genellikle erişilebilirlik için çok daha iyidir. Ayrıca, tablo tabanlı mizanpajlarla mücadele eden sadece ekran okuyucular değil: aynı zamanda mobil tarayıcıların bir sayfayı düzgün bir şekilde oluşturmasını da zorlaştırıyor.

Ayrıca, div tabanlı bir düzenle, üstbilgiler, altbilgiler ve yazdırılan sayfalardan gezinme gibi bir baskı stil sayfası ile çok güzel şeyler yapabilirsiniz - bence bunu bir ile yapmak imkansız veya en azından çok daha zor olurdu tablo tabanlı düzen.

Divs ile içeriğin mizanpajdan ayrılmasının tablolardan daha kolay olduğundan şüphe ediyorsanız, CSS Zen Garden'daki div tabanlı HTML'ye bir göz atın bakın, stil sayfalarını değiştirmenin mizanpajı nasıl değiştirebileceğini görün ve yapıp yapamayacağınızı düşünün HTML tablo tabanlıysa aynı düzenleri elde edin ... Tablo tabanlı bir düzen yapıyorsanız, hücrelerdeki tüm boşlukları ve dolguları kontrol etmek için CSS kullanmanız pek olası değildir ( neredeyse kesinlikle kayan div vb. kullanımı daha kolay bulabilirdim). Tüm bunları kontrol etmek için CSS kullanmadan ve tabloların HTML'deki şeylerin soldan sağa ve yukarıdan aşağıya sırasını belirtmesi nedeniyle, tablolar düzeninizin HTML'de çok sabit hale geldiği anlamına gelir.

Gerçekçi olarak, div ve CSS tabanlı bir tasarımın düzenini div'leri biraz değiştirmeden tamamen değiştirmek çok zor olduğunu düşünüyorum. Ancak, div ve CSS tabanlı bir düzende, çeşitli bloklar arasındaki boşluk ve bunların göreceli boyutları gibi şeyleri değiştirmek çok daha kolaydır.

Bunun çok tartışılan bir soru olması, W3C'nin denenecek düzen tasarımlarının çeşitliliğini öngörememesinin bir kanıtıdır. Anlamsal dostu düzen için divs + css kullanmak harika bir kavramdır, ancak uygulamanın ayrıntıları o kadar kusurludur ki, yaratıcı özgürlüğü gerçekten sınırlarlar.

Şirketimizin sitelerinden birini masalardan div'lara geçirmeye çalıştım ve öyle bir baş ağrısıydı ki, içine döktüğüm çalışma saatlerini tamamen hurdaya döktüm ve masalara geri döndüm. Dikey hizalamanın kontrolünü elde etmek için div'imle güreşmeye çalışmak, bu tartışma devam ettiği sürece asla sallamayacağım büyük psikolojik meselelerle lanetledi.

İnsanların basit tasarım hedeflerine (dikey hizalama gibi) ulaşmak için sık sık karmaşık ve çirkin geçici çözümler bulmaları gerektiği, kuralların yeterince esnek olmadığını ileri sürmektedir. Özellikler yeterliyse, neden yüksek profilli siteler (SO gibi) tabloları ve diğer geçici çözümleri kullanarak kuralları bükmeyi gerekli buluyor?

Düzen için tablo öğesini kullanmanın tablo verileriyle çok az ilgisi olduğunu tahmin ediyorum. Ne olmuş yani? Patronum umursuyor mu? Kullanıcılarım umurunda mı?

Google ve diğer otomatik sistemler yapmak bakım ve onlar birçok durumda tıpkı önemlisin. Anlamsal kod, akıllı olmayan bir sistemin ayrıştırılması ve işlenmesi için daha kolaydır.

Bazı uygulamaların oluşturduğu 6 adet iç içe geçmiş tablo içeren bir web sitesiyle çalışmak zorunda kaldım ve geçersiz HTML ürettikten sonra, küçük bir değişiklik için kırılmayı düzeltmek aslında 3 saatlik bir işti.

Bu elbette son durumdur, ancak tablo tabanlı tasarım sürdürülemez. Css kullanıyorsanız, HTML'yi onarırken kırma konusunda daha az endişe duyduğunuzdan stili ayırırsınız.

Ayrıca bunu JavaScript ile deneyin. Tek bir tablo hücresini bir yerden başka bir tablodaki başka bir yere taşıyın. Div / span'ın kopyala-yapıştır yöntemiyle çalışacağı yerde çalışmak oldukça karmaşıktır.

"Patronum umurunda mı?"

Ben senin patronun olsaydım. Umurumda olur. ;) Hayatınıza değer veriyorsanız.

Düzen esnekliği
Çok sayıda küçük resim içeren bir sayfa yaptığınızı düşünün.
DIV'ler :
Her küçük resmi sola yüzen bir DIV'ye koyarsanız, belki 10 tanesi bir sıraya sığar. Pencereyi daraltın ve BAM - arka arkaya 6 veya 2 veya çok sayıda uyuyor.
TABLO:
Bir satırda kaç tane hücrenin olduğunu açıkça söylemelisiniz. Pencere çok darsa, kullanıcının yatay olarak kaydırması gerekir.

Sürdürülebilirlik
Yukarıdaki ile aynı durum. Şimdi üçüncü satıra üç küçük resim eklemek istiyorsunuz.
DIV'ler:
Bunları ekleyin. Düzen otomatik olarak ayarlanır.
TABLO: Yeni hücreleri üçüncü satıra yapıştırın. Hata! Şimdi orada çok fazla ürün var. O sıradan biraz kesin ve dördüncü sıraya koyun. Şimdi orada çok fazla ürün var. Bu satırdan bir miktar kesin ... (vb.)
( Tabii ki, sunucu tarafı komut dosyası içeren satırları ve hücreleri oluşturuyorsanız, bu muhtemelen bir sorun olmayacaktır. )

Sanırım o tekne yelken açtı. Sektörün izlediği yöne bakarsanız, CSS ve Açık Standartların bu tartışmayı kazananlar olduğunu fark edeceksiniz. Bu da çoğu html çalışması için anlamına gelir, formlar hariç, tasarımcılar tablolar yerine div kullanır. Bununla bir zor zamanım var çünkü ben bir CSS gurusu değilim ama bu böyle.

Ayrıca, unutmayın, tablolar mobil tarayıcılarda pek iyi görünmüyor. Tabii, iPhone'un başlangıç ​​tarayıcısı var ama herkesin iPhone'u yok. Tablo oluşturma, modern tarayıcılar için yer fıstığı olabilir, ancak mobil tarayıcılar için bir grup karpuz.

Şahsen birçok kişinin çok fazla <div>etiket kullandığını gördüm , ancak ölçülü olarak, son derece temiz ve okunması kolay olabilir. İnsanların CSS okumak için tablolardan daha zor zamanlar olduğunu; belki doğru olan 'kod' açısından; ancak içeriği okumak açısından (view> source) yapıyı stil sayfalarıyla anlamak tablolardan çok daha kolay.

Görünüşe göre sadece masalara alışkınsınız ve hepsi bu. Bir tabloya mizanpaj koymak, o mizanpaj için sizi sınırlar. CSS ile bitleri hareket ettirebilir, http://csszengarden.com/ adresine bir göz atabilirsiniz. Ve hayır, düzen genellikle çok fazla iç içe div gerektirmez.

Düzen ve uygun anlambilim için tablolar olmadan HTML çok daha temiz, bu nedenle okunması daha kolaydır. CSS'yi anlamayan biri neden okumayı denemeli? Birisi kendini webdeveloper olarak görürse, CSS'nin iyi anlaşılması bir zorunluluktur.

SEO avantajları, en önemli içeriğin sayfayı daha yükseğe çıkarması ve daha iyi içerik-biçimlendirme oranına sahip olması yeteneğinden gelir.

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

• 508 Uyumluluk - Bir ekran okuyucunun işaretlemenizi anlamlandırma yeteneği.
• Oluşturma bekleniyor - tablolar </table>öğenin sonuna kadar tarayıcıda görüntülenmez .

Anlamsal işaretleme hakkındaki tüm fikir, işaretleme ve sunumun ayrılmasıdır.

Div'in tabloları değiştirmemesi, içeriği ilgili içerik bloklarına ayırmak için kendi kullanımlarına sahiptir (,). Becerilere sahip olmadığınızda ve tablolara güvendiğinizde, istenen düzeni elde etmek için genellikle içeriğinizi hücrelere ayırmanız gerekir, ancak semantik işaretlemeyi kullanırken sunuma ulaşmak için işaretlemeye dokunmanız gerekmez. Bu, statik sayfalar yerine biçimlendirme oluşturulduğunda gerçekten önemlidir.

Geliştiricilerin, içerik sunma becerisine sahip olanlarımızın işimize devam edebilmesi için düzen anlamına gelen biçimlendirme sağlamayı bırakması gerekir ve geliştiricilerin, sunumun değişmesi gerektiğinde değişiklik yapmak için kodlarına geri dönmeleri gerekmez.

Bu, 'div'ların mizanpaj tablolarından daha iyi olup olmadığıyla ilgili değildir. CSS'yi anlayan biri, 'düzen tablolarını' kullanarak oldukça basit bir şekilde herhangi bir tasarımı çoğaltabilir. Asıl kazanç, orada oldukları şey için HTML öğeleri kullanmaktır. Tabloları tablo dışı veriler için kullanmamanızın nedeni, tamsayıları karakter dizeleri olarak depolamamanızın nedenidir - teknoloji, tasarlandığı amaç için kullandığınızda çok daha kolay çalışır. Düzen için tablolar kullanmak gerekiyorsa (1990'ların başlarındaki tarayıcı eksiklikleri nedeniyle) kesinlikle şimdi değil.

Tablo mizanpajlarını kullanan araçlar, mizanpajı oluşturmak için gereken kod miktarı nedeniyle olağanüstü derecede ağır olabilir. SAP'nin Netweaver Portalı varsayılan olarak sayfalarını düzenlemek için TABLO kullanır.

Şu anki konserimdeki üretim SAP portalında, HTML'si 60K'ın üzerinde olan ve sayfa içinde üç kez yedi tablo derinlikli bir ana sayfa var. Javascript'e, içinde benzer tablo sorunları olan 16 iframe'in yanlış kullanımı, aşırı ağır CSS vb. Ekleyin ve sayfa 5MB'nin üzerinde.

Sayfa ağırlığını azaltmak için zaman ayırmak, böylece bant genişliğinizi kullanıcılarla etkileşimli etkinlikler yapmak için kullanabilmeniz çabaya değer.

CSS ve div öğelerini bulmaya değer, böylece merkezi içerik sütunu bir sayfa düzeninde kenar çubuğundan önce yüklenir ve oluşturulur. Ancak, bir logoyu bazı sponsorluk metniyle dikey olarak hizalamak için kayan div'ları kullanmakta zorlanıyorsanız, tabloyu kullanın ve hayata devam edin. Zen bahçe dini sadece paranın karşılığını vermez.

İçeriği sunumdan ayırma fikri, uygulamayı farklı çalışma türlerinin farklı kod bloklarını etkileyecek şekilde bölümlendirmektir. Bu aslında değişim yönetimi ile ilgilidir. Ancak kodlama standartları sadece mevcut kod durumunu yüzeysel olarak inceleyebilir.

"İçeriği sunumdan ayırmak" için kodlama standartlarına bağlı bir uygulama için değişiklik günlüğü, dikey silolarda paralel değişikliklerin bir modelini gösterecektir. "İçerik" de yapılan bir değişikliğe her zaman "sunu" daki bir değişiklik eşlik ediyorsa, bölümleme ne kadar başarılıdır?

Kodunuzu gerçekten verimli bir şekilde bölümlemek istiyorsanız Subversion'ı kullanın ve değişiklik günlüklerinizi inceleyin. Daha sonra uygulamayı basit ve rahat bir şekilde uyacak şekilde yapılandırmak için en basit kodlama tekniklerini (div, tablo, JavaScript, içerir, işlevler, nesneler, devamlar, her neyse) kullanın.

Çünkü tablo kullanan ve kodlanması çok daha uzun süren bir siteyi korumak HELL. Yüzen div'lardan korkuyorsanız, gidin ve onlardan bir ders alın. Anlamak zor değiller ve yaklaşık 100 kat daha verimli ve milyonda bir milyon daha az acı çekiyorlar (onları anlamadığınız sürece - ama hey, bilgisayarların dünyasına hoş geldiniz).

Düzenlerini bir tablo ile yapmayı düşünen herkes, onu korumamı beklemiyor. Bir web sitesi oluşturmanın en geriye dönük yoludur. Tanrıya şükür şimdi çok daha iyi bir alternatifimiz var. ASLA geri gitmek istiyorum.

Bazı kişilerin modern araçlar kullanarak bir site oluşturmanın zaman ve enerji faydalarından haberdar olamayacakları korkutucu.

Tablolar genel olarak CSS'den daha kolay veya bakımı daha kolay değildir . Bununla birlikte, tabloların gerçekten en basit ve en esnek çözüm olduğu birkaç özel düzen sorunu vardır.

CSS, sunum işaretlemesi ve CSS'nin aynı tür tasarımı desteklediği durumlarda açıkça tercih edilir, sağ akıllarında hiç kimse font-tag'lerin CSS'de tipografiyi belirtmekten daha iyi olduğunu iddia edemez, çünkü CSS size fontetiketlerden aynı gücü verir , ancak çok daha temiz bir yol.

Bununla birlikte, tablolardaki sorun temel olarak CSS'deki tablo düzeni modelinin Microsoft Internet Explorer'da desteklenmemesidir. Bu nedenle tablolar ve CSS güç bakımından eşdeğer değildir . Eksik kısım, hücrelerin içeriklerini içerecek şekilde genişlerken, hücrelerin kenarlarının hem dikey hem de yatay olarak hizalandığı tabloların ızgara benzeri davranışıdır . Bu davranışı, bazı boyutları zor kodlamadan saf CSS'de elde etmek kolay değildir, bu da tasarımı katı ve kırılgan hale getirir (Internet Explorer'ı desteklememiz gerektiği sürece - diğer tarayıcılarda bu kolayca kullanılarak elde edilir display:table-cell).

Bu yüzden gerçekten tabloların mı yoksa CSS'nin mi tercih edileceği sorusu değil, ancak tabloların kullanımının düzeni daha esnek hale getirebileceği belirli durumları tanıma meselesidir.

En önemli sebebi değil tabloları kullanarak erişilebilirlik olduğunu. Web İçeriği Erişilebilirlik Yönergeleri http://www.w3.org/TR/WCAG10/ düzen için tabloları kullanarak tavsiye againt. Erişilebilirlik konusunda endişeleriniz varsa (ve bazı durumlarda yasal olarak zorunlu olabilirsiniz), tablolar daha basit olsa bile CSS kullanmalısınız. CSS ile her zaman tablolardakiyle aynı düzeni oluşturabileceğinizi unutmayın, sadece daha fazla çalışma gerektirebilir.

Bazı konuların zaten ele alınmadığını görünce şaşırdım, bu yüzden daha önce yapılan tüm geçerli noktalara ek olarak 2 sentim:

0,1. CSS ve SEO:

a) CSS, sayfadaki içeriği istediğiniz yere konumlandırarak SEO üzerinde çok önemli bir etkiye sahipti. Birkaç yıl önce, Arama Motorları "sayfa" faktörlerine büyük önem veriyorlardı. Sayfanın üst kısmındaki bir şey, sayfanın alt kısmındaki bir şeyden daha sayfa ile alakalı kabul edildi. Bir örümcek için "sayfanın üstü", "kodun başında" anlamına geliyordu. CSS kullanarak, anahtar kelime açısından zengin içeriğinizi kodun başında düzenleyebilir ve yine de sayfada istediğiniz yerde konumlandırabilirsiniz. Bu hala biraz alakalı, ancak sayfa faktörleri sayfa sıralaması için gittikçe daha az önemli.

b) Düzen CSS'ye taşındığında, HTML sayfası daha açıktır ve bu nedenle bir arama motoru örümceği için daha hızlı yüklenir. (örümcekler harici css dosyalarını indirmeye zahmet etmiyor). Sayfaları hızlı yüklemek, Google dahil olmak üzere birçok arama motoru için önemli bir sıralama konusudur

c) SEO çalışması genellikle bir şeyleri test etmeyi ve değiştirmeyi gerektirir, bu da CSS tabanlı bir düzen ile çok daha uygundur

0,2. Oluşturulan içerik:

Bir tablonun programsal olarak üretilmesi, eşdeğer CSS mizanpajından çok daha kolaydır.

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

Bir tablo oluşturmak basit ve güvenlidir. Bağımsızdır ve herhangi bir şablona iyi entegre olur. CSS ile aynı şeyi yapmak oldukça zordur ve hiç faydası olmayabilir: uçuşta CSS stil sayfasını düzenlemek zordur ve stili satır içi eklemek tablo kullanmaktan farklı değildir (içerik mizanpajdan ayrılmaz).

Ayrıca, bir tablo oluşturulduğunda, içerik (değişkenlerde) zaten düzenden (kodda) ayrılır, bu da değiştirmeyi kolaylaştırır.

Bu, çok iyi tasarlanmış bazı web sitelerinin (örneğin SO) hala tablo düzenlerini kullanmasının bir nedenidir.

Tabii ki, sonuçların JavaScript aracılığıyla gerçekleştirilmesi gerekiyorsa, div'ler sorun olmaya değer.

0,3. Hızlı dönüşüm testi

Belirli bir kitle için neyin işe yaradığını anlarken, en iyi sonuçları elde etmek için düzeni çeşitli şekillerde değiştirebilmek yararlıdır. CSS tabanlı düzen işleri oldukça kolaylaştırır

0,4. Farklı problemler için farklı çözümler

Mizanpaj tabloları genellikle dağıtılır çünkü "herkes div ve CSS'yi bilir" yoludur.

Bununla birlikte, tabloların oluşturulması daha hızlı, anlaşılması daha kolay ve çoğu CSS mizanpajından daha sağlamdır. (Evet, CSS kadar güçlü olabilir, ancak farklı tarayıcılarda ve ekran çözünürlüklerinde internete hızlı bir bakış, durumun genellikle böyle olmadığını gösterir)

Bakım, esneklik eksikliği de dahil olmak üzere masaların bir çok dezavantajı var ... ama bebeği banyo suyuyla atmayalım. Hem hızlı hem de güvenilir bir çözüm için birçok profesyonel kullanım vardır.

Bir süre önce, kullanıcıların önemli bir kısmı CSS için gerçekten kötü bir destekle IE'nin eski bir sürümünü kullanıyor olacağı için tabloları kullanarak temiz ve basit bir CSS mizanpajını yeniden yazmak zorunda kaldım.

Ben, birincisi, diz sarsıntılı tepkiden bıktım ve yoruldum "Oh noes! Düzen için tablolar!"

"Bu amaç için tasarlanmamıştır ve bu nedenle bu şekilde kullanmamalısınız" kalabalık, bu ikiyüzlülük değil mi? Çoğu tarayıcıda lanet şeyi çalıştırmak için kullanmanız gereken tüm CSS hileleri hakkında ne düşünüyorsunuz? Bu amaç için mi kastedildiler?