Was ist, wenn benutzerdefinierte HTML-Attribute kein gültiges XHTML sind?

Ich weiß, das ist der Grund, warum manche Leute sie nicht gutheißen, aber ist das wirklich wichtig? Ich denke, dass die Leistung, die sie bei der Interaktion mit JavaScript und beim Speichern und Senden von Informationen vom und zum Server bieten, die Bedenken hinsichtlich der Validierung überwiegt. Vermisse ich etwas Was sind die Auswirkungen von "ungültigem" HTML? Und würde eine benutzerdefinierte DTD sie nicht trotzdem lösen?

Die Konsequenz ist, dass w3c in 2, 5, 10 Jahren erscheint und ein Attribut mit demselben Namen erstellt. Jetzt ist Ihre Seite kaputt.

HTML5 wird einen Datenattributtyp für legale benutzerdefinierte Attribute bereitstellen (wie data-myattr = "foo"), sodass Sie diesen möglicherweise jetzt verwenden und vor zukünftigen Namenskollisionen einigermaßen sicher sein können.

Schließlich übersehen Sie möglicherweise, dass die benutzerdefinierte Logik das Rationale hinter dem Klassenattribut ist. Obwohl es allgemein als Stilattribut angesehen wird, ist es in Wirklichkeit eine legale Möglichkeit, benutzerdefinierte Meta-Eigenschaften für ein Element festzulegen. Leider sind Sie grundsätzlich auf boolesche Eigenschaften beschränkt, weshalb HTML5 das Datenpräfix hinzufügt.

Übrigens meine ich mit "im Grunde boolesch" im Prinzip. In Wirklichkeit hindert Sie nichts daran, einen Trennzeichen in Ihrem Klassennamen zu verwenden, um benutzerdefinierte Werte sowie Attribute zu definieren.

class="document docId.56 permissions.RW"

Ja, Sie können mithilfe von "Daten" legal benutzerdefinierte Attribute hinzufügen.

Zum Beispiel:

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

Verwenden Sie danach einfach die neueste Version von jquery, um Folgendes zu tun:

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

oder um ein Datenattribut festzulegen:

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

Und da jQuery in fast allen Browsern funktioniert, sollten Sie keine Probleme haben;)

aktualisieren

• data-myData kann in einigen Browsern in Bezug auf die Javascript-Engine in data-mydata konvertiert werden. Halten Sie es am besten ganz in Kleinbuchstaben.

Die Validierung ist kein Selbstzweck, sondern ein Tool, mit dem Sie Fehler frühzeitig erkennen und die Anzahl mysteriöser Rendering- und Verhaltensprobleme verringern können, mit denen Ihre Webseiten möglicherweise konfrontiert sind, wenn sie in mehreren Browsertypen verwendet werden.

Das Hinzufügen von benutzerdefinierten Attributen wirkt sich derzeit nicht auf eines dieser Probleme aus und wird dies in Zukunft wahrscheinlich nicht tun. Da diese jedoch nicht validiert werden, müssen Sie dies tun, wenn Sie die Ausgabe einer Validierung Ihrer Seite bewerten möchten Wählen Sie sorgfältig zwischen den wichtigen Validierungsproblemen und denen, die dies nicht tun. Jedes Mal, wenn Sie Ihre Seite ändern und erneut validieren, müssen Sie diesen Vorgang wiederholen. Wenn Ihre Seite vollständig validiert ist, erhalten Sie eine schöne grüne PASS-Nachricht, und Sie können mit der nächsten Testphase oder der nächsten Änderung fortfahren, die vorgenommen werden muss.

Ich habe Leute gesehen, die von Validierung besessen sind und weitaus schlimmere / seltsamere Dinge tun als ein einfaches benutzerdefiniertes Attribut:

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

Meiner Meinung nach spielen benutzerdefinierte Attribute wirklich keine Rolle. Wie andere sagen, kann es gut sein, auf zukünftige Ergänzungen von Attributen in den Standards zu achten. Aber jetzt haben wir Daten- * Attribute in HTML5, also sind wir gespeichert.

Was wirklich wichtig ist, ist, dass Sie richtig verschachtelte Tags und richtig zitierte Attributwerte haben.

Ich verwende sogar benutzerdefinierte Tag-Namen (die von HTML5 eingeführten, wie Kopf-, Fuß- usw.), aber diese haben Probleme im IE.

Übrigens finde ich oft ironisch, wie sich all diese Validierungs-Fanatiker vor Googles cleveren Tricks wie Iframe-Uploads verneigen.

Anstatt benutzerdefinierte Attribute zu verwenden, können Sie Ihre HTML-Elemente mit JSON den Attributen zuordnen:

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

Und was die Konsequenzen angeht , siehe SpliFFs Antwort .

Das Speichern mehrerer Werte im Klassenattribut ist keine korrekte Codekapselung und nur eine komplizierte Hack-Methode. Nehmen Sie zum Beispiel einen benutzerdefinierten Anzeigenrotator, der jquery verwendet. Es ist viel sauberer auf der Seite zu tun

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

und lassen Sie einen einfachen JQuery-Code die Arbeit von hier aus erledigen. Jeder Entwickler oder Webdesigner kann jetzt am Anzeigenrotator arbeiten und die Werte ändern, wenn er ohne viel Aufforderung dazu aufgefordert wird.

Ein Jahr später zum Projekt zurückzukehren oder zu einem neuen zu wechseln, bei dem sich der vorherige Entwickler trennte und auf eine Insel irgendwo im Pazifik ging, kann die Hölle sein, wenn man versucht, Absichten herauszufinden, wenn Code auf eine unklare verschlüsselte Weise wie diese geschrieben wird:

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

Wenn wir Code in c # und anderen Sprachen schreiben, schreiben wir keinen Code, der alle benutzerdefinierten Eigenschaften in einer Eigenschaft als durch Leerzeichen getrennte Zeichenfolge platziert, und müssen diese Zeichenfolge jedes Mal analysieren, wenn wir darauf zugreifen oder darauf schreiben müssen. Denken Sie an die nächste Person, die an Ihrem Code arbeitet.

Die Sache mit der Validierung ist, dass es HEUTE vielleicht keine Rolle spielt, aber Sie können nicht wissen, ob es morgen eine Rolle spielt (und nach Murphys Gesetz wird es morgen eine Rolle spielen).

Es ist einfach besser, eine zukunftssichere Alternative zu wählen. Wenn sie nicht existieren ( in diesem speziellen Fall ), müssen Sie eine zukunftssichere Alternative erfinden.

Die Verwendung benutzerdefinierter Attribute ist wahrscheinlich harmlos. Warum sollten Sie jedoch eine potenziell schädliche Lösung wählen, nur weil Sie der Meinung sind (Sie können nie sicher sein), dass sie keinen Schaden anrichtet? Es könnte sich lohnen, dies weiter zu diskutieren, wenn die zukunftssichere Alternative zu kostspielig oder unhandlich wäre, aber dies ist sicherlich nicht der Fall.

Alte Diskussion aber trotzdem; Meiner Meinung nach ist HTML ein Markup und keine Programmiersprache. Daher sollte es für Markup-Fehler immer mit Nachsicht interpretiert werden. Ein Browser ist dazu in der Lage. Ich denke nicht, dass sich dies jemals ändern wird und sollte. Daher ist das einzige wichtige praktische Kriterium, dass Ihr HTML von den meisten Browsern korrekt angezeigt wird und dies auch in einigen Jahren tun wird. Nach dieser Zeit wird Ihr HTML-Code wahrscheinlich trotzdem neu gestaltet.

Um meine Zutat in die Mischung aufzunehmen, ist die Validierung auch wichtig, wenn Sie Inhalte erstellen müssen, die mit automatisierten Tools nachbearbeitet werden können / könnten. Wenn Ihr Inhalt gültig ist, können Sie Markups viel einfacher von einem Format in ein anderes konvertieren. Beispielsweise ist es viel einfacher, gültiges XHTML in XML mit einem bestimmten Schema auszuführen, wenn Sie Daten analysieren, die Sie kennen und überprüfen können, um einem vorhersehbaren Format zu folgen.

Ich brauche zum Beispiel, dass mein Inhalt gültiges XHTML ist, da er sehr oft für verschiedene Jobs in XML konvertiert und dann ohne Datenverlust oder unerwartete Rendering-Ergebnisse zurückkonvertiert wird.

Nun, es hängt von Ihrem Kunden / Chef / etc ab. Benötigen sie die Validierung von XHTML?

Einige Leute sagen, es gibt viele Problemumgehungen - und je nach Szenario können sie großartig funktionieren. Dies umfasst das Hinzufügen von Klassen, die Nutzung des relAttributs und jemanden, der sogar einen eigenen Parser geschrieben hat, um JSON aus HTML-Kommentaren zu extrahieren.

HTML5 bietet eine Standardmethode, indem Sie Ihren benutzerdefinierten Attributen "data-" voranstellen. Ich würde dies jetzt sowieso empfehlen, da die Möglichkeit besteht, dass Sie ein Attribut verwenden, das später in Standard-XHTML verwendet wird.

Die Verwendung von nicht standardmäßigem HTML kann dazu führen, dass der Browser die Seite im "Mackenmodus" rendert. In diesem Fall werden einige andere Teile der Seite möglicherweise anders gerendert, und andere Dinge wie die Positionierung können geringfügig abweichen. Die Verwendung einer benutzerdefinierten DTD kann dies jedoch umgehen.

Da sie nicht zum Standard gehören, wissen Sie weder jetzt noch in Zukunft, was passieren könnte. Wie andere gesagt haben, könnte W3C in Zukunft dieselben Namen verwenden. Noch gefährlicher ist jedoch, dass Sie nicht wissen, was die Entwickler von "browser xxx" getan haben, wenn sie auf sie stoßen.

Vielleicht ist die Seite im Quirks - Modus gerendert, vielleicht die Seite nicht rendert alle auf einem obskuren mobilen Browser, vielleicht wird der Browser eines Speicherleck, vielleicht ein Virus Killer auf Ihrer Seite ersticken, etc, etc, etc.

Ich weiß, dass das religiöse Befolgen der Standards wie Snobismus erscheinen kann. Sobald Sie jedoch Probleme haben, weil Sie ihnen nicht folgen, neigen Sie dazu, nicht mehr so ​​zu denken. Dann ist es jedoch meistens zu spät und Sie müssen Ihre Anwendung mit einem anderen Framework von Grund auf neu starten ...

Ich denke, Entwickler validieren nur, um zu validieren, aber es gibt etwas zu sagen, weil es das Markup sauber hält. Da jedoch jeder (Übertreibungswarnung!) Browser alles anders anzeigt, gibt es wirklich keinen Standard. Wir versuchen, Standards zu folgen, weil wir das Gefühl haben, zumindest eine Richtung zu haben. Einige Leute argumentieren, dass das Beibehalten des Code-Standards Probleme und Konflikte in Zukunft verhindern wird. Meine Meinung: Scheiße, dass heute sowieso niemand Standards korrekt und vollständig implementiert, könnte genauso gut davon ausgehen, dass Ihr gesamter Code irgendwann fehlschlägt. Wenn es funktioniert, funktioniert es, verwenden Sie es, es sei denn, es ist chaotisch oder Sie versuchen nur, Standards zu ignorieren, um es an W3C oder so zu halten. Ich denke, es ist wichtig, sich daran zu erinnern, dass Standards sehr langsam implementiert werden. Hat sich das Web in 5 Jahren so sehr verändert? ICH' Ich bin mir sicher, dass jeder jahrelang benachrichtigt wird, wenn er einen potenziellen Konflikt beheben muss. Kein Grund, die Kompatibilität von Standards in Zukunft zu planen, wenn Sie sich nicht einmal auf die heutigen Standards verlassen können.

Oh, ich hätte fast vergessen, wenn Ihr Code nicht bestätigt, dass 10 Babykätzchen sterben werden. Bist du ein Kätzchenkiller?

Jquery .html (Markup) funktioniert nicht, wenn das Markup ungültig ist.

Validierung

Sie sollten keine benutzerdefinierten Attribute benötigen, um die Validierung bereitzustellen. Ein besserer Ansatz wäre das Hinzufügen einer Validierung basierend auf der tatsächlichen Aufgabe der Felder.

Weisen Sie mithilfe von Klassen eine Bedeutung zu. Ich habe Klassennamen wie:

• date (Termine)
• zip (Postleitzahl)
• area (Bereiche)
• ssn (Sozialversicherungsnummer)

Beispiel-Markup:

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

Beispiel Javascript (mit jQuery):

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

Wenn Sie spezielle Validatoren für ein bestimmtes Szenario benötigen, erfinden Sie einfach neue Klassen (oder verwenden Selektoren ) für Ihren speziellen Fall:

Beispiel für die Überprüfung, ob zwei Passwörter übereinstimmen:

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

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

(Dieser Ansatz funktioniert ziemlich nahtlos sowohl mit der jQuery-Validierung als auch mit dem mvc .net-Framework und wahrscheinlich auch mit anderen.)

Bonus: Sie können mehrere Klassen zuweisen, die durch eine Leerzeichenklasse getrennt sind = "ssn custom-one custom-two"

Senden von Informationen "vom und zum Server"

Wenn Sie Daten zurückgeben müssen, verwenden Sie <input type="hidden" />. Sie arbeiten sofort.

(Stellen Sie sicher, dass Sie keine vertraulichen Daten mit versteckten Eingaben übergeben, da diese vom Benutzer fast ohne Aufwand geändert werden können.)