Co z tego, że niestandardowe atrybuty HTML nie są poprawne XHTML?

Tak możesz legalnie dodawać własne atrybuty za pomocą "data".

Na przykład:

<div id="testDiv" data-myData="just testing"></div>

Potem wystarczy użyć najnowszej wersji jquery, aby zrobić coś takiego:

alert($('#testDiv').data('myData'))

Lub ustawić atrybut danych:

$('#testDiv').data('myData', 'new custom data')

A ponieważ jQuery działa w prawie wszystkich przeglądarkach, nie powinieneś mieć żadnych problemów;)

Update

• data-myData może być konwertowana do data-mydata w niektórych przeglądarkach, jeśli chodzi o silnik javascript. Najlepiej go zatrzymać małe litery.

Walidacja nie jest celem samym w sobie, ale narzędziem, które może być używane do wczesnego wychwytywania błędów i zmniejszenia liczby tajemniczych problemów z renderowaniem i zachowaniem, które mogą napotkać strony internetowe, gdy są używane w wielu typach przeglądarek.

Dodanie niestandardowych atrybutów nie wpłynie teraz na żaden z tych problemów i prawdopodobnie nie nastąpi to w przyszłości, ale ponieważ nie sprawdzają się, oznacza to, że kiedy przyjdzie ci ocenić wynik walidacji Twojej strony, będziesz musiał starannie wybrać pomiędzy kwestie walidacji, które mają znaczenie, i te, które nie. za każdym razem, gdy zmieniasz stronę i aktualizujesz, musisz powtórzyć tę operację. Jeśli Twoja strona zostanie zweryfikowana w całości, otrzymasz ładny komunikat green PASS i możesz przejść do następnego etapu testowania lub do następnej zmiany, która musi zostać wprowadzona.

Widziałem ludzi z obsesją na punkcie walidacji robiących znacznie gorsze / dziwne rzeczy niż używanie prostego niestandardowego atrybutu:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

Moim zdaniem niestandardowe atrybuty naprawdę nie mają znaczenia. Jak mówią inni, dobrze jest uważać na przyszłe dodawanie atrybutów w standardach. Ale teraz mamy atrybuty data-* w HTML5, więc jesteśmy zapisani.

Naprawdę ważne jest to, że masz prawidłowo zagnieżdżone tagi i prawidłowo cytowane wartości atrybutów.

Używam nawet niestandardowych nazw tagów (tych wprowadzone przez HTML5, jak Nagłówek, Stopka itp.), ale te mają problemy w IE.

Przy okazji, często znajduję ironię, jak wszyscy ci fanatycy walidacji kłaniają się przed sprytnymi sztuczkami Google, takimi jak przesyłanie iframe.

Zamiast używać niestandardowych atrybutów, możesz powiązać elementy HTML z atrybutami za pomocą JSON:

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

A co do konsekwencji, Zobacz odpowiedź Spliffa .

Przechowywanie wielu wartości w atrybucie klasy nie jest poprawną enkapsulacją kodu, a tylko zawiłym hakerskim sposobem robienia rzeczy. Weźmy na przykład Niestandardowy rotator reklamowy, który używa jquery. Jest to o wiele czystsze na stronie do zrobienia

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

I niech jakiś prosty kod jquery wykona pracę stąd. Każdy programista lub projektant stron internetowych może teraz pracować na rotatorze reklam i zmieniać wartości na to, gdy jest to wymagane bez większych ceregieli.

Powrót do projektu rok później lub przejście do nowego, gdzie poprzedni deweloper podzielił się i udał się na wyspę gdzieś na Pacyfiku może być piekło próbując dowiedzieć się intencji, gdy kod jest napisany w niejasny zaszyfrowany sposób, jak to: {]}

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

Kiedy piszemy kod w c# i innych językach, nie piszemy kodu umieszczając wszystkie niestandardowe właściwości w jednej właściwości jako łańcuch oddzielony spacjami i kończymy na tym, że musimy parsować ten łańcuch za każdym razem, gdy musimy uzyskać do niego dostęp lub do niego napisać. Pomyśl o następnej osobie, która będzie pracować nad Twoim kodem.

Rzecz z walidacją jest taka, że dzisiaj może to nie mieć znaczenia, ale nie możesz wiedzieć, czy jutro będzie miało znaczenie (a zgodnie z prawem Murphy ' ego jutro będzie miało znaczenie).

Po prostu lepiej wybrać przyszłościową alternatywę. Jeśli nie istnieją ( mają miejsce w tym konkretnym przypadku ), należy wymyślić alternatywę przyszłościową.

Używanie niestandardowych atrybutów jest prawdopodobnie nieszkodliwe, ale nadal, Dlaczego wybrać potencjalnie szkodliwe rozwiązanie tylko dlatego, że myślisz (możesz nigdy nie mieć pewności) nie spowoduje szkody?. Warto byłoby o tym dalej dyskutować, jeśli alternatywa future proof była zbyt kosztowna lub nieporęczna, ale z pewnością tak nie jest.

Stara dyskusja, ale mimo to; moim zdaniem skoro html jest marką, a nie językiem programowania, to zawsze powinien być interpretowany z pobłażliwością dla markowych 'błędów'. Przeglądarka jest w stanie to zrobić. Myślę, że to się nigdy nie zmieni. Dlatego jedynym ważnym kryterium praktycznym jest to, że Twój html będzie poprawnie wyświetlany przez większość przeglądarek i będzie to robił za powiedzmy kilka lat. Po tym czasie twój html i tak zostanie przeprojektowany.

Aby dodać mój składnik do mieszanki, Walidacja jest również ważna, gdy musisz utworzyć zawartość, która może / może być przetwarzana za pomocą zautomatyzowanych narzędzi. Jeśli zawartość jest ważna, możesz znacznie łatwiej przekonwertować znaczniki z jednego formatu na inny. Na przykład wykonywanie poprawnego XHTML na XML z określonym schematem jest znacznie łatwiejsze podczas parsowania danych, które znasz i możesz zweryfikować, aby postępować zgodnie z przewidywalnym formatem.

Ja np. potrzebuję aby moja treść była poprawna XHTML bo bardzo często jest konwertowane do XML dla różnych zadań, a następnie konwertowane z powrotem bez utraty danych lub nieoczekiwanych wyników renderowania.

Cóż to zależy od Twojego klienta / szefa / itp .. czy wymagają walidacji XHTML?

Niektórzy mówią, że istnieje wiele obejść-i w zależności od scenerii, mogą pracować świetnie. Obejmuje to dodawanie klas, wykorzystanie atrybutu rel i kogoś, kto nawet napisał własny parser do wyodrębniania JSON z komentarzy HTML.

HTML5 zapewnia standardowy sposób, aby to zrobić, przedrostek niestandardowych atrybutów z"data -". I tak polecam zrobić to teraz, ponieważ tam jest szansa, że użyjesz atrybutu, który będzie używany w standardowym XHTML.

Użycie niestandardowego HTML może sprawić, że przeglądarka renderuje stronę w "trybie dziwactwa", w którym to przypadku niektóre inne części strony mogą być renderowane inaczej, a inne rzeczy, takie jak pozycjonowanie, mogą być nieco inne. Używanie niestandardowego DTD może to obejść.

Ponieważ nie są standardowe, nie masz pojęcia, co może się wydarzyć, ani teraz, ani w przyszłości. Jak powiedzieli inni, W3C może zacząć używać tych samych nazw w przyszłości. Ale jeszcze bardziej niebezpieczne jest to, że nie wiesz, co zrobili twórcy "browser xxx", gdy ich napotkają.

Może strona jest renderowana w trybie dziwactwa, może strona nie renderuje w wszystkie w jakiejś niejasnej mobilnej przeglądarce, Może przeglądarka wycieka pamięć, może zabójca wirusów będzie dusić się na swojej stronie, itp, itp, itp.

Wiem, że przestrzeganie norm religijnych może wydawać się snobistyczne. Jednak po doświadczeniu problemów z powodu nie podążania za nimi, masz tendencję do zatrzymania myślenia w ten sposób. Jednak w większości przypadków jest już za późno i musisz uruchomić aplikację od podstaw z innym frameworkiem...

Myślę, że deweloperzy walidują tylko po to, aby potwierdzić, ale jest coś do powiedzenia na fakt, że utrzymuje znaczniki czyste. Jednak, ponieważ każdy (Uwaga przesada!) przeglądarka wyświetla wszystko inaczej tam naprawdę nie ma standardu. Staramy się podążać za standardami, ponieważ sprawia to, że czujemy, że przynajmniej mamy jakiś kierunek. Niektórzy twierdzą, że utrzymanie standardu kodu zapobiegnie problemom i konfliktom w przyszłości. Moja opinia: wkręcić, że nikt nie wdraża standardów poprawnie i w pełni dzisiaj tak czy inaczej, równie dobrze można założyć, że cały Twój kod w końcu zawiedzie. Jeśli to działa to działa, użyj go, chyba że jego bałagan lub po prostu stara się ignorować standardy, aby przykleić go do W3C lub coś takiego. Myślę, że ważne jest, aby pamiętać, że standardy są wdrażane bardzo powoli, czy sieć zmieniła się tak bardzo w ciągu 5 lat. Jestem pewien, że każdy będzie miał lata wypowiedzenia, kiedy będzie musiał naprawić potencjalny konflikt. Nie ma powodu, aby planować zgodność standardów w przyszłości, gdy nie można nawet polegać na dzisiejsze standardy.

Och prawie zapomniałem, jeśli twój kod nie potwierdzi 10 kociąt umrze. Jesteś zabójcą kociaków?

Jquery .html (znaczniki) nie działa, Jeśli znacznik jest nieprawidłowy.

Walidacja

Nie powinieneś potrzebować niestandardowych atrybutów, aby zapewnić walidację. Lepszym podejściem byłoby dodanie walidacji w oparciu o rzeczywiste zadanie pól.

Przypisywanie znaczenia za pomocą klas. Mam takie nazwy klas jak:

• date (daty)
• zip (Kod Pocztowy)
• area (obszary)
• ssn (Numer ubezpieczenia społecznego)

Przykładowy znacznik:

<input class="date" name="date" value="2011-08-09" />

Przykład javascript (z jQuery):

$('.date').validate(); // use your custom function/framework etc here.

Jeśli potrzebujesz specjalne walidatory dla pewnego lub scenariusza po prostu wymyślasz nowe klasy (lub używasz selektorów ) dla swojego przypadek szczególny:

Przykład sprawdzania, czy dwa hasła pasują do siebie:

<input id="password" />
<input id="password-confirm" />

if($('#password').val() != $('#password-confirm').val())
{
 // do something if the passwords don't match
}

(to podejście działa całkiem bezproblemowo zarówno z walidacją jQuery, jak i mvc. NET framework i prawdopodobnie innymi)

Bonus: możesz przypisać wiele klas oddzielonych spacją class= "SSN custom-one custom-two"

Wysyłanie informacji " z I do Serwer "

Jeśli chcesz przekazać dane z powrotem, użyj <input type="hidden" />. Działają po wyjęciu z pudełka.

(Upewnij się, że nie przekazujesz żadnych poufnych danych z ukrytymi wejściami, ponieważ mogą być modyfikowane przez użytkownika prawie bez wysiłku)