Niestandardowe atrybuty w tagach HTML. Dobra rzecz? Zła rzecz? Twoje myśli?

HTML (a może tylko XHTML?) Jest stosunkowo surowy, jeśli chodzi o niestandardowe atrybuty tagów. Jeśli nie są częścią specyfikacji, Twój kod jest uznawany za niezgodny.

Niestandardowe atrybuty mogą być jednak dość przydatne do przekazywania metadanych do JavaScript. Na przykład, jeśli link ma pokazywać wyskakujące okienko, możesz ustawić nazwę wyskakującego okienka w atrybucie:

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

Alternatywnie możesz zapisać tytuł wyskakującego okienka w ukrytym elemencie, takim jak span:

<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>

Jestem jednak rozdarty, która metoda powinna być preferowana. Pierwsza metoda jest bardziej zwięzła i, jak sądzę, nie wkręca tak bardzo w wyszukiwarki i czytniki ekranu. I odwrotnie, druga opcja ułatwia przechowywanie dużych ilości danych, a tym samym jest bardziej wszechstronna. Jest również zgodny ze standardami.

Jestem ciekaw, co myśli te społeczności. Jak radzisz sobie w takiej sytuacji? Czy prostota pierwszej metody przewyższa potencjalne wady (jeśli takie istnieją)?

Jestem wielkim fanem proponowanego rozwiązania HTML 5 ( data-atrybuty z prefiksem). Edycja: dodałbym, że prawdopodobnie istnieją lepsze przykłady użycia atrybutów niestandardowych. Na przykład dane, których użyje aplikacja niestandardowa, które nie mają odpowiednika w standardowych atrybutach (np. Dostosowanie obsługi zdarzeń w oparciu o coś, co niekoniecznie musi być wyrażone w nazwie klasy lub identyfikatorze).

Atrybuty niestandardowe zapewniają wygodny sposób przenoszenia dodatkowych danych po stronie klienta. Dojo Toolkit robi to regularnie i stwierdzono ( obalanie mitów Dojo Toolkit ), że:

Atrybuty niestandardowe zawsze były prawidłowym kodem HTML, po prostu nie sprawdzają się, gdy są testowane z DTD. [...] Specyfikacja HTML stwierdza, że ​​każdy nierozpoznany atrybut ma być ignorowany przez silnik renderujący HTML w agentach użytkownika, a Dojo opcjonalnie wykorzystuje to w celu ułatwienia programowania.

Inną opcją byłoby zdefiniowanie czegoś takiego w JavaScript:

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

Następnie możesz użyć tego później w kodzie Javascript, zakładając, że Twój link ma identyfikator, który odpowiada identyfikatorowi w tej tablicy hashy.

Nie ma wad pozostałych dwóch metod: nie ma niestandardowych atrybutów ani brzydkiego ukrytego zakresu.

Wadą jest to, że może to być trochę przesada w przypadku rzeczy tak prostych, jak twój przykład. Ale w przypadku bardziej złożonych scenariuszy, w których masz więcej danych do przekazania, jest to dobry wybór. Zwłaszcza biorąc pod uwagę, że dane są przekazywane w formacie JSON, dzięki czemu można z łatwością przekazywać złożone obiekty.

Ponadto dane są oddzielone od formatowania, co jest dobre dla łatwości konserwacji.

Możesz nawet mieć coś takiego (czego nie możesz zrobić innymi metodami):

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>

A ponieważ najprawdopodobniej używasz jakiegoś języka programowania po stronie serwera, ta tablica skrótów powinna być prosta do wygenerowania dynamicznie (po prostu serializuj ją do JSON i wypluj ją w sekcji nagłówka strony).

W tym przypadku optymalnym rozwiązaniem jest

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

i używając atrybutu tytułu.

Czasami łamię specyfikację, jeśli naprawdę tego potrzebuję. Ale rzadko i tylko nie bez powodu.

EDYCJA: Nie jestem pewien, dlaczego -1, ale zwracałem uwagę, że czasami myślisz, że musisz złamać specyfikację, a kiedy tego nie robisz.

Dlaczego nie zadeklarować atrybutu popup_title w niestandardowym DTD? To rozwiązuje problem z walidacją. Robię to ze wszystkimi niestandardowymi elementami, atrybutami i wartościami i dzięki tej weryfikacji pokazuje mi tylko rzeczywiste problemy z moim kodem. To sprawia, że ​​błędy przeglądarki są mniej możliwe w przypadku takiego kodu HTML.

Możesz zagnieździć ukryte elementy wejściowe WEWNĄTRZ elementu zakotwiczenia

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

Następnie możesz łatwo wyciągnąć dane przez

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

Ostatecznie moim rozwiązaniem było ukrycie dodatkowych danych w tagu id oddzielonych jakimś separatorem (jeden znak podkreślenia to spacja, dwa to koniec tego argumentu), drugi argument to id:

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

Brzydkie i zakłada, że ​​nie używasz już identyfikatora do czegoś innego, ale jest zgodny z każdą przeglądarką.

Moje osobiste odczucie w twoim przykładzie jest takie, że trasa rozpiętości jest bardziej odpowiednia, ponieważ spełnia standardy specyfikacji XHTML. Jednak widzę argumenty za niestandardowymi atrybutami, ale myślę, że dodają one poziom zamieszania, który nie jest potrzebny.

Ja też nad tym zastanawiałem się. Podoba mi się czytelność niestandardowych atrybutów, ale nie podoba mi się to, że złamie standard. Przykład ukrytego zakresu jest zgodny, ale nie jest zbyt czytelny. A co z tym:

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

Tutaj kod jest bardzo czytelny dzięki notacji pary klucz / wartość JSON. Możesz stwierdzić, że są to metadane, które należą do linku, po prostu patrząc na nie. Jedyną wadą, jaką widzę, oprócz przechwytywania atrybutu „rel”, jest to, że mogłoby to spowodować bałagan w przypadku złożonych obiektów. Bardzo podoba mi się wspomniany powyżej pomysł atrybutów „data-” z prefiksem. Czy któreś z obecnych przeglądarek to obsługują?

Oto coś innego do przemyślenia. Jaki wpływ ma niezgodny kod na SEO?