Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] HTML5 Schreibweisen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] HTML5 Schreibweisen

    Ich lese in meinem neuen HTML 5 Buch, dass folgende Varianten alle
    valides HTML 5 darstellen.

    Code:
    <input type="checkbox" checked="checked" >
    <input type="checkbox" checked="checked" />
    <input type="checkbox" checked >
    <input type=checkbox checked >
    <input type=checkbox checked=checked >
    <input tYpE=cHecKboX cHeCked >
    Was seht Ihr für Pros und Cons für die Schreibweisen? Ist die XHTML - Variante (mit enstprechendem Doctype) an zweiter Stelle am sinnvollsten (wenn auch nicht am einfachsten), wenn es um Sicherheit geht z. B. bei XSS Attacken und natürlich um zweifelsfreie Validität zu gewährleisten.
    Es ist schon alles gesagt. Nur noch nicht von allen.


  • #2
    Was hat das mit HTML5 zu tun? Das sind auch alles Schreibweisen, die in HTML 4.01/XHTML 1.0 auch schon gültig sind. Die ersten beiden sind schlicht die saubersten, da sie den Code einheitlicher machen, wobei der schließende Slash in der XHTML-Variante natürlich Geschamckssache sind. Ich bevorzuge sie aber.
    Vor allem die letzte Variante ist doch vollkommen sinnloses Gekritzel, von daher verstehe ich die Frage nicht. Die ist übrigens nur in der HTML-Variante möglich (HTML 4.01 oder HTML5, nicht XHTML 1.0 oder XHTML5).

    Und vor allem was hat das mit PHP zu tun?
    Themenmoderation:
    [→] Verschoben von PHP Einsteiger
    Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

    Kommentar


    • #3
      Manko10: O. K. da hast Du wohl Recht. Öh, mit allem. War etwas schnell geschossen von mir.

      Spielt denn ein Sicherheitsaspekt bei Dir keine Rolle bzgl. der Wahl der HTML-Version? Ich denke, wenn viele Schreibweisen valide sind, hat man natürlich auch mehr Möglichkeiten, etwas einzuschleusen, oder?
      Es ist schon alles gesagt. Nur noch nicht von allen.

      Kommentar


      • #4
        Eigentlich nicht. Um etwas einzuschleusen gibt es genau genommen nur einen Weg: etwas ungefiltert in den Zeichen"scope" von HTML zu schreiben. Da ist der AUfbau des Tags dann ziemlich Banane..
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          Du vergisst zudem, dass HTML eine Spezifikation ist und keine konkrete Implementierung. Die Sicherheitslücken zu implementieren ist somit Aufgabe der Browserhersteller, nicht die des W3C und weiterer Gruppen, die sich mit HTML5 befassen. Natürlich kann eine Spezifikation potentielle Schwachstellen enthalten, aber auch hier sind dann die Browserhersteller gefragt, diese zu umgehen.
          Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

          Kommentar


          • #6
            Die Sicherheitslücken zu implementieren
            Sind die auch spezifiziert
            --

            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


            --

            Kommentar


            • #7
              Naja, Adobe spezifiziert seine Sicherheitslücken jedenfalls. Escape From PDF « Didier Stevens.
              Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

              Kommentar


              • #8
                Zitat von nikosch Beitrag anzeigen
                Eigentlich nicht. Um etwas einzuschleusen gibt es genau genommen nur einen Weg: etwas ungefiltert in den Zeichen"scope" von HTML zu schreiben. Da ist der AUfbau des Tags dann ziemlich Banane..
                Die Antwort gefällt mir. Ansich habe ich es nämlich nicht so mit dem Superformalismus in XHTML. Sachen wie
                checked="checked"
                fand ich schon immer Banane. Und diese ewigen Anführungszeichen...Irgendwann hatte ich mir mal einreden lassen, dass XHTML (mit einer ordentlichen Charset-Angabe) sicherer sei. Danke an beide für den Input.
                Es ist schon alles gesagt. Nur noch nicht von allen.

                Kommentar


                • #9
                  Ich finde einfach das checked="checked" "schöner" ist. Denn ein HTML Element hat eben Attribute und diese Attribute haben einen Wert. Wir haben hier das Attribut "checked" mit dem Wert "checked". Wenn ich nur "checked" im Quellcode stehen habe, was ist das dann? Da wird vom Browser verlangt das er diesen Text selbstständig als Attribut mit selbigem Wert versteht.

                  Und sollte man die Seite mal per XML parsen wollen dann hat man eben valides XML. Ich finde es ist einfach sauber!

                  Kommentar


                  • #10
                    Wohlgemerkt: Ich habe geschrieben, dass es für die Sicherheit Banane ist! Ansonsten habe ich oft genug Postings gesehen, wo sich gewundert wird, warum

                    <input type=text value=abc cde>

                    nicht funktioniert. Stringbegrenzer wegzulassen werde ich also nie empfehlen.
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #11
                      wo sich gewundert wird, warum <input type=text value=abc cde> nicht funktioniert.
                      Aha, das war eigentlich auch genau das, was ich wissen wollte, als ich fragte:
                      Was seht Ihr für Pros und Cons für die Schreibweisen
                      Muß wohl doch noch mal darüber nachdenken. Also, falls jemand noch so einen wertvollen Hinweis hat...
                      Es ist schon alles gesagt. Nur noch nicht von allen.

                      Kommentar


                      • #12
                        Gibt es einen Grund nicht die "richtige" Syntax anzuwenden sondern die "kurzform" die der Browser selbstständig vervollständigen muss? Ich denke nicht. Von daher sehe ich kein Kontra zur normalen Schreibweise und kein pro zur abgekürzten Variante.

                        Kommentar


                        • #13
                          Zitat von Flor1an Beitrag anzeigen
                          Gibt es einen Grund nicht die "richtige" Syntax anzuwenden sondern die "kurzform" die der Browser selbstständig vervollständigen muss? Ich denke nicht. Von daher sehe ich kein Kontra zur normalen Schreibweise und kein pro zur abgekürzten Variante.
                          Kann es nicht sein, dass das Erfordernis, vervollständigen zu müssen, die Performance negativ beeinflusst? Weißt Du darüber etwas?
                          Es ist schon alles gesagt. Nur noch nicht von allen.

                          Kommentar


                          • #14
                            Keine Ahnung kann schon sein dass es bissl mehr Rechenaufwand bedeutet ich glaube aber nicht das es wirklich relevant ist.

                            Kommentar


                            • #15
                              Das ist außerdem von Browserengine zu Browserengine unterschiedlich. Die meisten bereiten den Code aber meist durch eine Preprozessor vorher auf und parsen ihn dann erst. Das äußert sich meistens darin, dass tbodys in Tabellen eingefügt werden, nicht geschlossene HTML-Tags geschlossen werden, einzelne <p>-Angaben zu einem vollständigen <p>…</p> vervollständigt werden und eben auch, dass Angaben wie checked zu checked="checked" geändert werden oder genau umgekehrt (kenne aber keine Engine, die das so macht, vielleicht der IE? ). Außerdem wird noch der Whitespace angeglichen. Das kannst du vor allem sehen, wenn du im Firefox mal per Firebug den Code ansiehst. Was du da zu sehen bekommst, ist nicht das, was du geschrieben hast, sondern das, was Gecko daraus gemacht hat.
                              Inwieweit sich das auf die Performance auswirkt, weiß ich nicht. Ich denke, das ist aber zu vernachlässigen. Normales HTML-Kuddelmuddel ist zwar generell schwerer zu parsen, als strenges XML, aber dafür wird bei HTML auch (im Gegensatz zu XML) schon während des Parsevorgangs die sichtbare Seite aufgebaut. Übrigens auch ein Grund, keine Tabellen für Layoutzwecke zu verwenden, da diese erst angezeigt werden, wenn die gesamte Tabelle geladen ist.
                              Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                              Kommentar

                              Lädt...
                              X