janne: !DOCTYPE html -- was ist zu beachten?

Hi alle,

mehr und mehr sieht man Seiten, die den neuen "HTML5-Doctype" verwenden: <!DOCTYPE html>. Ich habe bisher immer in HTML4 strict gearbeitet -- verhalten sich die Browser bei HTML5 irgendwie anders?

Soweit ich das nach etwas Recherche sehen kann, fallen in HTML5 gegenüber HTML4 strict keine Elemente weg, es kommen nur neue hinzu (von denen viele aber noch nicht von allen Browsern verstanden werden). Und angeblich schaltet auch kein Browser beim Anblick dieses Doctypes in den Quirks-Modus. Von daher sollte man den doch eigentlich gefahrlos einsetzen können, oder?

Sprich: Kann / soll ich meinen Standard-Doctype von:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

... umstellen auf ein simples:

<!DOCTYPE html>

... oder handle ich mir damit Probleme ein?

Danke,

j.

  1. Ich habe bisher immer in HTML4 strict gearbeitet

    Was ist HTML4 strict?

    verhalten sich die Browser bei HTML5 irgendwie anders?

    Nein, die meisten Browser merken den unterschied nicht - in alten Browser kommt es aber vor, dass neue HTML5-Element einfach nicht dargestellt werden.

    Und angeblich schaltet auch kein Browser beim Anblick dieses Doctypes in den Quirks-Modus.

    Ja, das wurde bewusst so gewählt.

    Von daher sollte man den doch eigentlich gefahrlos einsetzen können, oder?

    Zu welchem Zweck? Wenn du keine der neuen Elemente verwenden kannst (mangels Browserunterstützung), wozu dann einen neuen Doctype.

    ... oder handle ich mir damit Probleme ein?

    Zu welchem Zweck? Um "hip" oder "in" zu sein?

    Wenn du davon absiehst, dass bestimmte Elemente eine andere semantische bedeutung haben: rein visuell sollte es keine Probleme geben.

    1. Hi suit!

      Danke für Deine Antwort!

      Was ist HTML4 strict?

      Na, der von mir genannte Doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

      Zu welchem Zweck? Wenn du keine der neuen Elemente verwenden kannst (mangels Browserunterstützung), wozu dann einen neuen Doctype.

      Ich will keine bestehenden Projekte umstellen, jedenfalls nicht ohne zwingenden Grund. Mir geht's nur darum, was ich als Standard-Doctype für neue Projekte hernehme.

      Zu welchem Zweck? Um "hip" oder "in" zu sein?

      Bei wem ist man denn "hip" und "in" durch die Wahl eines Doctypes O_o ? Nein, in erster Linie wollte ich einfach wissen, wie/ob sich das auswirkt.

      Davon abgesehen ist <!DOCTYPE html> erheblich einfacher zu merken/tippen ist als der obige Bandwurm :-)

      Welchen Doctype verwendest Du normalerweise?

      j.

      1. Was ist HTML4 strict?

        Na, der von mir genannte Doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

        Sieht mir eher nach HTML 4.01 Strict aus :p

        Bei wem ist man denn "hip" und "in" durch die Wahl eines Doctypes O_o ?

        Bei Bloggern die keine Ahnung davon haben, was sie tun aber einfach mal HTML5 brüllen :)

        Nein, in erster Linie wollte ich einfach wissen, wie/ob sich das auswirkt.

        Garnicht :)

        Welchen Doctype verwendest Du normalerweise?

        XHTML 1.0 Strict oder Transitional (je nach Erfordernissen des Projekts) - aber notwendigerweise als text/html ausgeliefert.

        Schlichtweg weil sich solche Dokumente mit einem XML-Parser einfach verarbeiten lassen.

      2. Hallo,

        Bei wem ist man denn "hip" und "in" durch die Wahl eines Doctypes O_o ?

        ganz ohne Hype, das ist offenbar zu einfach oder zu langweilig, ausserdem werden so wohl auch Entwicklungen beschleunigt. Was natürlich auch voraussetzt, dass Entwicklung an sich schon wünschenswert ist.

        Nein, in erster Linie wollte ich einfach wissen, wie/ob sich das auswirkt.

        Die neuen Elemente in html5 wie section, article, nav, oder aside sind zur Strukturierung m.E. passender als Divs mit Attributen. Abwärtskompatibel ist sowas aber weniger und bei den meisten Explorern ist halt JavaScript nötig, um CSS-Formatierungen dieser Elemente zu erlauben.

        Grüsse

        Cyx23

    2. @@suit:

      nuqneH

      in alten Browser kommt es aber vor, dass neue HTML5-Element einfach nicht dargestellt werden.

      ?? Browser sollten Tags, die sie nicht verstehen, einfach ignorieren. Also den Elementinhalt von <aside>Dies nur nebenbei</aside> durchaus darstellen (wenn auch unformatiert).

      Zu welchem Zweck? Wenn du keine der neuen Elemente verwenden kannst (mangels Browserunterstützung)

      Die neuen Elemente kann man verwenden. Man muss lediglich im Stylesheet angeben, wie sie dargestellt werden sollen:

      header, footer, section, aside { display: block }

      Damit der IE das rafft, müssen sie ihm per JavaScript (vor dem Stylesheet) bekanntgemacht werden:

      document.createElement('header');  
      document.createElement('footer');  
      document.createElement('section');  
      document.createElement('aside');
      

      Zu welchem Zweck? Um "hip" oder "in" zu sein?

      Weil <aside> besserer Code ist als <div class="aside">?

      Weil sich etliche Attribute (@autocomplete, @autofocus, @placeholder) sinnvoll verwenden lassen?

      Damit 'embed' valide ist? SCNR.

      Qapla'

      --
      Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
      (Mark Twain)
      1. in alten Browser kommt es aber vor, dass neue HTML5-Element einfach nicht dargestellt werden.

        ?? Browser sollten Tags, die sie nicht verstehen, einfach ignorieren. Also den Elementinhalt von <aside>Dies nur nebenbei</aside> durchaus darstellen (wenn auch unformatiert).

        Sag das einem alten Internet Exploder :)

        Damit der IE das rafft, müssen sie ihm per JavaScript (vor dem Stylesheet) bekanntgemacht werden:

        Das ist das Problem, ja - denn ohne JavaScript läuft dann nichts - und du wärst wirklisch überascht, wenn ich dir sage wieviele Kunden sich beschwerden, wenn etwas ohne JavaScript oder im IE6 nicht läuft - besonders Hotels sind da sehr heikel.

        Weil <aside> besserer Code ist als <div class="aside">?

        Alsob das irgend einen praktischen Effekt hätte.

        Weil sich etliche Attribute (@autocomplete, @autofocus, @placeholder) sinnvoll verwenden lassen?

        Ich hatte noch nie Bedarf diese zu nutzen.

        Damit 'embed' valide ist? SCNR.

        YMMD

        Das ist einer der Punkte den ich nie verstehen werde - wenn es <audio /> und <video /> gibt (obwohl ich auch hier den Sinn anzweifle), warum ist dann noch embed nötig? :)

        1. Sag das einem alten Internet Exploder :)

          Dargestellt werden die Elemente bzw. deren Inhalt doch schon. Nur ohne Tricks lassen sich die Elemente eben nicht formatieren. Aber das ist nicht die Schuld von (X)HTML N sondern von Microsoft (oder dem W3C, je nachdem).

          Ich hatte noch nie Bedarf diese zu nutzen.

          Ein einzelner Autor ist auch nicht repräsentativ. Ich hatte noch nie Bedarf am q-Element, aber eine Menge andere Leute schon.
          Und das placeholder-Attribut sollte dir doch gefallen, vor allem wenn man deine Kunden bedenkt.

          Das ist einer der Punkte den ich nie verstehen werde - wenn es <audio /> und <video /> gibt (obwohl ich auch hier den Sinn anzweifle), warum ist dann noch embed nötig? :)

          Weil embed - zugegeben kein schönes Element - nicht für Audio- und Videoeinbindung gedacht ist. Aber wenn es so sehr stört, frag doch ob man es in die "misbilligt" Sektion verschieben kann.

          Das ist das Problem, ja - denn ohne JavaScript läuft dann nichts - und du wärst wirklisch überascht, wenn ich dir sage wieviele Kunden sich beschwerden, wenn etwas ohne JavaScript oder im IE6 nicht läuft - besonders Hotels sind da sehr heikel.

          Schwierige Kunden in der Tat. Zum Glück müssen wir das ganze nur noch bis 2020 aushalten, danach sind die Browser (der IE) angepasst.

          Diese Zeit klingt natürlich erstmal total lächerlich. Andererseits haben wir diese Zeit auch schon damit verbracht auf z.B. CSS 2.1 zu warten.

          1. Das ist einer der Punkte den ich nie verstehen werde - wenn es <audio /> und <video /> gibt (obwohl ich auch hier den Sinn anzweifle), warum ist dann noch embed nötig? :)

            Weil embed - zugegeben kein schönes Element - nicht für Audio- und Videoeinbindung gedacht ist. Aber wenn es so sehr stört, frag doch ob man es in die "misbilligt" Sektion verschieben kann.

            Ich spielte da eher auf object an.

            Schwierige Kunden in der Tat. Zum Glück müssen wir das ganze nur noch bis 2020 aushalten, danach sind die Browser (der IE) angepasst.

            Zähne zusammenbeissen, ist ja nicht mehr lang ;D

            Andererseits haben wir diese Zeit auch schon damit verbracht auf z.B. CSS 2.1 zu warten.

            Und wir warten immer noch :D

      2. Hallo Gunnar,

        Die neuen Elemente kann man verwenden. Man muss lediglich im Stylesheet angeben, wie sie dargestellt werden sollen:

        header, footer, section, aside { display: block }

        Damit der IE das rafft, müssen sie ihm per JavaScript (vor dem Stylesheet) bekanntgemacht werden:

        document.createElement('header');

        document.createElement('footer');
        document.createElement('section');
        document.createElement('aside');

          
        Ziemlicher Aufwand...  
          
        Da verwende ich lieber role="article" oder andere Werte (banner, navigation usw.) - die haben auch einen praktischen Nutzen.  
          
        
        > Weil sich etliche Attribute (@autocomplete, @autofocus, @placeholder) sinnvoll verwenden lassen?  
          
        Wie willst Du autofocus sinnvoll verwenden? Wenn man das einsetzt, dann wohl in einem Formular, damit man direkt lostippen kann. Aber was passiert dann mit Texten über dem Formular (Tipps zum Ausfüllen, Hinweise auf Pflichtfelder usw.)? Sind die noch im sichtbaren Bereich? In welchen Browsern, ab welcher Version? Unter welchen Bedingungen?  
          
        Weißt Du was das für Nutzer von Screenreadern bedeutet, die man per se in den Formular-Modus schickt. Also gerade autofocus finde ich, ist kein gutes Argument, um auf HTML5 umzusteigen...  
          
        Obwohl auf der Google-Startseite, die man nur deswegen besucht, um einen Suchbegriff loszuschießen, macht auch das u. U. Sinn, weil man davon ausgehen kann, dass der Nutzer diese Seite kennt.  
          
        Trotzdem muss man hiermit sehr vorsichtig sein.  
          
        Ich nutze ebenfalls HTML5 (wegen den Gründen, die Du angegeben hast: neue Attribute und Elemente), verzichte aber auf so etwas wie autofocus aus den angegebenen Gründen - man muss halt genau wissen, was neue Elemente und Attribute tun und vor dem Einsatz testen, testen, testen.  
          
        Viele Grüße,  
        Marc.
        
        -- 
        Und immer schön  
        validieren (<http://validator.w3.org/>)
        
        1. @@Marc:

          nuqneH

          document.createElement('header');

          document.createElement('footer');
          document.createElement('section');
          document.createElement('aside');

          
          >   
          > Ziemlicher Aufwand...  
            
          Ach was. Einmal geschrieben, C&Ped.  
            
          Allerdings gehört das noch als conditional compilation auskommentiert, damit Nicht-IEs den für sie unnützen Code nicht ausführen.  
            
            
          
          > Wie willst Du autofocus sinnvoll verwenden? Wenn man das einsetzt, dann wohl in einem Formular, damit man direkt lostippen kann.  
            
          Ja, natürlich. Webseiten, die dazu bestimmt sind, dass der Nutzer dort Eingaben tätigt, dies aber erst nach einem eigentlich unnötigem Mausclick o.a. Aktion tun kann, sind ein Usability-Ärgernis.  
            
            
          
          > Aber was passiert dann mit Texten über dem Formular (Tipps zum Ausfüllen  
            
          Wenn ein Formular Tips zum Ausfüllen nötig hat, sollte man ernsthaft überlegen, ob es richtig designt ist (Anordnung der Felder, Beschriftung der Labels, …). Der Nutzer will auf dieser Seite Eingaben tätigen, nicht ellenlange Texte lesen.  
            
          
          > Hinweise auf Pflichtfelder  
            
          Diese lassen sich gut \_in\_ den Eingabefeldern unterbringen. Hier käme @placeholder ins Spiel:  
          ~~~html
          <label for="name">Name</label>  
          <input id="name" name="name" placeholder="Pflichtfeld"/>
          

          Weißt Du was das für Nutzer von Screenreadern bedeutet, die man per se in den Formular-Modus schickt.

          Wenn ein Screenreader ein Problemmit @autofocus hat, muss dieses im Screenreader behoben werden. Die Lösung kann nicht sein, den Sehenden (der großen Mehrheit) diese äußerst nützliche Funktionalität vorzuenthalten.

          Qapla'

          --
          Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
          (Mark Twain)
          1. Hallo @@Gunnar,

            document.createElement('header');

            document.createElement('footer');
            document.createElement('section');
            document.createElement('aside');

            
            > >   
            > > Ziemlicher Aufwand...  
            >   
            > Ach was. Einmal geschrieben, C&Ped.  
            >   
            > Allerdings gehört das noch als conditional compilation auskommentiert, damit Nicht-IEs den für sie unnützen Code nicht ausführen.  
              
            Einziger Haken: Leute, die ohne JavaScript unterwegs sind.  
              
            
            > > Aber was passiert dann mit Texten über dem Formular (Tipps zum Ausfüllen  
            >   
            > Wenn ein Formular Tips zum Ausfüllen nötig hat, sollte man ernsthaft überlegen, ob es richtig designt ist (Anordnung der Felder, Beschriftung der Labels, …). Der Nutzer will auf dieser Seite Eingaben tätigen, nicht ellenlange Texte lesen.  
              
            Na ja, klar kann man bei Google einfach lostippen und absenden - richtig gut sind Suchen aber meist erst, wenn man vernünftig einschränken kann - und das hat kaum jemand so ganz intuitiv gelöst - ein paar Tipps und Hinweise sind fast immr sinnvoll, meist sogar nötig.  
              
            
            > > Hinweise auf Pflichtfelder  
            >   
            > Diese lassen sich gut \_in\_ den Eingabefeldern unterbringen. Hier käme @placeholder ins Spiel:  
            > ~~~html
            
            <label for="name">Name</label>  
            
            > <input id="name" name="name" placeholder="Pflichtfeld"/>
            
            

            Finde ich auch problematisch - mir geht es öfters so, dass ich da (voreilig?) rein klicke und dann erst bemerke, dass ich gar nicht gelesen habe, was da stand - aber der placeholder (derzeit meist mit JavaScript realisiert) ist weg, Dann muss ich erst in ein anderes Feld klicken und hoffen, dass der Hinweis wieder erscheint.

            Du siehst Hinweise sind nicht immer ein Zeichen für schlechte Nutzerführung - manchmal geht es einfach nicht ohne. Vor allem wenn Web-Neulinge ein Formular bedienen sollen.

            Weißt Du intuitiv, wie Du in einem unbekannten Formular richtig trunkierst?

            Weißt Du was das für Nutzer von Screenreadern bedeutet, die man per se in den Formular-Modus schickt.

            Wenn ein Screenreader ein Problemmit @autofocus hat, muss dieses im Screenreader behoben werden. Die Lösung kann nicht sein, den Sehenden (der großen Mehrheit) diese äußerst nützliche Funktionalität vorzuenthalten.

            Nicht mit autofocus an sich, sondern mit der Tatsache, dass der sinnvolle und gewollte "Formularmodus" einfach anders funktioniert, als der "Vorlesemodus".

            Und es wäre schlecht, wenn das nicht so wäre. Gerade hier wird es auch noch eine Weile dauern, bis jeder der häufig weniger begürterten Menschen mit starken Seh-Schwierigkeiten die sehr teure neuste Version der Software
            kaufen können...

            Ein voll ausgestatter Blinden-Arbeitsplatz kostet schnell 10.000 EUR und mehr. Es wird niemanden wundern, dass die Kassen das nciht alle drei Jahre übernehmen.

            Also selbst wenn das Problem vom Hersteller gelöst ist, steht die Lösung noch lange nicht jedem Nutzer zur Verfügung. Du weißt selber, wie selten selbst kostenlose Software mitunter aktualisiert wird (wie z. B. der IE...)

            Die Idee ist ja an sich nett und Deine Vorschzläge machen durchaus Sinn. Aber noch würde ich dieses spezielle Attribut nicht verwenden.

            Klar gibt es zumeist sehende Menschen, aber ich bin ein großer Freund des Solidaritäts-Prinzips und nicht behinderte Menschen haben von den großen Fortschritten und der zunehmenden Verbreitung barriefreier Seiten sehr profitiert. Die meisten "Features" zugänglicher Webseiten sind vor alle Nutzer ein Vorteil. Viele Seiten im Web sind heute viel besser nutzbar, als vor zehn Jahren. Da kann man auch mal von einem Sehenden Zugeständnisse erwarten - zumal wenn die sich darin erschöpfen, einmal "unnötig" zu klicken.

            Meine 2 Cent...

            Viele Grüße,
            Marc.

            --
            Und immer schön
            validieren (http://validator.w3.org/)
    3. Hi,

      in alten Browser kommt es aber vor, dass neue HTML5-Element einfach nicht dargestellt werden.

      erwähnenswert ist vielleicht noch, dass die Definition "alte Browser" auch die IEs bis einschließlich Version 8 umfasst. Dort wird aus dem Code <aside><p>...</p></aside> etwa dies:

        
      <ASIDE></ASIDE>  
      <p>...</p>  
      <%2FASIDE></%2FASIDE>  
      
      

      Die Whitespaces mal außer Acht gelassen. Außerdem ist "%2F" hier als Symbol dafür zu sehen, dass der Name(!) des erzeugten Elements tatsächlich "/ASIDE" lautet ...

      Cheatah

      --
      X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
      X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
      X-Will-Answer-Email: No
      X-Please-Search-Archive-First: Absolutely Yes
  2. Hallo janne,

    was ist zu beachten? Als erstes mal über die Unterschiede informieren:

    HTML5 differences from HTML4 (englisch)

    Google wirft auhc viele deutsche Seiten zu dem Thema aus...

    Viele Grüße,
    Marc.

    --
    Und immer schön
    validieren (http://validator.w3.org/)