Thuộc tính không chuẩn trên thẻ HTML. Điều tốt? Điều tồi tệ? Suy nghĩ của bạn?

HTML (hoặc có thể chỉ là XHTML?) Tương đối nghiêm ngặt khi nói đến các thuộc tính không chuẩn trên thẻ. Nếu chúng không phải là một phần của thông số kỹ thuật, thì mã của bạn được coi là không tuân thủ.

Tuy nhiên, các thuộc tính không chuẩn có thể khá hữu ích để truyền siêu dữ liệu sang Javascript. Ví dụ: nếu một liên kết được cho là hiển thị cửa sổ bật lên, bạn có thể đặt tên của cửa sổ bật lên trong một thuộc tính:

<a href="#null" class="popup" title="See the Popup!" 
   popup_title="Title for My Popup">click me</a>

Ngoài ra, bạn có thể lưu trữ tiêu đề cho cửa sổ bật lên trong một phần tử ẩn, như một khoảng:

<style>
    .popup .title { display: none; }
</style>
<a href="#null" title="See the Popup!" class="popup">
    click me
    <span class="title">Title for My Popup</span>
</a>

Tuy nhiên, tôi bị rách vì đó nên là một phương pháp ưu tiên. Phương pháp đầu tiên ngắn gọn hơn và tôi đoán là không ảnh hưởng nhiều đến các công cụ tìm kiếm và trình đọc màn hình. Ngược lại, tùy chọn thứ hai giúp lưu trữ một lượng lớn dữ liệu dễ dàng hơn và do đó, linh hoạt hơn. Nó cũng tuân thủ các tiêu chuẩn.

Tôi tò mò những gì cộng đồng này suy nghĩ. Làm thế nào để bạn xử lý một tình huống như thế này? Sự đơn giản của phương pháp đầu tiên có vượt trội hơn những nhược điểm tiềm ẩn (nếu có) không?

Tôi là một fan hâm mộ lớn của giải pháp HTML 5 được đề xuất ( data-các thuộc tính có tiền tố). Chỉnh sửa: Tôi muốn nói thêm rằng có lẽ có nhiều ví dụ tốt hơn cho việc sử dụng các thuộc tính tùy chỉnh. Ví dụ: dữ liệu mà một ứng dụng tùy chỉnh sẽ sử dụng không có dữ liệu tương tự trong các thuộc tính tiêu chuẩn (ví dụ: tùy chỉnh cho trình xử lý sự kiện dựa trên một cái gì đó không nhất thiết phải được thể hiện trong className hoặc id).

Các thuộc tính tùy chỉnh cung cấp một cách thuận tiện để mang thêm dữ liệu cho phía khách hàng. Bộ công cụ Dojo đang làm điều này thường xuyên và nó đã được chỉ ra ( Gỡ lỗi lầm tưởng của bộ công cụ Dojo ) chỉ ra rằng:

Các thuộc tính tùy chỉnh luôn là HTML hợp lệ, chúng chỉ không xác thực khi được kiểm tra với DTD. [...] Đặc tả HTML tuyên bố rằng bất kỳ thuộc tính nào không được công nhận sẽ bị công cụ kết xuất HTML bỏ qua trong tác nhân người dùng và Dojo tùy ý tận dụng điều này để cải thiện tính dễ phát triển.

Một tùy chọn khác sẽ là xác định một cái gì đó như thế này trong Javascript:

<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>

Sau đó, bạn có thể sử dụng điều này sau trong mã Javascript của mình, giả sử liên kết của bạn có ID tương ứng với ID trong bảng băm này.

Nó không có nhược điểm của hai phương pháp còn lại: không có thuộc tính không chuẩn cũng như khoảng ẩn xấu xí.

Điểm bất lợi là nó có thể hơi quá mức cần thiết cho những thứ đơn giản như ví dụ của bạn. Nhưng đối với các tình huống phức tạp hơn, nơi bạn có nhiều dữ liệu hơn để vượt qua, đó là một lựa chọn tốt. Đặc biệt khi xem xét dữ liệu đang được truyền dưới dạng JSON, vì vậy bạn có thể truyền các đối tượng phức tạp một cách dễ dàng.

Ngoài ra, bạn giữ dữ liệu tách biệt với định dạng, đó là một điều tốt cho khả năng bảo trì.

Bạn thậm chí có thể có một cái gì đó như thế này (mà bạn thực sự không thể làm được với các phương pháp khác):

var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};

...

<a id="poi-2" href="/poi/2/">Hatsune</a>

Và vì hầu hết bạn có thể sử dụng một số ngôn ngữ lập trình phía máy chủ, bảng băm này sẽ rất nhỏ để tạo động (chỉ cần tuần tự hóa nó thành JSON và đưa nó vào phần tiêu đề của trang).

Trong trường hợp này, giải pháp tối ưu là

<a href="#" alt="" title="Title of My Pop-up">click</a>

và sử dụng thuộc tính tiêu đề.

Đôi khi tôi phá vỡ thông số kỹ thuật nếu tôi thực sự cần nó. Nhưng hiếm khi, và chỉ vì lý do chính đáng.

CHỈNH SỬA: Không chắc tại sao -1, nhưng tôi đã chỉ ra rằng đôi khi bạn nghĩ rằng bạn cần phải phá vỡ thông số kỹ thuật, khi bạn không.

Tại sao không khai báo thuộc tính popup_title trong DTD tùy chỉnh? Điều này giải quyết vấn đề với xác thực. Tôi làm điều này với mọi phần tử, thuộc tính và giá trị không chuẩn và cảm ơn việc xác thực này chỉ cho tôi thấy các vấn đề thực sự với mã của tôi. Điều này cũng làm cho mọi lỗi trình duyệt ít xảy ra hơn với HTML như vậy.

Bạn có thể lồng các phần tử đầu vào ẩn BÊN TRONG phần tử neo

<a id="anchor_id">
  <input type="hidden" class="articleid" value="5">
  Link text here
</a>

Sau đó, bạn có thể dễ dàng lấy dữ liệu ra bằng cách

$('#anchor_id .articleid').val()

Giải pháp của tôi cuối cùng là ẩn dữ liệu bổ sung trong thẻ id được phân tách bằng một số loại dấu phân cách (một dấu gạch dưới là dấu cách, hai là dấu cuối của đối số đó), đối số thứ hai có id:

<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>

Xấu xí và nó giả định rằng bạn chưa sử dụng thẻ id cho thứ khác, nhưng nó tuân thủ trên mọi trình duyệt.

Cảm nhận cá nhân của tôi trong ví dụ của bạn là lộ trình nhịp thích hợp hơn, vì nó đáp ứng các tiêu chuẩn của đặc tả XHTML. Tuy nhiên, tôi có thể thấy một phân đoạn cho các thuộc tính tùy chỉnh, nhưng tôi nghĩ chúng thêm một mức độ nhầm lẫn không cần thiết.

Tôi cũng đang vắt óc vì chuyện này. Tôi thích khả năng đọc của các thuộc tính không chuẩn, nhưng tôi không thích nó sẽ phá vỡ tiêu chuẩn. Ví dụ về nhịp ẩn là tuân thủ, nhưng nó không dễ đọc. Cái này thì sao:

<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>

Ở đây, mã rất dễ đọc, vì ký hiệu cặp khóa / giá trị của JSON. Bạn có thể biết rằng đây là dữ liệu meta thuộc liên kết chỉ bằng cách nhìn vào nó. Lỗ hổng duy nhất mà tôi có thể thấy bên cạnh việc chiếm đoạt thuộc tính "rel" là điều này sẽ trở nên lộn xộn đối với các đối tượng phức tạp. Tôi thực sự thích ý tưởng đó về các thuộc tính có tiền tố "data-" được đề cập ở trên. Có trình duyệt hiện tại nào hỗ trợ điều này không?

Đây là một cái gì đó khác để suy nghĩ về. Mã không tuân thủ có tác động như thế nào đến SEO?