Tại sao mọi người làm bảng với div?

Trong phát triển web hiện đại, tôi bắt gặp mô hình này thường xuyên hơn. Nó trông như thế này:

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

Và trong CSS có một cái gì đó như:

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

^{* (Tên lớp chỉ mang tính minh họa; trong thực tế, đó là các tên lớp bình thường phản ánh nội dung của phần tử)}

Gần đây tôi thậm chí đã thử làm điều này bởi vì ... bạn biết đấy, mọi người đều đang làm nó.

Nhưng tôi vẫn không hiểu. Tại sao chúng ta lại làm việc này? Nếu bạn cần một cái bàn, thì chỉ cần làm một cái nổ <table>và được thực hiện với nó. Vâng, ngay cả khi đó là để bố trí. Đó là những gì các bảng dành cho - sắp xếp các công cụ theo kiểu bảng.

Lời giải thích tốt nhất mà tôi có là bây giờ mọi người đã nghe câu thần chú "không sử dụng bảng để bố trí", vì vậy họ làm theo nó một cách mù quáng. Nhưng họ vẫn cần một bảng để bố trí (vì không có gì khác có khả năng mở rộng của bảng), vì vậy họ tạo một bảng <div>(vì đó không phải là bảng!) Và sau đó thêm CSS để biến nó thành bảng.

Đối với tất cả thế giới, điều này đối với tôi như đặt những chướng ngại vật không cần thiết theo cách của bạn và sau đó làm thêm để phá vỡ chúng.

Đối số ban đầu để di chuyển khỏi các bảng để bố trí là khó sửa đổi bố cục dạng bảng sau đó. Nhưng sửa đổi bố cục "bảng giả" cũng khó như vậy và vì những lý do tương tự. Trên thực tế, trong thực tế, việc sửa đổi bố cục luôn khó khăn và hầu như không bao giờ đủ để thay đổi CSS, nếu bạn muốn làm điều gì đó nghiêm trọng hơn các điều chỉnh nhỏ. Bạn sẽ cần hiểu và thay đổi cấu trúc HTML để thay đổi thiết kế nghiêm trọng. Và bảng không làm cho công việc khó hơn hoặc dễ hơn div.

Trong thực tế, cách duy nhất tôi thấy rằng bảng có thể làm cho một bố cục rất khó để thay đổi, là nếu bạn ab sử dụng chúng và tạo ra một mớ hỗn độn không tin kính. Bạn có thể làm điều đó với divs quá.

Vì vậy, ... trong một nỗ lực để thay đổi điều này từ một câu nói thành một câu hỏi mạch lạc: tôi đang thiếu gì? Những lợi ích thực sự của việc sử dụng "bảng giả" so với bảng thật là gì?

Về liên kết trùng lặp: Đây không phải là đề xuất sử dụng thẻ khác hoặc thứ gì đó. Đây là một câu hỏi về việc sử dụng <table>so với display:table.

Đây là một mô hình phổ biến để thực hiện các bảng đáp ứng. Dữ liệu dạng bảng rất khó hiển thị trên điện thoại di động vì trang sẽ được phóng to để đọc văn bản, nghĩa là các bảng nằm ở bên cạnh trang và người dùng phải cuộn qua lại và chuyển tiếp để đọc bảng hoặc trang sẽ được thu nhỏ , thường có nghĩa là bảng quá nhỏ để có thể đọc.

Các bảng đáp ứng thay đổi bố cục trên các màn hình nhỏ hơn - đôi khi một số cột bị ẩn hoặc các cột bị trộn lẫn, ví dụ tên và địa chỉ email có thể tách biệt trên các màn hình lớn, nhưng thu gọn thành một ô trên màn hình nhỏ để có thể đọc được thông tin mà không cần phải cuộn.

<div>s được sử dụng để tạo các bảng thay vì các <table>thẻ vì một vài lý do. Nếu <table>các thẻ được sử dụng thì bạn cần ghi đè lên kiểu và bố cục mặc định của trình duyệt trước khi thêm mã của riêng bạn, vì vậy trong trường hợp này, <div>thẻ sẽ tiết kiệm rất nhiều CSS soạn sẵn. Ngoài ra, các phiên bản IE cũ hơn không cho phép bạn ghi đè các kiểu bảng mặc định, do đó, việc sử dụng <div>cũng giúp làm mượt quá trình phát triển trình duyệt chéo.

Có một tổng quan khá tốt về các bảng đáp ứng trên CSS-Tricks .

Chỉnh sửa: Tôi nên chỉ ra rằng tôi không ủng hộ mô hình này - nó rơi vào bẫy viêm và không phải là ngữ nghĩa - nhưng đây là lý do tại sao bạn sẽ tìm thấy các bảng được làm từ divs.

Câu hỏi đặt ra là nếu dữ liệu là một bảng (nghĩa là một tập hợp dữ liệu hoặc đơn vị thông tin được sắp xếp hợp lý theo hai chiều) hoặc bạn chỉ sử dụng lưới để bố trí trực quan, ví dụ: vì bạn muốn một thanh bên mở rộng hoặc đại loại như thế.

Nếu thông tin của bạn về mặt ngữ nghĩa là một bảng, bạn sử dụng một <table>-tag. Nếu bạn chỉ muốn một lưới cho mục đích bố trí, bạn sử dụng một số phần tử html thích hợp khác và sử dụng display:tabletrong biểu định kiểu.

Khi nào dữ liệu về mặt ngữ nghĩa là một bảng? Khi dữ liệu được tổ chức hợp lý dọc theo hai trục. Nếu nó có ý nghĩa với các tiêu đề cho các hàng hoặc cột, thì bạn có thể có một bảng ngữ nghĩa. Một ví dụ về một cái gì đó không phải là về mặt ngữ nghĩa, một bảng đang trình bày một văn bản trong các cột như trong một tờ báo. Đây không phải là một bảng về mặt ngữ nghĩa, vì bạn vẫn sẽ đọc nó một cách tuyến tính và sẽ không có ý nghĩa gì nếu bài thuyết trình bị xóa.

OK, tại sao không sử dụng <table>cho tất cả mọi thứ thay vì chỉ cho một cái gì đó về mặt ngữ nghĩa là một bảng? Về mặt trực quan thì rõ ràng là giống nhau (vì phần tử bảng chỉ có display:elementtrong biểu định kiểu mặc định).

Sự khác biệt là thông tin ngữ nghĩa có thể giúp các tác nhân người dùng thay thế. Ví dụ, trình đọc màn hình có thể cho phép bạn điều hướng theo hai chiều trong bảng và đọc các tiêu đề cho một ô cho cả hai trục nếu bạn quên bạn đang ở đâu. Điều này sẽ gây nhầm lẫn nếu bảng không phải là một bảng mà chỉ được sử dụng để bố trí trực quan.

Cuộc thảo luận <table>so với display:tablechỉ là một trường hợp của nguyên tắc chung hơn là sử dụng đánh dấu ngữ nghĩa. Xem ví dụ: Tại sao người ta lại đánh dấu đúng và đúng ngữ nghĩa? hoặc Tại sao đánh dấu ngữ nghĩa được thêm trọng lượng cho các công cụ tìm kiếm?

Ở một số nơi bạn thực sự có thể được yêu cầu về mặt pháp lý để sử dụng đánh dấu ngữ nghĩa vì lý do truy cập và trong mọi trường hợp, không có lý do nào để cố tình làm cho trang của bạn ít truy cập hơn.

Ngay cả khi bạn không quan tâm đến người dùng khuyết tật, việc trình bày tách biệt với nội dung mang lại cho bạn lợi ích. Ví dụ: bố cục ba cột của bạn có thể được trình bày trong một cột duy nhất trên điện thoại di động bằng cách sử dụng biểu định kiểu thay thế.

Trên thực tế, tôi sẽ nói rằng việc sử dụng các tên lớp như "bảng" trong ví dụ của bạn cho thấy cách mọi người không thực sự hiểu những gì họ đang làm khi cố gắng đánh dấu ngữ nghĩa. Họ nhận được điểm khi cố gắng chỉ ra rằng nội dung không phải là dữ liệu dạng bảng , nhưng họ bị mất điểm vì tên lớp xấu.

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

Tất cả những gì nhà phát triển này đã làm là sao chép <table>đánh dấu ban đầu bằng tên lớp CSS. Điều này có nghĩa là ngay khi bố cục này không phải là một bảng, các tên lớp là bất hòa.

Những gì nhà phát triển này nên làm là xem xét thông tin nào trong bảng - đó có phải là thư viện hình thu nhỏ không? Vậy thì:

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

Bây giờ tôi có thể tạo một số CSS thích ứng:

@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%;
  }
}

Tại sao div và không bảng

Một bảng chứa dữ liệu dạng bảng - việc trình bày một bảng được liên kết chặt chẽ với cấu trúc của một bảng. Dữ liệu dạng bảng sẽ luôn cần ở dạng bảng bất kể bạn đặt nội dung đó ở đâu hoặc trên màn hình / thiết bị nào bạn muốn nó hiển thị.

Thư viện hình thu nhỏ (hoặc nhiều thứ khác, như mẫu đăng ký, menu và hơn thế nữa) không phải là dữ liệu dạng bảng. Nó có thể được trình bày giống như một bảng trong một số bố cục thiết kế, nhưng trong các trường hợp khác, như màn hình điện thoại hẹp, bạn muốn nó sử dụng bố cục khối truyền thống hơn. Hoặc có lẽ bạn muốn hiển thị hình thu nhỏ trong một thanh bên thay vì trong khu vực nội dung chính.

Lựa chọn của bạn bây giờ là xuất ra các đánh dấu khác nhau cho nội dung màn hình rộng (bảng) và thanh bên hoặc nội dung màn hình hẹp (div) - điều đó có nghĩa là các tập lệnh phía máy chủ của bạn sẽ phải nhận thức được nội dung sẽ đi đâu nếu bạn xây dựng chương trình này - hoặc bạn có tập lệnh phía máy chủ của bạn xuất ra cùng một đánh dấu (vì nó không quan tâm đến việc bạn đặt cái này ở đâu) và sử dụng các quy tắc CSS khác nhau cho các tình huống khác nhau.

Vì vậy, sau đó bạn có thể lựa chọn luôn xuất ra các bảng và sau đó ghi đè các quy tắc hiển thị bảng tự nhiên bằng khối (điều này thực sự sẽ mài một số bánh răng trong bất kỳ đầu phát triển nào), hoặc sử dụng các div có nhãn tốt cho phép tiếp cận linh hoạt hơn để tạo kiểu.

Và thực tiễn tốt nhất trong vài năm nay là tránh các bảng khi không cần phải trình bày dữ liệu dạng bảng.

Vào thời xa xưa, công cụ kết xuất bảng " xuất hiện " chậm hơn khi bạn sử dụng tỷ lệ phần trăm cho độ rộng cột. Công cụ về cơ bản phải tải xuống toàn bộ tập dữ liệu trước khi bắt đầu tìm hiểu xem mọi thứ lớn như thế nào để vẽ nó trên màn hình.

Động cơ DIV thì khác. Khi trình duyệt gặp DIV, nó sẽ tiếp tục và đặt nó và bắt đầu điền nội dung. Tất nhiên, div có thể nhảy xung quanh khi dữ liệu tải xong. Do đó tại sao tôi đã xuất hiện trong trích dẫn ở trên. Khung thời gian để hoàn thành cả hai là như nhau, tuy nhiên các bảng không được vẽ cho đến khi kết thúc có nghĩa là người dùng không chắc chắn liệu nó có tải hay không trong một hoặc hai giây.

Điều này trở nên tồi tệ hơn khi các bảng được lồng nhau.

Sau đó, có những cách (và vẫn tồn tại) để làm cho bảng hiển thị FAR FAR nhanh hơn. Về cơ bản bằng cách đưa ra gợi ý rằng kích thước cột không thay đổi, sau đó trình duyệt bắt đầu hiển thị dữ liệu dạng bảng ngay lập tức. Cuối cùng, điều này có nghĩa là các bảng thực sự có thể hiển thị ở vị trí chính xác nhanh hơn các div cho chúng vẻ ngoài tốt hơn.

Nhưng đó không phải là toàn bộ câu chuyện. Phần còn lại của nó là hầu hết các nhà phát triển chỉ đơn giản là không bận tâm để học thủ công của họ đủ tốt để biết điều này. Thay vào đó, họ nhảy vào nhiều băng thông khác nhau và đi với bất kỳ mã nào họ có thể sao chép / dán từ đó. Thậm chí ngày nay tôi thấy rằng rất ít nhà phát triển web biết sự khác biệt từ loại tài liệu này đến loại tiếp theo - và đó là lý do số một tại sao các trang web khác nhau có tất cả các cách giải quyết khác nhau để trình bày các trình duyệt khác nhau.

Vì vậy, +1 cho bạn để đặt câu hỏi.

Nếu tôi có thể có được một "meta" nhỏ ở đây, điều này mang đến hai vấn đề trong tâm trí của tôi:

Một: Ai đó đề xuất một quy tắc cho một số lý do chính đáng, và mọi người hoàn toàn bỏ lỡ quan điểm bằng cách làm theo thư kỹ thuật của quy tắc trong khi bỏ qua tinh thần. Họ tìm ra cách nào đó để hoàn thành tất cả những điều tồi tệ mà quy tắc đang cố gắng ngăn chặn, trong khi về mặt kỹ thuật vẫn tuân theo quy tắc như đã nói.

Hai: Ai đó nhìn thấy một vấn đề và đề xuất một quy tắc để ngăn chặn nó. Những người khác thấy giá trị của quy tắc này. Sau đó, họ nhấn mạnh vào sự tận tâm mù quáng đối với quy tắc này mà không liên quan đến vấn đề ban đầu mà nó được cho là phải giải quyết và / hoặc bất kể những vấn đề khác mà nó tạo ra. Tôi đã có nhiều cuộc trò chuyện khi có người nói: "Bạn phải làm X vì đó là quy tắc", và sau đó tôi hỏi, "Nhưng tại sao chúng ta phải làm X?", Và họ nhìn tôi với sự bối rối và bực tức và nói, "Nhưng Tôi chỉ nói với bạn! Bởi vì đó là quy tắc! " Tôi trả lời, "Nhưng nó dường như gây ra nhiều vấn đề hơn nó giải quyết. Tôi nghĩ chúng ta nên làm Y." Và sau đó người đó nói, "Không, nhìn này, tôi sẽ chỉ cho bạn. Xem, nó ở ngay trong cuốn sách này. X là quy tắc."

Trong trường hợp này, chúng tôi có một vấn đề: Thẻ bảng thực hiện hai điều: Một, nó kiểm soát bố cục của tài liệu. Hai, nó truyền đạt ý tưởng rằng dữ liệu kèm theo được tạo thành từ các hàng và cột số hoặc dữ liệu khác.

Vì vậy, nhiều người đề xuất giải pháp: Không sử dụng thẻ bảng để kiểm soát bố cục của những thứ không hợp lý với "bảng". Sử dụng CSS.

Nhưng có một vấn đề với giải pháp này. Thẻ bảng và thẻ phụ của nó thực hiện nhiều chức năng bố cục rất hữu ích mà không dễ dàng đạt được bằng CSS và khi chúng có thể đạt được, mã cần thiết để làm điều đó thường rất cồng kềnh - khó đọc và khó bảo trì. Tại sao chúng ta nên làm mọi thứ một cách vụng về, khó khăn khi có một cách sạch sẽ, dễ dàng?

Cá nhân, tôi nghĩ rằng chúng ta sẽ tốt hơn nếu chỉ tuyên bố, "Thực tế là một cái gì đó bên trong thẻ bảng không nhất thiết có nghĩa là nó đại diện cho các hàng và cột số." Đây sẽ không phải là một tuyên bố thái quá. Tôi chưa bao giờ nghe ai đó nói rằng thẻ "p" chỉ có thể được sử dụng cho những thứ thực sự là đoạn văn của các câu tiếng Anh được xây dựng một cách hợp lý, đúng ngữ pháp. Tôi chưa bao giờ nghe ai đó nói rằng việc sử dụng thẻ "ul" cho một danh sách thực tế là theo thứ tự hợp lý, chỉ vì bạn muốn có đạn và không phải là số thứ tự. Vân vân.

Đã có hàng tấn câu trả lời tuyệt vời ở đây. Nhưng tôi muốn thêm rằng tablecác phần tử có các giới hạn kết xuất không tồn tại cho divcác phần tử. Hãy thử và tạo một bảng thực hiện cuộn ảo (như: SlickGrid , DataTables và các bảng khác) và bạn sẽ thất vọng vô cùng. Nó không hoạt động. Hầu hết (Tất cả?) Các lưới Javascript hiện đại đều sử dụng divs vì css cho phép hiển thị linh hoạt hơn nhiều.

Có những hạn chế khác là tốt. Nguyên tắc chung của tôi là nếu tôi sẽ nhìn thấy toàn bộ bảng trên một màn hình và tôi không muốn bất kỳ / nhiều kết xuất tùy chỉnh nào cho nó, tôi sử dụng một tableyếu tố, nếu không tôi sẽ sử dụng div vì tôi có thể kiểm soát kết quả nhiều , dễ dàng hơn nhiều.

HTML và CSS đã phát triển một mức độ linh hoạt có nghĩa là các phần tử "chặn" về mặt khái niệm như <div>(dạng nội dung khối lâu đời nhất và chung nhất của HTML) không cần phải được hiển thị dưới dạng các khối:

div { display: inline; }

Như bạn lưu ý, <div>có thể được tái sử dụng để thi đua <table>và những người bạn đồng hành của nó. Trên thực tế, hầu hết các thẻ có thể. Với vai trò đặc biệt của họ, tôi nghi ngờ bạn hữu ích có thể remap thẻ vĩ mô như <html>, <head>, <body>, và <script>, nhưng thẻ "thông thường" như <div>, <p>, <b>, <em>, <span>, và <pre>? Lên cho lấy. Làm cho các khối thẻ nội tuyến, các khối nội tuyến, các thẻ được định dạng trước chảy, các khối cố định nổi. Phát điên, nếu bạn thích!

Điều đó là có thể . Bạn có thể muốn quay sợi về cách tất cả chúng ta nên sử dụng "đánh dấu ngữ nghĩa" blah blah blah , hoặc tin với Pythonistas rằng "Nên có một - và tốt nhất là chỉ có một - cách rõ ràng để làm điều đó". Tuy nhiên Tim Toady là một anh chàng thông minh và tò mò. Được một tay miễn phí, anh sẽ khám phá tất cả. Điều đó bao gồm sử dụng sự linh hoạt có sẵn để thực hiện thay thế. Một số là khôn ngoan, một số sẽ được chứng minh khác. Nhưng dùng thử, lỗi và kinh nghiệm là cách duy nhất để tìm ra điều đó. Vì vậy, các điều kiện đủ để thay thế là hiện tại.

Tôi không nghĩ rằng việc vượt qua để nói rằng sự thay thế cũng là cần thiết. Tối thiểu, nó cực kỳ thuận tiện . Trong một thời gian dài, HTML không có <menu>, <section>hoặc <aside>các yếu tố. Tuy nhiên, các trang web và ứng dụng ở khắp mọi nơi có menu, phần và thanh bên. Làm sao? Bởi vì các thành phần danh sách HTML ( <ul>, <ol>và <li>) dễ dàng được sử dụng lại và một số cách sử dụng được phân loại lại thành các bộ chứa và các phần của menu. <div>thể đứng trong cho <article>, <section>, <aside>, <figure>, và <summary>. HTML5 đã bắt kịp và thêm các yếu tố bespoke cho một số trường hợp sử dụng chưa được giải quyết trước đó. Đây là một bản cập nhật và chỉnh sửa tuyệt vời để phù hợp với việc sử dụng phổ biến trong thế giới thực.

Mặc dù vậy, vẫn còn rất nhiều thành ngữ phổ biến không có thẻ bespoke hoặc mô hình ngữ nghĩa . Những thứ như trang, chú thích, trích dẫn kéo, luồng nhận xét, hình đại diện liên quan, "thích", tiêu đề phụ và phụ đề mà tôi và nhiều người khác sử dụng hàng ngày. Chúng ta phải làm gì? Những gì chúng ta có thể. Tái sử dụng các yếu tố "gần nhưng không chính xác" với các lớp và id để hỗ trợ và hỗ trợ công việc của chúng tôi trong năm hoặc mười năm tiếp theo hoặc trong nhiều năm cho đến khi HTML6 hoặc HTML7 bắt kịp. Về mặt lý thuyết, HTML / CSS là "X, nhưng chúng tôi sẽ gắn thẻ nó và làm việc với nó như một khả năng Y" rất tiện lợi. Không thể thiếu, thật đấy. Nó làm cho nội dung Web trở nên linh hoạt và không dễ vỡ.

Đi xa hơn nữa, "đánh dấu ngữ nghĩa" có những hạn chế không thể khắc phục . Điều đó đúng với bất kỳ loại cấu trúc nghiêm ngặt nào bạn có thể tưởng tượng cho nội dung.

Các định dạng tiêu chuẩn không thể bao gồm toàn bộ sự giàu có của nhu cầu, mong muốn và sự đa dạng của con người. Họ sẽ luôn luôn "đứng sau đường cong" về những gì mọi người đang làm bây giờ . Làm thế nào họ đang đổi mới. Heck, HTML5 vẫn ở phía sau đường cong trên chú thích, tiêu đề phụ và các cải tiến in ấn khác của thế kỷ 17. Nó thiếu các tính năng cần thiết cho nhiều nhân viên thông tin và người tạo nội dung. Thế là chúng tôi ứng biến.

Thậm chí không thay đổi nhiều hơn là thông tin không tuân theo một bộ quy tắc. Chắc chắn, nó bắt đầu như một cái bàn. Nhưng có lẽ bạn chỉ muốn tóm tắt - nói tiêu đề cho mỗi hàng, như một danh sách. Có thể nó chiếm quá nhiều không gian và bạn muốn nó như một danh sách nội tuyến tiết kiệm không gian. Có thể bạn có hồ sơ bạn chỉ muốn tiêu đề, sau đó nếu bạn nhấp vào, bạn sẽ thấy các chi tiết cơ bản. Hoặc bạn muốn các mục trong một danh sách hoặc bảng phức tạp được nhóm lại và phân loại. Ồ, bây giờ bạn muốn nó chuyển đổi và phân loại một cách khác nhau. Hoặc các giá trị được vẽ như một biểu đồ thanh. Đây là những thứ được thực hiện mỗi ngày trong các ứng dụng, bảng tính và trực quan hóa dữ liệu. Chúng là một phần và phần của bối cảnh thông tin của chúng tôi, và những gì chúng tôi muốn và cần làm trên web. Con người liên tục tổ chức lại hình thức và trình bày dữ liệu của chúng tôi. Nó không chỉ là một thứ, hoặc một định dạng / bố cục, hoặc một khái niệm. Đó là nấm, với ngữ nghĩa tùy thuộc vào hoàn cảnh và lựa chọn người dùng thực hiện tương tác. Có, đánh dấu văn bản là "nhấn mạnh" (<em>), nhưng đó chỉ là một quy ước. Tôi đã làm việc trên các tài liệu với ít nhất nửa tá loại "nhấn mạnh" khác nhau. Chúng ta cần có khả năng tùy chỉnh và ánh xạ lại cho các mục đích sử dụng khác nhau, các cách hiểu khác nhau. Một loại nhấn mạnh HTML? Giảm đáng kể. Hạn chế. Giòn. Điều này cũng đúng đối với <table>, <p>vv

Thật tuyệt khi có các thẻ / yếu tố giúp tổ chức toàn bộ suy nghĩ của cộng đồng về "những gì đi đâu". Điều đó giúp thiết lập các quy ước và thành ngữ, và làm cho chúng ta tập thể hiệu quả hơn. Nhưng khả năng sắp xếp lại mọi thứ, để thiết kế lại và tái sử dụng các cấu trúc đó? Đó là một phần và phần của sự bao gồm của Web và thành công của nó.

Trường hợp sử dụng vấn đề. Có một sự khác biệt lớn giữa bố cục / trình bày trong một trang nội dung và trong một ứng dụng. Trong nội dung, ngữ nghĩa là vấn đề lớn đối với nhận thức và khả năng sử dụng SEO. Trong những trường hợp này, sử dụng bảng để trình bày dữ liệu dạng bảng nói chung là điều nên làm. Như những người khác đã lưu ý, các công cụ tìm kiếm sẽ xử phạt bạn và bạn thậm chí có thể chạy các luật về khả năng sử dụng nếu bạn được yêu cầu theo quy định để tuân thủ các nguyên tắc về khả năng sử dụng của chính phủ.

Trong một ứng dụng web, các nhà phát triển có thể chọn tạo các chế độ xem hoàn toàn riêng biệt cho mục đích SEO và khả năng sử dụng. Thiết kế đáp ứng đã khiến mọi người xây dựng các khung nhìn có thể xử lý bố cục trên máy tính để bàn và thiết bị di động và div tốt hơn các bảng trong các trường hợp sử dụng đó.

Lấy các trang web thương mại điện tử, ví dụ. Nhìn chung, xem danh sách các sản phẩm trong trình duyệt hoặc kết quả tìm kiếm sẽ hiển thị danh sách các sản phẩm ở định dạng bảng, nhưng các chế độ xem đó có thể được tạo bằng div (cung cấp các tùy chọn bố cục và kiểu dáng linh hoạt và chung chung hơn) thay vì bảng. Amazon và eBay là những ví dụ điển hình cho phương pháp này. Kiểm tra kết quả tìm kiếm trên một trong hai trang web và bạn sẽ thấy một tập hợp các div được lồng sâu.