it-swarm-tr.com

HTML'de mizanpaj için neden tablo kullanmıyorsunuz?

Görünüşe göre genel görüş tabloların HTML'deki düzen için kullanılmaması gerekiyor.

Niye ya?

Bunun için hiçbir zaman (veya nadiren dürüst olmak gerekirse) iyi argümanlar görmedim. Her zamanki cevaplar:

  • İyi --- düzenden içeriği ayır
    Ama bu yanlış bir argümandır; Cliche Thinking . Sanırım düzen için table elemanını kullanmanın tabulardaki verilerle pek ilgisi yok. Ne olmuş yani? Patronum umrunda mı? Kullanıcılarım umrunda mı?

    Belki de ben veya web sayfası bakımı sağlamak zorunda olan diğer geliştiricilerim ... Bir masa daha az bakım yapılabilir mi? Bence bir tablo kullanmak easy divs ve CSS kullanmaktan başka.

    Bu arada ... neden bir div veya bir yayılma alanı içeriğin mizanpajdan ve tablodan iyi bir şekilde ayrılmıyor? Yalnızca divlerle iyi bir düzen elde etmek için genellikle çok fazla iç içe div gerekir.

  • Kodun okunabilirliği
    Bence tam tersi. Çoğu insan HTML'yi, birkaçı CSS'yi anlar.

  • SEO'nun tablo kullanmaması daha iyi
    Niye ya? Birileri bunun olduğuna dair bir kanıt gösterebilir mi? Veya Google’ın tablolarının SEO açısından cesaretinin kırıldığı bir ifade?

  • Masalar daha yavaş.
    Fazladan bir tbody elemanı eklenmelidir. Bu, modern web tarayıcıları için yer fıstığıdır. Bir tablonun kullanılmasının bir sayfayı önemli ölçüde yavaşlattığı bazı kriterleri göster.

  • Bir yerleşim revizyonu tablo olmadan kolaydır, bakınız css Zen Garden .
    Yükseltme gerektiren çoğu web sitesinde de yeni içerik (HTML) gerekir. Bir web sitesinin yeni sürümünün sadece yeni bir CSS dosyasına ihtiyaç duyduğu senaryolar pek olası değildir. Zen Garden güzel bir web sitesi ama biraz teorik. CSS'den yanlış bahsetmiyorum.

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

665
Benno Richters

Ben argümanlarınızı birbiri ardına geçip hataları onlara göstermeye çalışacağım.

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

HTML kasıtlı olarak tasarlandığından hiç yanlış değil. Bir öğenin kötüye kullanımı tamamen söz konusu olmayabilir (sonuçta, diğer dillerde de yeni deyimler gelişti), ancak olası olumsuz sonuçların dengelenmesi gerekiyor. Ek olarak, bugün <table> öğesini kötüye kullanmaya karşı bir argüman olmasa bile, tarayıcı üreticilerinin öğeye özel muamele uygulamaları nedeniyle yarın olabilir. Sonuçta, “<table> öğelerinin yalnızca tablo verileri için olduğunu” biliyorlar ve bu gerçeği işleme altyapısını iyileştirmek için, <table> öğelerinin davranışını ustaca değiştiren ve böylece daha önce kötüye kullanıldığı durumları kıran süreçleri kullanabilirler.

Ne olmuş yani? Patronum umrunda mı? Kullanıcılarım umrunda mı?

Bağlı. Patronun sivri saçlı mı? O zaman umursamıyor olabilir. Yetkin ise, o zaman umursar, çünkü kullanıcılar olacaktır .

Belki de ben veya web sayfası bakımı sağlamak zorunda olan diğer geliştiricilerim ... Bir masa daha az bakım gerektirebilir mi? Bir tablo kullanmak divs ve css kullanmaktan daha kolay olduğunu düşünüyorum.

Profesyonel web geliştiricilerin çoğu size karşı geliyor[ alıntı yapılması gerekli ]. Bu tablolar 'dir aslında daha az bakım gerektirilebilmelidir. Mizanpaj için tablo kullanmak, kurumsal yerleşimi değiştirmenin aslında her sayfayı değiştirmek anlamına gelir. Bu çok pahalı olabilir. Öte yandan, CSS ile birleştirilen anlamsal anlamlı HTML’nin makul kullanımı, bu tür değişiklikleri CSS’de ve kullanılan resimlerde sınırlayabilir.

Bu arada ... neden bir div veya bir yayılma alanı içeriğin düzen ve tablodan iyi bir şekilde ayrılmıyor? Yalnızca divlerle iyi bir düzen elde etmek için genellikle çok fazla iç içe div gerekir.

Derinden iç içe geçmiş <div>s, tablo düzenleri gibi bir kalıp önleyicidir. İyi web tasarımcıları çoğuna ihtiyaç duymazlar. Öte yandan, bu derin iç içe divlerde bile masa düzeni sorunlarının çoğuna sahip değil. Aslında, içeriği bölümlere göre mantıksal olarak bölerek anlamsal bir yapıya bile katkıda bulunabilirler.

Kodun okunabilirliği bence tam tersi. Çoğu insan html'yi, az css'i anlar. Daha basit.

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

SEO'nun tablo kullanmaması daha iyi

Bunun doğru olup olmadığını bilmiyorum ve bunu argüman olarak kullanmazdım ama mantıklı olur. Arama motorları, alakalı veriler için arama yapar. Tablo verileri 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 belirgin konumlarını arar. Bu nedenle, tablo içeriğini filtrelemenin dışında bırakmak ve böylece işlem süresini (ve maliyetleri!) Büyük bir faktörle azaltmak mantıklı olacaktır.

Masalar daha yavaş. Fazladan bir tbody elemanı eklenmelidir. Bu, modern web tarayıcıları için yer fıstığıdır.

Ekstra elemanın masaların daha yavaş olmasıyla ilgisi yok. Ö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 zorunda kalır. Ek olarak, düzenin önbelleğe alınması çalışmaz (CSS kolayca önbelleğe alınabilir). Bütün bunlar daha önce de belirtilmişti.

Bir tablonun kullanılmasının bir sayfayı önemli ölçüde yavaşlattığı bazı kriterleri göster.

Ne yazık ki kıyaslama verilerim yok. Kendim de ilgimi çeker çünkü bu argümanın belli bir bilimsel titizlikten yoksun olması doğru.

Yükseltme gerektiren çoğu web sitesi de yeni içeriğe (html) ihtiyaç duyar. Bir web sitesinin yeni sürümünün sadece 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 çoğu zaman hala gerekli olmakla birlikte, değişiklikler her zaman çok daha sınırlı olacaktır. Ek olarak, tasarım değişiklikleri zaman zaman dinamik olarak yapılmalıdır. WordPress bloglama sistemi tarafından kullanılanlar gibi şablon motorları düşünün. Masa düzenleri tam anlamıyla bu sistemi öldürür. Ticari bir yazılım için benzer bir dava üzerinde çalıştım. Tasarımı HTML kodunu değiştirmeden 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) daha da zorlaştırır. Bu önemsiz görünebilir, çünkü sonuçta, kim yapar? Kendime şaşırdım. Söz konusu hizmet, verilerine erişmek için bir Web Hizmeti alternatifi sunmuyorsa, ekran kazıma işlemi size çok yardımcı olabilir. Bunun üzücü bir gerçek olduğu biyoinformatikte çalışıyorum. Modern web teknikleri ve Web Servisleri çoğu geliştiriciye ulaşmamıştır ve çoğu zaman, ekran alma işlemi veri alma işlemini otomatikleştirmenin tek yoludur. Pek çok biyolog hala bu tür işleri manuel olarak gerçekleştiriyor. Binlerce veri seti için.

497
Konrad Rudolph

İşte benim programcımın cevabı a simliar thread

Anlambilim 101

İlk ö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 ki bisikletin araba olmaması. Otomobil sınıfı, bisiklet örneği için uygun olmayan bir sınıftır. Kod hatasız, ancak anlamsal yanlış. Programcıya zayıf yansıyor.

Anlamsal 102

Şimdi bunu belge işaretlemesine uygulayın. Belgenizin sekmeli veri sunması gerekiyorsa, uygun etiket <table> olacaktır. Bununla birlikte, navigasyonu bir tabloya yerleştirirseniz, <table> öğesinin amaçlanan amacını kötüye kullanırsınız. İkinci durumda, sekmeli veri sunmuyorsunuz - sunum amaçlı bir hedefe ulaşmak için <table> öğesini kullanıyorsunuz (yanlış).

Sonuç

Ziyaretçiler fark edecek mi? Hayır. Patronun önemsiyor mu? Olabilir. Bazen programcı olarak köşeleri kesiyor muyuz? Emin. Ama yapmalı mıyız? Hayır. Anlamsal biçimlendirme kullanıyorsanız kim yararlanabilir? Siz - ve mesleki itibarınız. Şimdi git ve doğru olanı yap.

290
Carl Camera

Açık cevap: Bkz CSS Zen Bahçesi . Aynı şeyi tablo tabanlı bir düzende kolayca yapabileceğinizi söylerseniz (unutmayın - HTML değişmiyor) o zaman elbette düzen için tabloları kullanın.

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

Her ikisi de hangi sırada bilgilerin sunulduğunu önemser. Tablo tabanlı düzeniniz, sayfadaki 2. yuvalanmış tablonun 2. satırının 3. hücresine koyarsa gezinmenizi sayfanın en üstünde kolayca sunamazsınız.

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

Tembel olmayın. Öğrenmesi biraz zor olsa bile işleri doğru ve uygun şekilde yapın.

104
erlando

Bu yinelenen soruya bakın.

Unuttuğunuz bir öğe erişilebilirlik. Örneğin, tablo tabanlı mizanpajlar, örneğin bir ekran okuyucu kullanmanız gerekirse de çevrilmez. Ve devlet için çalışıyorsanız, ekran okuyucular gibi erişilebilir tarayıcıları desteklemeniz gerekebilir .

Ayrıca, soruda bahsettiğiniz bazı şeylerin etkisini hafife aldığınızı da 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 girdiğinizde avantajlar daha net olmaya başlar.

Ne yaptığınızı ve iyi araçlara sahip olduğunuzu biliyorsanız, CSS'nin düzen için tablolara göre gerçekten önemli avantajları vardır. Ve her bir öğe kendi başına terk masalarını haklı çıkarmasa da, birlikte alındığında genellikle buna değer.

91
Joel Coehoorn

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

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

Sadece katı DIV ve CSS dinini savunanların bile kendi kurallarına uyamayacağını gösterecek. Bunu, onları ne kadar yakından takip ettiğiniz konusunda bir rehber olarak kullanabilirsiniz.

54
James Curran

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

48
expedient

Düzen için bir tablo o kadar da kötü olmazdı. Fakat çoğu zaman sadece bir masa ile ihtiyacınız olan düzeni elde edemezsiniz. Çok yakında 2 ya da üç iç içe masanız var. Bu çok hantal olur.

  • Bu IS LOT okumak daha zor. Bu görüşe bağlı değil. Onları tanımlayıcı işaretleri olmayan daha fazla yuvalanmış etiket var.

  • İçeriği sunumdan ayırmak iyi bir şey çünkü yaptığınız işe odaklanmanıza izin veriyor. İkisini karıştırmak, okunması zor olan şişirilmiş sayfalara yol açar.

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

  • Tablolar sizi bir tasarıma kilitler. Elbette, herkesin CSS Zen Bahçesi'nin esnekliğine ihtiyacı yoktur, ancak tasarımı burada biraz değiştirmek zorunda kalmadığım bir yerde hiç çalışmadım. CSS ile çok daha kolay.

  • Tablolar stil vermek zordur. Onlarla fazla esnekliğe sahip değilsiniz (yani, bir tablonun stillerini tam olarak kontrol etmek için HTML özellikleri eklemeniz gerekir)

4 yıldan beri tablo dışı veriler için tablo kullanmamıştım. Geriye bakmadım.

Andy Budd tarafından CSS Ustalığı okumalarını önermek isterim. 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

45
Ben Scheirman

İçeriği düzenden ayırmak iyidir
Ama bu yanlış bir argümandır; Klişe düşünme

Yanlış bir argüman çünkü HTML tabloları düzen! İçeriği tabloda veri, sunum tablonun kendisi. Bu nedenle, CSS'yi HTML'den ayırmak bazen çok zor olabilir. İçeriği sunumdan ayırmıyorsunuz, sunumunuzu sunumdan ayırıyorsunuz! İç içe divs yığını bir masadan farklı değildir - bu sadece farklı bir etiket kümesidir.

HTML’yi CSS’den ayırmanın bir diğer sorunu da birbirleriyle ilgili samimi bir bilgiye ihtiyaç duymalarıdır - onları gerçekten tamamen ayıramazsınız. HTML'deki etiket düzeni, ne yaparsanız yapın, CSS dosyasına sıkıca bağlıdır.

Bence divs vs tablolar uygulamanızın ihtiyacına bağlı.

İşyerinde geliştirdiğimiz uygulamada, parçaların kendilerini içeriklerine göre dinamik bir şekilde boyutlandıracağı bir sayfa düzenine ihtiyacımız vardı. Bunu, CSS ve DIV'ler ile çapraz tarayıcı çalışması için çalışarak geçirdim ve tam bir kabus gibiydi. Tablolara geçtik ve hepsi sadece çalıştı.

Ancak, ürünümüz için çok kapalı bir kitleye sahibiz (web arayüzü olan bir donanım parçası satıyoruz) ve erişilebilirlik sorunları bizim için endişe verici değil. Ekran okuyucularının neden tablolarla iyi başa çıkamadıklarını bilmiyorum, ancak geliştiricilerin bunu yapması gereken yol buysa, sanırım.

36
17 of 26

CSS/DIV - sadece tasarım çocuklar için işler değil mi? DIV/CSS ile ilgili hata ayıklamak için harcadığım yüzlerce saat, belirsiz bir tarayıcıyla çalışmanın bir parçasını bulmak için interneti arayarak beni deli ediyor. Küçük bir değişiklik yaparsınız ve tüm düzen korkunç derecede yanlış gider - yemeğin mantığı buradadır. Bu şekilde 3 piksel bir şey hareket ettirmek için saat harcamak, sonra diğerlerini bir araya getirmek için 2 piksel diğer bir şey. Bu sadece bir şekilde bana yanlış görünüyor. Sırf sen safsın ve "yapılacak doğru şey değil" diye bir şey yapman, onu, özellikle hayatını 1000 kat daha kolaylaştıracak olursa, her dereceye kadar kullanmalısın anlamına gelmez.

Bu yüzden nihayet karar verdim, tamamen ticari gerekçelerle karar verdim, her ne kadar en az kullanmaya devam etsem de, bir DIV'nin doğru bir şekilde yerleştirilmesi için 20 saat çalışmayı umursam, bir masaya takılıyorum. Yanlış, safcıları kızdırıyor, ancak çoğu durumda daha az zaman alıyor ve yönetimi daha ucuz. Ardından, uygulamanın, alıcıları memnun etmek yerine, müşterinin istediği gibi çalışmasını sağlamaya konsantre olabilirim. Her şeyden önce faturaları öderler ve benim CSS/DIV kullanımını zorlayan bir yöneticiye olan argümanım - sadece müşterilerin maaşını da ödediğine işaret ederim!

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

Bir pencere formu tasarladığınızda, kontrolleri onları bıraktıktan sonra hareket ettirmeyi denemezsiniz, bu yüzden bunu neden bir web formu ile yapmak istediğinizi merak ettim. Ben sadece bu mantığı anlayamıyorum. Düzeni doğru başlatmak ve sorunun ne olduğunu. Bunun nedeni, tasarımcıların yaratıcılıkla flört etmekten hoşlanırken uygulama geliştiricileri daha çok uygulamanın çalışmasını sağlamak, iş nesneleri oluşturmak, iş kurallarını uygulamak, müşteri verilerinin birbirleriyle nasıl ilişkili olduğunu çalışmak, müşteriyle bir araya gelmelerini sağlamak. gereksinimler - bilirsin - gerçek dünyadakiler gibi.

Beni yanlış anlamayın, her iki argüman da geçerlidir, ancak geliştiricileri form tasarlamaya daha kolay ve daha mantıklı bir yaklaşım seçtiği için eleştirmeyin. Endişelenmemiz gereken şeyleri sık sık bir div masasında kullanmanın doğru anlambiliminden daha önemlidir.

Noktadan örnek - bu tartışmaya dayanarak mevcut birkaç tds ve tr'i divs'e dönüştürdüm. 45 dakikayı karıştırıp yanyana gelecek her şeyi bulmaya çalışıyorum ve ben de pes ettim. TD'ler 10 saniye sonra geri döner - çalışır - hemen - tüm tarayıcılarda, yapacak başka bir şey yok. Lütfen anlamamı sağlamaya çalış - başka bir şekilde yapmamı istemek için ne gibi bir haklılığın var?

23
Tim Black

Düzen kolay olmalı. CSS'de üstbilgi ve altbilgiyle dinamik bir üç sütun düzenine nasıl ulaşılacağı üzerine yazılmış makaleler olması, bunun kötü bir düzen sistemi olduğunu göstermektedir. Tabii ki çalışmasını sağlayabilirsiniz, ancak kelimenin tam anlamıyla nasıl yapılacağı hakkında çevrimiçi yüzlerce makale var. Açıkça belli olduğu için tablolarla benzer bir düzen için böyle bir makale yok. Tablolara karşı ve CSS'nin lehine ne derseniz deyin, bu gerçek hepsini geri alır: CSS'deki temel üç sütun düzenine genellikle "Kutsal Kase" denir.

Bu size "WTF" demenizi sağlamazsa, o zaman şimdi kool yardımcısını bırakmanız gerekir.

CSS'yi seviyorum. Şaşırtıcı şekillendirme seçenekleri ve bazı harika konumlandırma araçları sunar, ancak düzen motoru olarak eksiktir. Bir tür dinamik ızgara konumlandırma sistemi olması gerekir. İlk önce boyutlarını bilmeden kutuları birden çok eksende hizalamanın basit bir yolu. <table> veya <gridlayout> ya da her neyse, bunu umursamıyorum, ama bu CSS'den eksik olan temel bir düzen özelliğidir.

Daha büyük sorun, eksik özelliklerin olmadığını kabul etmeyerek, CSS zealotlarının CSS'yi olabilecek her şeyden geri tutmalarıdır. Eğer CSS, dünyadaki diğer tüm yerleşim motorları gibi düzgün çok eksenli ızgara konumlandırması sağlıyorsa, masaları kullanmayı bırakmaktan mutluluk duyarım. (Bu sorunun W3C hariç herkes tarafından birçok dilde çözüldüğünü biliyorsunuz, değil mi? Ve başka hiç kimse böyle bir özelliğin faydalı olduğunu inkar etmedi.)

İç çekmek. Yeterince havalandırma. Devam et ve kafanı tekrar kuma sok.

21
needlestack

508 uyumluluğuna göre (görsel olarak etkilenen ekran okuyucular için), ekranların okutulmasına neden olacağı için tablolar sadece veri tutmak için kullanılmalı ve düzen için kullanılmamalıdır. Ya da bana söylendi.

Div'lerin her birine adlar atadıysanız, CSS kullanarak da hepsini kaplayabilirsiniz. Onlar sadece sizin ihtiyaç duyduğunuz şekilde oturmak için biraz daha fazla acı çekiyorlar.

19
Rob

İşte yeni bir projenin html 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 bu tablo tabanlı bir düzenle aynı kodu.

<?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 temelli düzende gördüğüm tek temizlik girintiliğimi çok abartmış olduğum gerçeğidir. İçerik bölümünün iki ek gömülü tabloya sahip olduğundan eminim.

Düşünülmesi gereken başka bir şey: filesizes. Tablo tabanlı mizanpajların genellikle CSS emsallerinin iki katı boyutunda olduğunu gördüm. Yüksek hızlı genişbantımızda büyük bir sorun değil ama çevirmeli modemleri var.

18
Ross

Div tabanlı mizanpajların bakım, geliştirme ve yeniden düzenleme işlemlerinin daha kolay olduğunu eklemek isterim. Sadece CSS’deki bazı öğeleri yeniden düzenlemek için değişiklikler yapıldı ve yapıldı. Deneyimlerime göre, tabloları kullanan bir düzeni yeniden tasarlamak bir kabustur (daha fazla iç içe geçmiş tablolar varsa).

Kodunuzun ayrıca anlamsal bakış açısından bir anlamı vardır.

14
Guido

CSS mizanpajları, içeriğin doğal bir düzende olması ve bir stil sayfası olmadan anlamlı olması koşuluyla erişilebilirlik için genellikle çok daha iyidir. Ayrıca, tablo tabanlı mizanpajlarla uğraşan sadece ekran okuyucular değil: mobil tarayıcıların bir sayfayı düzgün şekilde oluşturmasını çok zorlaştırıyorlar.

Ayrıca, div tabanlı bir mizanpajla, başlıkları, altbilgileri ve yazdırılan sayfalarda gezinmeyi dışlama gibi bir baskı stil sayfasıyla çok kolay bir şekilde kolayca yapabilirsiniz - bununla birlikte yapmanın imkansız ya da en azından daha zor olacağını düşünüyorum. tablo tabanlı düzen.

İçeriğin mizanpajdan ayrılmasının divs ile tablolara göre daha kolay olduğundan şüpheleniyorsanız, div tabanlı HTML'ye CSS Zen Garden adresinden bir bakın, stil sayfalarını değiştirmenin mizanpajı önemli ölçüde nasıl değiştirebileceğini görün ve HTML tablo tabanlıysa aynı tür düzenleri elde edip edemeyeceğinizi düşünün ... Tablo tabanlı bir düzen yapıyorsanız, tüm boşlukları ve dolguyu kontrol etmek için CSS kullanmanız olası değildir. Hücreler (olsaydınız, ilk etapta kayan div vb. kullanımı neredeyse kesinlikle daha kolay olurdu). Bunları kontrol etmek için CSS kullanmadan ve tabloların HTML'deki şeylerin soldan sağa ve yukarıdan aşağıya sıralanmasından dolayı, tablolar düzeninizin HTML'de çok daha sabit hale geldiği anlamına gelir.

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

13
MB.

Bunun çok tartışılan bir soru olduğu gerçeği, W3C'nin denenecek düzen tasarımlarının çeşitliliğini tahmin etmedeki başarısızlığının bir kanıtıdır. Anlamsal dostu düzen için divs + css kullanmak harika bir konsepttir, ancak uygulamanın ayrıntıları o kadar kusurludur ki, aslında yaratıcı özgürlüğü sınırlar.

Şirketimizin sitelerinden birini masalardan divs'e çevirmeye çalıştım ve içine döktüğüm çalışma saatlerini tamamen hurdaya çıkarıp masalara geri döndüğümde başım ağrıyordu. Dikey uyumun kontrolünü ele geçirmek için divs ile güreşmeye çalışmak, bu tartışmalar devam ettiği sürece asla sallayamayacağım önemli psikolojik konularla beni lanetledi.

İnsanların, basit tasarım hedeflerini (dikey hizalama gibi) gerçekleştirmek için sık sık karmaşık ve çirkin geçici çözümler bulmaları gerektiği, kuralların neredeyse yeterince esnek olmadıklarını göstermektedir. Teknik özellikler yeterliyse, neden yüksek profilli siteler (SO gibi) tabloları ve diğer geçici çözümleri kullanarak kuralları bükmeyi gerekli buluyorlar?

13
DLH

DIV'lerde tartışma yok benden yana.

Derdim ki: Ayakkabı uyuyorsa, onu giy.

İki veya üç sütunda içerik oluşturma için iyi bir DIV + CSS yöntemi bulmak imkansız değilse de, tüm tarayıcılarda tutarlı olan ve yine de istediğim gibi görünen, zor olduğunu belirtmekte fayda var.

Bu, paftalarımın çoğunda masalara doğru dengeyi biraz öneriyor ve bunları kullanmaktan suçlu hissetmeme rağmen (smaçlılar, insanlar sadece kötü olduğunu söylüyor, yani onları dinlemeye çalışıyorum), sonuçta, pragmatik görünüm sadece TABLO kullanmak benim için daha kolay ve daha hızlı. Saat başına ödeme alamıyorum, bu yüzden masalar benim için daha ucuz.

13
Radu094

Sanırım düzen için table elemanını kullanmanın tabulardaki verilerle pek ilgisi yok. Ne olmuş yani? Patronum umrunda mı? Kullanıcılarım umrunda mı?

Google ve diğer otomatik sistemler do bakım ve birçok durumda onlar kadar önemlidir. Akıllı olmayan bir sistemin ayrıştırması ve işlenmesi için semantik kod daha kolaydır.

12
ceejayoz

Bazı uygulamaların oluşturduğu 6 kat iç içe geçmiş tabloyu içeren bir web sitesi ile çalışmak ve geçersiz HTML oluşturmak zorunda kalmak, aslında ufak bir değişikliği kırmak için düzeltmek 3 saatlik bir işti.

Bu elbette Edge davasıdır, fakat masa bazlı tasarım anlaşılmazdır. Css kullanıyorsanız, stili ayırırsınız; böylece HTML'yi düzeltirken kırma konusunda endişelenmenize gerek kalmaz.

Ayrıca, bunu JavaScript ile deneyin. Tek bir tablo hücresini başka bir tablodaki bir yerden başka bir yere taşıyın. Div/span'in sadece copy-paste-wise işlevini yerine getireceği yerde çalışması oldukça karmaşıktı.

"Patronum umurunda mı"

Patronun olsaydım. Umursarsın. ;) Hayatına değer veriyorsan.

8
Kent Fredric

Düzen esnekliği
Çok sayıda küçük resim içeren bir sayfa yaptığınızı düşünün.
DIV'leri:
Her küçük resmi bir DIV'ye yerleştirirseniz, sola kayar, belki 10 tanesi üst üste sığar. Camı daha dar hale getirin ve BAM - arka arkaya 6 ya da 2 ya da birçoğu uygunsa.
[. .____] TABLO:
Açıkça arka arkaya kaç hücre olduğunu söylemek zorundasınız. Pencere çok darsa, kullanıcının yatay kaydırması gerekir.

İdame
Yukarıdakiyle aynı durum. Şimdi üçüncü satıra üç küçük resim eklemek istiyorsunuz.
DIV'leri:
Bunları ekleyin. Düzen otomatik olarak ayarlanır.
TABLE: Yeni hücreleri üçüncü satıra yapıştırın. Oops! Şimdi orada çok fazla öğe var. O sıradan bir kısmını kesin ve dördüncü sıraya koyun. Şimdi orada çok fazla öğe var. O satırdan biraz kes ... (vb.)
(Tabii ki, sunucu tarafı komut dosyasıyla satırları ve hücreleri oluşturuyorsanız, bu muhtemelen bir sorun olmayacaktır.)

7
Nathan Long

Bence o tekne yelken açtı. Sektörün aldığı yöne bakarsanız, CSS ve Açık Standartların bu tartışmanın galibi olduğunu fark edeceksiniz. Sırasıyla, çoğu html çalışması için anlamına gelir, formlar dışında, tasarımcılar tablo yerine divs kullanırlar. Bununla zor zaman geçiriyorum çünkü ben bir CSS gurusu değilim ama bu böyle.

7
Thomas Wagner

Ayrıca, unutmayın, tablolar mobil tarayıcılarda iyi iş çıkarmaz. Tabii, iPhone bir kick-ass tarayıcı var ama herkes bir iPhone yok. Tablo oluşturma, modern tarayıcılar için yer fıstığı olabilir, ancak mobil tarayıcılar için bir miktar karpuz.

Şahsen birçok insanın çok fazla <div> etiketi kullandığını öğrendim, fakat ölçülü olarak okuması çok kolay ve kolay olabilir. İnsanların CSS okumakta tablolardan daha zor zamanlar geçirdiğini söylüyorsunuz; 'kod' açısından belki doğru; Ancak içerik okuma (view> source) açısından yapıyı stil sayfalarıyla anlamak tablolardan ziyade daha kolaydır.

5
Swati

Tablolara alışkın gibisin ve hepsi bu. Mizanpajı bir tabloya koymak sadece bu mizanpaj için sizi sınırlandırır. CSS ile bitleri hareket ettirebilir, bir göz atabilirsiniz http://csszengarden.com/ Ve hayır, düzen genellikle iç içe geçmiş çok fazla divs gerektirmez.

Mizanpaj ve uygun anlambilim için hiçbir tablo ile HTML çok daha temiz, bu nedenle okumak daha kolaydır. CSS'yi anlamayan biri neden okumayı denesin ki? Ve eğer biri kendini web geliştirici olarak görürse, CSS'nin iyi anlaşılması şarttır.

SEO avantajları, sayfanın üstündeki en önemli içeriğe sahip olma ve işaretleme oranının daha iyi olması özelliğinden kaynaklanıyor.

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

5
Rimantas

Anlamsal işaretlemenin etrafındaki tüm fikir, düzen içeren işaretleme ve sunumun ayrılmasıdır.

Div tabloları değiştirmiyor, içeriği ilgili içerik bloklarına ayırmada kendi kullanımları var (,). Becerilere sahip değilseniz ve masalara güveniyorsanız, istediğiniz düzeni elde etmek için içeriğinizi hücrelere ayırmanız gerekir, ancak semantik işaretleme kullanırken sunum yapmak için işaretlemeye dokunmanız gerekmez. İşaretleme statik sayfalardan ziyade üretilirken bu gerçekten önemlidir.

Geliştiricilerin mizanpajı belirleyen işaretlemeyi sağlamayı bırakmaları gerekir, böylece içeriğini sunma becerisine sahip olanların işlerimizle başa çıkabildiklerinden ve geliştiricilerin sunum ihtiyaçları değiştiğinde değişiklik yapmak için kodlarına geri dönmeleri gerekmez.

5
Steve Perks
  • 508 Uyumluluk - Bir ekran okuyucunun işaretlemenizi anlama yeteneği.
  • Render bekliyorum - tablolar tarayıcıda </table> öğesinin sonuna gelene kadar render etmez.
5
Rick Glos

Bu aslında 'divs'in yerleşim için tablolardan daha iyi olup olmadığı' ile ilgili değil. 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 öğelerini kullanmaktır. Tabloları tablo dışı veriler için kullanmamanın nedeni, tamsayıları karakter dizeleri olarak kaydetmemenizin aynı nedenidir - teknoloji, tasarlandığı amaç için kullandığınızda çok daha kolay çalışır. Düzen için tablo kullanmak hiç gerekli olsaydı (1990'ların başındaki tarayıcı eksiklikleri nedeniyle) kesinlikle şimdi değil.

4
domgblackwell

Merkezi içerik sütunu sayfa düzeninde kenar çubuğundan önce yüklenip işlenebilmesi için CSS ve divs'i bulmakta fayda var. Ancak bir logoyu bazı sponsorluk metinleriyle dikey olarak hizalamak için kayan div'ler kullanmakta zorlanıyorsanız, tabloyu kullanın ve yaşama devam edin. Zen bahçesi dinleri paraya pek zarar vermez.

İçeriği sunumdan ayırma fikri, uygulamayı bölümlere ayırmaktır; bu nedenle farklı iş türleri farklı kod bloklarını etkiler. Bu aslında değişim yönetimi ile ilgili. Ancak kodlama standartları, sadece mevcut kod durumunu yüzeysel bir şekilde inceleyebilir.

Kodlama standartlarına bağlı olarak "içeriği sunumdan ayırmak" şartına bağlı olan bir uygulama için değişiklik günlüğü, dikey silolar arasında paralel değişikliklerin bir modelini gösterecektir. "İçerik" e her zaman "sunum" olarak bir değişiklik eşlik ederse, bölümlendirme ne kadar başarılı olur?

Kodunuzu gerçekten verimli bir şekilde bölümlere ayırmak istiyorsanız, Subversion'u kullanın ve değişiklik kayıtlarınızı inceleyin. Sonra en basit kodlama tekniklerini kullanın - divs, tablo, JavaScript, içerir, fonksiyonlar, nesneler, süreklilikler, ne olursa olsun - değişiklikleri basit ve rahat bir şekilde uyacak şekilde uygulamayı yapılandırmak için.

3
Patrick May

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

Sunum işaretlemesi ve CSS'nin aynı tasarımı desteklediği durumlarda CSS açıkça tercih edilir, aklı başında hiç kimse font- etiketlerinin CSS'de tipografiyi belirtmekten daha iyi olduğunu iddia etmez, çünkü CSS size font- etiketleriyle aynı gücü verir, ama çok daha temiz bir şekilde.

Bununla birlikte, tablolardaki sorun temel olarak CSS'deki tablo düzeni modelinin Microsoft Internet Explorer'da desteklenmediğidir. Bu nedenle tablolar ve CSS [değil iktidarda eşdeğerdir]. Kayıp kısım, hücrelerin kenarlarını hem dikey hem de yatay olarak hizalayan tabloların ızgara benzeri davranışı , hücreler hala içeriğini içerecek şekilde genişler. Bu davranışı saf CSS'de bazı boyutları kodlamadan elde etmek kolay değildir, bu da tasarımı sert ve kırılgan hale getirir (Internet Explorer'ı desteklememiz gerektiği sürece - diğer tarayıcılarda bu display:table-cell kullanılarak kolayca elde edilebilir).

Bu yüzden, tabloların veya CSS'nin tercih edilip edilemeyeceği sorusu değil, ancak tablo kullanımının düzeni daha esnek hale getirebileceği belirli durumları tanıma meselesidir.

değil tabloları kullanmanın en önemli nedeni erişilebilirlik. Web İçeriği Erişilebilirlik Yönergeleri http://www.w3.org/TR/WCAG10/ Mizanpaj için tabloları kullanma konusunda tekrar tavsiye. Erişilebilirlik konusunda endişeleriniz varsa (ve bazı durumlarda yasal olarak zorunlu olabilirsiniz), tablolar daha basit olsa bile CSS kullanmalısınız. Yapabileceğinize göre her zaman tablolarla aynı CSS ile aynı mizanpajı oluşturabilirsiniz, sadece daha fazla çalışma gerektirebilir.

3
JacquesB

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 işimdeki üretim SAP portalı, HTML'si 60.000'in üzerinde ağırlığa sahip ve bir sayfada üç kez yedi masanın derinliğinde olan bir ana sayfaya sahip. Javascript’e, içindeki benzer tablo sorunlarına sahip 16 iframe’in kötüye kullanılması, aşırı ağır CSS vb. Ve sayfa 5 MB’nin üzerindedir.

Sayfa ağırlığını düşürmek için zaman ayırmak, böylece bant genişliğinizi kullanıcılarla ilgi çekici aktiviteler yapmak için kullanabilirsiniz.

3
Mike Cornell

DOM Manipülasyonu tablo tabanlı bir düzende zordur.

Anlamsal divs ile:

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

Tablolarla:

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

Şimdi, verildiğinde, ikinci örnek bir tür aptaldır ve her zaman bir tabloya veya td öğesine kimlikler veya sınıflar uygulayabilirsiniz, ancak bu, tablonun bu kadar şiddetle karşı çıktığı anlamsal bir değer katar.

3
Chris Fletcher

Bazı konuların henüz kapsanmadığını görünce şaşırdım, bu yüzden daha önce yapılmış 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 veriyordu. Sayfanın üstündeki bir şey, sayfanın en altındaki bir şeyden daha alakalı görünüyordu. "Sayfanın başı" bir örümcek için "kodun başında" anlamına geliyordu. CSS’yi kullanarak, anahtar kelime bakımından zengin içeriğinizi kodun başında düzenleyebilir ve yine de sayfayı istediğiniz yere yerleştirebilirsiniz. Bu hala biraz alakalı, ancak sayfa faktörleri sayfa sıralaması için daha az ve daha az önemli.

b) Mizanpaj CSS'e taşındığında, HTML sayfası daha hafiftir ve bu nedenle bir arama motoru örümceği için daha hızlı yüklenir. (örümcekler harici css dosyalarını indirmekten rahatsız olmaz). Hızlı yükleme sayfaları, Google dahil olmak üzere çeşitli arama motorları için önemli bir sıralama değerlendirmesidir.

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

0,2. Oluşturulan içerik:

Bir tabloyu programsal olarak oluşturmak 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 masa oluşturmak basit ve güvenlidir. Kendi kendine yeten ve herhangi bir şablon içinde iyi bütünleşir. CSS ile aynısını yapmak oldukça zordur ve hiç bir faydası olmayabilir: uçuş sırasında CSS stil sayfasını düzenlemek zordur ve stil satır içi çizgisini eklemek bir tablo kullanmaktan farklı değildir (içerik düzenden ayrılmaz).

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

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

Elbette, sonuçların JavaScript üzerinden uygulanması gerekiyorsa, divs bu konuda sorun yaratmaya değer.

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

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

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

Mizanpaj tabloları genellikle kullanılmaz çünkü “herkes divs & CSS'yi bilir”.

Bununla birlikte, tabloların oluşturulması daha hızlı, anlaşılması daha kolay ve çoğu CSS mizanpajından daha sağlam olduğu gerçeği devam etmektedir. (Evet, CSS kadar güçlü olabilir, ancak farklı tarayıcılarda ve ekran çözünürlüklerinde internette hızlı bir şekilde görünmesi durumun çok sık olmadığını gösteriyor)

Bakım, esneklik eksikliği de dahil olmak üzere masaların pek ç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, tabloları kullanarak temiz ve basit bir CSS mizanpajını yeniden yazmak zorunda kaldım, çünkü kullanıcıların önemli bir kısmı CSS için gerçekten kötü bir desteğe sahip IE eski bir sürümünü kullanıyor olacaktı.

Ben, birincisi, diz gerginliği reaksiyonundan bıktım ve yoruldum "Ah noes! Düzen için tablolar!"

"Bu amaç için tasarlanmadı ve bu yüzden bu şekilde kullanmamalısın" derken kalabalık, bu ikiyüzlülük değil mi? Çoğu tarayıcıda çalışacak lanet olası şeyi elde etmek için kullanmanız gereken tüm CSS hileleri hakkında ne düşünüyorsunuz? Bu amaç için mi kastediyorlardı?

3
Sylverdrag

Çünkü tablo kullanan bir siteyi korumak HELL, ve kodlaması LOT daha uzun sürüyor. Eğer yüzen divlerden korkuyorsan, git onlarla bir kursa git. Onlar anlamak zor değil ve yaklaşık 100 kat daha verimli ve kıçta bir milyon kat daha az acı çekiyorlar (onları anlamadığınız sürece - ama hey, bilgisayar dünyasına hoş geldiniz).

Düzenini bir tabloyla yapmayı düşünen hiç kimse, benim korumamı beklemiyor. Bir web sitesi oluşturmak için en geriye dönüş yolu. Tanrıya şükür artık daha iyi bir alternatifimiz var. ASLA geri dönmeyecektim.

Bazı insanların modern araçları kullanarak bir site oluşturmanın zaman ve enerjinin farkında olamayacağına korkutucu gelmek korkutucu.

3
Chuck Le Butt
  1. 10/20'lik bir şeyi derin bir kol/kürekle birleştirmeye/bölmeye çalışın. Bir kereden fazla biriyle kavga etmeye içgüdümü bastırmak zorunda kaldım. [?!]
  2. Kaynak kod sırasını görünür sırayı değiştirmeden değiştirmeye çalışın. [SEO, kullanılabilirlik, ...]
  3. Baktığımız çok (gerçekten basit) sayfa ~ 150K. Bahse girerim Uygun CSS kullanılarak neredeyse yarıya indirilebilir. [SEO (Evet, SEO, en son Google özelliklerini oku vs.), perfo, ...]
  4. Her genişlikte çalışabilen bir yineleyici şablonu oluşturmaya çalışın.
  5. Konunun bu tablo temelli SO ortamında tartışılması tekilliğe neden olabilir ve hepimizi yok edebilir
2
Halil Özgür

Sunum ve içeriğin kesinlikle ayrılması sorunu, başlık dosyalarının C++ 'daki uygulama dosyalarından ayrılmasının kabaca benzer olduğunu gösteriyor. Mantıklı, ama aynı zamanda bir acı olabilir. Sınıfların tek bir kaynak dosyada tanımlandığı Java ve C # 'ya tanık olun. Yeni dillerin yazarları, programcıların baş ağrısına neden olan bir şey fark ettiler ve ondan kurtuldular. Bu, bu tartışmanın özü gibi görünüyor. Bir taraf CSS'nin çok zor olduğunu söylüyor, diğer taraf birinin CSS ustası olması gerektiğini söylüyor.

Basit yerleşim sorunları için neden sunumun tamamen ayrı olması gerektiğini söyleyen kuralı bükmeyin? Sunumu doğrudan HTML olarak kontrol etmemize izin veren yeni bir etiket (veya div etiketinin bir uzantısı)? Sonuçta, zaten sunumu HTML'ye sızdırmıyor muyuz? Şuna bak h1, h2 ... h6. Bu kontrol sunumunu hepimiz biliyoruz.

Kod okuma yeteneği (ve HTML koddur) çok önemlidir. Gurus bir programlama ortamını kitlelere mümkün olduğunca erişilebilir hale getirmenin ne kadar önemli olduğunu görmezden gelme eğilimindedir. Sadece profesyonel programcıların önemli olduğunu düşünmek çok açık.

2
user825628

Benim için büyük bir sorun, masaların, özellikle iç içe geçmiş masaların, düzgün yerleştirilmiş bir css uygulamasından çok daha uzun sürmesidir. (Siz yapabilirsiniz css'i yavaşlatır).

Tüm tarayıcılar css'i daha hızlı hale getirir, çünkü her div ayrı bir öğedir, böylece kullanıcı okurken bir ekran yüklenebilir. (Büyük veri kümeleri vb. İçin). Tablolar yerine css kullandım, bu durumda mizanpajla uğraşmadım bile.

İç içe geçmiş bir tablo (hücrelerin içindeki tablolar, vb.) Son "/ tablo" bulunana kadar tarayıcı penceresine geçmez. Daha da kötüsü - kötü tanımlanmış bir tablo somtimes bile yapmaz! Ya da öyle olduğu zaman, işler kötüye gider. ("TD" ler vs. ile doğru şekilde örtüşmemek)

Çoğu şey için tabloları kullanıyorum, ancak büyük veriye gelince ve bir ekranın son kullanıcı için hızlı bir şekilde görüntülenmesi arzusu olduğunda - CSS'nin sunduğu şeyleri kullanmaya çalışıyorum.

2
Tim Fischer

Her iki şekilde de siteler yapmak zorunda kaldım, ayrıca üçüncüsü, masalarda, divlerde ve tarzlarda korkunç "karma" düzende: Divs/CSS kolayca kazandı.

Sadece bir tablo hücresinin kod ağırlığına uyması için divs'i üç derinlemesine sokmanız gerekir, yarasadan hemen. Bu etki iç içe geçmiş tablolarla ölçeklenir.

Ayrıca sitemdeki her sayfa için tek bir değişiklik yapmayı tercih ederim.

Divs/css ile sunumun her yönü üzerinde tam kontrolüm var. Tablolar, çirkin şekillerde, özellikle de IE'de henüz desteklememe seçeneğim olan bir tarayıcıyı bozuyor.

Bir divs/css web sitesinin bakım veya yeniden tasarımı için zamanım tablolarda ne olacağının bir kısmı.

Son olarak, CSS ve hemen hemen her türlü komut dosyası dili ile çoklu, değiştirilebilir düzenleri yenileyebilirim. Bu tablolarla benim için imkansız olurdu.

Bu kararı verirken YG'nizde iyi şanslar.

2
John Dunagan

Bir örnek: bir sayfanın ana içerik alanını ortalamak istiyorsunuz, ancak içinde yer alan yüzmeleri içermek için, yüzdürülmesi gerekiyor. CSS'de "şamandıra: merkez" yoktur.

Bu, merkezli bir öğenin içine "yüzmeleri" eklemenin tek yolu değil. Yani, hiç iyi bir tartışma değil!

Bir şekilde, sahte bir öncül, "divs vs tablo" şey.

Sayfanın hızlı ve kirli bölümü üç sütuna mı ayrılır? Tablolar are daha kolay, dürüst olmak gerekirse. Ancak hiçbir profesyonel onları düzen için daha fazla kullanmaz, çünkü sayfa öğelerinin sayfadaki konumunu kilitler.

Asıl argüman "sayfadaki HTML tarafından yapılan konumlandırma" nın aksine "CSS tarafından konumlandırma (umarım uzak bir dosyada)" dır. Elbette herkes, ikincisinin aksine, eskilerin faydalarını görebilir mi?

  1. Boyut - sayfa düzeniniz HTML’de ise, sayfalarda önbelleklenemez ve her sayfada tekrarlanmalıdır. Mizanpajınız sayfada değil, önbelleğe alınmış bir CSS dosyasındaysa, büyük miktarda bant genişliği kazanacaksınız.
  2. Birden fazla geliştirici aynı sayfada aynı anda çalışabilir - HTML üzerinde çalışıyorum, diğer adam da CSS'de çalışıyor. Depoya gerek yok, fazla yazma, dosya kilitleme vb.
  3. Değişiklik yapmak daha kolaydır - farklı tarayıcılarda mizanpajla ilgili sorunlar olur, ancak bunları çözmek için yalnızca bir dosyayı, CSS dosyasını düzeltmeniz gerekir.
  4. Erişilebilirlik, daha önce de belirtildiği gibi. Tablolar, herkes için iki boyutlu bir düzen çalıştığını varsayar. Bazı kullanıcılar içeriğinizi bu şekilde görmez ve Google içeriğinizi bu şekilde görüntülemez.

Bunu düşün:

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

6 hücreli bir tablonun iki sırasını temsil eder. İki boyutlu tablo düzenini görebilen biri, her resmin altında bir başlık görecektir. Ancak konuşma sentezi veya bir PDA kullanarak ve bir arama motoru örümceği için, bu

picture picture picture caption caption caption

ve masadaki yerinde belirgin olan ilişki ortadan kalkar.

DIV'ler ve CSS, yalnızca en kısa sürede belirli bir tasarım elde etmek için bir HTML sayfasına dikdörtgenler yerleştirmek mi?) Görevi için daha mı iyidir? Hayır, muhtemelen değildir. Ancak, belirli bir tasarıma ulaşmak için hızlı bir şekilde dikdörtgen yerleştirme işinde değilim. Daha büyük bir resim düşünüyorum.

2
AmbroseChapel

İçerik ve düzen arasındaki ayrım, farklı html dosyaları oluşturmak zorunda kalmadan, siteniz için yazıcı dostu düzenler veya yalnızca farklı görünümler (stiller) oluşturmayı da kolaylaştırır. Bazı tarayıcılar (Firefox gibi) görünüm menüsünden bir stil sayfası seçmeyi bile destekliyor.

Ve bence masasız bir düzeni sürdürmenin daha kolay olduğunu düşünüyorum. Kürek, kolyeler, vb. İçin endişelenmenize gerek yok. Sadece bir miktar konteyner divs oluşturup içeriği ihtiyacınız olan yere yerleştirin. Ve bu da daha okunabilir olduğunu düşünüyorum (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).

Öğrenmen gereken küçük bir 'hile' (ve hile konusunda ustalaşınca bence daha kolay ve daha mantıklı olur).

2
Grad van Horck

"Tablolar daha yavaştır" argümanına cevap vermek için - yanlış ölçüm olan oluşturma zamanını düşünüyorsunuz. Çok sık olarak, geliştiriciler bir sayfanın tüm düzenini yapmak için çok büyük bir tablo yazar - bu da indirilecek sayfanın büyüklüğünü önemli ölçüde artırır. Beğen ya da beğenme, orada hala bir ton çevirmeli bağlantı kullanıcısı var.

Ayrıca bakınız: ViewState'i fazla kullanma

1
Greg Hurlman

Geçmiş deneyimlerden DIV'lere gitmek zorunda kaldım. OOP'de bile, asıl amaç nesneler arasındaki eşleşmeyi azaltmaktır, bu nedenle bu kavram DIVS ve tablolara uygulanabilir. Tablolar, verileri bir sayfa etrafında düzenlemek için değil, tutmak için kullanılır. Bir DIV, bir sayfa etrafındaki öğeleri düzenlemek için özel olarak tasarlanmıştır, bu yüzden tasarım DIV'leri kullanmalı, tablolar veri depolamak için kullanılmalıdır.

Ayrıca, tablolarla yapılan web sitelerini düzenlemek oldukça basittir (bence)

1
Richard

div ve CSS konumlandırma daha esnek bir tasarım sağlar ve web sayfalarınızın daha kolay değiştirilmesine ve şablonlanmasına yol açar.

Bununla birlikte, eğer esneklikle ilgilenmiyorsanız, CSS tarafından masaya uyarlanan bazı divler yerine bir masa kullanmak, masaya çarpmak için çok daha kolay ve daha hızlıdır. Sadece biraz daha hızlı görünmesini sağlamak için bir tasarım yıkarken tabloları kullanmak eğilimindedir.

1
workmad3

Mizanpajımı CSS kullanarak tasarladığımda, genellikle her büyük bölüme kendi kök (vücut seviyesi) div'ini veriyorum ve onu uygun yerine getirmek için göreceli/mutlak konumlandırma kullanıyorum. Bu, tablolardan biraz daha esnektir, çünkü satır ve sütun kullanarak temsil edebileceğim bir düzenleme ile sınırlı değilim.

Ayrıca, düzeni yeniden düzenlemek istediğime karar verirsem (gezinme çubuğunun şu anda olmasını istediğimi söyleyin), tek bir yerdeki öğelerin konumunu (CSS dosyası) gidip değiştirebilirim ve HTML değişmek zorunda değilsin. Bunu tablolarla yapıyor olsaydım, içeri girip bilgiyi bulmalı ve aynı etkiyi elde etmek için bir çok öznitelik modunu ve kopyalamayı ve yapıştırmayı yapmalıydım.

Aslında, CSS kullanarak, düzenimin nasıl çalışmasını istediklerimi seçmelerine bile kullanıcı seçebilirim. İçerik alanlarının genel boyutu değişmediği sürece, kullanıcı tercihlerime dayanarak CSS'imi çıktılamak için biraz PHP komut dosyası kullanmak ve siteyi yeniden düzenlemelerine izin vermek için tamamen kullanıyorum kendi beğenileriyle. Tablolarla bir kez daha mümkün, ancak bakımı çok daha zor.

Son olarak, CSS tabloların asla sağlamayacağı bir MAJOR avantajına izin verir: görüntüleme cihazına dayalı içeriği yeniden biçimlendirme yeteneği. CSS, bir yazıcı için monitör için kullandığımdan tamamen farklı bir stil seti (konum, biçimlendirme vb. Dahil) kullanmama izin veriyor. Bu, diğer medyalara da genişletilebilir, mükemmel bir örnek, akıllıca tasarlanmış (ve çok standart) bir CSS geliştirilmiş sayfanın slayt gösterisi olarak görüntülenmesine olanak sağlayan Opera Show'dur.

Sonuçta, esneklik ve yönetim gerçek kazananlar. Genel olarak, CSS mizanpajla daha fazlasını yapmanızı sağlar. Hiçbir şey yok teknik olarak tablo tabanlı bir düzende standart olmayan bir şey var, ama neden kendini sınırlamak istiyorsun?

1
Nicholas Flynt

Geçmişte, ekran okuyucular ve diğer erişilebilirlik yazılımları masaları verimli bir şekilde ele almakta zorlanıyordu. Bir dereceye kadar, bu, ekran okuyucularında, "masa" modu ve tablonun içinde gördüklerine dayanarak "düzen" modu arasında geçiş yapan okuyucu tarafından ele alındı. Bu genellikle yanlıştı ve bu nedenle kullanıcılar tabloları gezerken modu manuel olarak değiştirmek zorunda kaldılar. Her durumda, büyük, genellikle yüksek oranda yuvalanmış masalar vardı ve büyük ölçüde, bir ekran okuyucu kullanarak gezinmek hala çok zor.

Aynısı, divs veya diğer blok seviyesindeki elemanlar, tabloları yeniden oluşturmak için kullanıldığında ve çok iç içe olduğunda geçerlidir. Div'lerin amacı, bir fomating ve düzen elemanı olarak kullanılmak ve bu nedenle, benzer bilgileri tutmak ve görsel kullanıcılar için ekranda göstermek üzere tasarlanmıştır. Bir ekran okuyucusu bir sayfa ile karşılaştığında, genellikle hem CSS tabanlı hem de html niteliği temelli herhangi bir düzen bilgisini yoksayar (Bu, tüm ekran okuyucular için değil, JAWS, Windows Eyes ve Linux için Orca budur).

Bu amaçla, tabular veri, yani iki veya daha fazla boyutta, bazı başlıklarla sıralanacak mantıklı mantıklı olan veriler, en iyi tablolara yerleştirilir ve sayfadaki içeriğin düzenini yönetmek için divs kullanır. ("tablo verilerinin" ne olduğunu düşünmenin bir başka yolu, onu grafik şeklinde çizmeye çalışmaktır ... eğer yapamazsanız, muhtemelen en iyi şekilde bir tabloda temsil edilmez)

Son olarak, tablo tabanlı bir düzende, öğelerin sayfadaki konumunun iyi ayarlanmış bir kontrolünü elde etmek için sık sık iç içe geçmiş tablolar kullanılır. Bunun iki etkisi vardır: 1.) Her sayfa için artırılmış kod boyutu - Gezinme ve genel yapı tablolarla sık sık yapıldığından, her istek için aynı kod ağ üzerinden gönderilir, oysa div/css tabanlı bir düzen css dosyasını çeker bir kereden fazla ve daha az wordy divs kullanır. 2.) Çok fazla iç içe geçmiş tablolar, istemcinin tarayıcısının oluşturması için çok daha uzun sürer, bu da biraz daha yavaş yükleme sürelerine yol açar.

Her iki durumda da, "son mil" bant genişliğindeki artış ve bunun yanı sıra çok daha hızlı kişisel bilgisayarlar bu faktörleri hafifletiyor, ancak hiç olmadığı kadar, pek çok site için halen mevcut olan sorunlar.

Tüm bunların akılda tutulmasıyla, başkalarının da söylediği gibi, tablolar daha kolaydır, çünkü daha fazla düşünmeye izin veren daha ızgara odaklıdırlar. Söz konusu sitenin uzun sürmesi beklenmiyorsa veya korunmuyorsa, en kolay olanı yapmak mantıklı olabilir, çünkü en uygun maliyetli olabilir. Bununla birlikte, beklenen kullanıcı temeli engelli bireylerin önemli bir bölümünü içerebiliyorsa veya site uzun süre boyunca başkaları tarafından korunacaksa, işleri kısa ve öz bir şekilde yapmak için zaman harcayarak, erişilebilir bir yolla sonuçta daha fazla ödeme yapabilir.

1
cdeszaq

Değişikliklerin tüm tarayıcılarda, özellikle de tüm bilgisayar hırsızlıklarında, vb. Çalışmasını sağlamak için test miktarını göz önüne aldığınızda, sayfa tasarımını değiştirmeyi nasıl kolaylaştırdığını hala tam olarak anlayamadım. Çok fazla zaman ve para harcayan oldukça sinir bozucu ve sıkıcı bir süreç. Neyse ki 508 mevzuatı yalnızca ABD (serbest ülke - evet hakkı ülkesi) için geçerlidir ve İngiltere’de olduğum gibi, hangi tarzı seçersem seçeyim. Popüler (ABD) inancının aksine, Washington'da yapılan yasalar dünyanın geri kalanına uygulanmaz - bunun için şükür. Mevzuatın yürürlüğe girdiği gün web tasarım dünyasında güzel bir gün olmalı. Bilişim sektöründe 25 yıl ile yaşlandıkça gittikçe artan bir şekilde alaycı olduğumu düşünüyorum, ancak bu tür bir mevzuatın yalnızca işleri korumak için olduğundan eminim. Gerçekte, herkes makul bir web sayfasını birkaç tabloyla bir araya getirebilir. Bunu DIV'ler/CSS ile yapmak çok daha fazla çaba ve bilgi gerektirir. Tecrübelerime göre saatler ve saatler sürebilir Googling, oldukça basit sorunlara çözüm bulmak ve tamamen doğru şeyler yapmayı tartışan idealist zealotlarla dolu forumlarda anlaşılmaz makaleler okuyor. Ayak parmağını suya batırıp her durumda düzgün bir şekilde çalışmasını sağlayamazsın. Bana öyle geliyor ki, tüm durumlarda geçerli olan, tarayıcılarda çalışan ve "normal" bir dil kullanarak yazılmış olan, DIVS/CSS "kutudan çıkma" konusunda kesin bir rehberin olmaması biraz korumacılık.
Ben bir uygulama geliştiricisiyim ve yerleşim problemlerini çözmenin ve tüm tarayıcılara karşı test etmenin temel uygulamayı oluşturmak, iş nesneleri tasarlamak ve uygulamak ve veritabanını oluşturmaktan neredeyse iki kat daha uzun sürdüğünü söyleyebilirim. arka uç Zamanım = para, hem benim hem de müşterilerim için bu yüzden tüm profesyonel DIV/CSS argümanlarını masrafları düşürmek ve müşterilerim için paranın karşılığını vermek için reddetmiyorsam özür dilerim. Belki de geliştiricilerin zihinleri çalışmaktadır, ancak karmaşık bir masa yapısını değiştirmek, DIV/CSS'yi değiştirmekten çok daha kolay görünüyor. Neyse ki şimdi bu sorunlara bir çözüm şu anda hazır görünüyor - WPF.

1
Tim Black

Bence hiç kimse bir web sitesinin harika davrandığında ve hızlı çalıştığında nasıl tasarlandığını/uygulandığını umursamıyor.

HTML işaretlemesinde hem "table" hem "div"/"span" etiketlerini kullanıyorum.

Neden divs seçtiğime dair birkaç argüman vereyim:

  1. bir tablo için en az 3 etiket (tablo, tr, td, thead, tbody) yazmalısınız, Güzel bir tasarım için, bazen çok fazla iç içe geçmiş tablo vardır

  2. Sayfada bileşenlerin olmasını seviyorum. Tam olarak nasıl açıklayacağımı bilmiyorum ama deneyeceğim. Bir logoya ihtiyacınız olduğunu ve bunun bir sonraki sayfa içeriğinin üzerine küçük bir parçası yerleştirilmesi gerektiğini varsayalım. Tabloları kullanarak 2 resim kesmeli ve bunu 2 farklı TD'ye koymalısınız. DIV'leri kullanarak istediğiniz gibi düzenlemek için basit bir CSS'ye sahip olabilirsiniz. En çok hangi çözümü seviyorsunuz?

  3. ne zaman bir şey yapmak için 3 iç içe geçmiş masa varsa, DIV'ler kullanarak yeniden tasarlamayı düşünüyorum

AMA hala tablolar için kullanıyorum:

  1. tablo verileri

  2. kendini genişleten içerik

  3. hızlı çözümler (prototipler), çünkü DIV'ler kutu modeli her tarayıcıda farklıdır, çünkü birçok üretici tablo, vb. kullanıyordur.

1
Dani

Düzenler için hala tabloyu kullanarak, div tarafındaki yeniliği kaçırıyoruz.

Birçoğu divs için düzen oluşturmayı kolaylaştıran çözümler geliştirdi. En popüler ızgara mimarisi olmak. Bu mimariye dayanan dinamik yerleşim jeneratörleri var. Çıkış: 1) 960.gs ve (http://grids.heroku.com/) 2) Blueprint ve daha pek çoğu.

Tablo düzeninde mimari ve araçlar açısından pek fazla yenilik görmedim.

Tüm teorileri bir yana, pratik olarak CSS ve divs ile düzenlemenin daha hızlı olduğunu söyleyebilirim. Bu yöndeki yenilik yerine her şeyden daha kolay.

1
Pixelgrey

Tablolar, basit veya geçici bir şey için birlikte attığınız HTML için iyidir. Büyük ölçekli bir web sitesi oluşturuyorsanız, web siteniz değiştikçe zamanla bakımı daha kolay olacağından divs ve CSS ile devam etmeniz gerekir.

1
Adam Rosenfield

1: Evet, kullanıcılarınız umursuyor. Ekran okuyucu kullanıyorlarsa, kaybolur. Sayfadan bilgi çıkarmaya çalışan başka bir araç kullanırsam, tablo verilerini temsil etmek için kullanılmayan tablolarla karşılaşmak yanıltıcıdır.

İçeriği ayırmak için bir div veya span kabul edilebilir çünkü tam olarak bu öğelerin anlamı budur. Ben, bir arama motoru, ekran okuyucusu veya başka bir şey bir tablo öğesiyle karşılaştığımda, bunun "aşağıdaki tabloda verilen tablo şeklinde veri" anlamına gelmesini bekliyoruz. Bir div ile karşılaştığımızda, "bunun div için içeriğimi ayrı parçalar veya alanlar halinde tanımlamak için kullanılan bir öğe olduğunu umuyoruz.

2: Okunabilirlik: Yanlış. Tüm sunum kodları css ise html dosyasını okuyabilir ve sayfanın içeriğini anlarım. Veya CSS'yi okuyabilir ve sunumu anlayabilirim. Eğer html'de her şey birbirine karışırsa, içeriğin ne olduğunu ve ne olmadığını bile görmeden önce sunumla ilgili tüm parçaları zihinsel olarak ele almalıyım. Dahası, css'i anlamayan bir web geliştiricisiyle tanışmaktan korkardım, bu yüzden bunun bir sorun olduğunu sanmıyorum.

3: Tablolar daha yavaş: Evet, onlar. Nedeni basit: Tablolar tamamen ayrıştırılmalıdır, dahil içeriği oluşturulmadan önce içeriği. Karşılaşıldığında bir div oluşturulabilir, hatta önce içeriği ayrıştırılmış olsa bile. Bu, divs sayfanın yüklenmesi tamamlanmadan önce görüneceği anlamına gelir.

Ve sonra bonus var, bu tablolar çok daha kırılgan ve her zaman farklı tarayıcılarda, farklı yazı tipleri ve yazı tipi boyutları ve mizanpajın değişmesine neden olabilecek diğer tüm faktörlerle aynı hale getirilmeyecek. Tablolar, sitenizin belirli tarayıcılarda bir ya da iki piksel tarafından kapatılmasını, kullanıcı yazı tipi boyutunu değiştirdiğinde veya ayarlarını başka bir şekilde değiştirdiğinde iyi ölçeklenmemesini sağlamanın mükemmel bir yoludur.

Tabii ki # 1 büyük olanıdır. Bir çok araç ve uygulama bir web sayfasının anlam anlamına bağlıdır. Genel örnek, görme engelli kullanıcılar için ekran okuyuculardır. Bir web geliştiricisiyseniz, sizi bir sitede çalışmak için başka şekilde kiralayabilecek birçok büyük şirketin, zorunl siteye bu durumda bile erişilebilir olduğunu göreceksiniz. Bu, html'nizin anlamsal anlamını düşünmeniz gerektiği anlamına gelir. Semantik web veya daha alakalı olarak, mikro biçimler, rss okuyucuları ve diğer araçlar sayesinde, sayfa içeriğiniz artık yalnızca bir tarayıcı aracılığıyla görüntülenmez.

1
jalf

İngilizcem için üzgünüm ama işte başka bir sebep:

Bazı devlet kurumlarında çalıştım ve TABLE'ın kullanılmamasının bir numaralı nedeni engelli insanlar için. Web sayfalarını "çevirmek" için makineler kullanıyorlar.

Sorun, bu "çeviri makinesi", TABLO tarafından yapılırsa web sitesini okuyamaz. Niye ya ? Çünkü TABLO DATAS içindir.

aslında, TABLES kullanıyorsanız, her HÜCRELER için, engellilerin TABLO'da nerede olduklarını bilmelerini sağlamak için bazı bilgiler belirtmeniz gerekir. Büyük bir masaya sahip olduğunuzu ve ekranda sadece 1 hücre görmek için yakınlaştırmanız gerektiğini hayal edin: hangi satırda/sütunta olduğunuzu bilmeniz gerekir.

Bu nedenle, DIV kullanılır ve engelliler basitçe metin okuyabilir ve orada olmaları gerekmediğinde çizgiler/sütunlar hakkında garip bilgiler edinemezler.

Ayrıca hızlı ve kolay şablonlar oluşturmak için TABLO'yu tercih ediyorum, ama şimdi CSS'ye alışkınım ... bu güçlü, ama gerçekten ne yaptığını bilmek zorundasın ... :)

1
RVeur23

Flex, işleri dikey sütunlara yerleştirme etiketine sahiptir. Tüm mizanpaj/içerik düzenini dürüst olmaları doğru olduğunu sanmıyorum, ama en azından bu sorunu çözdüler.

CSS ile sinirli olan birçok insan gibi Ben de kolay ve kolay bir cevap için çok geniş baktım, bulduğumu düşündüğümde mutlu hissetmeye başladım ve daha sonra sayfayı Chrome'da açtığımda umutlarım parçalanmıştı. Bunun mümkün olmadığını söyleyecek kadar yetenekli değilim, ancak akran incelemesi için güvenilir bir şekilde yapılabileceğini kanıtlayan kimsenin örnek kod sunduğunu görmedim.

Öyleyse, bu adanın CSS tarafındaki biri dikey sütunları yerleştirmek için bir zihniyet/metodoloji önerebilir mi? İkinci ve üçüncü satırlarda mutlak konumlandırma denedim, ancak sonuçta her yerde üst üste binen şeyler var ve sayfa daraltılmışsa yüzdürmenin benzer sorunları var.

Buna bir cevap olsaydı kendinden emin olurdum - doğru olanı yap - Bana sadece şöyle bir şey söyle, "Hey denediniz mi ** akış: dikey | yatay" ve tamamen saçlarınızdan çıktım.

1
Shanimal

Google, bir tablonun içindeki metin içeriğine çok düşük öncelik verir. Yerel bir hayır kurumuna SEO tavsiyesi veriyordum. Web sitelerini incelerken siteyi yerleştirmek için tablolar kullanıyordu. Her sayfaya bakıldığında, hangi kelimelerin - veya kelimelerin birleşiminin - ne olursa olsun - Google arama kutusunda kullandığım sayfalarından, en üstteki arama sayfalarının hiçbirinde sayfalar açılmayacaktı. (Ancak, aramada siteyi belirterek sayfa döndürüldü.) Bir sayfa, bir aramada iyi bir sonuç elde etmek için normal standartlara göre iyi bir şekilde yazıldı, ancak yine de döndürülen arama sonuçlarının ilk sayfalarında görünmedi. . (Bu metnin bir tablonun içinde olduğuna dikkat edin.) Daha sonra bir tablodan ziyade div'de bulunan sayfalarda bir metin bölümü gördüm. Arama motorunda bu div kelimelerinin bir kısmını yazdık. Sonuç? Arama sonucunda 2 numarada geldi.

1
Simon Measures

Bir kerede bir tablonun bir kerede yüklendiğini, başka bir deyişle, bir bağlantı yavaş olduğunda, tablonun geldiği alanın tüm tablonun yüklenene kadar boş kaldığını, diğer taraftan bir div'nin veri geldiği zaman yukarıdan aşağıya yüklendiğini öğrendim. ve tamamen tamamlanmış olup olmadığına bakılmaksızın.

1
Davy

Öğelerin mizanpajdaki belirli bir fiziksel ilişkide kalması gerektiğinden emin olmanız gerektiğinde tabloları kullanın. Veriler için, tablo genellikle kullanılacak en iyi düzen öğesidir, çünkü sütunlarınızın beklenmedik şekillerde sarılmasını ve ilişkilendirmeleri karıştırmasını istemezsiniz.

Ayrıca, belirli bir ilişkide kalması gereken veri dışı öğelerin de bir tabloda gösterilmesi gerektiği ileri sürülebilir.

Esnek css mizanpajları, mobil cihazlar ve büyük ekranlar ve yazdırma ve diğer ekran türleri için uygun içerik için mükemmeldir, ancak bazen içeriğin çok özel bir şekilde gösterilmesi gerekir ve bunun için ekran okuyucuların kolayca erişememeleri gerekir, çok haklı olabilirdi.

1
Sal

TABLO'lardan mümkün olduğu kadar kaçınmaya çalışıyorum, ancak çoklu kontrol tiplerini ve farklı altyazı konumlarını gruplamadaki oldukça katı kontrollerle birleştiren karmaşık formlar tasarlarken, DIV'lerin kullanılması güvenilmezdir veya çoğu zaman imkansızdır.

Şimdi, bu formların DIV tabanlı bir düzeni daha iyi yerleştirmek için yeniden tasarlanamayacağını iddia etmeyeceğim, ancak bazılarına göre müşterimiz mevcut düzenleri önceki sürümden (klasik ASP ile yazılmış) değiştirmeyeceği konusunda kararlı, çünkü kullanıcılarının aşina olduğu kağıt form.

Formların sunumu dinamik olduğundan (bazı bölümlerin gösterimi, durumun durumuna veya kullanıcının izinlerine dayanıyorsa), her biri mantıksal olarak gruplandırılmış form öğelerinin bir TABLO'sunu içeren yığılmış DIV kümeleri kullanırız. TABLO'nun her sütunu CSS tarafından kontrol edilebilecek şekilde sınıflandırılmıştır. Bu yolla, formdaki farklı bölümleri DIV'lere satır sarmak için tablo olmama problemi olmadan kapatabiliriz.

1
CMPalmer

Birkaç yıl önce ekran okuyucuları ve tabloları konusunu araştırdım ve çoğu geliştiricinin inandıklarıyla çelişen bilgiler buldum:

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

“Muhtemelen bazı erişilebilirlik savunucularının, mizanpaj tablolarının kötü bir fikir olduğunu ve bunun yerine CSS mizanpaj tekniklerinin kullanılması gerektiğini söylediğini duyacaksınız. Dürüst olmak gerekirse, mizanpaj için tabloları kullanmak en kötüsü değil. erişilebilirlik açısından yapabileceğiniz şey. Her türlü engelli insanlar, masalar erişilebilirliği göz önünde bulundurularak tasarlandığı sürece masalara kolayca erişebilirler. ”

1
Rimian

Bunun genel bir soruna bağlı bir mesele olduğuna inanıyorum. HTML doğduğunda kimse yaygın kullanımını öngöremezdi. Neredeyse kendi başarısının ağırlığı altında çöktü bir başka teknoloji. HTML sayfaları yeşil bir metin terminaline vi yazıldığında, sayfanın ziyaretçilerine veri sunmak için gerekli olan bir TABLE gerekliydi ve çoğunlukla tablo şeklinde bir anlam ifade eden verilerdi.

Hepimiz işlerin nasıl geliştiğini biliyoruz. TABLOlar yakın zamanda nispeten modası geçti, ancak DIV'leri ve CSS tabanlı mizanpajları tercih etmek için pek çok neden var (erişilebilirlik sonuncusu değil). Tabii ki hayatımı kurtarmak için bir CSS yazamıyorum :-) ve bir grafik tasarım uzmanının her zaman elinizin altında olması gerektiğini düşünüyorum.

Bununla birlikte ... modern bir web sitesinde bile bir tabloda sunulması gereken birçok veri var.

1
Manrico Corazzi

Bunun için masa açısını destekliyorsanız, tabloları olan bir site bulun ve kendinize bir ekran okuyucu edinin - ekran okuyucuyu kapatın ve monitörünüzü kapatın.

Sonra bir Nice semantik olarak doğru div düzen sitesi ile deneyin.

Farkı göreceksin.

İçlerindeki veriler sayfayı yerleştirmemek için tablo halinde ise tablolar kötü değildir.

1
Allen Hardy

Tablolar hakkındaki bilgilerime göre, eğer çok fazla tablo iç içe geçmişse, sayfayı oluşturmada tarayıcı için çok fazla masraf vardır.

1 - Tarayıcı, son tabloyu tüm tablo yüklenene kadar bekletmek için bekliyor.

2 - Masayı oluşturma algoritması pahalıdır ve tek seferde değildir. Tarayıcı, içeriği ne zaman ve ne zaman alır, içeriğin genişliğini ve yüksekliğini hesaplamaya çalışır. Yani, iç içe geçmiş tablolara sahipseniz, örneğin, tarayıcı ilk satırı aldı ve 1. hücre çok miktarda içeriğe ve genişliğe ve yüksekliğe sahip değilse, genişliği hesaplar ve ilk satırı oluşturur. 2. sırada yer alırken hücre # 2'ye sahip olacak ve çok fazla içeriğe sahip olacak! Şimdi 2. sıra hücrelerin genişliğini hesaplayacaktır. Peki ya ilk? Genişlikleri özyinelemeli olarak hesaplar. Müşteri tarafında bu kötü. (Bir örnek için) Bir programcı olarak, veri toplama zamanı, veri yapılarını optimize etme vb. Gibi şeyleri optimize edersiniz. Sunucu tarafında tamamlanması gereken şeyleri optimize eder, in2 sn. 8 saniye Burada yanlış olan ne? 1. Ağ yavaş olabilir! Ya ağ iyi ise? Ağ içeriği 1 saniye içinde ileten nedir? Bu ekstra 5 saniye nerede tüketiliyor? Endişelenecek bir şey var - Tarayıcı tabloları tahmin ederken ve hazırlarken çok zaman alıyor olabilir!

Tablolar nasıl optimize edilir? Tablo kullanıyorsanız, her zaman hücreler için genişlik tanımlamanızı öneririm. Bu, tarayıcının sadece bu genişlikleri kör olarak alacağını garanti etmez, ancak ilk genişliklere karar vermede tarayıcıya çok yardımcı olacaktır.

Ancak, sonunda, div CSS tarayıcı tarafından önbelleğe alınabilir gibi harika bir yoldur; masa önbelleğe alınmazken!

1
Biranchi Panda

Saf sayfa düzeni olarak kullanılan tablolar erişilebilirlik için bazı problemler doğurur (duydum). Ancak, burada ne sorulduğunu anlıyorum, bir şekilde sayfanızdaki bir şeyin doğru şekilde hizalanmasını sağlamak için bir tablo kullanarak web'i sakatladığınızı anlıyorum.

İnsanların daha önce FORM etiketlerinin ve girdilerinin aslında veri olduğunu ve tablolara izin verilmesi gerektiğini savunduğunu duydum.

Birkaç elemanın doğru bir şekilde sıralandığından emin olmak için bir tablo kullanmanın argümanı, koddaki bu büyük artışa neden olarak, tek bir DIV'nin tüm ihtiyaçlarını nasıl karşılayabileceğine dair örnekler içerir. Her zaman 10 satır CSS ve IE5, IE5.5, IE6, IE7 için yazmaları gereken özel tarayıcı bölümlerini içermezler ...

Bence tasarımında dengeyi kullanmaya devam ediyor. Tablolar araç kutusundadır, sadece ne için olduklarını hatırlayın ...

0
HB

Kuşkusuz OP bir nebze kadar yükselmişti, tartışmalar çok hafta gibi gözüküyor ve kolayca karşı çıkıyordu.

Web sayfaları, web geliştiricilerinin etki alanıdır ve div & CSS'nin benim için yeterli olan tablolardan daha iyi olduğunu söylerler.

Bir düzen, bir sunucu uygulaması tarafından oluşturulan tablolar tarafından gerçekleştirilirse, yeni bir düzen, sadece bir css dosyasında yapılan değişikliklere göre uygulamanın yeniden yapılandırılması ve yeniden düzenlenmesi anlamına gelir.

Ayrıca erişilebilirlik. Mizanpaj için kullanılan tablolar bir web sitesine erişilemez hale getirir, bu yüzden onları kullanmayın. Bu bir beyin fırtınası değil, yasa dışı demek değil.

0
Ian

Süper kısa cevap: bakımı yapılabilir web siteleri tasarlamak tablolarla zordur ve standart yöntemle yapmak kolaydır.

Bir web sitesi bir tablo değil, birbiriyle etkileşimde bulunan bir bileşenler topluluğudur. Bir tablo olarak tanımlamak mantıklı değil.

0
Rich Bradshaw

Site bakımı ve tasarım açısından içerik korunurken (özellikle e-ticarette her zaman olan) bakım

İçerik ve tasarım tablolarla birbirine bölündü = hem içeriğin hem de tasarımın güncellenmesi.

Tasarımdan ayrı içerik = tasarım güncelleme ve belki biraz içerik.

Benim tarzım olsaydı, içeriğimi PHP üreten XML'de tutar, XSLT'de işaretlemeye dönüştürülür ve etkileşim için CSS ve Javascript ile tasarlardım. Nesnelerin Java tarafı için, JSP'den JSTL'ye, markayı oluşturmak için.

0
mltorrefranca

DIV'yi kullanarak işleri kolayca değiştirebilirsiniz. Örneğin, bunu yapabilirsiniz:

Menu | Content

Content | Menu

Menu
----
Content

HTML’de değil, CSS’de değiştirmek kolaydır. Ayrıca birkaç stil sunabilirsiniz (sağ el, sol el, küçük ekranlar için özel).

CSS'de, menüyü yazdırmak için kullanılan özel bir stil sayfasında da gizleyebilirsiniz.

Bir başka iyi şey, görsel olarak aksi belirtilmiş olsa bile içeriğinizin kodda her zaman aynı sırada (önce menü, ardından gelen içerik) olmasıdır.

0
ofaurax