Dlaczego nie użyć tabel do układu w HTML? [Zamknięte]


665

Wydaje się być ogólną opinią, że tabele nie powinny być używane do układu w HTML.

Dlaczego?

Nigdy nie widziałem (lub rzadko szczerze mówiąc) dobrych argumentów na to. Typowe odpowiedzi to:

  • Dobrze jest oddzielić zawartość od układu,
    ale jest to błędny argument; Myślenie stereotypowe . Wydaje mi się, że to prawda, że ​​użycie elementu tabeli do układu ma niewiele wspólnego z danymi tabelarycznymi. Więc co? Czy mój szef się przejmuje? Czy obchodzą mnie użytkownicy?

    Być może ja lub moi programiści, którzy muszą dbać o stronę internetową ... Czy stół jest mniej konserwowalny? Myślę, że używanie tabeli jest łatwiejsze niż używanie div i CSS.

    Nawiasem mówiąc ... dlaczego używanie div lub span nie jest dobrym oddzieleniem treści od układu i tabeli? Uzyskanie dobrego układu tylko z divami często wymaga dużej ilości zagnieżdżonych div.

  • Czytelność kodu
    Myślę, że jest na odwrót. Większość ludzi rozumie HTML, niewielu rozumie CSS.

  • Lepiej dla SEO nie używać tabel
    Dlaczego? Czy ktoś może udowodnić, że tak jest? Lub oświadczenie Google, że stoły są zniechęcane z punktu widzenia SEO?

  • Tabele są wolniejsze.
    Należy wstawić dodatkowy element tbody. To jest orzeszki ziemne dla nowoczesnych przeglądarek internetowych. Pokaż mi niektóre testy porównawcze, w których użycie tabeli znacznie spowalnia stronę.

  • Przegląd układu jest łatwiejszy bez tabel, patrz css Zen Garden .
    Większość stron internetowych, które wymagają aktualizacji, również potrzebuje nowej treści (HTML). Scenariusze, w których nowa wersja strony wymaga tylko nowego pliku CSS, są mało prawdopodobne. Zen Garden to fajna strona internetowa, ale trochę teoretyczna. Nie wspominając o niewłaściwym użyciu CSS.

Naprawdę interesują mnie dobre argumenty do używania div + CSS zamiast tabel.


Uzgodnione, tabele są w porządku podczas prezentacji danych tabelarycznych. Należy ich unikać, gdy używa się go wyłącznie do układu. Z drugiej strony, czasami trzeba teraz wybrać łatwą drogę i poprawić ją później. Po prostu zobacz źródło, a zobaczysz, co mam na myśli.
Haacked

Duplikat pytań i odpowiedzi znajduje się na stackoverflow.com/questions/30251/tables-instead-of-divs
Onorio Catenacci

11
Odpowiedź jest prosta: to zależy. Jeśli tabele są używane do rozwiązania konkretnego problemu, którego nie potrafią obecne wersje CSS, są dobrze używane. Jeśli zaczniesz umieszczać tabele w tabelach, w milionach tabel, robisz to źle. Jeśli jest to okazjonalny stół tylko po to, żeby ułożyć jakieś 2 kolumny lub coś w tym stylu, nie wykluczam tego w moim zespole: jest to szybsze i łatwiejsze. (Ja sam zawsze staram się używać CSS, ale w końcu dostawa jest ważniejsza niż poprawny semantyczny HTML)
AlfaTeK

1
@Camilo SO nadal żyje w XX wieku. Jeff najwyraźniej nie wie, jak korzystać z ultagu. Przejrzyj wszystkie listy w tej witrynie (odznaki, powiązane pytania, najnowsze tagi). Wszystkie są pojedynczymi kolumnami lub długimi akapitami oddzielonymi br.
Yi Jiang

2
@Brad: W zależności od pewnych konkretnych szczegółów (to jest moje wyjście na wszelkie sprytne powroty ;-), że użycie DIV jest Wciąż lepsze niż nadużywanie tabel. Dwie części dokumentu, które zostały ułożone obok siebie, mogą być legalnie zawarte w elementach DIV, ale z pewnością NIE są danymi tabelarycznymi. Nie ma znaczenia, jaki konkretnie jest styl; treść jest tabelaryczna lub nie. Uwaga: NIE jestem również zwolennikiem DIVitis :)
Bobby Jack

Odpowiedzi:


496

Omówię kolejno wasze argumenty i spróbuję pokazać w nich błędy.

Dobrze jest oddzielić zawartość od układu, ale jest to błędny argument; Myślenie stereotypowe.

To wcale nie jest błędne, ponieważ HTML został zaprojektowany celowo. Niewłaściwe użycie elementu może nie być całkowicie wykluczone (w końcu nowe idiomy rozwinęły się również w innych językach), ale możliwe negatywne implikacje muszą zostać zrównoważone. Dodatkowo, nawet jeśli nie było argumentów przeciwko niewłaściwemu użyciu tego <table>elementu dzisiaj, może być jutro z powodu sposobu, w jaki dostawcy przeglądarki stosują specjalne traktowanie tego elementu. W końcu wiedzą, że „ <table>elementy są tylko dla danych tabelarycznych” i mogą wykorzystać ten fakt, aby poprawić silnik renderowania, w procesie subtelnie zmieniając <table>zachowanie się, a tym samym rozbijając przypadki, w których wcześniej był niewłaściwie wykorzystywany.

Więc co? Czy mój szef się przejmuje? Czy obchodzą mnie użytkownicy?

Zależy. Czy twój szef jest spiczasty? Wtedy może go to nie obchodzi. Jeśli jest kompetentna, będzie ją to obchodzić, ponieważ użytkownicy będą .

Być może ja lub moi programiści, którzy muszą dbać o stronę internetową ... Czy stół jest mniej konserwowalny? Myślę, że używanie tabeli jest łatwiejsze niż używanie divs i css.

Większość profesjonalnych programistów wydaje się być przeciwna[ potrzebne źródło ] . To, że tabele mniej konserwowalne, powinno być oczywiste. Użycie tabel do układu oznacza, że ​​zmiana układu korporacyjnego w rzeczywistości oznacza zmianę każdej pojedynczej strony. To może być bardzo drogie. Z drugiej strony rozsądne użycie semantycznie znaczącego HTML w połączeniu z CSS może ograniczyć takie zmiany do CSS i użytych zdjęć.

Nawiasem mówiąc ... dlaczego używanie div lub span nie jest dobrym oddzieleniem treści od układu i tabeli? Uzyskanie dobrego układu tylko z divami często wymaga dużej ilości zagnieżdżonych div.

Głęboko zagnieżdżone <div>s są anty-wzorami, podobnie jak układy tabel. Dobrzy projektanci stron internetowych nie potrzebują wielu z nich. Z drugiej strony, nawet tak głęboko zagnieżdżone divy nie mają wielu problemów z układami tabel. W rzeczywistości mogą nawet przyczynić się do struktury semantycznej, logicznie dzieląc zawartość na części.

Czytelność kodu Myślę, że jest na odwrót. Większość ludzi rozumie html, mało rozumie css. To jest prostsze.

„Większość ludzi” nie ma znaczenia. Specjaliści mają znaczenie. Dla profesjonalistów układy tabel powodują znacznie więcej problemów niż HTML + CSS. To tak, jakby powiedzieć, że nie powinienem używać GVima ani Emacsa, ponieważ Notatnik jest prostszy dla większości ludzi. Albo że nie powinienem używać LaTeXa, ponieważ MS Word jest prostszy dla większości ludzi.

SEO lepiej nie używać tabel

Nie wiem, czy to prawda i nie użyłbym tego jako argumentu, ale byłoby to logiczne. Wyszukiwarki wyszukują odpowiednie dane. Chociaż dane tabelaryczne mogą być oczywiście istotne, rzadko szukają tego użytkownicy. Użytkownicy szukają terminów użytych w tytule strony lub podobnie widocznych pozycjach. Logiczne byłoby zatem wykluczenie filtrowania treści tabelarycznych, a tym samym znaczne skrócenie czasu przetwarzania (i kosztów!).

Tabele są wolniejsze. Należy wstawić dodatkowy element tbody. To jest orzeszki ziemne dla nowoczesnych przeglądarek internetowych.

Dodatkowy element nie ma nic wspólnego z wolniejszymi tabelami. Z drugiej strony algorytm układu tabel jest znacznie trudniejszy, przeglądarka często musi czekać na załadowanie całej tabeli, zanim zacznie układać zawartość. Dodatkowo buforowanie układu nie będzie działać (CSS można łatwo buforować). Wszystko to zostało wspomniane wcześniej.

Pokaż mi niektóre testy porównawcze, w których użycie tabeli znacznie spowalnia stronę.

Niestety nie mam żadnych danych porównawczych. Byłbym zainteresowany tym sam, ponieważ to prawda, że ​​ten argument nie ma pewnego rygoru naukowego.

Większość stron internetowych, które wymagają aktualizacji, również potrzebuje nowej zawartości (HTML). Scenariusze, w których nowa wersja strony wymaga tylko nowego pliku css, są mało prawdopodobne.

Ani trochę. Pracowałem nad kilkoma przypadkami, w których zmiana projektu została uproszczona przez rozdzielenie treści i projektu. Często nadal konieczna jest zmiana kodu HTML, ale zmiany zawsze będą znacznie bardziej ograniczone. Ponadto zmiany konstrukcyjne muszą być czasami wprowadzane dynamicznie. Zastanów się nad silnikami szablonów, takimi jak ten wykorzystywany przez system blogowy WordPress. Układy tabel dosłownie zabiłyby ten system. Pracowałem nad podobną sprawą dla oprogramowania komercyjnego. Możliwość zmiany projektu bez zmiany kodu HTML była jednym z wymagań biznesowych.

Inna rzecz. Układ tabeli znacznie utrudnia automatyczne analizowanie stron internetowych (zgarnianie ekranu). To może brzmieć trywialnie, bo przecież kto to robi? Sam byłem zaskoczony. Skrobanie ekranu może bardzo pomóc, jeśli dana usługa nie oferuje alternatywy dla WebService dostępu do jej danych. Pracuję w bioinformatyce, gdzie jest to smutna rzeczywistość. Nowoczesne techniki sieciowe i usługi sieciowe nie dotarły do ​​większości programistów i często skrobanie ekranu jest jedynym sposobem zautomatyzowania procesu pozyskiwania danych. Nic dziwnego, że wielu biologów wciąż wykonuje takie zadania ręcznie. Dla tysięcy zestawów danych.


139
„zmiana układu korporacyjnego w rzeczywistości oznacza zmianę każdej pojedynczej strony” - Czy ludzie nadal kopiują układ korporacyjny na każdej stronie? Jest to tak łatwe do rozwiązania dzięki stronom wzorcowym lub kontrolkom użytkownika w .net, dołączaniu plików w php lub klasycznym asp itp. Każdy, kto kopiuje taki układ firmy, zasługuje na ** wykopanie! ;-)
John MacIntyre

43
Przepraszam, ale to jest naprawdę pobożne życzenie. Czy obchodzi użytkowników? Nie. Nikogo to nie obchodzi oprócz niewielkiej liczby wprowadzonych w błąd rewizjonistów. HTML (w tym tabele) jest znacznie starszy od stosunkowo nowego pojęcia „semantyka vs. układ”. No i proszę o źródło dla „większości profesjonalnych twórców stron internetowych jest ci przeciwnych”.
cletus

20
Literówka powyżej: semantyka była sugerowana od samego początku. <table> w HTML zawsze było przeznaczone tylko do danych tabelarycznych, nigdy do układania (w początkowych latach i tak nie można było zmienić wyglądu tabeli, co uniemożliwiało użycie jej jako kotwicy układu). W rzeczywistości wczesne wersje HTML nie miały żadnego pojęcia o układzie, a HTML nigdy nie był przeznaczony do układu, ale do strukturyzacji tekstu. Co więcej: pierwsza propozycja HTML wielokrotnie ostrzega przed nadużywaniem tagów, aby wpływać na układ, oraz ostrzega przed logicznym stosowaniem znaczników fizycznych.
Konrad Rudolph

109
Pobierz czytnik ekranu i poproś go o przeczytanie strony z układem tabeli. to wszystko.
corymathews

8
@Sergio: nie edytuj odpowiednich informacji. Jest to wątpliwe, bezzasadne twierdzenie, którego tam używam i chcę to wyjaśnić. Twoja edycja zawierała w moich ustach twierdzenie, że nie mogę się cofnąć, skutecznie czyniąc mnie kłamcą, jeśli okaże się to nieprawdą.
Konrad Rudolph

290

Oto odpowiedź mojego programisty z podobnego wątku

Semantyka 101

Najpierw spójrz na ten kod i zastanów się, co tu jest nie tak ...

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

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

Problem polega oczywiście na tym, że rower nie jest samochodem. Klasa samochodu jest nieodpowiednia dla instancji roweru. Kod jest wolny od błędów, ale jest semantycznie niepoprawny. To źle odbija się na programatorze.

Semantyka 102

Teraz zastosuj to do znaczników dokumentów. Jeśli twój dokument musi zawierać dane tabelaryczne, odpowiednim znacznikiem będzie <table>. Jeśli jednak umieścisz nawigację w tabeli, niewłaściwie wykorzystasz zamierzony cel <table>elementu. W drugim przypadku nie prezentujesz danych tabelarycznych - (nie) używasz <table>elementu do osiągnięcia celu prezentacji.

Wniosek

Czy odwiedzający to zauważą? Nie. Czy twój szef się przejmuje? Może. Czy czasami skracamy rogi jako programiści? Pewnie. Ale powinniśmy? Nie. Kto skorzysta, jeśli użyjesz znaczników semantycznych? Ty - i twoja profesjonalna reputacja. Teraz idź i zrób właściwą rzecz.


39
Przepraszam, to nie trzyma wody. Nie używasz samochodu do mybike, ponieważ zamiast tego zdefiniowałbyś klasę „rower”. Nie można zdefiniować czegoś innego dla „<table>”, ponieważ jest to coś więcej niż zwykły znacznik semantyczny - mówi przeglądarce, jak renderować również jego zawartość.
Jimmy

57
Ładna analogia i świetny wniosek. Dlaczego ktoś miałby być zmuszany przez szefa i / lub użytkowników do robienia właściwych rzeczy? Czy nikt już nie jest dumny ze swojej pracy?
Sherm Pendley,

39
Myślę, że to dość arogancki post, który niczego nie wyjaśnia, tylko powtarza te same twierdzenia bez odpowiedzi na pytanie. Nie rozumiem, dlaczego ma tyle głosów poparcia ????
markus

10
Zgadzam się z tharkum. Ta odpowiedź jest raczej subiektywna i w rzeczywistości nie odpowiada na postawione pytanie. Chociaż zgadzam się, że DIV powinny być używane do układu strony, nie mogę sobie wyobrazić, że jakikolwiek projektant stron internetowych byłby zdezorientowany układem opartym na tabeli.
Richard Ev

16
@tharkun & Richard: Dlaczego „semantycznie niepoprawny” jest subiektywny i niczego nie wyjaśnia?
Vinko Vrsalovic

104

Oczywista odpowiedź: patrz CSS Zen Garden . Jeśli powiesz mi, że możesz łatwo zrobić to samo z układem opartym na tabelach (pamiętaj - HTML się nie zmienia), to na pewno użyj tabel do układu.

Dwie inne ważne rzeczy to dostępność i SEO.

Obie dbają o to, w jakiej kolejności prezentowane są informacje. Nie możesz łatwo zaprezentować nawigacji na górze strony, jeśli układ oparty na tabeli umieszcza ją w 3. komórce 2. rzędu 2. zagnieżdżonej tabeli na stronie.

Więc twoje odpowiedzi to łatwość konserwacji, dostępność i SEO.

Nie bądź leniwy. Rób rzeczy we właściwy i właściwy sposób, nawet jeśli są nieco trudniejsze do nauczenia się.


24
Często stosowaną sztuczką w Zen Garden jest zamiana tekstu na obrazy i zdefiniowanie go w CSS, dzięki czemu jest niewidoczny z HTML. Bardzo, bardzo źle.
GvS

3
Przepraszam, ale to nie w porządku. Tekst jest nadal w HTML - to jedno z wymagań projektu CSSZG. HTML musi pozostać niezmieniony.
erlando

10
Jeśli przyjrzysz się uważnie niektórym projektom, tekst w niektórych nagłówkach różni się od tekstu w HTML. To dlatego, że HTML jest niewidoczny, a zamiast tego wstawiany jest obraz. (Przykład: csszengarden.com/?cssfile=/212/212.css&page=0 , „Ścieżka? Do? Osiągnięcia?”)
GvS,

6
Niestety, absolutnie nie ma dowodów, że układy div są lepsze dla SEO. Również sami Google stwierdzili, że sprawdzanie poprawności HTML nie ma dla nich znaczenia - nieco inny problem, ale dotyczył tabel, ponieważ rzadko sprawdzają poprawność.
Disgruntled

„Większość z was zna zalety programisty. Oczywiście są trzy: lenistwo, niecierpliwość i pycha. ” - Larry Wall
inkredibl

91

Zobacz to zduplikowane pytanie.

Jedną rzeczą, o której zapominasz, jest dostępność. Układy oparte na tabelach również nie tłumaczą się, jeśli potrzebujesz na przykład czytnika ekranu. A jeśli pracujesz dla rządu, może być wymagana obsługa dostępnych przeglądarek, takich jak czytniki ekranu .

Myślę też, że nie doceniasz wpływu niektórych rzeczy wymienionych w pytaniu. Na przykład, jeśli jesteś zarówno projektantem, jak i programistą, możesz nie w pełni docenić, jak dobrze oddziela prezentację od treści. Ale kiedy wejdziesz do sklepu, w którym pełnią dwie różne role, zalety stają się coraz wyraźniejsze.

Jeśli wiesz, co robisz i masz dobre narzędzia, CSS ma naprawdę znaczącą przewagę nad tabelami pod względem układu. I chociaż każdy przedmiot sam w sobie może nie uzasadniać porzucenia stołów, razem wzięty, ogólnie jest tego wart.


W rzeczy samej. Widzę, że to duplikat. Brakowało mi tego. Jakieś działania wymagane oprócz obiecania, że ​​następnym razem będę bardziej ostrożny :-)?
Benno Richters,

Nie martw się Będzie to coraz bardziej powszechne w miarę wzrostu liczby pytań. Nawet nie przegłosowałem. Chcemy tylko mieć pewność, że w jak największym stopniu wszystkie one ostatecznie wskazują na wspólne źródło.
Joel Coehoorn,

8
Naprawdę podoba mi się ta odpowiedź. Używanie znaczników znaczących semantycznie nie jest tylko tradycją, pozwala tym nieprzejrzystym przeglądarkom (czytniki ekranu, zgarniacze ekranu, różne parsery) poprawnie kategoryzować różne obiekty na twojej stronie.
Phantom Watson

6
Miałem nadzieję, że ktoś o tym wspomni. Dostępność powinna być najwyższym priorytetem!
Andrew

Nie mogę powiedzieć, że zgadzam się z poglądem, że dostępność powinna być najwyższym priorytetem w działalności komercyjnej. Wskaźnik kosztów i korzyści jest niewykonalny. To jak umieszczenie rampy dla wózków inwalidzkich w sklepie wspinaczkowym - absurdalne marnotrawstwo zasobów, które można by wykorzystać na przedmioty o lepszym CBR. Jeśli mówisz o placówce medycznej, priorytetem będzie rampa dla wózków inwalidzkich. Podobnie zawracałbym sobie głowę dostępem do stron internetowych dla osób z upośledzeniem wzroku.
Peter Wone

54

Niestety, CSS Zen Garden nie może być dłużej używany jako przykład dobrego projektu HTML / CSS. Praktycznie wszystkie najnowsze projekty wykorzystują grafikę do nagłówków sekcji. Te pliki graficzne są określone w CSS.

W związku z tym strona internetowa, której celem jest wykazanie korzyści z utrzymywania projektu poza treścią, obecnie regularnie popełnia NIEZWYKŁANY GRZEWSTWO wprowadzenia treści do projektu. (Jeśli nagłówek sekcji w pliku HTML miałby się zmienić, wyświetlany nagłówek sekcji nie zmieniłby się).

Co tylko pokazuje, że nawet ci, którzy opowiadają się za ścisłą religią DIV i CSS, nie mogą przestrzegać własnych zasad. Możesz wykorzystać to jako wskazówkę, jak ściśle ich przestrzegasz.


18
Chcesz powiedzieć, że robią <h1>Some Text</h1>, a następnie w ich css: h1 { background-image('foo.jpg'); text-indent:-3000px }? Jest to poprawny sposób, ponieważ zachowujesz maksymalną ilość informacji semantycznych w html bez stylu. A może źle cię zrozumiałem.
Karan,

9
Karen ma rację, mylisz się, James. Twój przykład to słomkowy mężczyzna. Zapominanie o zmianie obrazu po zmianie semantycznego HTML byłoby głupie. Więc zostawia laptopa w autobusie. O co ci chodzi?
AmbroseChapel

36
@Ambrose: Ponieważ całym celem tej cholernej strony jest wykazanie oddzielenia treści i stylu. Treść i styl powinny być obsługiwane przez różne osoby, z których żadna z nich nie powinna „pamiętać” tego, co zmienili inni.
James Curran

5
Pan S&N: pogorszyłoby to sytuację. Będziesz musiał dynamicznie generować nowe obrazy - we właściwym stylu. Więc teraz przeniosłeś stylizację z CSS do kodu warstwy biznesowej.
James Curran

9
@James: Treści i styl nie zawsze mogą być obsługiwane przez różne osoby. Gdy treść jest stylizowana, musi nastąpić współpraca. Jak można <h1><img src="something.png"></h1>bardziej utrzymać niż <h1 class="something image">Something</h1>? W obu przypadkach coś.png wymaga aktualizacji. Ale drugi przykład jest znacznie bardziej dostępny.
Josh

48

W żadnym wypadku nie jest to ostateczny argument, ale dzięki CSS możesz wziąć ten sam znacznik i zmienić układ w zależności od medium, co jest niezłą zaletą. W przypadku strony do wydruku możesz cicho ukryć nawigację bez konieczności tworzenia na przykład strony do wydruku.


Dobrze, że można użyć css do ukrywania komórek w układzie opartym na tabeli, aby na przykład ukryć nawigację w wersji do wydruku, układ CSS zapewnia znacznie większą elastyczność za ukrywaniem danych.
Cory House

Uderzyłem to w jednej z moich aplikacji; chłopiec, byłem szczęśliwy, kiedy zdałem sobie sprawę, jak łatwo jest stworzyć wersję „przyjazną dla drukarki”, używając tylko wydruku CSS dla tych samych stron, które były na ekranie.
Lawrence Dol

45

Jeden stół do układu nie byłby taki zły. Ale nie możesz uzyskać potrzebnego układu tylko przy jednym stole. Wkrótce masz 2 lub 3 zagnieżdżone tabele. To staje się bardzo kłopotliwe.

  • O wiele trudniej jest czytać. To nie zależy od opinii. Jest tylko więcej zagnieżdżonych tagów bez oznaczeń identyfikujących.

  • Oddzielanie treści od prezentacji jest dobrą rzeczą, ponieważ pozwala skupić się na tym, co robisz. Mieszanie tych dwóch prowadzi do nadętych, trudnych do odczytania stron.

  • CSS dla stylów pozwala twojej przeglądarce buforować pliki, a kolejne żądania są znacznie szybsze. To jest ogromne.

  • Tabele zamykają cię w projekt. Jasne, nie każdy potrzebuje elastyczności Zen Garden CSS, ale nigdy nie pracowałem na stronie, na której nie musiałem tu i ówdzie trochę zmieniać projektu. Z CSS jest znacznie łatwiej.

  • Stoły są trudne do stylizacji. Nie masz z nimi zbyt dużej elastyczności (tzn. Nadal musisz dodać atrybuty HTML, aby w pełni kontrolować style tabeli)

Nie korzystałem z tabel dla danych nie tabelarycznych od prawdopodobnie 4 lat. Nie oglądałem się za siebie.

Naprawdę chciałbym zasugerować przeczytanie CSS Mastery autorstwa Andy'ego Budd'a. To jest fantastyczne.

Zdjęcie na ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


1
Mogę gorąco polecić tę książkę
Jacob T. Nielsen

Zawiera dobre przykłady modeli pudełkowych, selektorów i pozycjonowania.
KMån

36

Dobrze jest oddzielić zawartość od układu,
ale jest to błędny argument; Myślenie stereotypowe

To błędny argument, ponieważ tabele HTML mają układ! Treść to dane w tabeli, prezentacja to sama tabela. Dlatego oddzielenie CSS od HTML może być czasami bardzo trudne. Nie oddzielasz treści od prezentacji, oddzielasz prezentację od prezentacji! Stos zagnieżdżonych elementów div nie różni się od tabeli - to po prostu inny zestaw tagów.

Innym problemem związanym z oddzielaniem kodu HTML od CSS jest to, że potrzebują one wzajemnej znajomości - naprawdę nie można ich całkowicie oddzielić. Układ znaczników w kodzie HTML jest ściśle powiązany z plikiem CSS bez względu na to, co robisz.

Myślę, że tabele vs. div sprowadzają się do potrzeb twojej aplikacji.

W aplikacji, którą tworzymy w pracy, potrzebowaliśmy układu strony, w którym elementy dynamicznie dostosowywałyby się do swojej zawartości. Spędziłem dni próbując sprawić, by działało w różnych przeglądarkach z CSS i DIV i był to kompletny koszmar. Przeszliśmy do stolików i wszystko po prostu działało .

Mamy jednak bardzo zamkniętą grupę odbiorców naszego produktu (sprzedajemy sprzęt z interfejsem sieciowym), a problemy z dostępnością nie są dla nas problemem. Nie wiem, dlaczego czytniki ekranu nie radzą sobie dobrze z tabelami, ale chyba tak to jest, to programiści muszą sobie z tym poradzić.


6
screenreadery radzą sobie z tabelami ok. Problem polega na tym, że tabele nie radzą sobie z screenreaderami. Układ oparty na tabeli jest skłonny do przedstawiania informacji w sposób niedostępny. Zastanów się, jak wyglądałaby nawigacja po prawej stronie. Byłoby to dość daleko w dół strony.
erlando

Ok, to ma sens - dzięki!
17 z 26

8
Tylko dlatego, że <table> lub <div> mają domyślną prezentację w większości agentów ekranu, nie oznacza to, że są elementami prezentacji zamiast elementów semantycznych.
Mark Brackett,

1
Nie mówię konkretnie o HTML, mówię o koncepcyjnie w podstawowym projekcie interfejsu użytkownika. Tabela pokazuje, jak rzeczy są układane na ekranie, tj. Jak są prezentowane użytkownikowi. To jest prezentacja.
17 z 26

1
„Spędziłem dni próbując sprawić, by to zadziałało” - jeśli coś, co próbuję odkryć, zajmuje więcej niż kilka godzin, przekazuję to społeczności StackOverflow. Nie wiedząc, jak zrobić coś poprawnie, nie jest usprawiedliwieniem, aby nie robić tego poprawnie. Zwłaszcza, gdy mamy wszystkie odpowiedzi na wyciągnięcie ręki.
DaveDev,

23

CSS / DIV - to tylko praca dla projektantów, prawda? Setki godzin, które spędziłem na debugowaniu problemów DIV / CSS, przeszukiwaniu Internetu, aby uzyskać część znaczników podczas pracy z niejasną przeglądarką - doprowadza mnie to do szału. Dokonujesz jednej drobnej zmiany, a cały układ idzie strasznie źle - logika w tym jest zła. Spędzanie godzin na przenoszeniu czegoś o 3 piksele w ten sposób, a następnie o coś innego o 2 piksele w drugą stronę, aby je wszystkie wyrównać. Wydaje mi się to po prostu błędne. To, że jesteś purystą, a coś jest „niewłaściwe”, nie oznacza, że ​​powinieneś z niego korzystać w stopniu n-tym i we wszystkich okolicznościach, szczególnie jeśli to uczyni twoje życie 1000 razy łatwiejszym.

W końcu zdecydowałem, czysto komercyjnie, chociaż ograniczam się do minimum, jeśli spodziewam się 20 godzin pracy na poprawne umieszczenie DIV, pozostanę przy stole. To źle, denerwuje purystów, ale w większości przypadków kosztuje mniej czasu i jest tańszy w zarządzaniu. Następnie mogę skoncentrować się na tym, aby aplikacja działała tak, jak chce klient, zamiast zadowolić purystów. W końcu płacą rachunki, a mój argument skierowany do menedżera, który egzekwuje stosowanie CSS / DIV - chciałbym jedynie wskazać, że klienci płacą również jego pensję!

Jedynym powodem, dla którego występują wszystkie te argumenty CSS / DIV, jest przede wszystkim niedociągnięcie CSS i ponieważ przeglądarki nie są ze sobą kompatybilne, a gdyby tak było, połowa projektantów stron internetowych na świecie byłaby bez pracy .

Podczas projektowania formularza systemu Windows nie próbujesz przesuwać elementów sterujących po ich rozmieszczeniu, więc myślę, że to dziwne, dlaczego chcesz to zrobić za pomocą formularza internetowego. Po prostu nie rozumiem tej logiki. Ułóż układ od samego początku i na czym polega problem. Myślę, że to dlatego, że projektanci lubią flirtować z kreatywnością, podczas gdy twórcy aplikacji są bardziej zainteresowani faktycznym uruchomieniem aplikacji, tworzeniem obiektów biznesowych, wdrażaniem reguł biznesowych, sprawdzaniem, w jaki sposób fragmenty danych klientów odnoszą się do siebie, zapewniając, że rzecz spełnia klientów wymagania - wiesz - jak rzeczy z prawdziwego świata.

Nie zrozum mnie źle, oba argumenty są prawidłowe, ale proszę nie krytykuj programistów za wybranie łatwiejszego, bardziej logicznego podejścia do projektowania formularzy. Często musimy martwić się ważniejszymi kwestiami niż poprawna semantyka używania tabeli nad div.

Przypadek - na podstawie tej dyskusji przekonwertowałem kilka istniejących tds i trs na div. 45 minut bawiąc się tym, próbując ustawić wszystko obok siebie, a ja się poddałem. TD z powrotem w 10 sekund później - działa - od razu - we wszystkich przeglądarkach, nic więcej do roboty. Proszę, spróbuj mnie zrozumieć - jakie masz uzasadnienie, że chcesz, abym zrobił to w inny sposób!


Nie mogłem się bardziej zgodzić z tym postem. W ciągu 10 lat projektowania, nie potrafię wymyślić jednego momentu, w którym argument „używamy CSS, ponieważ ułatwia on zarządzanie zmianami na całej stronie” był tak trafny.
Daniel Szabo

6
wiesz, co ułatwia zarządzanie zmianami na całej stronie? MVC i systemy szablonów
Jiaaro

Nie zrozumcie mnie źle - nadal używam CSS, ale używam go do stosowania stylu (koloru, obrazów tła itp.), A nie układu. Wygląda na to, że CSS jest dość spójny w różnych przeglądarkach, gdy jest używany tylko do kontroli stylu. Jego wadą i dużym upadkiem jest sposób, w jaki układ jest zarówno określany, jak i wdrażany w przeglądarkach. Czy ktoś kiedykolwiek próbował sprawić, że ASP.NET MasterPages działa niezawodnie z DIV? To prawie niemożliwe!
Tim Black

21

Układ powinien być łatwy. Fakt, że w CSS napisano artykuły o tym, jak osiągnąć dynamiczny układ trzech kolumn z nagłówkiem i stopką, świadczy o tym, że jest to zły układ. Oczywiście możesz go uruchomić, ale istnieją dosłownie setki artykułów online o tym, jak to zrobić. Nie ma prawie żadnych takich artykułów dla podobnego układu z tabelami, ponieważ jest to oczywiste. Bez względu na to, co mówisz przeciwko tabelom i na korzyść CSS, ten jeden fakt odwraca to wszystko: podstawowy układ trzech kolumn w CSS jest często nazywany „Świętym Graalem”.

Jeśli to nie oznacza, że ​​mówisz „WTF”, to naprawdę musisz teraz odłożyć pomoc kool.

Uwielbiam CSS. Oferuje niesamowite opcje stylizacji i kilka fajnych narzędzi do pozycjonowania, ale jako silnik układu jest niewystarczający. Potrzebny jest jakiś rodzaj dynamicznego systemu pozycjonowania siatki. Prosty sposób na wyrównanie ramek na wielu osiach bez uprzedniej znajomości ich rozmiarów. Nie obchodzi mnie to, jeśli nazwiesz to <tabela> lub <gridlayout> czy cokolwiek innego, ale jest to podstawowa funkcja układu, której brakuje w CSS.

Większy problem polega na tym, że nie przyznając się do brakujących funkcji, fanatycy CSS powstrzymują CSS od wszystkiego, co mogłoby być. Byłbym bardzo szczęśliwy, mogąc przestać używać tabel, jeśli CSS zapewnia przyzwoite pozycjonowanie siatki w wielu osiach, jak w zasadzie każdy inny silnik układu na świecie. (Zdajesz sobie sprawę, że ten problem został już rozwiązany wiele razy w wielu językach przez wszystkich oprócz W3C, prawda? I nikt inny nie zaprzeczył, że taka funkcja była przydatna).

Westchnienie. Dość wentylacji. Śmiało i wbij głowę w piasek.


„Zealoci CSS” (jak to ująłeś) nie są nieświadomi tego faktu. Następna specyfikacja CSS zawiera nie tylko jedno, ale dwa rozwiązania problemów z układami w CSS. Układy szablonów: w3.org/TR/css3-layout i pozycjonowanie siatki: w3.org/TR/css3-grid To nie wprowadza konkurencyjnych specyfikacji. Te 2 specyfikacje faktycznie się uzupełniają. W chwili pisania tego komentarza żadna przeglądarka jeszcze go nie implementuje.
Dan Herbert

+1: całkowicie się zgadzam. Nie powinieneś „zmuszać go do działania” (chociaż nie lubię też tabel).
3lectrologos

To w 100% dokładnie to, co czuję. Chciałbym głosować na najwyższą odpowiedź.
bobwienholt

19

Zgodnie ze zgodnością 508 (w przypadku czytników ekranu dla osób niedowidzących) tabele powinny być używane wyłącznie do przechowywania danych, a nie do układu, ponieważ powoduje to dziwne zachowanie czytników ekranu. A przynajmniej tak mi powiedziano.

Jeśli przypiszesz nazwy do każdego z div, możesz je wszystkie skórować razem za pomocą CSS. To tylko trochę trudniej usiąść tak, jak potrzebujesz.


18

Oto sekcja html z ostatniego projektu:

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

A oto ten sam kod co układ oparty na tabeli.

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

Jedyną czystością, jaką widzę w tym układzie opartym na stole, jest to, że jestem nadgorliwy z powodu mojego wcięcia. Jestem pewien, że sekcja zawartości będzie miała jeszcze dwie osadzone tabele.

Kolejna rzecz do przemyślenia: rozmiary plików . Przekonałem się, że układy tabel są zwykle dwa razy większe niż ich odpowiedniki CSS. W naszym szybkim łączu szerokopasmowym nie jest to duży problem, ale dotyczy to modemów telefonicznych.


3
Szybkość nie jest jedyną rzeczą, która ucierpiała z powodu większych plików: wiele firm płaci za przepustowość. Jeśli możesz obniżyć rachunki za przepustowość klienta o połowę, po prostu dobrze kodując, to ogromna zaleta.
Mr. Shiny and New 安 宇

2
Tak, ale nie zapominaj, że chociaż HTML może być dwa razy większy w układzie bez CSS, użycie układu DIV + CSS spowoduje (przynajmniej) dodatkowe żądanie HTTP dla pliku CSS, a także użycie przepustowości dla sam plik.
goldenratio

12
Ale plik css należy pobrać tylko raz, ponieważ cała struktura tabeli jest wysyłana ponownie przy każdym żądaniu strony.
user151841,

3
Wybrałeś projekt dobrze dopasowany do div + css i pokazałeś, że jest bardziej szczegółowy w projekcie opartym na tabeli? Co z tego: równie łatwo byłoby stworzyć projekt, który byłby dobrze dopasowany do układu opartego na stole i pokazać obręcze, przez które trzeba będzie przejść, aby powielić go w CSS.
Draemon

4
@Draemon: Może chciałbyś podać przykład?
Bobby Jack

14

Chciałbym dodać, że układy oparte na div są łatwiejsze do zarządzania, ewolucji i refaktoryzacji. Tylko kilka zmian w CSS, aby zmienić kolejność elementów i gotowe. Z mojego doświadczenia wynika, że ​​przeprojektowanie układu wykorzystującego tabele to koszmar (więcej, jeśli istnieją tabele zagnieżdżone).

Twój kod ma również znaczenie z semantycznego punktu widzenia.


Moim marzeniem jest mieć projektanta graficznego, który bierze dostarczone przeze mnie obiekty / dane i umieszcza je na stronie bez konieczności dbania o CSS, DIV, TABLE ... :)
Manrico Corazzi

Po drugie, Manrico - projektant wizualny, który pozwoliłby ci zbudować układ i zdefiniować stałe i procentowe wymiary, a następnie wygenerować minimalny HTML i CSS byłby niezwykle użyteczny!
Richard Ev

Problem, który mam z koncepcją semantycznej sieci, polega na tym, że w HTML 4 słownictwo jest bardzo ograniczone i przeznaczone głównie dla dokumentów technicznych. Wiele witryn z celami komercyjnymi / marketingowymi może zawierać elementy, które nie pasują do tego słownictwa. HTML 5 naprawia niektóre z tych tagów, takich jak nav, nagłówek, stopka, ale na razie utknęliśmy przy użyciu tagów takich jak span, które w rzeczywistości mówią niewiele o tym, jak należy interpretować treść.
Nick Van Brunt

13

Żadne argumenty w DIV nie sprzyjają mi.

Powiedziałbym: jeśli but pasuje, noś go.

Warto zauważyć, że trudno jest, jeśli nie niemożliwe, znaleźć dobrą metodę renderowania zawartości DIV + CSS w dwóch lub trzech kolumnach, która jest spójna we wszystkich przeglądarkach i nadal wygląda tak, jak zamierzałem.

To trochę przesuwa równowagę w stronę tabel w większości moich układów i chociaż czuję się winny z ich używania (nie wiem dlaczego, ludzie po prostu mówią, że to źle, więc próbuję ich słuchać), w końcu pragmatyczny pogląd jest taki, że to po prostu łatwiej i szybciej korzystam z TABEL. Nie płacą mi godziny, więc stoliki są dla mnie tańsze.


1
jeśli chcesz stworzyć dwu- lub trzykolumnową stronę internetową z divs + css, która działa we wszystkich przeglądarkach, nie powinieneś zaczynać od zera. Istnieje wiele szablonów typu barebone dostępnych w Internecie, których można użyć jako podstawy. Są one zazwyczaj zoptymalizowane do prawidłowego wyświetlania we wszystkich przeglądarkach, tj. 6 +
arturh

13

Układy CSS są ogólnie o wiele lepsze pod względem dostępności, pod warunkiem, że treść jest w naturalnej kolejności i ma sens bez arkusza stylów. I nie tylko czytniki ekranu mają problemy z układami opartymi na tabelach: znacznie utrudniają również prawidłowe wyświetlanie strony przez przeglądarki mobilne.

Ponadto dzięki układowi opartemu na div możesz bardzo łatwo robić fajne rzeczy za pomocą arkusza stylów drukowania, takiego jak wykluczanie nagłówków, stopek i nawigacji z drukowanych stron - myślę, że byłoby to niemożliwe, a przynajmniej znacznie trudniejsze, aby to zrobić za pomocą układ oparty na tabeli.

Jeśli masz wątpliwości, że oddzielenie treści od układu jest łatwiejsze w przypadku div niż w tabelach, spójrz na HTML oparty na div w CSS Zen Garden , zobacz, jak zmiana arkuszy stylów może radykalnie zmienić układ i zastanów się, czy możesz osiągnąć taką samą różnorodność układów, jeśli HTML był oparty na tabeli ... Jeśli robisz układ oparty na tabeli, prawdopodobnie nie używasz CSS do kontrolowania wszystkich odstępów i wypełnienia w komórkach (jeśli tak, to prawie na pewno łatwiej będzie użyć pływających div itp.). Bez użycia CSS do kontrolowania tego wszystkiego, a także z uwagi na fakt, że tabele określają kolejność elementów od lewej do prawej i od góry do dołu w tabelach, tabele zwykle oznaczają, że układ bardzo się poprawia w HTML.

Realistycznie myślę, że bardzo trudno jest całkowicie zmienić układ projektu opartego na div i CSS bez zmiany div. Jednak dzięki układowi opartemu na div i CSS znacznie łatwiej jest dostroić takie rzeczy, jak odstępy między różnymi blokami i ich względne rozmiary.


13

Fakt, że jest to gorąco dyskutowane pytanie, świadczy o tym, że W3C nie przewidział różnorodności projektów układu, które byłyby podejmowane. Używanie divs + css do semantycznie przyjaznego układu jest świetną koncepcją, ale szczegóły implementacji są tak błędne, że faktycznie ograniczają swobodę twórczą.

Próbowałem zamienić jedną z witryn naszej firmy ze stolików na divy i było to tak bolesne, że całkowicie zmarnowałem godziny pracy, które w nie włożyłem i wróciłem do stolików. Próba zmagania się z moimi divami w celu uzyskania kontroli nad pionowym wyrównaniem przeklęła mnie głównymi problemami psychologicznymi, których nigdy nie będę się trząść, dopóki trwa ta debata.

Fakt, że ludzie często muszą wymyślać złożone i brzydkie obejścia, aby osiągnąć proste cele projektowe (takie jak wyrównanie pionowe), zdecydowanie sugeruje, że reguły nie są wystarczająco elastyczne. Jeśli specyfikacje są wystarczające, dlaczego witryny o wysokim profilu (takie jak SO) uważają za konieczne naginanie reguł za pomocą tabel i innych obejść?


12

Wydaje mi się, że to prawda, że ​​użycie elementu tabeli do układu ma niewiele wspólnego z danymi tabelarycznymi. Więc co? Czy mój szef się przejmuje? Czy obchodzą mnie użytkownicy?

Google i inne zautomatyzowane systemy zrobić opieki, i są one tak samo ważne w wielu sytuacjach. Kod semantyczny jest łatwiejszy do przeanalizowania i przetworzenia przez nie-inteligentny system.


Tak, na przykład dla blogów silnik oddziela komentarze od posta na blogu. Wyobraź sobie, że układ został stylizowany za pomocą tabel.
Omar Abid

2
-1: Google absolutnie nie obchodzi w najmniejszym stopniu, jeśli używasz tabel do układu.
Tom Anderson,

@Tom Anderson Nie dlatego, że mają problem z używaniem tabel do układu, ale po prostu dlatego, że nie-tabelowy HTML jest bardziej semantyczny.
ceejayoz

8

Musiałem współpracować ze stroną internetową, która obejmowała 6 warstw zagnieżdżonych tabel wygenerowanych przez jakąś aplikację, i po wygenerowaniu niepoprawnego HTML-a, w rzeczywistości było 3 godziny pracy, aby naprawić to zepsucie dla drobnej zmiany.

Jest to oczywiście przypadek na krawędzi, ale konstrukcja oparta na stole jest nie do utrzymania. Jeśli używasz css, rozdzielasz styl, więc przy naprawianiu HTML nie musisz się już martwić o złamanie.

Spróbuj również z JavaScript. Przenieś pojedynczą komórkę tabeli z jednego miejsca do innego miejsca w innym stole. Raczej skomplikowane wykonywanie tam, gdzie div / span działałoby po prostu kopiuj-wklej.

„Czy mój szef się przejmuje”

Gdybym był twoim szefem. Zależy ci na tym. ;) Jeśli cenisz swoje życie.


Musiałem współpracować ze stroną internetową, na której była ogromna zupa tagów span i div, i będąc świadkiem jej kruchości przy zmianie pojedynczego elementu,
zniszczyłaby

Korzystanie z Div's oczywiście nie czyni magicznie ładniejszym kodu. Wiele należy powiedzieć o odpowiednim semantycznym stosowaniu znaczników.
Kent Fredric,

7

Elastyczność układu
Wyobraź sobie, że tworzysz stronę z dużą liczbą miniatur.
DIV :
Jeśli umieścisz każdą miniaturę w DIV, uniesie się w lewo, może 10 z nich zmieści się w rzędzie. Uczyń okno węższym, a BAM - to 6 w rzędzie lub 2, lub jakkolwiek wiele pasuje.
TABELA:
Musisz wyraźnie powiedzieć, ile komórek jest w rzędzie. Jeśli okno jest zbyt wąskie, użytkownik musi przewijać w poziomie.

Konserwowalność Taka
sama sytuacja jak powyżej. Teraz chcesz dodać trzy miniatury do trzeciego rzędu.
DIV:
dodaj je. Układ dostosuje się automatycznie.
TABELA: Wklej nowe komórki do trzeciego rzędu. Ups! Teraz jest tam zbyt wiele przedmiotów. Wytnij trochę z tego rzędu i umieść je w czwartym rzędzie. Teraz jest tam zbyt wiele przedmiotów. Wytnij trochę z tego wiersza ... (itp.)
( Oczywiście, jeśli generujesz wiersze i komórki za pomocą skryptów po stronie serwera, prawdopodobnie nie będzie to problemem ).


7

Myślę, że ta łódź wypłynęła. Jeśli spojrzysz na kierunek, w którym podążyła branża, zauważysz, że CSS i otwarte standardy są zwycięzcami tej dyskusji. Co z kolei oznacza większość prac HTML, z wyjątkiem formularzy, projektanci użyją div zamiast tabel. Mam z tym problem, ponieważ nie jestem guru CSS, ale tak już jest.


5

Nie zapominaj też, że tabele nie wyświetlają się dobrze w przeglądarkach mobilnych. Jasne, iPhone ma przeglądarkę typu kick-ass, ale nie każdy ma iPhone'a. Renderowanie tabel może być orzeszkami ziemnymi w nowoczesnych przeglądarkach, ale jest to arbuz dla przeglądarek mobilnych.

Osobiście odkryłem, że wiele osób używa zbyt wielu <div>tagów, ale z umiarem może być wyjątkowo czyste i łatwe do odczytania. Wspominasz, że ludziom trudniej jest czytać CSS niż tabele; w kategoriach „kodu” to może być prawda; ale pod względem czytania treści (widok> źródło) jest o wiele łatwiej zrozumieć strukturę za pomocą arkuszy stylów niż tabel.


Dobrze, że tam masz; ale IMHO interfejs dla urządzeń mobilnych powinien być zupełnie inny, biorąc pod uwagę ograniczenia wejściowe.
Manrico Corazzi

Prawdziwe; dlatego czasami zacząłem stosować inne podejście. W modelu MVC mój widok wyskakuje tylko z surowych danych XML, tj. Z treści. Następnie zacznij od innego modelu MVC, w którym xml raw data = model; view = html / css; kontroler = xsl. Arkusz stylów XSL usuwa niepotrzebne dane z telefonu komórkowego.
Swati,

5

Wygląda na to, że jesteś przyzwyczajony do stołów i to wszystko. Umieszczenie układu w tabeli ogranicza Cię tylko do tego układu. Dzięki CSS możesz przenosić bity, spójrz na http://csszengarden.com/ I nie, układ zwykle nie wymaga wielu zagnieżdżonych div.

Bez tabel dla układu i właściwej semantyki HTML jest znacznie czystszy, a zatem łatwiejszy do odczytania. Dlaczego ktoś, kto nie rozumie CSS, powinien go przeczytać? A jeśli ktoś uważa się za programistę stron internetowych, konieczne jest dobre zrozumienie CSS.

Korzyści z SEO wynikają z możliwości umieszczania najważniejszych treści na górze strony i lepszego stosunku treści do znaczników.

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


5
  • 508 Zgodność - zdolność czytnika ekranu do zrozumienia znaczenia znaczników.
  • Oczekiwanie na renderowanie - tabele nie renderują się w przeglądarce, dopóki nie dojdzie do końca </table>elementu.

Pamiętam, jak wiele lat temu tworzyłem ogromne tabele w czasach wolniejszych komputerów i pamiętam, kiedy pojawił się kod, który powodował, że renderowały się one w miarę, jak się pojawiał. IE6? IE4? Nie pamiętam, ale na pewno się zmieniło. Oczywiście jest to przydatne w przypadku danych tabelarycznych, ale tabele układu są stylizowane na cal ich życia, więc być może renderowanie progresywne byłoby mniej przydatne, gdy tabela przeskakuje, aby pomieścić nowo załadowaną zawartość.
ijw

5

Cały pomysł wokół znaczników semantycznych polega na oddzieleniu znaczników i prezentacji, które obejmują układ.

Div nie zastępują tabel, mają swój własny użytek w rozdzielaniu treści na bloki powiązanych treści (,). Jeśli nie masz umiejętności i polegasz na tabelach, często będziesz musiał podzielić zawartość na komórki, aby uzyskać pożądany układ, ale nie będziesz musiał dotykać znaczników, aby uzyskać prezentację podczas korzystania ze znaczników semantycznych. Jest to naprawdę ważne, gdy generowane są znaczniki, a nie strony statyczne.

Programiści muszą przestać udostępniać znaczniki implikujące układ, aby ci z nas, którzy mają umiejętności prezentowania treści, mogli zająć się naszymi zadaniami, a programiści nie muszą wracać do kodu, aby wprowadzać zmiany, gdy konieczna jest zmiana prezentacji.


4

Tak naprawdę nie chodzi o to, czy „div są lepsze niż tabele do układu”. Ktoś, kto rozumie CSS, może powielić dowolny projekt za pomocą „tabel układu” całkiem prosto. Prawdziwą wygraną jest użycie elementów HTML do tego, do czego służą. Powodem, dla którego nie korzystasz z tabel dla danych niepostosowanych do tablic, jest ten sam powód, dla którego nie przechowujesz liczb całkowitych jako ciągów znaków - technologia działa o wiele łatwiej, gdy używasz jej do celu, dla którego jest przeznaczona. Jeśli kiedykolwiek konieczne było użycie tabel do układu (z powodu niedociągnięć przeglądarki na początku lat 90.), z pewnością nie jest to teraz.


3

Narzędzia korzystające z układów tabel mogą stać się wyjątkowo ciężkie z powodu ilości kodu wymaganego do utworzenia układu. SAP Netweaver Portal domyślnie używa TABELI do układania swoich stron.

Produkcyjny portal SAP na moim obecnym koncercie ma stronę główną, której HTML waży ponad 60 KB i ma głębokość siedmiu tabel, trzy razy na stronie. Dodaj Javascript, niewłaściwe użycie 16 ramek iframe z podobnymi problemami z tabelami, nadmiernie duży CSS itp., A strona waży ponad 5 MB.

Warto poświęcić czas na zmniejszenie wagi strony, abyś mógł wykorzystać swoje pasmo do angażowania użytkowników w działania.


3

Warto wymyślić CSS i div, aby środkowa kolumna treści ładowała się i renderowała przed paskiem bocznym w układzie strony. Ale jeśli masz problem z użyciem pływających elementów div do pionowego wyrównania logo z tekstem sponsora, po prostu skorzystaj ze stołu i idź dalej z życiem. Religia ogrodowa Zen po prostu nie daje wielkiego zysku.

Ideą oddzielenia treści od prezentacji jest podział aplikacji na partycje, aby różne rodzaje pracy wpływały na różne bloki kodu. W rzeczywistości chodzi o zarządzanie zmianami. Jednak standardy kodowania mogą jedynie badać obecny stan kodu w sposób powierzchowny.

Dziennik zmian aplikacji zależnej od standardów kodowania w celu „oddzielenia treści od prezentacji” pokaże wzór równoległych zmian w silosach pionowych. Jeśli zmianie „treści” zawsze towarzyszy zmiana „prezentacji”, jak skuteczne jest dzielenie na partycje?

Jeśli naprawdę chcesz produktywnie podzielić swój kod na partycje, użyj Subversion i przejrzyj swoje dzienniki zmian. Następnie użyj najprostszych technik kodowania - div, tabele, JavaScript, obejmuje, funkcje, obiekty, kontynuacje, cokolwiek - aby ustrukturyzować aplikację, aby zmiany pasowały w prosty i wygodny sposób.


+1 dla pierwszych dwóch zdań.
Sean McMillan

3

Ponieważ utrzymywanie witryny korzystającej z tabel jest PIEKŁO, a kodowanie zajmuje dużo czasu. Jeśli boisz się pływających div, idź na nich. Nie są trudne do zrozumienia i są około 100 razy bardziej wydajne i milion razy mniej boli w dupie (chyba że ich nie rozumiesz - ale hej, witaj w świecie komputerów).

Każdy, kto zastanawia się nad układem ze stołem, lepiej nie oczekuje, że go utrzymam. Jest to najbardziej zwrotny sposób renderowania strony internetowej. Dzięki Bogu mamy teraz znacznie lepszą alternatywę. NIGDY nie wrócę.

To przerażające, że niektórzy ludzie mogą nie być świadomi korzyści czasu i energii wynikających z tworzenia witryny przy użyciu nowoczesnych narzędzi.


3

Tabele nie są na ogół łatwiejsze ani łatwiejsze w utrzymaniu niż CSS. Istnieje jednak kilka specyficznych problemów z układem, w których tabele są rzeczywiście najprostszym i najbardziej elastycznym rozwiązaniem.

CSS jest wyraźnie preferowany w przypadkach, gdy znaczniki prezentacji i CSS obsługują ten sam projekt, nikt przy zdrowych zmysłach nie argumentowałby, że font-tagi są lepsze niż określanie typografii w CSS, ponieważ CSS daje taką samą moc niż font-tagi, ale w znacznie czystszy sposób.

Problem z tabelami polega jednak na tym, że model układu tabeli w CSS nie jest obsługiwany w przeglądarce Microsoft Internet Explorer. Tabele i CSS są zatem nie równowartość w mocy. Brakująca część to siatkowe zachowanie tabel, w których krawędzie komórek są wyrównane zarówno w pionie, jak iw poziomie, podczas gdy komórki nadal się rozszerzają, aby zawierać ich zawartość. To zachowanie nie jest łatwe do osiągnięcia w czystym CSS bez twardego kodowania niektórych wymiarów, co czyni projekt sztywnym i kruchym (o ile musimy obsługiwać Internet Explorera - w innych przeglądarkach można to łatwo osiągnąć za pomocą display:table-cell).

Tak więc tak naprawdę nie chodzi o to, czy tabele lub CSS są preferowane, ale chodzi o rozpoznanie konkretnych przypadków, w których użycie tabel może uczynić układ bardziej elastycznym.

Najważniejszym powodem nieużywania tabel jest dostępność. Wytyczne dotyczące dostępności treści internetowych http://www.w3.org/TR/WCAG10/ radzą ponownie, używając tabel do rozmieszczenia. Jeśli obawiasz się o dostępność (a w niektórych przypadkach możesz być prawnie zobowiązany), powinieneś używać CSS, nawet jeśli tabele są prostsze. Pamiętaj, że zawsze możesz stworzyć ten sam układ za pomocą CSS jak w przypadku tabel, może to wymagać więcej pracy.


3

Byłem zaskoczony, widząc, że niektóre problemy nie zostały jeszcze omówione, więc oto moje 2 centy, oprócz wszystkich bardzo ważnych punktów wcześniej:

.1. CSS i SEO:

a) CSS miał bardzo znaczący wpływ na SEO, umożliwiając pozycjonowanie treści na stronie, gdziekolwiek chcesz. Kilka lat temu wyszukiwarki kładły duży nacisk na czynniki „na stronie”. Coś na górze strony uznano za bardziej odpowiednie dla strony niż coś na dole. „Góra strony” dla pająka oznaczało „na początku kodu”. Za pomocą CSS możesz uporządkować treści bogate w słowa kluczowe na początku kodu i nadal umieszczać je w dowolnym miejscu na stronie. Jest to nadal dość istotne, ale czynniki na stronie są coraz mniej ważne dla rankingu strony.

b) Po przeniesieniu układu do CSS strona HTML jest jaśniejsza i dlatego ładuje się szybciej dla pająka wyszukiwarki. (pająki nie przejmują się pobieraniem zewnętrznych plików css). Szybkie ładowanie stron jest ważnym czynnikiem uwzględniającym ranking wielu wyszukiwarek, w tym Google

c) Praca SEO często wymaga testowania i zmiany rzeczy, co jest znacznie wygodniejsze w przypadku układu opartego na CSS

.2. Wygenerowana treść:

Tabela jest znacznie łatwiejsza do wygenerowania programowego niż równoważny układ CSS.

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

Generowanie tabeli jest proste i bezpieczne. Jest samodzielny i dobrze integruje się z dowolnym szablonem. Zrobić to samo z CSS jest znacznie trudniejsze i może w ogóle nie przynieść korzyści: trudno edytować arkusz stylów CSS podczas lotu, a dodanie wbudowanego stylu nie różni się od używania tabeli (treść nie jest oddzielona od układu).

Ponadto, gdy tabela jest generowana, zawartość (w zmiennych) jest już oddzielona od układu (w kodzie), co ułatwia modyfikację.

Jest to jeden z powodów, dla których niektóre bardzo dobrze zaprojektowane strony internetowe (na przykład SO) nadal używają układów tabel.

Oczywiście, jeśli wyniki muszą zostać przetworzone za pomocą JavaScript, div są warte kłopotu.

.3 Szybkie testowanie konwersji

Kiedy zastanawiasz się, co działa dla określonej grupy odbiorców, przydatna jest możliwość zmiany układu na różne sposoby, aby dowiedzieć się, co daje najlepsze wyniki. Układ oparty na CSS znacznie ułatwia

.4. Różne rozwiązania różnych problemów

Tabele układów są zwykle zbędne, ponieważ „wszyscy wiedzą, że div i CSS” są właściwą drogą.

Jednak faktem jest, że tworzenie tabel jest szybsze, łatwiejsze do zrozumienia i bardziej niezawodne niż większość układów CSS. (Tak, CSS może być równie niezawodny, ale szybki przegląd sieci w różnych przeglądarkach i rozdzielczościach ekranu pokazuje, że nie jest to często przypadek)

Stoły mają wiele wad, w tym konserwację, brak elastyczności ... ale nie wlewajmy dziecka z kąpielą. Istnieje wiele profesjonalnych zastosowań rozwiązania, które jest zarówno szybkie, jak i niezawodne.

Jakiś czas temu musiałem przepisać czysty i prosty układ CSS za pomocą tabel, ponieważ znaczna część użytkowników używałaby starszej wersji IE z naprawdę słabą obsługą CSS

Ja, na przykład, mam już dość szarpniętej kolanem reakcji „O nie! Tabele do układu!”

Jeśli chodzi o „tłum nie był przeznaczony do tego celu i dlatego nie należy go używać w ten sposób”, czy to nie hipokryzja? Co sądzisz o wszystkich sztuczkach CSS, których musisz użyć, aby ta cholerna rzecz działała w większości przeglądarek? Czy były przeznaczone do tego celu?

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.