Archive for the ‘HTML5’ tag
HTML-Validierung: Reine Zeitverschwendung, oder?
Gastartikel von David Becker, er arbeitet als Autor bei netzsieger.de
Diese Frage wird ein Teil der Webgemeinde vehement bejahen, die anderen werden ebenso überzeugt widersprechen. Ob eine klare Antwort in dieser Thematik überhaupt möglich ist, sei vorerst offengelassen. Jeder, der sich etwas genauer mit der Frage auseinandergesetzt hat, kommt zu einem anderen Schluss, hauptsächlich abhängig von den eigenen Erfahrungen und Konsequenzen. Bei näherer Recherche ergibt sich schnell, dass selbst Branchengrößen wie Amazon oder Facebook invaliden Code verwenden. Ja, selbst Google nimmt diese in Kauf. Aber nur weil andere es machen, muss es nicht zwangsläufig für jeden der richtige Weg sein.
Welche Vorteile ergeben sich durch validen Code?
Mit einem Vorurteil kann direkt aufgeräumt werden. Google bestraft Websites mit invalidem Code nicht. Die Top-Suchergebnisse beliebiger Sucheingaben sind fast immer Websites, die ungültiges HTML beinhalten. Den Code des eigenen Webauftritts komplett fehlerlos zu halten, ist also kein Freifahrtschein, von Google dafür auch belohnt zu werden. Es gibt aber durchaus andere Argumente, die für möglichst ausschließliche Nutzung validen Codes sprechen.
Gerade veraltetes, fehlerhaftes HTML mag aktuell korrekt angezeigt werden. Bei zukünftigen Browsern könnte das aber schon nicht mehr der Fall sein. Was gerade noch problemlos erscheint, könnte dann plötzlich doch Probleme bereiten. Außerdem darf auch nicht die gegenseitige Verstärkung mehrerer Fehler unterschätzt werden. Zwei, drei Fehler auf einer Seite bleiben vielleicht ohne Konsequenzen, bei noch mehr invalidem Code wird die Seite dann aber vielleicht doch nicht mehr korrekt angezeigt.
Weiterlesen »
Der Stand von HTML5
Da viele von uns wahrscheinlich bereits HTML5 Webseiten erstellen oder ältere Seiten um HTML5-Features erweitern ist es wichtig zu wissen welcher Browser welches Feature unterstützt, um abschätzen zu können wieviel Prozent der Besucher das neue Feature nutzen können und wie viele nicht.
Die wohl korrekteste Methode das herauszufinden ist auf die aktuelle Webseite ein paar Javascript-Zeilen hinzuzufügen die die entsprechende Feature-Unterstützung testet, die sogenannte Feature Detection. Die Liste mit unterstützten bzw. nicht unterstützten Features schickt man via AJAX zum Server zurück. Nur so hat man aktuelle und auf die eigenen Besucher abgestimmte Zahlen.
Man müßte also ähnlich wie hier für das canvas-Element einen Test schreiben:
function supports_canvas() {
return !!document.createElement('canvas').getContext;
}
Aber es gibt schon große Bibliotheken, die hunderte von solchen Tests kennen und wo man einfach eine Funktionalität testen kann, wie hier beispielsweise mit Modernizr:
if (Modernizr.canvas) {
// let's draw some shapes!
} else {
// no native canvas support available :(
}
Modernizr ist der bekannteste Vertreter, es ist auch möglich die unterstützten Codecs des <video> und <audio> Tags abzufragen und vieles mehr.
Es gibt aber auch Webseiten und Tabellen, die allgemein darstellen welche Browser-Versionen welche Features unterstützen. Wenn man diese Tabellen nimmt und ungefähr mit der Browser-Verteilung der eigenen Besucher verrechnet kommt man auch zu einem Ergebnis.
Die bekanntesten Seiten sind:
- http://html5test.com/results.html bzw. http://www.browserscope.org/user/tests/table/agt1YS1wcm9maWxlcnINCxIEVGVzdBiBsqYGDA
Wenn man nun das Ergebnis erhält dass bereits 85% der Besucher das Feature X unterstützt gilt es Entscheidungen zu treffen. Ist es noch zu früh, das Feature einzubauen? Was macht man mit denjenigen, die noch einen alten Browser haben? Versucht man das fehlende Feature nachzubilden? Für diese Nachbildungen gibt es Sammlungen von sogenannten Polyfills und Shims. Wenn der Browser also beispielsweise das placeholder-Attribut noch nicht unterstützt ist trotzdem möglich, sie mittels Javascript hinzuzufügen. Das geht natürlich nicht für alle neuen Features, aber für viele gibt es Nachbauten. Aber dieses zusätzliche Javascript bläht natürlich die Webseite auf und es ist auch nicht so schnell wie die native Unterstützung des Browsers. Aber was tut man nicht alles dafür, neue Features nutzen zu können ohne einen Teil seiner Besucher zu verärgern.
Hier eine schöne Liste der aktuell verfügbaren Polyfills und Shims:
Linkpool Nummer 8
Growl-ähnliche Benachrichtigungen auf dem Desktop aus dem Browser heraus:
http://www.peterkroener.de/web-notifications/
Sammlung von HTML5 Beispielen:
http://html5watch.tumblr.com/
Sehr umfangreicher Artikel über Password Hashing, SQL Injection und alles was mit User-Administration zu tun hat:
http://php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/
Das Zend Framework 2.0 ist nun per Git verfügbar, auch auf Github:
http://www.zendframeworkinaction.com/2010/06/04/zend-framework-2-development-starting-in-earnest/
Das Geburtstags-Pacman-Spiel bei Google ist nach wie vor online:
http://www.google.de/pacman/
Ich sag es ja immer wieder: Auch NOTICEs sollten sofort behoben werden:
http://phpperformance.de/programmiert-sauber-auch-fuer-die-performance/
Linkpool Nummer 5
Was für eine aufregende Woche: Polen verliert ihr Präsidentenpaar, in Afghanistan fallen deutsche Soldaten, eine Aschewolke nebelt Europa ein, ein Video „Collateral Murder“ aus dem Irak taucht bei Wikileaks auf. Aber auch in der IT-Welt gibt es hier und da interessante News und Blogeinträge:
Deployment kurz und gut zusammengefasst in einer Präsentation:
Mit HTML5 verlieren wir einige alte HTML-Tags:
Mocks beim Testen:
OAuth für IMAP und SMTP:
Daten rauszugeben an ein Medium das nicht vergisst kann Schaden verursachen:
Ein Zend_Form Validator über mehrere Felder (Passwort wiederholen):
Ich hatte leider noch keine Zeit, Googles neue Sicherheits-Test–Software auszuprobieren:
phpMyAdmin Timeout erhöhen:
HTML 5 und Javascript 5: Clientseitige Datenbanken
Nachdem sich die Web Hypertext Application Technology Working Group (WHATWG) 2004 gegründet hat, die aus einigen bedeutenden Internet-Riesen besteht (u.a. Apple, Mozilla, Opera), kommt wieder Fahrt in neue HTML- und Javascript-Standards. Die Gruppe hat viele Proposals erstellt, von denen jetzt einige vom W3C übernommen werden. Stichworte sind da HTML 5, ECMAScript 5, Web Workers, Web Storage, Web Sockets und einiges mehr.
Zu den Web Workern hatte ich ja bereits etwas geschrieben.
Web Sockets wird die Pushing-Technik werden, mit der Server bei Änderungen Nachrichten an den Browser schicken können, dann erübrigt sich das derzeitige Pullen und Nachfragen via AJAX, ob es Neuigkeiten gibt. Das entlastet die Server und spart Traffic, und Nachrichten kommen genau dann im Browser an wenn sie auf dem Server passieren, nicht erst beim nächsten Pull.
Heute soll es um den Web Storage gehen, die clientseitige Datenbank im Browser. In der Vergangenheit konnte man Daten nur auf der aktuellen Seite in Javascript-Variablen vorhalten, sobald aber der nächste Full-Page-Reload kommt sind die Daten futsch. Die zweite Möglichkeit waren Cookies, in denen man Daten speichern kann. Da aber Cookies bei jedem Request mitgesendet werden, ist das kein guter Speicherort für größere Datenmengen, Cookies sollte man höchstens für eine SessionID nutzen.
