Tom: eigene Attribute

Hello,

zur Steuererung der Funktionsweise und Ansicht von Formularen habe ich mal mit den Attributen herumexprimentiert.

Es geht dabei um [disabled="disabled"]

oder versuchswiese um [disabled="error"], was es ja offizell nicht gibt,

(Das funktioniert leider sowieso nur beim FF)

und ersatzweise um das selbst erfundene Attribut [message="error"] - oder andere Werte.

Das Spannende dabei ist, dass man über den Attribut-Selector von CSS mit der zweiten Methode sowohl ab Firefox 3.6.13 (ein älterer steht mir leider nicht mehr zur Verfügung) und ab IE 8.0.6001.x (auch hier habe ich keinen älteren mehr...) sowohl das Verhalten für disabled, als auch für die Background-Color der Input-Felder steuern kann. Das vereinfacht die Logic im Backend enorm!

Leider kassiere ich dann einen Fehler beim Vailidator.

Validation Output: 1 Error

1. Error Line 79, Column 121: there is no attribute "MESSAGE"

…input name="data[email]" type="text" value="<!--EMAIL-->" message="error" ></p>

Realsatire guckst Du unter http://bikers-lodge.com/contact/

Wie kann ich es jetzt besser machen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

--
 ☻_
/▌
/ \ Nur selber lernen macht schlau
http://restaurant-zur-kleinen-kapelle.de
  1. Moin

    Das Spannende dabei ist, dass man über den Attribut-Selector von CSS mit der zweiten Methode sowohl ab Firefox 3.6.13 (ein älterer steht mir leider nicht mehr zur Verfügung) und ab IE 8.0.6001.x (auch hier habe ich keinen älteren mehr...) sowohl das Verhalten für disabled, als auch für die Background-Color der Input-Felder steuern kann. Das vereinfacht die Logic im Backend enorm!

    Das liegt m.E. an der Möglichkeit CSS für XML zu schreiben. XML wird durch die Browser wiederum ebenfalls dargestellt, deswegen wird der Selector auch interpretiert.

    Leider kassiere ich dann einen Fehler beim Vailidator.

    Validation Output: 1 Error

    1. Error Line 79, Column 121: there is no attribute "MESSAGE"

    …input name="data[email]" type="text" value="<!--EMAIL-->" message="error" ></p>

    Ist auch logisch. HTML 4.01 Transitional kennt kein Attribut Message. Das ist einfach nicht valide.

    Wie kann ich es jetzt besser machen?

    Ich würde hier mit Klassen arbeiten. zum Bsp. eine Klasse "err" oder so, die dann dynamisch über JS gesetzt wird.

    Gruß Bobby

    --
    -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
    ### Henry L. Mencken ###
    -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
    ## Viktor Frankl ###
    ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
  2. Om nah hoo pez nyeetz, Tom!

    data-attribute sind in HTM5 valide.

    Matthias

    --
    Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Qual und Qualle.

    1. Hello Matthias,

      data-attribute sind in HTM5 valide.

      Dann wir es wohl nun doch mal Zeit, dass ich mich mit HTML5 näher auseinandersetze.

      Eigene Attribute sind nämlich sehr praktisch. Das ist schließlich der erste Schritt zu einem "programmierbaren HTML" bzw. CSS.

      Die Trennung von Daten und deren Darstellungs-Design wird damit immer leichter.

      Worüber ich mich außerdem noch ärgere ist, dass Kommentare in HTML (4.01) nicht wirklich überall funktionieren.

      Ein

      <input name="data[subject]" type="text" value="<!--SUBJECT-->"></p>

      ist valide, aber ein

      <input name="data[subject]" type="text" value="<!--SUBJECT-->" <!--ATTRIB-->></p>

      macht Probleme

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://restaurant-zur-kleinen-kapelle.de
      1. Worüber ich mich außerdem noch ärgere ist, dass Kommentare in HTML (4.01) nicht wirklich überall funktionieren.

        Ein

        <input name="data[subject]" type="text" value="<!--SUBJECT-->"></p>

        ist valide, aber ein

        <input name="data[subject]" type="text" value="<!--SUBJECT-->" <!--ATTRIB-->></p>

        macht Probleme

        Notiere sie doch über dem Feld so wie es "üblich" ist.
        Ist auch nicht gerade schön sowas.

          
        <!-- InputFeld -->  
        <input name="data[subject]" type="text" value="<!--SUBJECT-->"></p>  
        
        

        Auf diese Idee kommt ja auch keiner auch wenn es valide wäre :p

          
        foreach ($list as $entry /** $entry \Ns\Template\Dummy */) {  
           ...  
        }  
        
        
        1. Hello,

          Notiere sie doch über dem Feld so wie es "üblich" ist.
          Ist auch nicht gerade schön sowas.

          <!-- InputFeld -->
          <input name="data[subject]" type="text" value="<!--SUBJECT-->"></p>

            
          Das verstehe ich jetzt nicht, wie Du das meinst.  
            
          Könntest Du das bitte nochmal ausführlicher für Doofe erklären?  
            
            
            
            
            
            
          Liebe Grüße aus dem schönen Oberharz  
            
            
          Tom vom Berg  
          ![](http://selfhtml.bitworks.de/Virencheck.gif)  
            
          
          -- 
           ☻\_  
          /▌  
          / \ Nur selber lernen macht schlau  
          <http://restaurant-zur-kleinen-kapelle.de>
          
      2. @@Tom:

        nuqneH

        Dann wir es wohl nun doch mal Zeit, dass ich mich mit HTML5 näher auseinandersetze.

        Ja, höchste.

        Worüber ich mich außerdem noch ärgere ist, dass Kommentare in HTML (4.01) nicht wirklich überall funktionieren.

        Da mittlerweile alle Browser über einen HTML5-Parser verrfügen, d.h. Quellcode gemäß HTML5 verarbeiten, ist die 4.01-Spec kaum noch relevant.

        Ein
        <input name="data[subject]" type="text" value="<!--SUBJECT-->"></p>
        ist valide,

        Kein Kommentar. (No pun intended.)

        Natürlich ist es valide. Es ist ein Attributwert, kein Kommentar. Wäre es ein Kommentar, müsste value den Wert "" haben. Hat’s aber nicht, sondern "<!--SUBJECT-->".

        aber ein
        <input name="data[subject]" type="text" value="<!--SUBJECT-->" <!--ATTRIB-->></p>
        macht Probleme

        Innerhalb von Tags sind Kommentare nicht erlaubt. HTML-Spec 8.1.2.1 ff.

        Qapla'

        --
        „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
        1. Hello Gunnar,

          [...]

          aber ein
          <input name="data[subject]" type="text" value="<!--SUBJECT-->" <!--ATTRIB-->></p>
          macht Probleme

          Innerhalb von Tags sind Kommentare nicht erlaubt. HTML-Spec 8.1.2.1 ff.

          So schlau war ich auch schon ;-D

          Ich wäre Dir sehr verbunden, wenn Du mir weiterhelfen könntest, wie ich in einem HTML-Dokument einen "Kommentar" notieren kann für die Attribute eines Elementes, der vom Backend-System ausgetauscht werden muss, aber keinen Schaden anrichtet, wenn das Backend ihn übersehen hat auzutauschen ...

          Ist es richtig, dass bei HTML5 ein Attribut attrib="attrib" zulässig wäre?

          Wie aufwändig ist die Umstellung von HTML 4.01 auf HTML5?

          Muss ich da ganz von vorne anfangen?

          Liebe Grüße aus dem schönen Oberharz

          Tom vom Berg

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://restaurant-zur-kleinen-kapelle.de
          1. Hallo,

            Ist es richtig, dass bei HTML5 ein Attribut attrib="attrib" zulässig wäre?

            nein, einfach erfundene Attribute sind auch in HTML 5 nicht valide. Ein Attribut data-attrib="attrib" dagegen schon.

            Wie aufwändig ist die Umstellung von HTML 4.01 auf HTML5?

            Gar nicht. Im Prinzip ist HTML 5 eine Obermenge von HTML 4.01. Was in HTML 4.01 gültig ist, ist AFAIK auch in HTML 5 gültig; zusätzlich dazu ist in HTML 5 einiges erlaubt, was in HTML 4.01 nicht valide ist/war.

            Muss ich da ganz von vorne anfangen?

            Nein. In den meisten Fällen ist mit der DOCTYPE-Deklaration

            <!DOCTYPE html>

            schon der erste korrekte Schritt getan. Ob man das wirklich möchte, ist eine ganz andere Frage. Ich würde die relativ konsequente Systematik von HTML 4.01 Strict oder gar XHTML 1.0 Strict nicht zugunsten des Wischiwaschi von HTML 5 aufgeben wollen.

            Ciao,
             Martin

            --
            F: Kennt jemand ein Automobil-Märchen?
            A: Radkäppchen und der böse Golf.
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            1. @@Der Martin:

              nuqneH

              Gar nicht. Im Prinzip ist HTML 5 eine Obermenge von HTML 4.01.

              Von HTML 4.01 Strict, nicht von HTML 4.01 Transitional oder HTML 4.01 Frameset.

              Was in HTML 4.01 gültig ist, ist AFAIK auch in HTML 5 gültig;

              Was in HTML 4.01 Strict gültig ist, sollte auch in HTML 5 gültig sein. Ohne jetzt genau geprüft zu haben, ob das bin ins kleinste Detail so stimmt. Aber im Prinzip ist HTML5 abwärtskompatibel. Weswegen es auch die Designfehler von HTML 2 weiter mit sich rumschleppt. (Beispiel)

              In den meisten Fällen ist mit der DOCTYPE-Deklaration <!DOCTYPE html> schon der erste korrekte Schritt getan. Ob man das wirklich möchte, ist eine ganz andere Frage.

              Natürlich möchte man. Da moderne Browser ohnehin für alles, was als 'text/html' reinkommt, einen HTML5-Parser verwenden, hat man’s sowieso mit HTML5 zu tun, auch wenn man HTML 4.01 oder XHTML 1.0 draufschreibt.

              HTML5 bietet gegenüber seinen Vorgängern deutliche Vorteile hinsichtlich User Experience (getypte Eingabefelder, Formularvalidierung), Barrierefreiheit (Elemente für Dokumentstruktur, ARIA-Roles), Internationalisierung (translate-Attribut) und und und.

              Ich würde die relativ konsequente Systematik von HTML 4.01 Strict oder gar XHTML 1.0 Strict nicht zugunsten des Wischiwaschi von HTML 5 aufgeben wollen.

              Mit Systematik meinst du das Regelwerk? Ja, HTML5 ist in Prosa geschrieben, und mitunter sind die Regeln kontextabhängig. HTML 4.01 und insbesondere XHTML 1.0 haben einfache Regeln in Form einer maschinenlesbaren DTD, die auch für Menschen einfacher zu lesen ist als die HTML5-Spec.

              Qapla'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
            2. Hallo,

              Im Prinzip ist HTML 5 eine Obermenge von HTML 4.01. Was in HTML 4.01 gültig ist, ist AFAIK auch in HTML 5 gültig

              Im Prinzip nicht, in der Praxis meistens schon.

              HTML 4 ist eine SGML-Anwendung, daher sind relativ fiese Syntaxtricks möglich, die die Browser nie unterstützt haben, da sie keine SGML-Parser benutzt haben. HTML5 basiert nicht auf SGML.

              Ich würde die relativ konsequente Systematik von HTML 4.01 Strict oder gar XHTML 1.0 Strict nicht zugunsten des Wischiwaschi von HTML 5 aufgeben wollen.

              HTML 4.01 ist nicht wirklich konsequent. XHTML 1.0 lässt sich auch nur mit viel Aufwand vernünftig validieren.

              Der HTML5-Validator ist insgesamt strenger und prüft weitaus mehr Regeln, als SGML-DTD-, XML-DTD- und XML-Schema-Validierung es je getan haben. Der Unterschied zwischen Strict und Transitional ist im Vergleich dazu eher klein.

              Mathias

          2. Ich wäre Dir sehr verbunden, wenn Du mir weiterhelfen könntest, wie ich in einem HTML-Dokument einen "Kommentar" notieren kann für die Attribute eines Elementes, der vom Backend-System ausgetauscht werden muss, aber keinen Schaden anrichtet, wenn das Backend ihn übersehen hat auzutauschen ...

            Wenn Du ein Backend-System hast, dann hast Du doch bestimmt ein Templatesystem? Die meisten dieser sind dann so ausgereift, dass sie selbst eigene Kommentare haben. Smarty, so hab ich gerade ergoogelt, hat z.B. eine Kommentarsyntax, die keinen katastrophalen Schaden anrichten würde, stände sie aus irgendeinem Grund in einem Attributwert.

            Oder gleich selbstsprechende Variablen nutzen.

            Ist es richtig, dass bei HTML5 ein Attribut attrib="attrib" zulässig wäre?

            Was heisst denn „zulässig“?

            Wenn wir uns an XML erinnern, hat das einen Unterschied zwischen zwei Formen von Zulässigkeit gemacht, zwischen Wohlgeformtheit und Validität. Wohlgeformte Dokumente halten sich an die Syntaxregeln von HTML 4 oder XHTML 1, keine überlappenden Elemente, Attribute mit nur einem Wert und bitte in Anführungszeichen, all das Zeug. Aber <a attribute="attribute"> könnte auch in XHTML-1-Dokumenten wohlgeformt also quasi zulässig sein. Mal ganz abgesehen davon, dass man auf DOM-Ebene Dank [gs]etAttribute(NS)? eh machen kann, was man will.
            Validität bedeutet, dass jedes Syntaxelement auch bitte eine Definition in der DTD besitzen sollte, also dem begrenzten Vorrat von HTML-Elementen und deren jeweiligen Attributen entspringt.

            HTML5 hat keine DTD. Und nu? Wohlgeformtheit existiert auch dort. Der Parser parst das Dokument und was er erfolgreich geparst hat, ist per Definition wohlgeformt. Und Validität gibt es nicht per DOM sondern durch Conformance-Checking, d.h. haufenweiser kleiner Regeln, die durch die Spec verstreut sind und von jemanden in maschinell überprüfbare Regeln übersetzt wurde oder letztendlich durch menschliche Augen. Sorry, geht nicht nun mal nicht besser.

            attribute=attribute wird sowohl vom HTML5-Parsing-Algorithmus als auch von XML-Parsern erfolgreich geparst und in DOM umgewandelt und Du kannst mit getAttribute() darauf zugreifen. Das ist Zulässigkeit auf der Form von Wohlgeformtheit. Es ist nur nicht sinnvoll.

            Es ist nicht sinnvoll, weil es gegen das HTML-Ökosystem schwieriger macht, sprich Interoperabilität und Zukunftsplanung. Die Spec rät davon ab und bietet alternative Mechanismen an, XML-Namensräume in XML-Syntax oder in HTML5-Syntax das Präfixen des Attributes mit x-, sprich x-attribute=attribute. Dinge mit X werden nie offiziell spezifiziert werden.

            Es ist nicht sinnvoll, weil es einen weiteren definierten Mechanismus gibt, wo man Browsern und Spec-Schreibern nicht ins Gehege kommt. Data-Attribute, die alle das Präfix "data-" haben: <div data-attribute="value" data-foo="bar">. Und man kann in JS mit der dataset API bei Elementen bequem darauf zugreifen: document.querySelector("div").dataset.foo = "baz".

            Wie aufwändig ist die Umstellung von HTML 4.01 auf HTML5?

            <!doctype html>

            Muss ich da ganz von vorne anfangen?

            Nein, aber Du lernst wieder viel Neues dazu.

            1. @@Tim Tepaße:

              nuqneH

              Wohlgeformte Dokumente halten sich an die Syntaxregeln von HTML 4 oder XHTML 1

              In HTML 4 gibt es den Begriff „Wohlgeformtheit“ nicht, IIRC.

              _Valide_ Dokumente halten sich an die Syntaxregeln von HTML 4 oder XHTML 1. Wohlgeformte Dokumente halten sich an die Syntaxregeln von XML.

              Aber <a attribute="attribute"> könnte auch in XHTML-1-Dokumenten wohlgeformt also quasi zulässig sein.

              Nö. Zulässig ist, was den Syntaxregeln entspricht, also valide ist.

              Oder meintest du „quasi-zulässig“?

              Mal ganz abgesehen davon, dass man auf DOM-Ebene Dank [gs]etAttribute(NS)? eh machen kann, was man will.

              Das ist aber eine ganz andere Ebene. DOM != HTML.

              HTML5 hat keine DTD. Und nu? Wohlgeformtheit existiert auch dort. Der Parser parst das Dokument und was er erfolgreich geparst hat, ist per Definition wohlgeformt.

              Gibt es den Begriff „Wohlgeformtheit“ in HTML5 tatsächlich?

              Was der Parser erfolgreich geparst hat, muss allerdings nicht valide sein, da HTML5 die Fehlerbehandlung (d.h. das Verhalten bei invalidem Code) gleich mit spezifiziert.

              Die Spec […] bietet alternative Mechanismen an, XML-Namensräume in XML-Syntax

              Die Spec erlaubt nur wenige Attribute mit Namensräumen.

              <!doctype html>

              In polyglottem HTML5 <!DOCTYPE html>

              Qapla'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
              1. Hallo,

                In HTML 4 gibt es den Begriff „Wohlgeformtheit“ nicht, IIRC.
                Gibt es den Begriff „Wohlgeformtheit“ in HTML5 tatsächlich?

                Nein. Tim war sich dessen vermutlich bewusst und hat den Begriff der Wohlgeformtheit bloß zur Erklärung auf HTML 4 und HTML 5 übertragen.

                Was der Parser erfolgreich geparst hat, muss allerdings nicht valide sein, da HTML5 die Fehlerbehandlung (d.h. das Verhalten bei invalidem Code) gleich mit spezifiziert.

                Es gibt ja (mindestens) drei Fälle:

                • Der Parser verarbeitet das Dokument und es treten Parse Errors auf. Der Parser kann dabei abbrechen oder die vorgeschriebene Fehlerbehandlung durchführen.
                • Der Parser verarbeitet das Dokument ohne Fehler. Wenn das der Fall ist, entspricht das Dokument vermutlich auch der Syntaxdefinition.
                • Der Parser verarbeitet das Dokument ohne Fehler und es entspricht den sämtlichen anderen spezifizierten Regeln. Das ist, was der Validator versucht zu prüfen.

                Mathias

              2. In HTML 4 gibt es den Begriff „Wohlgeformtheit“ nicht, IIRC.

                Jo. Aber der Begriff (Und die Unterscheidung zu Validität) ist so praktisch, dass ich ihn übertrage, wie molily schon sagt. Wie will man sonst zwischen Syntax und Inhalt dieser Syntax unterscheiden können?

                Aber <a attribute="attribute"> könnte auch in XHTML-1-Dokumenten wohlgeformt also quasi zulässig sein.
                Nö. Zulässig ist, was den Syntaxregeln entspricht, also valide ist.

                … Syntax („Wohlgeformtheit“) im XML-Sinne ist die Übereinstimmung mit der XML-EBNF. Validität ist die zusätzliche Übereinstimmung mit der DTD. Das kann ein kontextfreier Parser nicht überprüfen; dazu braucht es einen validating Parser. Aber es gibt eben aus vielen Gründen auch non-validating Parser, weswegen, wie ich schon sagte, die Unterscheidung zwischen beiden Konzepten sehr sinnvoll ist. Auch, wenn man über (X)HTML5 nachdenkt. Die Syntaxdefinition der HTML5-Syntax ist zwar in Prosa gehalten, strukturell aber einer solchen kontextfreien Grammatik vergleichbar.

                Was der Parser erfolgreich geparst hat, muss allerdings nicht valide sein, da HTML5 die Fehlerbehandlung (d.h. das Verhalten bei invalidem Code) gleich mit spezifiziert.

                Ja. Aber ganz abgesehen vom Konzept der Validität gibt es ja das noch viel größere Konzept Conforming, das dafür sorgen will, ob Dokumente nicht nur maschinenlesbaren Regeln folgen, sondern auch dem Geist und Herz der Spec. Die Notiz bei der Definition für Conformance Checker ist da recht erläuternd.

                Die Spec […] bietet alternative Mechanismen an, XML-Namensräume in XML-Syntax
                Die Spec erlaubt nur wenige Attribute mit Namensräumen.

                Wieso verlinkst Du auf eine HTML-Syntax-Definition, wenn ich über die XML-Syntax rede? ;)

                Ich bezog mich übrigens auf 2.2.3 Extensibility:
                  For markup-level features that can be limited to the XML serialization and need not be
                  supported in the HTML serialization, vendors should use the namespace mechanism to
                  define custom namespaces in which the non-standard elements and attributes are
                  supported.

                DOM != HTML.

                Das ist ein anderes Thema, aber ich würde argumentieren, dass, nach vielen Problemen HTML nur in Rahmen dessen, was über das Netzwerkkabel geht, zu verhandeln, HTML5 den richtigen Schritt gemacht hat, HTML vorrangig in Termen des DOMs zu definieren und dann noch zusätzlich eine Syntax und dazu zusätzlich noch einen fehlerbehandelnden Parsingalgorithmus mitzuliefern. Insofern macht Deine Unterscheidung für mich eher weniger Sinn, weil man z.B. nicht über Elemente wie <canvas> nur im Rahmen von HTML-Syntax reden kann. Und dennoch ist <canvas> definitiv HTML.

  3. Moin!

    Leider kassiere ich dann einen Fehler beim Vailidator.

    Du hast Dich hier verschrieben. Das heisst Failidator.

    *scnr*

    --
    Signaturen sind bloed.