Thuộc tính tùy chỉnh - Yea hay nay?


254

Gần đây tôi đã đọc nhiều hơn về những người sử dụng các thuộc tính tùy chỉnh trong các thẻ HTML của họ, chủ yếu cho mục đích nhúng một số bit dữ liệu bổ sung để sử dụng trong mã javascript.

Tôi đã hy vọng thu thập một số thông tin phản hồi về việc có sử dụng các thuộc tính tùy chỉnh hay không là một cách thực hành tốt và cũng là một số lựa chọn thay thế.

Có vẻ như nó thực sự có thể đơn giản hóa cả mã phía máy chủ và mã phía máy khách, nhưng nó cũng không tuân thủ W3C.

Chúng ta có nên sử dụng các thuộc tính HTML tùy chỉnh trong các ứng dụng web của mình không? Tại sao hay tại sao không?

Đối với những người nghĩ thuộc tính tùy chỉnh là một điều tốt: một số điều cần lưu ý khi sử dụng chúng là gì?

Đối với những người nghĩ rằng các thuộc tính tùy chỉnh là điều xấu: bạn sử dụng những lựa chọn thay thế nào để thực hiện một cái gì đó tương tự?

Cập nhật: Tôi chủ yếu quan tâm đến lý do đằng sau các phương pháp khác nhau, cũng như các điểm về lý do tại sao một phương pháp tốt hơn phương pháp khác. Tôi nghĩ rằng tất cả chúng ta có thể đưa ra 4-5 cách khác nhau để hoàn thành cùng một điều. (các yếu tố ẩn, tập lệnh nội tuyến, lớp bổ sung, phân tích thông tin từ id, v.v.).

Cập nhật 2: Có vẻ như data-tính năng thuộc tính HTML 5 có rất nhiều hỗ trợ ở đây (và tôi có xu hướng đồng ý, nó trông giống như một tùy chọn chắc chắn). Cho đến nay tôi đã không thấy nhiều trong cách phản bác cho đề nghị này. Có bất kỳ vấn đề / cạm bẫy để lo lắng về việc sử dụng phương pháp này? Hay nó chỉ đơn giản là sự vô hiệu 'vô hại' của thông số kỹ thuật W3C hiện tại?


Thành thật mà nói, lập trường ban đầu của tôi là chúng không phải là một điều xấu, điều này có thể gây tranh cãi với những người theo chủ nghĩa thuần túy. Tôi cảm thấy như tôi thực sự cần phải ngồi xuống và đánh giá tất cả các tùy chọn có sẵn để sao lưu chính xác điều này, do đó, do đó cần phải viết bài luận dài.
Paolo Bergantino

Để làm điều đó, bạn có thể chỉ cần một số ví dụ ngược lại: về những gì bạn đang cố gắng thực hiện, làm thế nào thuận tiện để làm điều đó với các thuộc tính tùy chỉnh và tại sao giải pháp đó tốt hơn không tệ hơn các giải pháp khác mà không có thuộc tính tùy chỉnh.
ChrisW

@ChrisW Tôi yêu cầu chủ yếu là quan tâm, không phải từ một số ứng dụng cụ thể.
TM.

Chà, có rất nhiều tùy chọn để đưa dữ liệu về phía máy khách: các trường đầu vào ẩn, danh sách định nghĩa ẩn, lớp, plugin siêu dữ liệu, có một từ điển Javascript (đối tượng) lớn với tất cả ánh xạ dữ liệu riêng, thuộc tính tùy chỉnh, thuộc tính dữ liệu ( HTML5), v.v. Tôi muốn khám phá tất cả những điều này, xem xét giá trị của chúng, cạm bẫy của chúng và cuối cùng đi đến kết luận. Bài viết này cuối cùng đã khiến tôi bắt đầu viết này. :) Nên được thực hiện vào khoảng thời gian trước năm 2010
Paolo Bergantino

2
@Paolo bạn không thể chỉ nói rằng bạn đã viết một bài luận trả lời câu hỏi này mà không cho chúng tôi liên kết. Không mát mẻ.
Connell

Câu trả lời:


253

HTML 5 rõ ràng cho phép các thuộc tính tùy chỉnh bắt đầu bằng data. Vì vậy, ví dụ, <p data-date-changed="Jan 24 5:23 p.m.">Hello</p>là hợp lệ. Vì nó chính thức được hỗ trợ bởi một tiêu chuẩn, tôi nghĩ rằng đây là tùy chọn tốt nhất cho các thuộc tính tùy chỉnh. Và nó không yêu cầu bạn quá tải các thuộc tính khác với hack, vì vậy HTML của bạn có thể duy trì ngữ nghĩa.

Nguồn: http://www.w3.org/TR/html5/dom.html#embpping-custom-non-visible-data-with-the-data-*-attribut


Đây là một cách tiếp cận tốt .. Nhưng tôi nghi ngờ rằng nó sẽ hoạt động khi bạn phải hỗ trợ IE 6 và các trình duyệt cũ khác.
cllpse

8
Tôi khá chắc chắn rằng nó hoạt động với các trình duyệt cũ hơn; các thuộc tính được thêm vào DOM, nơi bạn có thể truy cập chúng.
Ms2ger

12
Nó hoạt động hoàn toàn tốt với tất cả các trình duyệt sử dụng phương thức getAttribution () trên HTMLEuity. Ngoài ra, khi hỗ trợ bộ dữ liệu HTML5 phát triển, bạn có thể dễ dàng thêm nó vào.
ajm

1
@Chuck rõ ràng bạn có thể thêm Thuộc tính vào DOCTYPE: Rodsdot.com/html/ Khăn - không phải tôi nghĩ đó là một ý tưởng hay, nhưng có vẻ như đã được chuẩn hóa.
Michael Stum

2
@Wahnfrieden: w3.org/TR/REC-html40/intro/sgmltut.html#idx-attribution-8 là phương pháp tuân thủ tiêu chuẩn được phê duyệt. Điều này cũng được mô tả và chứng minh ở đây: Rodsdot.com/html/ Từ Như những người khác đã đăng trước đó.
ndivilbiss

95

Đây là một kỹ thuật tôi đã sử dụng gần đây:

<div id="someelement">

    <!-- {
        someRandomData: {a:1,b:2},
        someString: "Foo"
    } -->

    <div>... other regular content...</div>
</div>

Đối tượng nhận xét liên kết với phần tử cha (ví dụ #someelement).

Đây là trình phân tích cú pháp: http://pastie.org/511353

Để lấy dữ liệu cho bất kỳ phần tử cụ thể nào, chỉ cần gọi parseDatavới tham chiếu đến phần tử đó được truyền dưới dạng đối số duy nhất:

var myElem = document.getElementById('someelement');

var data = parseData( myElem );

data.someRandomData.a; // <= Access the object staight away

Nó có thể ngắn gọn hơn thế:

<li id="foo">
    <!--{specialID:245}-->
    ... content ...
</li>

Truy cập nó:

parseData( document.getElementById('foo') ).specialID; // <= 245

Nhược điểm duy nhất của việc sử dụng này là nó không thể được sử dụng với các phần tử tự đóng (ví dụ <img/>), vì các nhận xét phải nằm trong phần tử được coi là dữ liệu của phần tử đó.


CHỈNH SỬA :

Lợi ích đáng chú ý của kỹ thuật này:

  • Dễ để thực hiện
  • Liệu không vô hiệu HTML / XHTML
  • Dễ sử dụng / hiểu (ký hiệu JSON cơ bản)
  • Không phô trương và sạch hơn về mặt ngữ nghĩa so với hầu hết các lựa chọn thay thế

Đây là mã trình phân tích cú pháp (được sao chép từ siêu liên kết http://pastie.org/511353 ở trên, trong trường hợp nó không bao giờ có sẵn trên pastie.org):

var parseData = (function(){

    var getAllComments = function(context) {

            var ret = [],
                node = context.firstChild;

            if (!node) { return ret; }

            do {
                if (node.nodeType === 8) {
                    ret[ret.length] = node;
                }
                if (node.nodeType === 1) {
                    ret = ret.concat( getAllComments(node) );
                }
            } while( node = node.nextSibling );

            return ret;

        },
        cache = [0],
        expando = 'data' + +new Date(),
        data = function(node) {

            var cacheIndex = node[expando],
                nextCacheIndex = cache.length;

            if(!cacheIndex) {
                cacheIndex = node[expando] = nextCacheIndex;
                cache[cacheIndex] = {};
            }

            return cache[cacheIndex];

        };

    return function(context) {

        context = context || document.documentElement;

        if ( data(context) && data(context).commentJSON ) {
            return data(context).commentJSON;
        }

        var comments = getAllComments(context),
            len = comments.length,
            comment, cData;

        while (len--) {
            comment = comments[len];
            cData = comment.data.replace(/\n|\r\n/g, '');
            if ( /^\s*?\{.+\}\s*?$/.test(cData) ) {
                try {
                    data(comment.parentNode).commentJSON =
                        (new Function('return ' + cData + ';'))();
                } catch(e) {}
            }
        }

        return data(context).commentJSON || true;

    };

})();

2
Vì tò mò, bạn sử dụng phương pháp nào cho các thẻ tự đóng? Tôi thường cần sử dụng một cái gì đó như thế này trên các phần tử <input> (để hỗ trợ các quy tắc xác thực phía máy khách). Bạn thay thế gì trong tình huống đó?
TM.

2
Có lẽ tôi đã sử dụng một kỹ thuật tương tự, thay vì dữ liệu nhận xét gắn vào "chaNode", nó có thể liên kết với "trước đây" của nhận xét ... Sau đó, bạn có thể có nhận xét ngay sau <input /> và nó sẽ công việc: <input /> <! - {data: 123} ->
James

7
ai đó nên biến nó thành một plugin jquery
SeanDowney

10
Nhận xét có thể được thay đổi / xóa mà không phá vỡ bất cứ điều gì. Đó là toàn bộ vấn đề. Vì vậy, đó là một ý tưởng tồi để đưa bất cứ điều gì quan trọng vào đánh dấu hoặc mã vào bình luận. Các nhà phát triển trong tương lai có thể dễ dàng nghĩ rằng họ là những bình luận và xóa chúng. Chúng tôi đã có một giải pháp thực sự cho câu hỏi này: các thuộc tính tùy chỉnh có tiền tố là "data-". Cách tiếp cận này không bao giờ nên được sử dụng.
MGOwen

6
Hãy để tôi củng cố tuyên bố của @MGOwen: không sử dụng nhận xét để thêm chức năng. Đặc biệt trong HTML. Bạn không sử dụng công cụ khai thác? Bạn sẽ không thể xóa bình luận mà không phá vỡ mã của bạn. Điều này cũng có nghĩa là bạn không thể thêm ý kiến ​​thực sự nữa.
Olivictor

15

Bạn có thể tạo bất kỳ thuộc tính nào nếu bạn chỉ định một lược đồ cho trang của mình.

Ví dụ:

Thêm điều này

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:addthis="http://www.addthis.com/help/api-spec">
...
<a addthis:title="" addthis:url="" ...>

Facebook (thẻ chẵn)

<html xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb="http://www.facebook.com/2008/fbml">
...
<fb:like href="http://developers.facebook.com/" width="450" height="80"/>

10

Cách dễ nhất để tránh sử dụng các thuộc tính tùy chỉnh là sử dụng các thuộc tính hiện có.

sử dụng tên lớp có ý nghĩa, có liên quan.
Ví dụ: làm một cái gì đó như: type='book'type='cd', để đại diện cho sách và đĩa CD. Các lớp học tốt hơn nhiều để đại diện cho những gì IS .

ví dụ class='book'

Tôi đã sử dụng các thuộc tính tùy chỉnh trong quá khứ, nhưng thành thực mà nói, thực sự không cần thiết cho chúng nếu bạn sử dụng các thuộc tính hiện có theo cách có ý nghĩa về mặt ngữ nghĩa.

Để đưa ra một ví dụ cụ thể hơn, giả sử bạn có một trang web cung cấp liên kết đến các loại cửa hàng khác nhau. Bạn có thể sử dụng như sau:

<a href='wherever.html' id='bookstore12' class='book store'>Molly's books</a>
<a href='whereverelse.html' id='cdstore3' class='cd store'>James' Music</a>

kiểu css có thể sử dụng các lớp như:

.store { }
.cd.store { }
.book.store { }

Trong ví dụ trên, chúng tôi thấy rằng cả hai đều là liên kết đến các cửa hàng (trái ngược với các liên kết không liên quan khác trên trang web) và một là cửa hàng cd và hai là cửa hàng sách.


4
Điểm hay, nhưng công bằng mà nói, "loại" chỉ hợp lệ trên một số thẻ nhất định và khi nó là thuộc tính hợp lệ, nó cũng có một danh sách các giá trị hợp lệ, do đó bạn vẫn không thực sự tuân thủ w3c.
TM.

1
quan điểm của tôi là bạn KHÔNG nên sử dụng thẻ loại cho việc này. do đó, nếu bạn là ... thì bạn nên ... Tôi sẽ chỉnh sửa để làm cho rõ ràng hơn
Jonathan Fingerland

Tôi có xu hướng làm cho các thuộc tính "đẳng cấp" của mình có hương vị bằng cách thêm một số trong số chúng được gắn thêm một số loại "vòng loại-". đối với các div chỉ liên quan đến bố cục, tôi sẽ có lớp là "layout-xxx" hoặc đối với các div bên trong bao quanh một phần quan trọng, như sách hoặc cửa hàng, tôi sẽ có một cuốn sách nội dung hoặc cửa hàng nội dung . sau đó trong JavaScript của tôi, tôi có một chức năng bổ sung những thứ đó vào thẻ dựa trên những gì tôi đang tìm kiếm. nó giúp giữ mọi thứ sạch sẽ và có tổ chức cho tôi, nhưng đòi hỏi một mức độ kỷ luật và tổ chức trước nhất định.
Ape-inago

2
@Jonathan điều hai lớp hoạt động tuyệt vời ngoại trừ trong trường hợp 'giá trị' không được biết đến. Ví dụ: nếu đó là một loại id số nguyên, chúng tôi không thể chọn tốt cho mọi trường hợp có thể. Sau đó, chúng tôi còn lại để phân tích thuộc tính lớp một cách thủ công, điều này chắc chắn có thể thực hiện được, nhưng không rõ ràng trong mã và trong một số trường hợp, có thể rất chậm (nếu có nhiều yếu tố ứng cử viên để phân tích cú pháp).
TM.

2
thật đáng buồn, việc viết các bộ chọn css cho hai lớp cùng một lúc (.ab thông báo trống bị thiếu) không hoạt động trong IE. Nó không hoạt động trong firefox và các trình duyệt khác. Tuy nhiên, sử dụng các lớp là một cách tuyệt vời để thêm ý nghĩa ngữ nghĩa bổ sung vào đánh dấu của bạn
knittl

6

Nhúng dữ liệu vào dom và sử dụng siêu dữ liệu cho jQuery .

Tất cả các plugin tốt đều hỗ trợ plugin siêu dữ liệu (cho phép mỗi tùy chọn thẻ).

Nó cũng cho phép cấu trúc dữ liệu / dữ liệu vô cùng phức tạp, cũng như các cặp khóa-giá trị.

<li class="someclass {'some': 'random,'json':'data'} anotherclass">...</li>

HOẶC LÀ

<li class="someclass" data="{'some':'random', 'json': 'data'}">...</li>

HOẶC LÀ

<li class="someclass"><script type="data">{"some":"random","json":"data"}</script> ...</li>

Sau đó lấy dữ liệu như vậy:

var data = $('li.someclass').metadata();
if ( data.some && data.some == 'random' )
alert('It Worked!');

22
Tham nhũng thuộc tính lớp khi có cách xác định thuộc tính tùy chỉnh được W3C phê duyệt có lẽ là lý do khiến bạn bị bỏ phiếu.
ndivilbiss

2
làm hỏng thuộc tính lớp chỉ là một trong những cách sử dụng plugin; nó không phải là cách duy nhất
antony.trupe

1
Một lý do khác khiến bạn bỏ phiếu xuống là đề xuất một plugin mà không cần plugin nào cả.
meandre

4

Tôi thấy không có vấn đề gì trong việc sử dụng các tính năng XHTML hiện tại mà không phá vỡ bất cứ điều gì hoặc mở rộng không gian tên của bạn. Hãy xem một ví dụ nhỏ:

<div id="some_content">
 <p>Hi!</p>
</div>

Làm cách nào để thêm thông tin bổ sung vào some_content mà không cần thuộc tính bổ sung? Điều gì về việc thêm một thẻ khác như sau?

<div id="some_content">
 <div id="some_content_extended" class="hidden"><p>Some alternative content.</p></div>
 <p>Hi!</p>
</div>

Nó giữ mối quan hệ thông qua một id / phần mở rộng được xác định rõ "_extends" của sự lựa chọn của bạn và theo vị trí của nó trong hệ thống phân cấp. Tôi thường sử dụng cách tiếp cận này cùng với jQuery và không thực sự sử dụng các kỹ thuật như Ajax.


2
Vấn đề với việc thêm các thẻ lồng nhau như thế này là nó có xu hướng tạo mã máy chủ RẤT cồng kềnh và xấu xí (JSP / ASP / DTL, v.v.)
TM.

3

Không. Thay vào đó hãy thử một cái gì đó như thế này:

<div id="foo"/>

<script type="text/javascript">
  document.getElementById('foo').myProperty = 'W00 H00! I can add JS properties to DOM nodes without using custom attributes!';
</script>

1
Vì vậy, bạn thích viết nhiều thẻ script hơn trên tài liệu của mình cho các trang động? Tôi sẽ sử dụng các bài tập javascript thủ công khi thông tin đang được thêm vào phía máy khách, nhưng vấn đề này chủ yếu là về những gì sẽ hiển thị trên máy chủ. Ngoài ra, jQuery.data () tốt hơn nhiều so với phương thức của bạn.
TM.

Câu trả lời ở trên là một ví dụ độc lập với khung, để chứng minh chức năng. Bạn có thể dễ dàng mở rộng dựa trên ý chính của nó để làm cho mã khá ngắn gọn. Ví dụ: <div id = "foo" /> <div id = "bar" /> <div id = "baz" /> <script type = "text / javascript"> xtrnlFnc ({foo: 'w00 h00', bar : 'vv', baz: 3.14159}); </ script> Nếu bạn đang sử dụng jQuery (không phải là bạn đã đề cập đến nó trong câu hỏi ban đầu của bạn), bằng mọi cách, hãy sử dụng phương thức dữ liệu - đó là những gì nó dùng. Nếu không, truyền dữ liệu giữa các lớp kiến ​​trúc là việc sử dụng hoàn toàn hợp lệ các thẻ script nội tuyến.
Anon

Đó chắc chắn là một lựa chọn rõ ràng, hợp lệ. Theo tôi, nó chỉ làm xáo trộn mã lên nhiều hơn nhiều so với các lựa chọn thay thế khác không sử dụng các thuộc tính tùy chỉnh. Và để rõ ràng, tôi không cố tỏ ra chống đối hay thô lỗ, tôi chỉ cố gắng dỗ dành một số lý do của bạn như lý do tại sao bạn thích phương pháp này. Bạn đã cung cấp một giải pháp thay thế nhưng đó thực sự không phải là câu hỏi.
TM.

1
Tôi không nghĩ rằng có một vấn đề với cách tiếp cận này phá vỡ các trình duyệt. Microsoft sử dụng cơ chế chính xác này vì đây là cơ chế ưa thích trong các trang ASP.NET. (bằng cách gọi RegisterExpandoAttribution ở phía máy chủ). Câu hỏi dường như tập trung vào máy khách chứ không phải máy chủ, nhưng về phía máy chủ, tất cả các cách tiếp cận này có thể được (nên là?).
Adrian

3
Ưu điểm của phương pháp này: - Nó tạo ra đánh dấu hợp lệ (ngay cả dưới các trình duyệt / thông số kỹ thuật cũ). - Nó làm cho ý định của dữ liệu (được tiêu thụ bởi JS) rõ ràng. - Nó được gắn kết với các yếu tố mà không sử dụng thông minh các tính năng khác (chẳng hạn như nhận xét). - Nó không yêu cầu phân tích đặc biệt. Từ góc độ phía máy chủ, bạn có thể nghĩ nó giống như một RPC.
hấp25

2

Tôi không sử dụng các thuộc tính tùy chỉnh, vì tôi đang xuất XHTML, vì tôi muốn dữ liệu có thể đọc được bằng máy bởi phần mềm của bên thứ 3 (mặc dù, tôi có thể mở rộng lược đồ XHTML nếu tôi muốn).

Thay thế cho các thuộc tính tùy chỉnh, chủ yếu tôi đang tìm các thuộc tính id và lớp (ví dụ như được đề cập trong các câu trả lời khác) là đủ.

Ngoài ra, hãy xem xét điều này:

  • Nếu dữ liệu bổ sung có thể đọc được bằng con người cũng như có thể đọc bằng máy, thì nó cần được mã hóa bằng cách sử dụng các thẻ và văn bản HTML (hiển thị) thay vì làm thuộc tính tùy chỉnh.

  • Nếu nó không cần phải có thể đọc được, thì có lẽ nó có thể được mã hóa bằng các thẻ và văn bản HTML vô hình .

Một số người tạo một ngoại lệ: họ cho phép các thuộc tính tùy chỉnh, được thêm vào DOM bằng Javascript ở phía máy khách vào thời gian chạy. Họ cho rằng điều này là ổn: vì các thuộc tính tùy chỉnh chỉ được thêm vào DOM vào thời gian chạy, HTML không chứa thuộc tính tùy chỉnh.


1

Chúng tôi đã tạo một trình soạn thảo dựa trên web để hiểu một tập hợp con của HTML - một tập hợp con rất nghiêm ngặt (được hiểu gần như phổ biến bởi các ứng dụng thư). Chúng ta cần thể hiện những thứ như <td width="@INSWIDTH_42@">trong cơ sở dữ liệu, nhưng chúng ta không thể có trong DOM, nếu không thì trình duyệt nơi trình soạn thảo chạy, sẽ bị lỗi (hoặc có nhiều khả năng bị hoảng loạn hơn là có khả năng phát hiện ra các thuộc tính tùy chỉnh) . Chúng tôi muốn kéo và thả, do đó, việc đưa nó hoàn toàn vào DOM đã bị loại bỏ, cũng như jquery .data()(dữ liệu bổ sung không được sao chép đúng cách). Chúng tôi có lẽ cũng cần thêm dữ liệu để đi cùng .html(). Cuối cùng, chúng tôi đã quyết định sử dụng <td width="1234" rs-width="@INSWIDTH_42@">trong quá trình chỉnh sửa, và sau đó khi chúng tôi ĐĂNG tất cả, chúng tôi xóa widthvà thực hiện tìm kiếm và hủy bỏ regex s/rs-width=/width=/g.

Lúc đầu, anh chàng viết phần lớn trong số này là xác nhận về vấn đề này và đã thử mọi cách để tránh thuộc tính tùy chỉnh của chúng tôi, nhưng cuối cùng đã chấp nhận khi dường như không có gì khác phù hợp với TẤT CẢ yêu cầu của chúng tôi. Nó giúp ích khi anh ta nhận ra rằng thuộc tính tùy chỉnh sẽ không bao giờ xuất hiện trong email Chúng tôi đã xem xét mã hóa dữ liệu bổ sung của chúng tôi class, nhưng quyết định đó sẽ là tệ nạn lớn hơn trong hai tệ nạn.

Cá nhân, tôi thích có mọi thứ sạch sẽ và thông qua các trình xác nhận, v.v. độ tinh khiết kỹ thuật. Công cụ nên làm việc cho chúng tôi; không phải chúng tôi cho họ.


1

Tôi biết mọi người chống lại nó, nhưng tôi đã đưa ra một giải pháp siêu ngắn cho việc này. Nếu bạn muốn sử dụng một thuộc tính tùy chỉnh như "của tôi", ví dụ:

<a href="test.html" mine-one="great" mine-two="awesome">Test</a>

Sau đó, bạn có thể chạy mã này để lấy lại một đối tượng giống như jquery.data ().

var custom_props = {} ;
$.each($(".selector")[0].attributes, function(i,x) {
    if (this.specified && x.name.indexOf("mine-") !== -1) 
        self.new_settings[x.name.replace("modal-","")] = x.value;
});

0

Spec: Tạo một điều khiển ASP.NET TextBox tự động định dạng văn bản của nó thành một số, theo các thuộc tính "DecimalSpayator" và "ThousandsSpayator", sử dụng JavaScript.


Một cách để chuyển các thuộc tính này từ điều khiển sang JavaScript là điều khiển hiển thị các thuộc tính tùy chỉnh:

<input type="text" id="" decimalseparator="." thousandsseparator="," />

Thuộc tính tùy chỉnh có thể dễ dàng truy cập bằng JavaScript. Và trong khi một trang sử dụng các thành phần có thuộc tính tùy chỉnh sẽ không xác thực , việc hiển thị trang đó sẽ không bị ảnh hưởng.


Tôi chỉ sử dụng phương pháp này khi tôi muốn liên kết các loại đơn giản như chuỗi và số nguyên với các phần tử HTML để sử dụng với JavaScript. Nếu tôi muốn làm cho các phần tử HTML dễ xác định hơn, tôi sẽ sử dụng các thuộc tính lớpid .


0

Đối với các ứng dụng web phức tạp, tôi bỏ các thuộc tính tùy chỉnh ở mọi nơi.

Đối với các trang đối diện công khai hơn, tôi sử dụng thuộc tính "rel" và kết xuất tất cả dữ liệu của mình trong JSON và sau đó giải mã nó bằng MooTools hoặc jQuery:

<a rel="{color:red, awesome:true, food: tacos}">blah</a>

Gần đây tôi đang cố gắng gắn bó với thuộc tính dữ liệu HTML 5 chỉ để "chuẩn bị", nhưng nó vẫn chưa đến một cách tự nhiên.


-1

Tôi sử dụng các trường tùy chỉnh mọi lúc, ví dụ <ai = "" .... Sau đó, tham chiếu đến i với jquery. Html không hợp lệ Nó hoạt động tốt, vâng.


Một cái gì đó trông như mất tích ở đây. Thẻ của bạn đã hoàn thành chưa?
Stuart Siegler

Làm thế nào bất cứ ai có thể hiểu điều này? Hãy hoàn thành câu trả lời của bạn.
Rahul Raj

-2

Thuộc tính tùy chỉnh, theo ý kiến ​​khiêm tốn của tôi, không nên được sử dụng vì chúng không xác nhận. Thay vào đó, bạn có thể định nghĩa nhiều lớp cho một thành phần như:

<div class='class1 class2 class3'>
    Lorem ipsum
</div>

10
Cá nhân, tôi nghĩ rằng đây là một ví dụ khủng khiếp. tên lớp của bạn xác định giao diện của nó, không phải mục đích của nó. Hãy suy nghĩ về thời điểm bạn muốn thay đổi tất cả các div tương tự ... bạn phải đi và thay đổi tất cả chúng thành span-11 hoặc tương tự. các lớp nên định nghĩa nó là gì. các tờ phong cách sẽ xác định cách những thứ đó trông như thế nào
Jonathan Fingerland

Làm thế nào bạn sẽ sử dụng phương pháp này để chỉ định nhiều hơn là một cờ? Tôi có xu hướng đồng ý với lập trường của bạn và tôi không sử dụng các thuộc tính tùy chỉnh (mặc dù tôi đang xem xét nó). Ưu điểm của việc có một cặp khóa / giá trị có vẻ khá tiện dụng hơn một chút so với việc thêm một lớp khác.
TM.

@Jonathan Fingerland: Nếu La bàn được sử dụng, bạn không cần đặt tên lớp ở đây. Bạn chỉ có thể chỉ định chúng trong tệp .sass và đánh dấu của bạn sẽ sạch.
Alan Haggai Alavi

@Jonathan Fingerland, classthuộc tính chắc chắn không chỉ dành riêng cho "ngoại hình". Một cách sử dụng khác là "xử lý mục đích chung bởi các tác nhân người dùng". Điều này nói lên thông số kỹ thuật: w3.org/TR/REC-html40/struct/global.html#h-7.5.2
npup

@npup: sự lựa chọn thú vị của dấu ngoặc kép. Như tôi đã nói cách đây hơn một năm, các biểu định kiểu xác định cách những thứ đó sẽ trông như thế nào (cũng như thuộc tính kiểu, tôi sẽ thêm) và thuộc tính lớp được sử dụng để xác định mục đích của phần tử. Đó là, nó đặc biệt được sử dụng để xác định nó là gì, chứ không phải nó LOOKS như thế nào. Tôi nghĩ rằng bạn có thể đã đọc sai những gì tôi nói, vì chúng tôi đồng ý với những gì tôi có thể nói.
Jonathan Fingerland
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.