Dlaczego ludzie robią tabele z divami?


269

We współczesnym tworzeniu stron internetowych coraz częściej spotykam się z tym wzorcem. To wygląda tak:

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

A w CSS jest coś takiego:

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

* (Nazwa klasy ma jedynie charakter poglądowy; w rzeczywistości są to normalne nazwy klas odzwierciedlające to, o czym jest element)

Nawet ostatnio próbowałem to zrobić sam, ponieważ ... no wiesz, wszyscy to robią.

Ale wciąż tego nie rozumiem. Dlaczego to robimy? Jeśli potrzebujesz stolika, po prostu zrób coś wielkiego <table>i gotowe. Tak, nawet jeśli chodzi o układ. Do tego służą tabele - układanie rzeczy w formie tabelarycznej.

Najlepszym wyjaśnieniem, jakie mam, jest to, że do tej pory wszyscy słyszeli mantrę „nie używaj tabel do układania”, więc postępują zgodnie z nią na ślepo. Ale nadal potrzebują tabeli do układu (ponieważ nic więcej nie ma możliwości rozszerzania tabeli), więc tworzą <div>(ponieważ to nie jest tabela!), A następnie dodają CSS, który czyni ją tabelą.

Dla całego świata wygląda mi to na stawianie arbitralnych niepotrzebnych przeszkód na twojej drodze, a następnie wykonywanie dodatkowej pracy, aby je ominąć.

Pierwotny argument przemawiający za odejściem od tabel dla układu był taki, że później trudno jest zmienić układ tabelaryczny. Ale modyfikacja układu „faux-table” jest równie trudna i z tych samych powodów. W rzeczywistości modyfikowanie układu jest zawsze trudne i prawie nigdy nie wystarczy po prostu zmienić CSS, jeśli chcesz zrobić coś poważniejszego niż drobne poprawki. Ci będzie potrzebne, aby zrozumieć i zmienić strukturę HTML do poważnych zmian projektowych. A tabele nie sprawiają, że praca jest trudniejsza lub łatwiejsza niż div.

W rzeczywistości, jedynym sposobem, widzę, że tabele mógłby zrobić układ trudny do modyfikowania, to jeśli ab wykorzystywali je i stworzył bezbożnego bałagan. Możesz to zrobić również za pomocą div.

Więc ... próbując zmienić to z rantu w spójne pytanie: czego mi brakuje? Jakie są rzeczywiste zalety używania „faux-table” w porównaniu z prawdziwym?

Informacje o duplikacie linku: To nie jest sugestia użycia innego tagu lub czegoś takiego. Jest to pytanie o użyciu <table>VS display:table.


6
@JuhaUntinen: to ... brzmi mało prawdopodobne. Źródło?
Paul D. Waite,

5
@ PaulD.Waite - Wydaje mi się, że to nadal prawda. Przeczytaj pozostałe odpowiedzi. O ile nie ma tej tabeli table-layout:fixed, konieczne będzie jej całkowite załadowanie, zanim będzie można ją wyświetlić. W przypadku nowoczesnych łączy szerokopasmowych efekt ten jest po prostu mniej zauważalny.
Vilx-

4
@JuhaUntinen: To nie do końca dokładne. Silnik renderowania tabel działał wolniej, gdy używałeś wartości procentowych dla szerokości kolumn, ponieważ cała tabela musiała zostać pobrana, zanim przeglądarka mogła zacząć ustalać, jak duży jest wszystko. To było zbyt skomplikowane przez zagnieżdżone tabele. Jednak istniały (i nadal istnieją) sposoby na szybsze renderowanie FAR FAR. Tylko nieliczni deweloperzy starają się wystarczająco dobrze nauczyć swojego rzemiosła i zamiast tego wskakują na bandwagon.
NotMe

4
W dawnych czasach zwykliśmy naśladować div z tabelami, więc tam.
Wyatt Barnett

4
Ktoś przeczytał, że nie powinni używać tabel do rozmieszczenia i uznał, że w ogóle nie powinni używać tabel. Nie znoszę tego trendu.
Casey

Odpowiedzi:


120

Jest to powszechny wzorzec tworzenia responsywnych tabel. Dane tabelaryczne są trudne do wyświetlenia na telefonach komórkowych, ponieważ strona zostanie albo powiększona, aby czytać tekst, co oznacza, że ​​tabele wychodzą z boku strony, a użytkownik musi przewijać w tył i w przód, aby przeczytać tabelę, lub strona zostanie pomniejszona , co zwykle oznacza, że ​​tabela jest zbyt mała, aby można ją było odczytać.

Elastyczne tabele zmieniają układ na mniejszych ekranach - czasami niektóre kolumny są ukryte lub kolumny są połączone, np. Imię i adres e-mail mogą być oddzielne na dużych ekranach, ale zwinięte w jedną komórkę na małych ekranach, aby informacje były czytelne bez konieczności przewijania.

<div>s są używane do tworzenia tabel zamiast <table>znaczników z kilku powodów. Jeśli <table>używane są tagi, musisz nadpisać domyślne style i układ przeglądarki przed dodaniem własnego kodu, więc w tym przypadku <div>tagi oszczędzają na wielu płytkach CSS. Ponadto starsze wersje IE nie pozwalają na przesłonięcie domyślnych stylów tabel, więc użycie <div>s również usprawnia rozwój w różnych przeglądarkach.

W CSS-Tricks jest całkiem dobry przegląd responsywnych tabel .

Edycja: Powinienem zaznaczyć, że nie popieram tego wzorca - wpada w pułapkę divitis i nie jest semantyczny - ale właśnie dlatego znajdziesz tabele wykonane z divs.


6
Akceptuję tę odpowiedź, ponieważ wydaje się, że nic więcej już się nie przyda. Są głosowane wyżej odpowiedzi, ale w zasadzie mówią „bo semantyka” (a jedynym powodem, dla którego semantyka mogą one zapewnić, są czytniki ekranu, co mnie nie przekonuje). @ Odpowiedź HorusKola wspomniała o twojej reakcji, ale twoja jest bardziej istotna. Jeśli w przyszłości pojawi się lepsza odpowiedź, zmienię ją na akceptowaną.
Vilx-

5
To jest śmieszne i leniwe. Wszystko, co robisz z <div>„tabelami”, można prawdopodobnie zrobić przy użyciu zwykłych, więc dosłownie nie ma powodu (poza starymi wersjami IE i lenistwem) do używania elementów nie-semantycznych do budowania tabel. To powiedziawszy, rzeczywiste dane tabelaryczne wydają się rzadkie w Internecie, więc może to nie jest problem.
Ty

1
@Vilx: Pytanie, które postawiłeś, brzmi: „Dlaczego ludzie robią tabele z divami”, na co otrzymujesz odpowiedzi. Na przykład możesz nie dbać o czytniki ekranu, ale to nie zmienia faktu, że dostępność jest poważnym problemem dla wielu i (wraz z wyszukiwarkami) głównym powodem, dla którego wiele osób wybiera semantyczny HTML.
JacquesB

13
Wbrew wszystkim celom i celom jest to po prostu źle. Jeśli dane są tabelaryczne, trafiają do tabeli. Twierdzenie, że tabele zachowują się szczególnie źle na urządzeniu mobilnym, to BS. Możesz równie łatwo zmienić właściwości wyświetlania elementów tabeli na wartości inne niż tabelowe, jak możesz sprawić, że elementy nie będące tabelami mają wartości tabel.
cimmanon

8
Uważam, że ta odpowiedź jest nieco myląca. Responsywne tabele to dobry projekt, ale nie zależy od pytania, czy powinieneś użyć <table> czy <div> - możesz użyć tego samego efektu wizualnego. Rzeczywiście, jest to sedno idei oddzielenia struktury i prezentacji. Prawdą jest, że starsze wersje IE nie pozwalały na przesłonięcie stylu tabeli, ale starsze wersje IE również nie obsługiwały display: table, więc nie można było używać tabel responsywnych w żaden sposób.
JacquesB

153

Pytanie brzmi, czy dane są semantycznie tabelą (tj. Zestawem danych lub jednostkami informacji logicznie zorganizowanymi w dwóch wymiarach), czy po prostu używasz siatki do wizualnego układu, np. Dlatego, że chcesz rozwinąć pasek boczny lub coś w tym rodzaju.

Jeśli twoja informacja jest semantycznie tabelą, używasz <table>-tag. Jeśli chcesz siatkę do celów układu, użyj innych odpowiednich elementów HTML i użyj jej display:tablew arkuszu stylów.

Kiedy dane semantycznie są tabelą? Gdy dane są logicznie zorganizowane wzdłuż dwóch osi. Jeśli ma to sens w przypadku nagłówków wierszy lub kolumn, możesz mieć tabelę semantyczną. Przykładem czegoś, co nie jest semantycznie tabelą, jest prezentowanie tekstu w kolumnach jak w gazecie. To nie jest semantycznie tabela, ponieważ nadal czytalibyśmy ją liniowo i żadne znaczenie nie zostałoby utracone, gdyby prezentacja została usunięta.


OK, dlaczego nie użyć <table>do wszystkiego, a nie tylko do czegoś, co jest semantycznie tabelą? Wizualnie jest oczywiście taki sam (ponieważ element tabeli ma po prostu display:elementdomyślny arkusz stylów).

Różnica polega na tym, że informacje semantyczne mogą pomóc alternatywnym aplikacjom użytkowników. Na przykład czytnik ekranu może umożliwiać nawigację w tabeli w dwóch wymiarach i czytać nagłówki komórki dla obu osi, jeśli zapomnisz, gdzie jesteś. Byłoby to mylące, gdyby stół nie był semantycznie stołem, ale służył tylko do wizualnego układu.

<table>Kontra display:tabledyskusja jest tylko przypadkiem bardziej ogólnej zasady korzystania semantycznych znaczników. Zobacz na przykład: Dlaczego ktoś miałby zawracać sobie głowę oznaczaniem poprawnie i semantycznie? lub Dlaczego znaczniki semantyczne mają większą wagę dla wyszukiwarek?

W niektórych miejscach może być prawnie wymagane użycie znaczników semantycznych ze względu na dostępność, aw każdym razie nie ma powodu, aby celowo zmniejszać dostępność strony.

Nawet jeśli nie troszczysz się o niepełnosprawnych użytkowników, prezentacja niezależna od treści daje korzyści. Na przykład układ trzech kolumn można przedstawić w pojedynczych kolumnach na telefonie komórkowym za pomocą alternatywnego arkusza stylów.


14
@ Vilx- dlaczego używać <em>i <strong>zamiast <b>a <i>? Ponieważ <b>i <i>nie dotyczą semantyki znacznika. <table>ma znaczenie semantyczne . Używanie go do czegoś, co nie jest tabelą, utrudnia zrozumienie semantycznego znaczenia dokumentu.

22
@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. Umieszczenie <i>wokół najlepiej byłoby źle, bo to oznacza coś innego niż <i>po tytule książki. Aby uzyskać więcej informacji, zobacz Dlaczego tagi <b>i są <i>przestarzałe? i Jaka jest różnica między <b>i <strong>, <i>a <em>?

19
Jeśli nie obchodzi Cię, co oznaczają Twoje treści, zdecydowanie zalecamy zaprzestanie używania jakichkolwiek elementów oprócz formularzy i div. Wystarczy dodać klasy, aby zastosować styl i zachowanie.
Rich Remer

9
@ Vilx-: Kiedy mówisz, że zależy ci na zadowoleniu użytkowników, wydaje się, że masz na myśli tylko ich podzbiór. Głównym powodem prawidłowego używania znaczników w opisywanym przez Ciebie sposobie jest dostępność, która bezpośrednio odnosi się do wrażeń użytkowników niepełnosprawnych. Są ludzie, którzy czerpią korzyści z tego, że robisz to, co robisz we właściwy sposób, a ignorowanie tych konwencji oznacza prawdopodobnie utrudnienie korzystania z Internetu.
rooby

31
@ Vilx - tak, czytnik ekranu traktuje <tabela> bardzo inaczej niż <div>. <div> są najczęściej ignorowane i odczytywane sekwencyjnie. Wewnątrz <tabela> musi zapewniać różne klawisze / polecenia nawigacyjne („Przejdź do komórki w prawo”, „Odczytaj tytuł kolumny i wiersza” itd.) Oraz wypowiada różne informacje o lokalizacji (gdy strumień odczytu wchodzi do tabeli idzie coś w stylu „Tabela 3, wiersz 1 kolumna 1, Lorem Ipsum dolor ... ”)
Euro Micelli

102

Właściwie powiedziałbym, że użycie nazw klas takich jak „table” w twoim przykładzie pokazuje, jak ludzie nie rozumieją, co robią, kiedy próbują znaczników semantycznych. Dostają oceny za próbę wykazania, że treść nie jest danymi tabelarycznymi , ale tracą oceny za złe nazwy klas.

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

Wszystko, co zrobił ten programista, to replikacja oryginalnego <table>znacznika przy użyciu nazw klas CSS. Oznacza to, że gdy tylko ten układ nie jest tabelą, nazwy klas są sprzeczne.

To, co ten programista powinien zrobić, to zastanowić się, jakie informacje są w tabeli - czy jest to galeria miniatur? No więc:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Teraz mogę stworzyć adaptacyjny CSS:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Dlaczego div, a nie tabele

Tabela zawiera dane tabelaryczne - prezentacja tabeli jest nierozerwalnie związana ze strukturą tabeli. Dane tabelaryczne zawsze będą musiały mieć formę tabelaryczną, bez względu na to, gdzie umieścisz tę treść lub na jakim ekranie / urządzeniu chcesz ją wyświetlić.

Galeria miniaturek (lub wiele innych rzeczy, takich jak formularz rejestracyjny, menu itp.) Nie jest danymi tabelarycznymi. W niektórych układach projektowych może być prezentowany jak tabela, ale w innych przypadkach, takich jak wąskie ekrany telefonu, chcesz go używać przy użyciu bardziej tradycyjnych układów bloków. A może chcesz wyświetlać miniatury na pasku bocznym zamiast w głównym obszarze zawartości.

Twoim wyborem jest teraz wyświetlanie różnych znaczników dla zawartości szerokiego ekranu (tabele) i paska bocznego lub zawartości wąskiego ekranu (div) - co oznacza, że ​​skrypty po stronie serwera będą musiały wiedzieć, dokąd zmierza treść, jeśli budujesz to programowo - lub twój skrypt po stronie serwera wyświetla ten sam znacznik (ponieważ nie powinno to mieć znaczenia, gdzie to umieszczasz) i używasz różnych reguł CSS dla różnych sytuacji.

Masz więc wybór, zawsze wypisując tabele, a następnie nadpisując naturalne reguły wyświetlania tabel za pomocą bloku (który naprawdę powinien szlifować niektóre biegi w głowie każdego programisty), lub wybierając dobrze oznaczone divy, które pozwalają na bardziej elastyczne podejście do stylizacji.

A najlepszymi praktykami od kilku lat jest unikanie tabel, gdy nie trzeba przedstawiać danych tabelarycznych.


Nazwy klas były właściwie tylko przykładem. W prawdziwym życiu są one zazwyczaj odpowiednio opisowe. W każdym razie, w twoim przykładzie, dlaczego używasz <div>zamiast <table>? Jakie oferuje to korzyści?
Vilx

1
Hmm ... cóż, w twoim przypadku robisz dwie różne reprezentacje tego samego HTML za pomocą zapytań o media. OK, to dobry przypadek użycia. Ale gdyby tak nie było i wcześniej wiedziałbyś, że ta galeria miniaturek będzie wyświetlana tylko w jednym miejscu i tylko w formacie tabelarycznym - użyjesz <table>wtedy, czy nadal display:table? Ponieważ, dobrze, w pewnym sensie to jest danych tabelarycznych. Tyle że „dane” to zdjęcia, ale nadal.
Vilx

15
cóż, nie, to nie są dane tabelaryczne. przedstawiasz go w siatce przypominającej stół. Dane tabelaryczne to statystyki i informacje porównawcze - myśl jak arkusz kalkulacyjny. Czy powiedziałbyś, że widok miniatur w eksploratorze plików Windows to dane tabelaryczne? I czy zawsze będzie to prezentowane jak stół? Co jeśli chcesz inny styl widoku za 6 lub 12 miesięcy? Po co nakładać ograniczenia, które mają długofalowe skutki, ponieważ upierają się w obliczu powszechnie przyjętej praktyki?
HorusKol

12
Tyle że wcale nie są to dane tabelaryczne. Nie ma innego powodu niż arbitralna decyzja dotycząca układu, że ta treść przypomina tabelę. To nie są uporządkowane dane w kolumnach i wierszach, to lista treści ułożona w siatkę. - edycja: Co powiedział HorusKol.
Eric King

3
Cóż, OK, to trochę rozciągało. :) Cóż, dałeś mi coś do przemyślenia! Dziękuję za to! Nadal nie jestem w 100% przekonany, ale przynajmniej jest to coś, co można kontynuować. :)
Vilx-

11

W dawnych czasach silnik renderowania tabeli „ pojawiał się ” wolniej, gdy używałeś wartości procentowych dla szerokości kolumn. Silnik w zasadzie musiał pobrać cały zestaw danych, zanim zaczął zastanawiać się, jak duże jest wszystko, aby narysować go na ekranie.

Silnik DIV był inny. Gdy przeglądarka napotka DIV, umieści go i zacznie wypełniać zawartość bezpośrednio. Oczywiście div może przeskakiwać, gdy dane są ładowane. Dlatego pojawiłem się w cytatach powyżej. Ramy czasowe ukończenia obu były takie same, jednak tabele nie były rysowane do końca, co oznaczało, że użytkownik nie był pewien, czy się ładuje, czy nie przez sekundę lub dwie.

Sytuacja pogorszyła się wraz z zagnieżdżeniem tabel.

Istniały wtedy (i nadal istnieją) sposoby na szybsze renderowanie FAR FAR. Zasadniczo, dając wskazówkę, że rozmiary kolumn się nie zmieniają, przeglądarka natychmiast zaczyna renderować dane tabelaryczne. Ostatecznie oznacza to, że tabele mogą faktycznie wyświetlać się w prawidłowej pozycji szybciej niż div, dzięki czemu wyglądają lepiej.

Ale to nie jest cała historia. Reszta jest taka, że ​​większość deweloperów po prostu nie zadaje sobie trudu, aby nauczyć się swojego rzemiosła wystarczająco dobrze, aby o tym wiedzieć. Zamiast tego wskakują na różne bandwagony i używają kodu, z którego mogą kopiować / wklejać. Nawet dzisiaj stwierdzam, że bardzo niewielu twórców stron internetowych zna różnicę między poszczególnymi typami dokumentów - i jest to główny powód, dla którego różne witryny mają różnego rodzaju obejścia obejmujące różne przeglądarki.

Daj więc +1 do zadania pytania.


Offtopic o DOCTYPE: Pomyślałem, że chociaż istnieje teoretyczna różnica (i weryfikatorzy potraktowali ją poważnie), w praktyce przeglądarki tak naprawdę nie rozróżniały między nimi. OK, być może były niewielkie zmiany między smakami HTML / XHTML, ale wersja i informacje DTD przynajmniej nie zostały użyte. Właśnie dlatego HTML5 zrezygnował z tego i poszedł z właśnie <!DOCTYPE html>i dlatego działa nawet w starych przeglądarkach, takich jak IE6. Czy coś przeoczyłem?
Vilx-

2
@Vilx: Doctype wprowadza przeglądarkę w określony tryb. Między innymi określa używany model pudełkowy. W przypadku wielu typów dokumentów przeglądarki nie były w jednej linii, ponieważ zastosowany model pudełkowy był inny. Dlatego tak wielu programistów narzekało, że przeglądarki wyświetlały strony inaczej i zamiast naprawiać doctype, używały ogromnych arkuszy resetowania css. Było jednak kilka rodzajów dokumentów, w których wszystkie przeglądarki korzystały z tego samego modelu pudełkowego - ale nigdy nie były to domyślne ustawienia, trzeba je było znać.
NotMe,

@vilx: html 5 nie upuścił całości. Zamiast tego dodano nowy doctype. Chodzi o to, że pierwsza linia, która pojawia się na górze dokumentu HTML, jest krytyczna, a jeśli nie rozumiesz, co robi i jak reagują na nią różne przeglądarki, poświęcisz zbyt dużo czasu na zastanawianie się, dlaczego układ jest „uszkodzony” w określonej przeglądarce.
NotMe,

Czekaj, więc tam różne doctypes które sprawiają, że ten sam dokument czyni inaczej? Które? Pamiętaj, że mówię o różnych typach dokumentów, a nie o typie dokumentu a brakie typu dokumentu (inaczej tryb quirksmode).
Vilx-

@Vilx: Jest to nieco bardziej skomplikowane, ponieważ niektóre typy dokumentów wywołują tryb dziwactw (taki sam jak bez doctype), a niektóre inne typy dokumentów (w tym html5 doctype) uruchamiają tryb standardów, a nawet niektóre typy dokumentów wywołują trzeci „prawie standardowy” ”w niektórych przeglądarkach.
JacquesB

5

Jeśli uda mi się tutaj uzyskać trochę „meta”, przychodzą mi na myśl dwa problemy:

Po pierwsze: ktoś proponuje regułę z jakiegoś dobrego powodu, a ludzie całkowicie nie rozumieją sensu, przestrzegając technicznej litery reguły, ignorując ducha. Znajdują sposób, aby osiągnąć wszystkie złe rzeczy, którym reguła próbowała zapobiec, a jednocześnie technicznie przestrzegać reguły w brzmieniu.

Po drugie: ktoś widzi problem i proponuje regułę, aby temu zapobiec. Inni widzą wartość tej reguły. Następnie nalegają na ślepe poświęcenie się tej zasadzie bez względu na pierwotny problem, który miał rozwiązać i / lub niezależnie od tego, jakie inne problemy stwarza. Przeprowadziłem wiele rozmów, w których ktoś mówi: „Musisz zrobić X, bo taka jest reguła”, a potem pytam: „Ale dlaczego powinniśmy robić X?”, A oni patrzą na mnie z zaskoczeniem i rozdrażnieniem i mówią: „Ale Właśnie ci powiedziałem! Bo to reguła! ” Odpowiadam: „Ale wydaje się, że powoduje więcej problemów niż rozwiązuje. Myślę, że lepiej byłoby zrobić Y.” A potem osoba mówi: „Nie, spójrz, pokażę ci. Widzisz, jest tutaj, w tej książce. X jest regułą”.

W tym przypadku mamy problem: Tag tabeli ma dwie rzeczy: po pierwsze, kontroluje układ dokumentu. Po drugie, przekazuje ideę, że zamknięte dane składają się z wierszy i kolumn liczb lub innych danych.

Tak wiele osób zaproponowało rozwiązanie: nie używaj znaczników tabeli do kontrolowania układu rzeczy, które nie są logicznie „tabelami”. Użyj CSS.

Ale z tym rozwiązaniem jest problem. Znacznik tabeli i jego podtagi wykonują wiele bardzo przydatnych funkcji układu, które nie są łatwe do osiągnięcia przy użyciu CSS, a gdy można je osiągnąć, kod niezbędny do tego jest często uciążliwy - trudny do odczytania i trudny do utrzymania. Dlaczego powinniśmy robić rzeczy w niezdarny, trudny sposób, skoro istnieje czysty, łatwy sposób?

Osobiście uważam, że lepiej byłoby po prostu zadeklarować: „Fakt, że coś znajduje się w znaczniku tabeli, niekoniecznie oznacza, że ​​reprezentuje on wiersze i kolumny liczb”. To nie byłby skandaliczny wyrok. Nigdy nie słyszałem, żeby ktoś powiedział, że znacznika „p” można używać tylko do rzeczy, które są tak naprawdę akapitami poprawnych gramatycznie, logicznie skonstruowanych angielskich zdań. Nigdy nie słyszałem, żeby ktoś powiedział, że źle jest używać znacznika „ul” do listy, która w rzeczywistości ma logiczną kolejność, tylko dlatego, że chciałeś punktorów, a nie numerów porządkowych. Itp.


7
wrt do ostatniego akapitu - przeczytałeś specyfikację HTML5 dla tych elementów, prawda? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html # the-ol-element - szczególnie, jeśli kolejność ma znaczenie, użyj elementu ol (ponieważ jest to część strukturalna) - nadal możesz go prezentować jako listę punktowaną za pomocą CSS
HorusKol

5
a jeśli spojrzysz na pozostałe dwie odpowiedzi tutaj, zobaczysz, że żadne z nich nie mówi po prostu „ponieważ to jest reguła” - oba zawierają bardzo jasne uzasadnienie reguły i przypadki użycia
HorusKol

1
Hmm, wydaje mi się, że powiedziałem coś w stylu: „Ktoś widzi problem i proponuje regułę, aby temu zapobiec. Inni widzą wartość tej reguły. Następnie nalegają na ślepe przywiązanie do tej zasady bez względu na pierwotny problem, który zakładano do rozwiązania i / lub niezależnie od tego, jakie inne problemy stwarza. ” Nie przeczę, że za zasadą kryje się rozsądne myślenie. Po prostu nie zgadzam się z wnioskiem. Z pewnością mogę powiedzieć: „Masz rację, ale nie zgadzam się”. I na pewno nie zaprzeczasz, że są ludzie, którzy nie rozumieją zalet i wad i mówią ...
Jay

1
... „bo to reguła”. Przez lata rozmawiałem z takimi ludźmi na ten temat i na wielu innych. Ludzie, którzy nie chcą nawet omawiać zalet i wad reguły, ponieważ jest to reguła, koniec dyskusji.
Jay

Pojawiło się to niefortunne przekonanie, że projektowanie HTML ma swoje korzenie w abstrakcyjnej formie inżynierii, a nie w sztuce. W związku z tym niektórzy zdecydowali, że muszą istnieć bezwzględne reguły analogiczne do fizyki, a grawitacji, której należy przestrzegać, lub ktoś, kto łamie takie reguły, odchodzi od „czystej wiary”. Rzeczywistość jest taka, że ​​żadna przeglądarka ani metafora projektu nie są nieomylne. Ostrożnie stąpaj po tych, którzy twierdzą inaczej.
David W

5

Tutaj jest już mnóstwo świetnych odpowiedzi. Chciałem jednak dodać, że tableelementy mają ograniczenia renderowania, które nie istnieją dla divelementów. Spróbuj stworzyć tabelę, która będzie wirtualnie przewijać (jak: SlickGrid , DataTables i inne), a będziesz bardzo rozczarowany. To po prostu nie działa. Większość (wszystkich?) Nowoczesnych siatek JavaScript używa divs, ponieważ css pozwala na znacznie bardziej elastyczne renderowanie.

Istnieją również inne ograniczenia. Moją ogólną zasadą jest to, że jeśli mam zobaczyć całą tabelę na jednym ekranie i nie chcę żadnego niestandardowego renderowania, używam tableelementu, w przeciwnym razie korzystam z div, ponieważ mogę dużo kontrolować wyniki , o wiele łatwiej.


3

HTML i CSS rozwinęły się w pewnym stopniu elastyczności, co oznacza, że ​​nawet koncepcyjnie elementy blokujące, takie jak <div>(najstarsza i najbardziej ogólna forma HTML treści) nie muszą być wyświetlane jako bloki:

div { display: inline; }

Jak można zauważyć, <div>można go zmienić w celu naśladowania <table>i innych podróżników. W rzeczywistości większość tagów może. Biorąc pod uwagę ich specjalne role, wątpię można użytecznie przemapować tagi makro jak <html>, <head>, <body>i <script>, ale „wspólnych” tagów takich jak <div>, <p>, <b>, <em>, <span>, i <pre>? Do zgarnięcia. Ustaw bloki znaczników w linii, bloki w linii, przepływy wstępnie sformatowanych znaczników, pływające stacjonarne. Zaszalej, jeśli chcesz!

To możliwe . Być może zechcesz opowiedzieć o tym, w jaki sposób wszyscy powinniśmy używać „znaczników semantycznych”, bla, bla, bla , bla , bla bla bla , lub wierzyć w Pythonistas, że „Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób na to”. Jednak Tim Toady jest sprytnym i ciekawskim facetem. Mając wolną rękę, zbada je wszystkie. Obejmuje to wykorzystanie dostępnej elastyczności do dokonywania podstawień. Niektóre są mądre, inne zostaną udowodnione w inny sposób. Ale próba, błąd i doświadczenie to jedyny sposób, aby się tego dowiedzieć. Występują więc wystarczające warunki do zastąpienia.

Nie sądzę, aby przesadne było stwierdzenie, że podstawienie jest również konieczne. Jest to co najmniej niezwykle wygodne . Przez długi czas, HTML nie mają <menu>, <section>albo <aside>elementy. Jednak strony internetowe i aplikacje wszędzie mają menu, sekcje i paski boczne. W jaki sposób? Ponieważ elementy listy HTML ( <ul>, <ol>i <li>) można łatwo zmienić przeznaczenie, a niektóre zastosowania zostały ponownie sklasyfikowane jako kontenery i części menu. <div>mógłby stanąć na <article>, <section>, <aside>, <figure>, i <summary>. HTML5 nadrobił zaległości i dodał niestandardowe elementy dla niektórych wcześniej nieadresowanych przypadków użycia. Jest to świetna aktualizacja i korekta pozwalająca na dostosowanie do powszechnego użytku w świecie rzeczywistym.

Mimo to wciąż istnieje wiele popularnych idiomów, które nie mają niestandardowych tagów ani modeli semantycznych . Rzeczy takie jak strony, przypisy, cytaty, strumienie komentarzy, powiązane awatary, „polubienia”, podtytuły i napisy, których ja i wielu innych używam każdego dnia. Co mamy robić? Co możemy Zmień przeznaczenie elementów „bliskich, ale niedokładnych” za pomocą klas i identyfikatorów, aby stać w miejscu i wspierać naszą pracę przez następne pięć lub dziesięć, a nawet wiele lat, aż HTML6 lub HTML7 nadrobią zaległości. Teoretycznie HTML / CSS „tak, to X, ale oznaczymy to tagiem i będziemy pracować z nim jako Y”, jest to niezwykle wygodne. Niezbędne, naprawdę. Sprawia, że ​​zawartość sieci Web jest elastyczna i nie krucha.

Idąc dalej, „znacznik semantyczny” ma nieredukowalne ograniczenia . Dotyczy to każdego rodzaju rygorystycznej struktury, jaką można sobie wyobrazić dla treści.

Standardowe formaty nie mogą obejmować całego bogactwa ludzkich potrzeb, pragnień i różnorodności. Zawsze będą „za zakrętem” tego, co ludzie robią teraz . Jak są innowacyjne. Do licha, HTML5 wciąż pozostaje poza zakresem przypisów, podtytułów i innych innowacji drukarskich XVII wieku. Brakuje funkcji niezbędnych dla wielu pracowników informacji i twórców treści. Improwizujemy.

Jeszcze bardziej niezmienne jest to, że informacje nie podlegają jednemu zestawowi reguł. Jasne, zaczyna się od stołu. Ale może chcesz tylko podsumowanie - wypowiedz tytuł każdego wiersza jako listę. Może zajmuje zbyt dużo miejsca i chciałbyś, aby była to wbudowana lista zajmująca mało miejsca. Być może masz rekordy, których chcesz tylko tytuł, a następnie kliknięcie spowoduje wyświetlenie podstawowych informacji. Lub chcesz, aby elementy ze złożonej listy lub tabeli były grupowane i kategoryzowane. Och, teraz chcesz to przetransponować i skategoryzować w inny sposób. Lub wartości wykreślone jako wykres słupkowy. Są to czynności wykonywane codziennie w aplikacjach, arkuszach kalkulacyjnych i wizualizacji danych. Są nieodłączną częścią naszego krajobrazu informacyjnego i tego, co chcemy i musimy robić w Internecie. Ludzie stale reorganizują formę i prezentację naszych danych. To nie jest tylko jedna rzecz lub jeden format / układ, lub jedna koncepcja. Jest zamienny, z semantyką zależną od okoliczności i wyborów dokonywanych interaktywnie przez użytkowników. Tak, zaznacz tekst jako „wyróżniony” (<em>), ale to tylko konwencja. Pracowałem nad dokumentami z co najmniej kilkoma różnymi rodzajami „akcentów”. My potrzebujemy , aby móc dostosować i przemapować że dla różnych zastosowań, różne interpretacje. Jeden rodzaj podkreślenia HTML? Zaskakująco redukcjonistyczny. Ograniczanie Kruchy. To samo odnosi się do <table>, <p>itp

Wspaniale jest mieć tagi / elementy, które pomagają uporządkować myślenie całej społeczności o tym, co się dzieje. Pomaga to w ustalaniu konwencji i idiomów oraz sprawia, że ​​jesteśmy bardziej wydajni. Ale zdolność do zmiany map, przeprojektowania i zmiany przeznaczenia tych struktur? To nieodłączna część integralności sieci i jej sukcesu.


4
jak to się w ogóle zbliża do odpowiedzi na pytanie?
HorusKol

2
IMO omawia podstawowe pytanie, dlaczego projektanci, programiści i pracownicy treści decydują się na użycie ogólnych elementów ( <div>i <span>) zamiast określonych, specjalnie zaprojektowanych elementów (np <table>.). To trochę więcej meta niż tylko te tagi, ale mówi bezpośrednio o wzorach i zasadach użytkowania.
Jonathan Eunice

@HorusKol W rzeczywistości, spośród wszystkich odpowiedzi tutaj, ta jest najbardziej zgodna z twoją odpowiedzią. Powiedziałbym, że dobrze się łączą.
Jonathan Eunice

1
Nie wiem, czy posunęłbym się tak daleko, aby skontrastować div(jako ogólny) z table(jako zbudowany specjalnie). Oba są zbudowane specjalnie dla dwóch różnych (choć być może częściowo pokrywających się) celów. To, jak sądzę, stanowi sedno pytania.
Eric King

@EricKing Można śmiało powiedzieć, że divma cel. Ale divi spannie mają bardzo konkretny cel zamierzony, że table, thead, tdetc zrobić. Nikt nie przestraszy się, jeśli użyjesz różnych divelementów do pasków bocznych, wyciagów, grupowania sekcji itp. - prawie w dowolnym miejscu w dokumencie. Spróbuj to zrobić, że przy stanie otwartym thead, tdlub li. Zamiast „zbudowanego na cel”, może „specyficznego na cel” lub „o określonej roli”.
Jonathan Eunice

0

Przypadki użycia mają znaczenie. Istnieje duża różnica między układem / prezentacją na stronie treści a aplikacją. W treści semantyka ma ogromne znaczenie dla świadomości SEO i użyteczności. W takich przypadkach użycie tabel do prezentacji danych tabelarycznych jest ogólnie rzecz biorąc właściwe. Jak zauważyli inni, wyszukiwarki będą cię karać, a nawet możesz przestrzegać przepisów dotyczących użyteczności, jeśli ustawa wymaga od ciebie przestrzegania rządowych wytycznych dotyczących użyteczności.

W aplikacji internetowej programiści mogą zdecydować się na tworzenie całkowicie oddzielnych widoków dla celów SEO i użyteczności. Elastyczne projektowanie doprowadziło ludzi do tworzenia widoków, które mogą obsługiwać układy stacjonarne i mobilne, a div są lepsze niż tabele w tych przypadkach użycia.

Weźmy na przykład witryny e-commerce. Przeglądanie listy produktów w wynikach przeglądania lub wyszukiwania pokazuje, ogólnie rzecz biorąc, listę produktów w formacie tabelarycznym, ale widoki te mogą być generowane przy użyciu div (które zapewniają bardziej ogólne i elastyczne opcje układu i stylizacji) niż tabel. Amazon i eBay są dobrymi przykładami tego podejścia. Sprawdź wynik wyszukiwania w dowolnej witrynie, a zobaczysz głęboko zagnieżdżony zestaw div.

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.