最近一直在困擾我的是使用HTML5 data attributes以及何時適合使用它們。隱藏輸入與HTML5數據屬性
通常，在對我的服務器執行多次AJAX調用的頁面上，我需要代表正在查看的頁面的ID。我目前一直在存儲這個頁面上的隱藏的<input>元素，然後訪問它並存儲在我的jQuery doc ready調用頂部的JS變量中。
我一直在考慮將它移動到body元素上的data-id屬性，然後我可以使用$('body').data('id');在jQuery中訪問它。
使用HTML5數據atttributes或反之亦然有什麼好處？性能？安全？ 「最佳實踐」？
我的理解是數據屬性可以被所有的瀏覽器訪問，所以處理IE不是問題。
因爲數據屬性是新的，所以我不認爲他們什麼時候合適或最佳實踐是否有真正的共識。我個人的感覺是，當你將數據附加到頁面中的DOM元素時，它們會很有意義，因爲它們邏輯上與這些DOM元素一起。當你在使用body標籤時，我想知道爲什麼你不把這些值保存在常規的javascript變量中。我懷疑你會有更好的表現使用常規的JavaScript變量。所有這些變量都可以很容易地在Firebug中查看等等，所以它在這個意義上或多或少是安全的。
關於初始頁面狀態，聽起來好像你可能直接將javascript變量放入頁面中，而不是按照使用方式放入隱藏字段中。如果您將表單發佈到服務器上，那麼隱藏元素可能會很有用，這是隱藏元素的設計目的。
這是一個很好的開放性問題，關於什麼是最佳實踐。
如果從服務器發送正文中的data- *屬性值，該怎麼辦？你不能先知道他們使他們的JavaScript變量。 – sports 2013-04-16 14:12:20
鑑於這個答案是2歲，我認爲在如何使用這些答案方面存在更多共識，是的，我認爲在body標籤或其他任何地方有數據屬性都很好。 – 2013-04-16 19:21:35
Id已經在URL中。可靠地將它從URL中取出是我努力做的事情。這是因爲我目前的路線設置。他們目前是{controller}/{id}/{action}。我正在努力解決這個問題，但這是另一個問題。 – 2011-04-06 01:40:03
我已經使用JavaScript和PHP來提取ID的一個好的正則表達式有時可以幫助 – mcgrailm 2011-04-06 01:41:45
我從來沒有想過要使用正則表達式。感謝您的想法！ – 2011-04-06 01:54:32
這裏的我的看法：
input s的意味着形式用作將數據傳回服務器，而不使其可見，或可編輯的一種方式，在PAG即data-屬性旨在將關於元素的信息傳遞給頁面上的JavaScript。此基礎上，該html或body元素上data-屬性似乎最合適的。
另一種替代方法雖然語義較少，但可以將頁面元數據序列化爲JSON，並使用script標記將其設置爲頁面上的全局變量。例如，您可以在GitHub repositories上看到此操作，其中在頁面頂部附近創建了一個全局對象GitHub，並添加了一些信息（回購名稱，當前分支，最新提交）以便於訪問。
其中一個主要缺點是可訪問性。
由於這些屬性未在POST中提交給服務器，因此您需要記住JavaScript禁用的瀏覽器會發生什麼情況。如果您的頁面也應該能夠正常降級並在必要時通過傳統表單提交執行相同的AJAX請求的功能，則仍然需要隱藏字段。
這就是說，當他們有意義時，我是數據屬性的忠實粉絲，特別是在嚴格的「應用程序」類型網站，你可以安全地命令JavaScript。例如，標記具有data-id屬性的表格行比在其單元中填充隱藏字段更好。尤其是與jQuery對.data()方法的良好數據屬性支持相結合，這使得在隱藏字段可能有點混亂的情況下，提供乾淨，直觀的代碼。
簡而言之數據屬性可被附連到由 屬性所描述的元件，其中區域中的隱藏的輸入不能是另一個DOM元素 內部和它的使用僅限於形式（在良好做法反正） 。 隱藏的輸入是一個實際的DOM元素，而數據屬性很好......屬性，所以它可以綁定到DOM元素。這在大多數情況下，但如果你需要 更多的信息，也許一個例子繼續閱讀，我警告你它有點長，英語不是我的母語。
基本上，數據屬性的創建是爲了向DOM元素添加額外的信息，這些額外的信息無法用現有的屬性（例如類或好的舊ID）附加到它。
這主要影響基於Web的應用程序，或者更具體地說，Saas'對數據驅動的屬性的需求比普通網站（即使CMS背後有CMS）要廣泛得多。
我很多年前，當你只有兩個選擇用來白日夢這個屬性使用在他們的令牌的HTML屬性，將它們與 客戶端或服務器端函數解碼（分裂，剪接，爆炸）
這種方法的問題是在於n無論你如何看待它，你都不是 使用他們的方式，他們的意思和設計使用的HTML屬性。
Html是一種標記語言，因此它不會自然擁有數據驅動屬性 ，您無法使用它來操縱數據處理和行爲。
，我有那麼基本的情況是，我想有一個 jQuery的對話框加載所有的數據輸入表單（客戶，產品，供應商等） 各自與不同的寬度和高度。這樣，客戶端腳本 會小得多，我需要爲每個添加到客戶端請求的應用程序中的新表單添加一個新對話框 。
這是我用來做什麼的數據屬性出現之前：
點擊添加新的產品
在ID令牌中我有3個值：
其他的方法是使用href屬性，但是這是遠遠超過使用id 只是因爲href屬性是爲了指向一個DOM元素或其他來源，沒有任何數據保持於雪上加霜被處理。
兩種方法都涉及使用拆分或類似功能來分解令牌。
這我怎麼做現在的真棒數據屬性：
點擊添加新的產品
這樣，我並不需要一個道理，我就可以得到每個屬性的值 與（'data-form'），$（this）.attr（'data-dwith'）;等等。
恕我直言，我認爲向html元素添加一點額外的數據比創建 更長的JavaScript文件更重，更復雜。
我知道這個帖子一直很活躍已經有一段時間了，但是最近我遇到了這個話題，我想評論兩者的性能方面。
正如其他人指出的那樣，數據屬性用於將數據存儲在DOM本身，並且在HTML5之前有不同的方式通過使用嵌套在DOM中的隱藏輸入或通過使用其他屬性來解決該需求。
由於隱藏的輸入是具有許多其他屬性（佔用更多內存）的DOM對象，因此隱藏的輸入會更加性能密集（尤其是當您擴展它們時）。
與隱藏輸入相比，使用其他屬性的內存效率更高，但可能需要更多處理。您可能需要爲它們加上前綴並使用這些前綴提取數據。另外，設置它們並獲取它們也可能會非常棘手，並且可能會混淆某些元素的默認功能。
所以這裏是我爲自己設定的指導方針，當涉及到在隱藏的輸入和數據屬性之間進行選擇時。
對於這種情況，你爲什麼不寫數據或大量數據時，請選擇隱藏的輸入該ID作爲常規ID屬性？ – elwyn 2011-04-06 02:19:42
@elwyn：我不知道。我從來沒有真正想過。 – 2011-04-06 05:45:01