Định nghĩa thích hợp cho "dữ liệu dạng bảng" trong HTML

Question

Tôi có một đối số theo ngữ cảnh cần giải quyết.

Là người uống koolaid thích hợp khi nói đến HTML, tôi là tất cả về đánh dấu ngữ nghĩa. Kết quả là, tất nhiên tôi ghét phải xem các bảng mà họ không thuộc về. Quy tắc ngón tay cái cho các bảng là bạn chỉ nên sử dụng chúng cho "dữ liệu dạng bảng", nhưng tôi đã chú ý rằng đây là một cụm từ được xác định rất kém. Tôi muốn tạo ra các dữ liệu sau một bảng, nhưng những người khác tại văn phòng của tôi không đồng ý rằng một bảng sẽ là ngữ nghĩa chính xác trong trường hợp này (như trái ngược với một dl hoặc ul, vv):

------------------ 
| SomeEmployee | 
|----------------| 
| Field | val | 
| Field | val | 
| Field | val | 
| Field | val | 
------------------ 

Yêu cầu xung quanh văn phòng (và interwebs), tôi nhận được một số câu trả lời sau về những gì làm cho dữ liệu "dạng bảng":

• "Bất kỳ thứ gì bạn đưa vào bảng tính" (Tôi đã thấy toàn bộ các mô hình được tạo trong bảng tính) có vẻ hơi thiếu với tôi)
• Dữ liệu sẽ ánh xạ tốt tới cơ sở dữ liệu bảng (ví dụ: dữ liệu hàng và cột, cụ thể)
• "Văn bản, văn bản được định dạng sẵn, hình ảnh, liên kết, biểu mẫu, trường biểu mẫu, các bảng khác, v.v ..." (cảm ơn W3C, điều đó thực sự hữu ích)

Và cứ tiếp tục như vậy. Không ai trong số này có vẻ là định nghĩa kinh điển, và họ không cung cấp các đường phân chia tuyệt vời để đưa ra quyết định. Vì vậy, tôi hỏi bạn, đồng bào thông minh của tôi: cách chúng tôi nên xác định dữ liệu dạng bảng.

Nếu có thể, vui lòng trích dẫn nguồn cho câu trả lời của bạn để ngăn chặn chuỗi câu trả lời "tôi nghĩ".

Cảm ơn!

Joe

Answer 1

Wikipedia có một số quy tắc thực tế trong nguyên tắc viết bài viết nội bộ của nó. Chúng ở xa một định nghĩa đầy đủ nhưng hoạt động tốt trong IMO trong thế giới thực.

• When tables are appropriate
• When tables may not be appropriate

Toàn bộ nét rất đáng đọc, nhưng một đoạn đập vào mắt tôi là đặc biệt tốt đẹp:

Trước khi bạn định dạng một danh sách ở dạng bảng, xem xét liệu thông tin sẽ được chuyển tải rõ ràng hơn nhờ có hàng và cột. Nếu vậy, thì một bảng có lẽ là một lựa chọn tốt. Nếu không có lợi ích rõ ràng để có hàng và cột, thì bảng có lẽ không phải là lựa chọn tốt nhất.

Answer 2

Vấn đề với ví dụ của bạn là nó nằm trong hai cột.

Trong giới hạn đó, sự khác biệt giữa việc có sử dụng thẻ TABLE hay thẻ DL làm mờ một chút. Cách duy nhất để phân biệt sẽ là trong dl, thẻ DT phải là nhãn và dd sẽ giữ "dữ liệu". Nếu "dữ liệu" bạn đưa vào thẻ DT không phải là một nhãn (hay còn gọi là Siêu dữ liệu) cho thẻ DD, thì bạn nên sử dụng một bảng. Trong ví dụ của bạn, đó là một loại từ điển, tôi chắc chắn sẽ sử dụng một thẻ dl.Tôi sẽ sử dụng một bảng mà dữ liệu trong mỗi trong hai cột đại diện cho các thuộc tính INDEPENDENT của một điều. Nhưng như tôi nói, sự phân biệt sẽ mờ nhạt.

Trong "bảng" của bạn, cột Trường trông giống với siêu dữ liệu hơn. Vì vậy, quy tắc sẽ có: luôn sử dụng thẻ ngữ nghĩa cụ thể nhất. Trong trường hợp này, một DL.

Điều tôi KHÔNG BAO GIỜ sẽ làm là sử dụng thẻ ul hoặc ol cho việc này. Rất đơn giản, chúng dành cho các danh sách cột đơn. Ngoài ra, không có yêu cầu cho mỗi hàng của danh sách là dữ liệu, tức là các thuộc tính đại diện cho một điều nhất định. Nội dung nằm trong thẻ UL hoặc OL không có siêu dữ liệu được liên kết với thẻ: thẻ UL và OL không cung cấp bất kỳ đánh dấu siêu dữ liệu nào, không giống như thẻ DL và thẻ TABLE.

Di chuyển vào các khía cạnh chung chung hơn câu hỏi của bạn, sau đây được áp dụng:

Như với tình yêu đích thực, bạn biết dữ liệu bảng khi bạn nhìn thấy nó.

Và như với bất kỳ điều gì bạn biết khi bạn nhìn thấy nó, định nghĩa chính xác sẽ lấp đầy một khối lượng triết học khó tiêu. Để bắt đầu, bạn sẽ cần phải xác định những gì bạn có nghĩa là bởi dữ liệu trước khi bạn thậm chí đặt câu hỏi.

Với những dữ kiện đó, và chỉ dành riêng cho các hoạt động thần kinh, ở đây chúng tôi đi:

A. bảng dữ liệu phải được cấu trúc dữ liệu: Dữ liệu phải là thứ bậc hoặc quan hệ. Bởi điều này tôi có nghĩa là nó có thể có khả năng đúc dữ liệu vào một hoặc cấu trúc khác (hoặc cả hai).

Điều này cho phép các quy tắc sau đây để được bắt nguồn, mà khá nhiều khóa xuống những gì có thể đi trong một bảng dữ liệu, do đó việc trả lời câu hỏi của bạn và tuân thủ các yêu cầu của W3C cho việc sử dụng của thẻ:

1. Atomicity : Mỗi ROW dữ liệu phải đại diện cho một ĐƠN VỊ riêng lẻ của cùng một điều. Tức là, dữ liệu trong mỗi CELL của bảng, PHẢI là một thuộc tính của mỗi ROW dữ liệu đại diện. Điều này nhanh chóng cho bạn biết lý do tại sao một số thứ nên đi trong thẻ UL: chúng là DANH SÁCH KHÔNG CẦN, nghĩa là mỗi hàng có thể tham chiếu đến những thứ rất khác nhau, trái với STRUCTURED DATA, trong đó mỗi hàng LUÔN đại diện cho một thể hiện khác của một lớp vật.

2. CELLS: Sẽ khả thi khi đặt từng thuộc tính của nội dung trong thẻ (còn gọi là ô). Nội dung của mỗi ô phải là dữ liệu; các thành phần bố cục không được phép. Lưu ý rằng điều này loại trừ những thứ phụ kiện như tiêu đề cột, không nên sử dụng thẻ và nên sử dụng thẻ chức năng phù hợp hơn.

3. ĐỊNH NGH ROA ROW hoặc 'ĐỊNH DẠNG' DỮ LIỆU: Dữ liệu trong mỗi hàng() phải ánh xạ tới 'định dạng' được xác định trước. Theo định dạng, tôi có nghĩa là một danh sách các thuộc tính mô tả một điều nhất định. Trong phần sau, thuộc tính và cột của các từ được sử dụng thay thế cho nhau.

4. ĐẶT HÀNG ĐƠN HÀNG: Định dạng này phải được sắp xếp nghiêm ngặt. Tức là, thứ tự của các cột không được thay đổi từ hàng này sang hàng khác.

5. ROW INDEPENDENCE: Dữ liệu trong mỗi hàng không được phụ thuộc vào dữ liệu trong các hàng khác. Nó cũng không phụ thuộc vào sự tồn tại của bất kỳ hàng nào khác. Dữ liệu trong mỗi hàng chỉ phụ thuộc vào 'định dạng'.

6. ROW INTEGRITY: Dữ liệu trong mỗi hàng phải tuân thủ các ràng buộc do định dạng xác định.

7. DỮ LIỆU CÓ LIÊN QUAN: Cần có phần mở rộng cho các quy tắc trên để tính toán dữ liệu có liên quan và phân cấp. Điều này có thể dễ dàng thực hiện bằng cách mở rộng định dạng để cho phép một loại cột tự nó là một bảng.

8. Trong các quy tắc trên, không nơi nào nó nêu rõ rằng "cột" phải được sắp xếp theo chiều ngang. Điều này cho phép các hàng có nhiều "cấu trúc" hơn và vẫn tuân thủ các quy tắc 0 - 6. Ví dụ, một bảng con của dữ liệu "con" được phép xuất hiện DƯỚI dữ liệu tương ứng với bản ghi "cha mẹ" của nó. Hay không. Hoặc một trường Memo lớn có thể được hiển thị các ô khác. Chỉ vì nó là dữ liệu dạng bảng không có nghĩa là nó không thể có bố cục.

9. DỮ LIỆU ẢNH: hình ảnh sản phẩm trong danh mục là dữ liệu. Tuy nhiên, trong trường hợp hình ảnh, ràng buộc cột là hình ảnh PHẢI liên quan đến "cột" khác của "định dạng". Điều này gõ ra, ví dụ, một gif minh bạch mà justs thiết lập chiều cao vật lý và hoặc chiều rộng của một hàng. Vì nó không có mối quan hệ nội tại với các dữ liệu khác trong liên tiếp, nó không phải là thực hiện quy tắc 0 - 7.

B.- bảng dữ liệu KHÔNG BAO GỒM NHỮNG SỰ phi cấu trúc dữ liệu. Đây là chi tiết của một hệ quả tất yếu, nhưng đề cập đến "tệ nạn" của thẻ:

1. Bất cứ điều gì đó là bố trí, ví dụ, liên quan đến bố trí của nội dung và trang web, như trái ngược với nội dung chính nó, là KHÔNG dữ liệu bảng .

Trên đây không ít hơn sử dụng nhảm nhí để đánh bóng các nguyên tắc sau đó bạn mình ghi trong câu hỏi của bạn:

Bất cứ điều gì mà đi trong một tờ lây lan hoặc một bảng cơ sở dữ liệu, trong khi không bao gồm mục đích sử dụng của bảng tính mà làm không liên quan đến dữ liệu.

Điều không phải là nhảm nhí là tuyên bố rõ ràng, nhưng có khả năng mơ hồ rằng dữ liệu dạng bảng không có gì khác ngoài dữ liệu có cấu trúc. Theo cấu trúc, tôi có nghĩa là nó phải tạo thành một bộ sưu tập "mạnh mẽ đánh máy".

Một lần nữa, tôi lưu ý rằng định nghĩa này không bao gồm văn bản cho tiêu đề cột, chú thích, chân trang. Nói cách khác, dữ liệu dạng bảng là những gì xảy ra với thẻ tbody. Mọi thứ khác trong thẻ bảng là siêu dữ liệu đề cập đến, nhưng không phải là một phần của dữ liệu dạng bảng.

Các quy tắc trên xác định dữ liệu dưới dạng điều gì đó tuân thủ ràng buộc cột.

Vì vậy, tôi đoán bây giờ bạn cần định nghĩa về ràng buộc cột. Nhưng sau đó một lần nữa, bạn biết một khi bạn nhìn thấy một ...