Quyết định thiết kế - tại sao tạo <p> mà không </ p>?


14

tl; dr

Một số chương trình được sử dụng rộng rãi, tạo ra html, sẽ chỉ tạo các thẻ đoạn mở và không đóng các đoạn, giả sử rằng trình duyệt sẽ đóng các đoạn đúng.

Về mặt này, dường như đối với tôi, giả định rằng các trình duyệt sẽ đóng các đoạn đúng cách là không chính xác. Là giải thích của tôi chính xác? Tổng quát hơn, những gì đánh đổi có liên quan đến loại quyết định này?


Duyệt qua mã nguồn moinmoin, dòng mã sau đây lọt vào mắt tôi:

# We only open those tags and let the browser auto-close them:
_auto_closing_tags = set(['p'])

( nguồn )

Sau khi đọc phần còn lại của quá trình triển khai, tôi đã tự thuyết phục rằng có, thực sự, khi moinmoin tạo mã html cho một trong các trang của nó, nó sẽ tạo chính xác các thẻ mở đoạn, khi thích hợp, đồng thời tránh bất kỳ mục đích nào các thẻ đóng đoạn văn (mặc dù có thể làm như vậy một cách tầm thường).

Đối với trường hợp sử dụng cụ thể, khá bất thường của tôi, hành vi này là không chính xác. Tôi muốn gửi báo cáo lỗi và / hoặc thay đổi hành vi. Tuy nhiên, có vẻ như quyết định thiết kế này đã được thực hiện chu đáo. Tôi không đủ thành thạo về sự phức tạp của tiêu chuẩn html, hoặc các triển khai trình duyệt khác nhau, để có thể biết liệu đây có phải là hành vi đúng hay không và tôi có cảm giác rằng bản năng của mình để sửa / thay đổi hành vi này có thể là sai lầm.

Là mã này làm cho một giả định hợp lệ về việc triển khai trình duyệt? Html được tạo có hợp lệ không? Tổng quát hơn, những gì tôi có thể đánh đổi ở đây?


2
Các câu trả lời hiện tại mặc dù, điều này trông giống như một thiết kế biến thái. Hãy tự do trong những gì bạn chấp nhận và bảo thủ trong những gì bạn gửi và tất cả những thứ đó. Nó cũng hoàn toàn không cần thiết. Tôi chắc chắn sẽ gửi một báo cáo lỗi (mạnh mẽ) cho Moinmoin. Ít nhất họ nên ghi chép và bình luận hành vi không trực quan này một cách rõ ràng.
Konrad Rudolph

Câu trả lời:


33

Thẻ kết thúc cho pcác thành phần là tùy chọn trong HTML và chỉ được yêu cầu trong XHTML. Tuy nhiên, dự thảo HTML5 giới thiệu một tập hợp các điều kiện khi pthẻ kết thúc thực sự là tùy chọn:

Thẻ kết thúc của phần tử p có thể bị bỏ qua nếu phần tử p ngay lập tức được theo sau bởi một địa chỉ, bài viết, sang một bên, blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, tiêu đề , hgroup, hr, menu, nav, ol, p, pre, phần, bảng hoặc ul, phần tử hoặc nếu không có thêm nội dung trong phần tử cha và phần tử cha không phải là một phần tử.

Nguồn: Đặc tả HTML5

Điều đó nói rằng, đối số duy nhất tôi từng nghe khi bỏ qua các thẻ kết thúc cho pcác thành phần là kích thước tài liệu. Điều đó hoàn toàn tùy thuộc vào bạn để quyết định xem điều đó có hợp lý với tài liệu của bạn hay không. Cá nhân tôi có xu hướng bao gồm tất cả các thẻ kết thúc tùy chọn, chỉ trong trường hợp tôi không đáp ứng các yêu cầu khi thẻ kết thúc là tùy chọn.


5
Những bộ óc vĩ đại nghĩ giống nhau, tôi đoán vậy. :)
Robert Harvey

@RobertHarvey Bạn giành chiến thắng trong vòng này, sau 12 giây ...
yannis

2
Một đối số khác có lợi cho việc bỏ qua các thẻ kết thúc: chúng hiển nhiên từ cấu trúc tài liệu và khi bị sử dụng sai, cũng có thể đưa ra khoảng trắng giả.
Jon Purdy

1
Có thể bỏ qua các thẻ kết thúc rõ ràng là một tính năng thiết kế của SGML, HTML dựa trên. Nó rõ ràng KHÔNG phải là một tính năng của XML, mà XHTML dựa trên.
Alan Shutko

4
Một lập luận tôi thấy rất nhiều là nó trông sạch sẽ hơn. Đặc biệt trong trường hợp <li>thẻ, các thẻ hoạt động giống như các gạch đầu dòng.
DisgruntledGoat

16

Đặc tả W3C cho HTML5 quy định cụ thể rằng:

Thẻ kết thúc của phần tử p có thể bị bỏ qua nếu phần tử p ngay lập tức được theo sau bởi một địa chỉ, bài viết, sang một bên, blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, tiêu đề , hr, menu, nav, ol, p, pre, phần, bảng hoặc phần tử ul hoặc nếu không có thêm nội dung trong phần tử cha và phần tử cha không phải là một phần tử.

Vì vậy, về cơ bản, thông số kỹ thuật đã cung cấp rất nhiều cách mà có thể tránh được sự phức tạp (lớn hay nhỏ) của việc đóng thẻ. Bất kỳ thực hiện trình duyệt phù hợp sẽ phải phù hợp với các ngoại lệ này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.