HTML: Bao gồm, hoặc loại trừ, các thẻ đóng tùy chọn?


149

Một số thẻ đóng HTML 1tùy chọn , nghĩa là:

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

Lưu ý: Không được nhầm lẫn với các thẻ đóng bị cấm đưa vào, tức là:

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Lưu ý: xhtml khác với HTML. xhtml là một dạng của xml, yêu cầu mọi phần tử đều có thẻ đóng. Một thẻ đóng có thể bị cấm trong html, nhưng bắt buộc trong xhtml.

Là các thẻ đóng tùy chọn

  • lý tưởng bao gồm , nhưng chúng tôi sẽ chấp nhận chúng nếu bạn quên chúng, hoặc
  • lý tưởng không bao gồm, nhưng chúng tôi sẽ chấp nhận chúng nếu bạn đặt chúng vào

Nói cách khác, tôi nên bao gồm chúng, hay tôi không nên bao gồm chúng?

Thông số kỹ thuật HTML 4.01 nói về việc đóng các thẻ phần tử là tùy chọn , nhưng không nói liệu có nên bao gồm chúng hay không nên bao gồm chúng.

Mặt khác, một bài viết ngẫu nhiên trên DevGuru nói :

Thẻ kết thúc là tùy chọn. Tuy nhiên, nó được khuyến khích rằng nó được bao gồm.

Lý do tôi hỏi là vì bạn chỉ biết đó là tùy chọn vì lý do tương thích; và họ sẽ làm cho họ ( bắt buộc | cấm ) nếu họ có thể.

Nói một cách khác: HTML 1, 2, 3 đã làm gì liên quan đến những cái này, bây giờ là tùy chọn, đóng thẻ. HTML 5 làm gì? Và tôi nên làm gì?

Ghi chú

Một số thành phần trong HTML bị cấm không có thẻ đóng. Bạn có thể không đồng ý với điều đó, nhưng đó là đặc điểm kỹ thuật và nó không phải là tranh luận. Tôi đang hỏi về các thẻ đóng tùy chọn , và ý định là gì.

Chú thích

1 HTML 4.01


4
Câu hỏi khó khăn ... một số đề xuất của w3c thậm chí bao gồm các ví dụ thực hiện cả hai: w3.org/TR/html401/struct/global.html#id-and- class Ví dụ đầu tiên có </p>các thẻ đóng và thứ hai bỏ qua chúng!
Richard JP Le Guen

Chỉ cần làm rõ - trong trường hợp các thẻ bị cấm trong HTML5, giải pháp hợp lệ "rõ ràng" / XML là đóng chúng bằng một />, chẳng hạn như <meta charset="utf-8" />mặc dù <meta charset="utf-8">HTML5 có hợp lệ không?
cboettig

@cboettig Vâng. <meta charset="utf-8" />là html không hợp lệ , nó phải được <meta charset="utf-8">. Mặt khác <meta charset="tuf-8">không hợp lệ xhtml, nó phải được<meta charset="utf-8" />
Ian Boyd

@IanBoyd thật sao? trong HTML5? Các W3C thủ dự thảo cho biết nhiều thứ tiếng html / xhtml nói để sử dụng <meta charset="UTF-8"/>với thẻ đóng. Mặt khác, làm thế nào polyglot hoặc xhtml có thể xác nhận là html5 và xml?
cboettig

@cboettig Bạn nói đúng. Đánh dấu Polyglot (tức là Tài liệu XHTML tương thích HTML ) không thể là HTML 4.01 hợp lệ. HTML5 (vẫn là một công việc đang tiến hành) có khái niệm về các phần tử Void - các phần tử không thể có thẻ kết thúc . Có lẽ hầu hết các trình duyệt đều nhẹ nhàng và sẽ tha thứ cho các lỗi đánh dấu của bạn.
Ian Boyd

Câu trả lời:


49

Những cái tùy chọn là tất cả những cái nên rõ ràng về mặt ngữ nghĩa nơi chúng kết thúc, mà không cần thẻ kết thúc. Mỗi cái đều <li>ngụ ý </li>nếu không có cái nào ngay trước nó.

Tất cả các thẻ kết thúc bị cấm sẽ ngay lập tức được theo sau bởi thẻ kết thúc của chúng, vì vậy nó sẽ là loại dư thừa để phải gõ <img src="blah" alt="blah"></img>mỗi lần.

Tôi hầu như luôn luôn sử dụng các thẻ tùy chọn (trừ khi tôi có lý do rất chính đáng để không) bởi vì nó cho vay mã dễ đọc và cập nhật hơn.


18
tôi thấy nó bây giờ. <LI>giống như một viên đạn. Không ai muốn phải bọc toàn bộ một viên đạn <LI>...</LI>. Vì vậy, theo cách đó LIphù hợp với những gì mọi người sẽ viết một cách tự nhiên trong quá trình đánh dấu. Sames đi cho một dấu đoạn ( <P>), trong xử lý văn bản, bạn thêm một dấu đoạn ở đầu đoạn văn; và không phải ở cuối của mỗi một quá. Vì vậy, trong cách giải thích này, các thẻ đóng là tùy chọn vì không người bình thường nào nghĩ rằng có chúng. Thêm vào đó, bản thân phần tử không có nội dung - phần tử nội dung.
Ian Boyd

8
Ý tôi là gì khi tôi hầu như luôn sử dụng các thẻ tùy chọn - bạn có nghĩa là bạn bao gồm thẻ kết thúc hay bạn bỏ nó đi ? (Tôi có ấn tượng rằng bạn bao gồm nó, khi tôi đọc câu trả lời của bạn - nhưng nhận xét ở trên của Ian Boyd cho tôi ấn tượng rằng bạn loại trừ nó.)
KajMagnus

3
@IanBoyd Và cho đoạn cuối?
Pacerier

22
@Pacerier Mọi người đã viết các đoạn văn bản trong hàng trăm năm. Không ai từng bối rối khi một đoạn kết thúc.
Ian Boyd

4
Liên kết có liên quan cho HTML5, cho những người tìm thấy câu trả lời này trong khi cố gắng tìm tài liệu tham khảo thực tế: w3.org/TR/html5/syntax.html#optional-tags
Mike 'Pomax' Kamermans 4/12/13

59

Có những trường hợp các thẻ rõ ràng giúp đỡ, nhưng đôi khi nó không cần thiết phải đi bộ.

Lưu ý rằng thông số kỹ thuật HTML chỉ định rõ ràng khi nào nó hợp lệ để bỏ qua các thẻ, vì vậy nó không phải lúc nào cũng là một lỗi.

Ví dụ, bạn không bao giờ cần </body></html>. Không ai từng nhớ đặt <tbody>một cách rõ ràng (đến mức XHTML đưa ra ngoại lệ cho nó).

Bạn không cần </head><body>trừ khi bạn có các tập lệnh thao tác DOM thực sự tìm kiếm <head>(tốt hơn hết là đóng nó một cách rõ ràng, bởi vì các quy tắc cho kết thúc ngụ ý <head>có thể làm bạn ngạc nhiên).

Danh sách lồng nhau thực sự tốt hơn mà không có </li>, bởi vì sau đó khó tạo ra ul > ulcây sai .

Có hiệu lực:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Không hợp lệ:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

Và hãy nhớ rằng các thẻ kết thúc được ngụ ý cho dù bạn có cố gắng đóng tất cả các yếu tố hay không. Đặt thẻ kết thúc sẽ không tự động làm cho phân tích cú pháp mạnh mẽ hơn:

<p>foo <p>bar</p> baz</p>

sẽ phân tích thành:

<p>foo</p><p>bar</p> baz

Nó chỉ có thể giúp đỡ khi bạn xác nhận tài liệu.


4
Đợi đã, tại sao <p>foo <p>bar</p> baz</p>không được phân tích cú pháp thành hai pthẻ lồng nhau ?
Eric

19
Bởi vì một <P>phần tử không thể chứa các phần tử mức khối và <P>là một phần tử mức khối. Từ ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "Phần tử P đại diện cho một đoạn. Nó không thể chứa các phần tử cấp khối (bao gồm cả chính P)."
Ian Boyd

1
@IanBoyd Ý bạn là không thể chứa các thành phần cấp khối bất kể quy tắc CSS?
Pacerier

6
@Pacerier CSS không thể ảnh hưởng đến DOM theo bất kỳ cách nào. DOM được phân tích cú pháp trước, và sau đó CSS ​​hiển thị nó. blockHiển thị CSS là một điều hoàn toàn khác với nội dung cấp khối của HTML (điều này xảy ra là hầu hết các yếu tố cấp khối HTML được hiển thị dưới dạng khối CSS theo mặc định).
Kornel

2
@ anton1980 Không, điều này không giống nhau. Việc xử lý các thẻ đóng tùy chọn bị bỏ qua được chỉ định rõ ràng và hoạt động đáng tin cậy trong tất cả các trình duyệt tuân thủ. OTOH một trang điểm <t>sẽ không hoạt động như thế nào <title>.
Kornel

18

Tôi đang thêm một số liên kết ở đây để giúp bạn về lịch sử của HTML, để bạn hiểu được những mâu thuẫn khác nhau. Đây không phải là câu trả lời cho câu hỏi của bạn, nhưng bạn sẽ biết nhiều hơn sau khi đọc những thông báo khác nhau này.

Một số trích đoạn từ Lặn vào HTML5 :

[T] ông thực tế rằng đánh dấu HTML bị hỏng của HTML vẫn hoạt động trong các trình duyệt web khiến các tác giả tạo ra các trang HTML bị hỏng. Rất nhiều trang bị hỏng. Theo một số ước tính, hơn 99% các trang HTML trên web hiện nay có ít nhất một lỗi trong đó. Nhưng vì những lỗi này không khiến trình duyệt hiển thị thông báo lỗi hiển thị, nên không ai sửa chúng.

W3C thấy đây là một vấn đề cơ bản với web và họ đã bắt đầu sửa nó. XML, được xuất bản năm 1997, đã phá vỡ truyền thống tha thứ cho khách hàng và bắt buộc rằng tất cả các chương trình sử dụng XML phải coi cái gọi là lỗi có định dạng tốt của Google là nghiêm trọng. Khái niệm thất bại về lỗi đầu tiên này được gọi là xử lý lỗi hà khắc, sau khi nhà lãnh đạo Hy Lạp Draco , người đã đưa ra án tử hình vì những vi phạm tương đối nhỏ trong luật pháp của mình. Khi W3C định dạng lại HTML dưới dạng từ vựng XML, họ bắt buộc tất cả các tài liệu được cung cấp với application/xhtml+xmlloại MIME mới sẽ phải chịu xử lý lỗi hà khắc. Nếu thậm chí chỉ có một lỗi hình thành duy nhất trong các trình duyệt web XHTML của bạn thì không có lựa chọn nào khác ngoài việc dừng xử lý và hiển thị thông báo lỗi cho người dùng cuối.

Ý tưởng này không phổ biến toàn cầu. Với tỷ lệ lỗi ước tính 99% trên các trang hiện có, khả năng hiển thị lỗi cho người dùng cuối và các tính năng mới trong XHTML 1.0 và 1.1 để loại bỏ chi phí, về cơ bản, các tác giả web đã bỏ qua application/xhtml+xml. Nhưng điều đó không có nghĩa là họ bỏ qua XHTML hoàn toàn. Ồ, chắc chắn là không. Phụ lục C của đặc tả XHTML 1.0 đã tạo cho lỗ hổng của các tác giả web trên thế giới: Sử dụng một cái gì đó trông giống như cú pháp XHTML, nhưng tiếp tục phục vụ nó với text/htmlloại MIME. Và đó chính xác là điều mà hàng ngàn nhà phát triển web đã làm: họ đã nâng cấp cú pháp của Google thành XHTML nhưng vẫn phục vụ nó với kiểu MIME văn bản / html.

Thậm chí ngày nay, hàng triệu trang web tuyên bố là XHTML. Chúng bắt đầu với loại tài liệu XHTML trên dòng đầu tiên, sử dụng tên thẻ chữ thường, sử dụng dấu ngoặc kép quanh các giá trị thuộc tính và thêm dấu gạch chéo sau các phần tử trống như <br /><hr />. Nhưng chỉ một phần rất nhỏ trong số các trang này được cung cấp với application/xhtml+xmlloại MIME sẽ kích hoạt xử lý lỗi hà khắc của XML. Bất kỳ trang nào được phục vụ với loại MIME text/html- bất kể kiểu tài liệu, cú pháp hoặc kiểu mã hóa - sẽ được phân tích cú pháp bằng cách sử dụng trình phân tích cú pháp HTML tha thứ cho HTML, âm thầm bỏ qua mọi lỗi đánh dấu và không bao giờ cảnh báo cho người dùng cuối (hoặc bất kỳ ai khác) ngay cả khi các trang bị hỏng kỹ thuật.

XHTML 1.0 bao gồm kẽ hở này, nhưng XHTML 1.1 đã đóng nó và XHTML 2.0 chưa bao giờ hoàn thiện tiếp tục truyền thống yêu cầu xử lý lỗi hà khắc. Và đó là lý do tại sao có hàng tỷ trang tuyên bố là XHTML 1.0 và chỉ một số ít tuyên bố là XHTML 1.1 (hoặc XHTML 2.0). Vậy bạn có thực sự sử dụng XHTML không? Kiểm tra loại MIME của bạn. (Trên thực tế, nếu bạn không biết loại MIME nào bạn đang sử dụng, tôi có thể đảm bảo rằng bạn vẫn đang sử dụng text/html.) Trừ khi bạn đang phục vụ các trang của mình với loại MIME application/xhtml+xml, cái gọi là của bạn là tên XML chỉ.

[T] ông, những người đã đề xuất phát triển các biểu mẫu HTML và HTML đã phải đối mặt với hai lựa chọn: từ bỏ hoặc tiếp tục công việc của họ bên ngoài W3C. Họ đã chọn cái sau, đăng ký whatwg.orgtên miền và vào tháng 6 năm 2004, Nhóm làm việc WHAT đã ra đời .

[T] anh ấy làm việc gì cũng lặng lẽ làm việc với một vài thứ khác. Một trong số đó là một đặc tả, ban đầu được đặt tên là Web Forms 2.0 , đã thêm các loại điều khiển mới vào các biểu mẫu HTML. (Bạn sẽ tìm hiểu thêm về các hình thức web trong A Form of Madness .) Một cái khác là một đặc tả dự thảo có tên là Ứng dụng web 1.0, có bao gồm các tính năng mới chính như một bản vẽ chế độ trực tiếp và hỗ trợ riêng cho âm thanh và video mà không cần plugin .

Vào tháng 10 năm 2009, W3C đã đóng cửa Nhóm làm việc XHTML 2đưa ra tuyên bố này để giải thích quyết định của họ :

Khi W3C công bố Nhóm làm việc HTML và XHTML 2 vào tháng 3 năm 2007, chúng tôi đã chỉ ra rằng chúng tôi sẽ tiếp tục theo dõi thị trường cho XHTML 2. W3C nhận ra tầm quan trọng của tín hiệu rõ ràng đối với cộng đồng về tương lai của HTML.

Mặc dù chúng tôi nhận ra giá trị đóng góp của Nhóm làm việc XHTML 2 trong những năm qua, sau khi thảo luận với những người tham gia, ban quản lý W3C đã quyết định cho phép điều lệ của Nhóm công tác hết hạn vào cuối năm 2009 và không gia hạn.

Những người chiến thắng là những người tàu.


12

Lý do tôi hỏi là vì bạn chỉ biết đó là tùy chọn vì lý do tương thích; và họ sẽ làm cho họ (bắt buộc | cấm) nếu họ có thể.

Đó là một suy luận thú vị. Tôi đọc nó là bất cứ khi nào một thẻ có thể được suy luận đáng tin cậy, thẻ là tùy chọn. Thiết kế cho thấy rằng ý định là làm cho nó nhanh chóng và dễ dàng để viết.

HTML 1, 2, 3 đã làm gì liên quan đến những cái này, bây giờ là tùy chọn, đóng thẻ.

DTD cho HTML 2 được nhúng trong RFC , cùng với DTD HTML gốc , có các thẻ bắt đầu và kết thúc tùy chọn ở khắp mọi nơi.

HTML 3 đã bị hủy bỏ (nhờ các cuộc chiến trình duyệt) và được thay thế bằng HTML 3.2 (được thiết kế để mô tả trạng thái hiện tại của web).

HTML 5 làm gì?

HTML 5 đã hướng tới việc "mở đường băng" ngay từ đầu.

Và tôi nên làm gì?

Ah, bây giờ đó là chủ quan và lập luận :)

Một số người nghĩ rằng các thẻ rõ ràng là tốt hơn cho khả năng đọc và duy trì nhờ vào việc đứng trước mắt độc giả.

Một số người nghĩ rằng các thẻ được suy luận là tốt hơn cho khả năng đọc và duy trì nhờ vào việc không làm lộn xộn trình soạn thảo.


1
+1 tôi đã không nghĩ đến khái niệm "đáng tin cậy". Vì vậy, người ủng hộ ý tưởng rằng thực sự không có bất kỳ ý định nào theo cách này hay cách khác. tôi giả định rằng đặc tả đã cố gắng tương thích nhất có thể với nội dung HTML và thông số kỹ thuật HTML hiện có.
Ian Boyd

Xin lỗi, Dave, tôi đã đưa nó cho Aslum; anh ấy cần người đại diện :) Nhưng bạn có cùng ý tưởng, với nội dung được liên kết và trích dẫn nhiều hơn. Nhưng câu trả lời tốt đẹp.
Ian Boyd

8

HTML 5 làm gì?

Câu trả lời cho câu hỏi này nằm trong Dự thảo làm việc của W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

Và tôi nên làm gì?

Đó là một vấn đề về phong cách. Tôi cố gắng không bao giờ bỏ qua các thẻ kết thúc bởi vì nó giúp tôi nghiêm ngặt và không bỏ sót các thẻ cần thiết.


+1 cho liên kết đến bản phác thảo HTML 5 và phần thích hợp. Nhưng html 5 không nói cách này hay cách khác.
Ian Boyd

6

Nếu nó là thừa, hãy để nó ra.

Nếu nó phục vụ một mục đích (thậm chí là một mục đích có vẻ tầm thường, chẳng hạn như xoa dịu IDE của bạn hoặc xoa dịu đôi mắt của bạn), hãy để nó vào.

Thật hiếm khi trong một thông số kỹ thuật được xác định rõ để xem các mục tùy chọn không ảnh hưởng đến hành vi. Tất nhiên, ngoại trừ "ý kiến". Nhưng thông số kỹ thuật HTML không phải là thông số kỹ thuật thiết kế và nhiều tài liệu về tình trạng triển khai chính hiện tại. Vì vậy, khi một mục là tùy chọn trong HTML và dường như không phục vụ mục đích nào, chúng tôi có thể đoán rằng bản chất tùy chọn chỉ là tài liệu của một trò chơi trong trình duyệt cụ thể.

Nhìn vào phần RFC đặc tả HTML-5 được liên kết ở trên, bạn sẽ thấy rằng các thẻ tùy chọn được liên kết kỳ lạ với sự hiện diện của các bình luận! Điều đó sẽ cho bạn biết rằng các tác giả không đội mũ thiết kế. Thay vào đó, họ đang chơi trò chơi "ghi lại những điều kỳ quặc" trong các triển khai chính. Vì vậy, chúng ta không thể quá coi trọng thông số kỹ thuật về mặt này.

Vì vậy, giải pháp là: Đừng đổ mồ hôi. Chuyển sang một cái gì đó thực sự quan trọng. :)


5

Tôi nghĩ rằng câu trả lời tốt nhất là bao gồm các thẻ đóng để dễ đọc hoặc phát hiện lỗi. Tuy nhiên, nếu bạn có nhiều HTML được tạo (giả sử, bảng dữ liệu), bạn có thể tiết kiệm băng thông đáng kể bằng cách bỏ qua các thẻ tùy chọn.


2
Richard: Khi bạn có các cấu trúc lồng nhau sâu, bạn sẽ dễ dàng tìm thấy lỗi hơn vì các thẻ đóng cung cấp thêm thông tin về ý định.
Gabe

1
Tôi nghĩ rằng "các thẻ đóng cung cấp thêm thông tin về ý định" là câu trả lời ngắn gọn nhất cho câu hỏi này. Lập luận một lý do rõ ràng tốt bằng cách này hay cách khác.
squarecandy

4

Đề nghị của tôi là bạn bỏ qua hầu hết các thẻ đóng tùy chọn và tất cả các thuộc tính tùy chọn mà bạn có thể thoát khỏi. Nhiều IDE sẽ phàn nàn vì vậy bạn có thể không thoát khỏi việc bỏ qua một số trong số này nhưng thường tốt hơn cho kích thước tệp nhỏ hơn và ít lộn xộn hơn. Nếu bạn có trình tạo mã chắc chắn bỏ qua các thẻ kết thúc ở đó bởi vì bạn có thể nhận được một số giảm kích thước tốt từ nó. Thông thường nó không thực sự quan trọng bằng cách này hay cách khác.

Nhưng khi nó quan trọng thì hãy hành động. Trong một số công việc gần đây của tôi, tôi đã có thể giảm kích thước HTML được hiển thị của mình từ 1,5 MB xuống còn 800 KB bằng cách loại bỏ hầu hết các thuộc tính giá trị kết thúc và dự phòng được tạo cho thẻ mở, trong đó văn bản của phần tử giống như giá trị. Tôi có khoảng 200 thẻ. Tôi có thể thực hiện điều này theo một cách khác hoàn toàn, nhưng đó sẽ là công việc nhiều hơn ($$$), vì vậy điều này cho phép tôi dễ dàng làm cho trang phản hồi nhanh hơn.

Vì tò mò tôi thấy rằng nếu tôi loại bỏ các trích dẫn xung quanh các thuộc tính không cần đến chúng, tôi có thể tiết kiệm 20 KB, nhưng IDE của tôi (Visual Studio) không thích điều đó. Tôi cũng rất ngạc nhiên khi thấy rằng ID thực sự dài mà ASP.NET tạo ra chiếm 20% tệp của tôi.

Ý tưởng rằng chúng tôi có thể nhận được bất kỳ phần nào có liên quan của HTML hợp lệ ngay từ đầu đã bị nhầm lẫn, do đó, hãy làm bất cứ điều gì tốt nhất cho bạn và khách hàng của bạn. Hầu hết các công cụ mà tôi từng thấy hoặc sử dụng sẽ nói rằng chúng tạo ra xhtml, nhưng chúng không thực sự hoạt động 100% và dù sao cũng không có lợi ích gì cho việc tuân thủ nghiêm ngặt.


Tôi khó có thể chấp nhận bỏ qua các thẻ kết thúc tùy chọn, nhưng tôi thấy đó là một ý tưởng khá tồi để bỏ qua các trích dẫn trên các thuộc tính. Bạn đang mạo hiểm trang web của bạn để phá vỡ một số trình duyệt theo cách đó. Nếu bạn có tệp html 800kb, bạn đang làm gì đó sai nghiêm trọng.
Christoph

2
@Christoph: Bỏ qua các thẻ kết thúc tùy chọn (như </p>hoặc </li>) là hoàn toàn tốt theo đặc điểm kỹ thuật HTML. Nếu trình duyệt không hiểu điều đó, thì đó là vấn đề với trình duyệt.
Konrad Borowski

2

Cá nhân tôi là một fan hâm mộ của XHTML và, giống như ghoppe, "Tôi cố gắng không bao giờ bỏ qua các thẻ kết thúc bởi vì nó giúp tôi nghiêm ngặt và không bỏ sót các thẻ cần thiết."

nhưng

Nếu bạn cố tình sử dụng HTML 4.n, người ta không thể lập luận rằng việc bao gồm chúng giúp việc sử dụng tài liệu dễ dàng hơn, vì khái niệm về hình thức tốt trái với tính hợp lệ là một khái niệm XML và bạn sẽ mất lợi ích đó khi bạn cấm một số thẻ đóng. Vì vậy, vấn đề duy nhất trở thành hợp lệ ... và nếu nó vẫn còn hiệu lực nếu không có chúng ... bạn cũng có thể tiết kiệm băng thông, phải không?


2

Sử dụng thẻ kết thúc giúp xử lý các đoạn dễ dàng hơn vì hành vi của chúng không phụ thuộc vào các yếu tố anh chị em. Lý do này một mình nên đủ hấp dẫn. Có ai đối phó với các tài liệu html nguyên khối nữa không?


1

Trong một số ngôn ngữ ngoặc nhọn như C #, bạn có thể bỏ qua các dấu ngoặc nhọn quanh một câu lệnh if nếu nó chỉ dài hai dòng. ví dụ...

if ([điều kiện])
    [mã]

nhưng bạn không thể làm điều này ...

if ([điều kiện])
    [code]
    [code]

dòng thứ ba sẽ không phải là một phần của câu lệnh if. nó làm tổn thương khả năng đọc và các lỗi có thể dễ dàng được giới thiệu và rất khó tìm.

vì những lý do tương tự, tôi đóng tất cả các thẻ. các thẻ như thẻ img vẫn cần phải được đóng, nhưng không phải với một thẻ đóng riêng biệt.


Bạn có thể cho ví dụ về HTML rất khó? Theo kinh nghiệm của tôi, thẻ kết thúc tùy chọn không lừa đảo nhiều.
Kornel

Tôi nhớ có một vấn đề với IE7 vài năm trước khi tôi tìm thấy một thẻ li mở trên một dòng riêng biệt với văn bản chứa trong đó, không có li đóng, IE7 đối xử với tất cả các viên đạn như một viên đạn lớn. đặt thẻ và văn bản trên một dòng hoặc đóng thẻ sẽ khắc phục sự cố. Tôi dường như không thể chế lại điều này ngay bây giờ, vì vậy có lẽ nó cũng có liên quan đến css đang chơi. nhưng tôi sẽ không trách bạn vì đã coi đây là "tôi hoàn toàn có bạn gái ... ở Canada!" câu chuyện.
MiguelR

0

Nếu bạn đang viết một trình phân tích cú pháp HTML, việc phân tích HTML có bao gồm các thẻ đóng tùy chọn hoặc HTML không có dễ dàng hơn không? Tôi nghĩ rằng các thẻ đóng tùy chọn có mặt sẽ làm cho nó dễ dàng hơn, vì tôi sẽ không phải suy ra vị trí của thẻ đóng.

Vì lý do đó, tôi luôn bao gồm các thẻ đóng tùy chọn - theo lý thuyết rằng trang của tôi có thể hiển thị nhanh hơn, vì tôi đang tạo ra ít công việc hơn cho trình phân tích cú pháp HTML của trình duyệt.


1
Tôi không đồng ý; khái niệm về sự hình thành tốt trái ngược với tính hợp lệ là một khái niệm chỉ có XML và trở nên không liên quan khi bạn có các yếu tố mà các thẻ đóng bị cấm .
Richard JP Le Guen

1
Tôi hiểu điều đó, nhưng phần tử DOM được kết xuất có cả phần đầu và phần cuối, ngay cả khi thẻ HTML của bạn không có. Nếu bạn bao gồm một <li>thẻ không có thẻ đóng, đến một lúc nào đó trình duyệt sẽ phải quyết định nơi phần tử kết thúc và hành động như thể bạn đã đặt thẻ kết thúc tại thời điểm đó. Đây có thể là một lượng logic tương đối tầm thường, nhưng "một số" vẫn còn hơn "không" và tôi không nghĩ rằng thật vô lý khi cho rằng bỏ đi các thẻ kết thúc tùy chọn sẽ làm việc cho trình duyệt nhiều hơn so với bao gồm cả chúng.
Joel Mueller

Đó là một điểm thú vị nhưng tôi vẫn không đồng ý; các thẻ gần như là không bắt buộc họ sẽ được yêu cầu và do đó tiềm ẩn theo quy tắc xác nhận ... vì vậy khi phân tích cú pháp đạt đến một điểm mà ở đó trở thành một thẻ đóng theo xác nhận, không thể nó được lập luận rằng nhiệm vụ tiêu thụ một thẻ đóng (khi có mặt) sẽ làm nó chậm lại?
Richard JP Le Guen

@Richard - Tôi đoán điều đó phụ thuộc vào việc triển khai thực tế trong một trình duyệt cụ thể, nhưng tôi gặp khó khăn khi tin rằng ý tưởng rõ ràng về nơi bạn muốn một yếu tố kết thúc sẽ tệ hơn về hiệu suất so với việc trình duyệt tìm ra nó bạn.
Joel Mueller

@RichardJPLeGuen Tôi đoán, tất cả phụ thuộc vào chính xác các quy tắc trông như thế nào. Khi bạn đóng một </table>ngăn xếp và ngăn xếp của bạn chứa <table><tbody><tr><td>, thì bạn có thể chỉ cần đóng mọi thứ cho đến khi bạn khớp với <table>. Tương tự như vậy để mở <p>trong một bối cảnh không đồng hồ. Nhưng có thể có nhiều trường hợp khó hơn, tôi không biết.
maaartinus

-1

Làm bất cứ điều gì bạn cảm thấy làm cho mã dễ đọc và dễ bảo trì hơn.

Cá nhân tôi sẽ luôn có xu hướng đóng <td><tr>, nhưng tôi sẽ không bao giờ bận tâm đến <li>.


1
tôi đã hy vọng một số hướng dẫn về quyết định thiết kế ban đầu, và rằng họ sẽ thực hiện x nếu họ có thể.
Ian Boyd

Sự khác biệt giữa <td><li>điều đó khiến bạn không bận tâm là <li>gì? Đối với tôi, có rất ít sự khác biệt.
ghoppe

Không có sự khác biệt về kỹ thuật, nó hoàn toàn chủ quan. Tôi cảm thấy mình có thể đọc HTML tốt hơn nếu đóng td và tr. Nhưng tôi chưa bao giờ cảm thấy cần thiết với li.
Matthew Wilson

-2

Đối với các kiểu đóng bị cấm sử dụng cú pháp như: <img />Với việc />đóng thẻ được chấp nhận trong xml


1
Nó không hoạt động trong HTML4 (nó phù hợp với cú pháp SGML tối nghĩa làm một cái gì đó hơi khác). Trong HTML5, điều đó được cho phép, nhưng vô nghĩa.
Kornel
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.