{"id":988,"date":"2012-01-27T20:08:43","date_gmt":"2012-01-27T19:08:43","guid":{"rendered":"https:\/\/sgaul.de\/?p=988"},"modified":"2014-03-31T15:00:42","modified_gmt":"2014-03-31T13:00:42","slug":"der-neue-script-tag-in-html-5","status":"publish","type":"post","link":"https:\/\/sgaul.de\/2012\/01\/27\/der-neue-script-tag-in-html-5\/","title":{"rendered":"Der neue Script-Tag in HTML 5"},"content":{"rendered":"

Eine nette kleine \u00c4nderung in HTML 5, die ich bisher \u00fcbersehen habe: Auch das Script-Tag wurde \u00fcberarbeitet und bietet gleich drei interessante Neuheiten.<\/p>\n

Optionales Type-Attribut<\/h2>\n

Vorbei ist die Zeit von <script type=\"text\/javascript\"><\/code>: Der Typ, welcher in rund 100% aller F\u00e4lle immer auf Javascript gesetzt werden musste, ist endlich optional. Das sch\u00f6ne daran: Alte Browser hatten ohnehin nie Probleme, wenn das Attribut fehlte.<\/p>\n

Viele Code-Schreiber entschieden sich daher schon fr\u00fch, das Attribut wegzulassen. F\u00fcr mich f\u00fchlte es sich das falsch an. Standards zu brechen \u201eweil es geht\u201c und etwas praktisch ist. Auch bei der Apacheerweiterung\u00a0Modpagespeed<\/a> gab es des \u00f6fteren Diskussionen \u00fcber das Thema. Nun ist dieses Thema also keines mehr: Es funktioniert \u00fcberall und ist valide.<\/p>\n

Asynchrones Ausf\u00fchren von JS: <script async><\/code><\/h2>\n

Mit dem Async-Attribut kann man den JS-Code einer Datei asynchron ausf\u00fchren. Dies bedeutet, dass vor allem aufwendige Berechnungen nicht mehr dazu f\u00fchren, dass der Browser einfriert. Bisher habe ich mir in solchen Situationen mit einem Timeout geholfen, so dass einzelne Code-Teile immer wieder mit einer Auszeit gestartet wurden.<\/p>\n

function recursive(a) {\r\n  window.setTimeout(function(){\r\n    a += 1;\r\n    return recursive(a);\r\n  }, 0);\r\n}<\/pre>\n
Das Beispiel zeigt die Idee und keinen sinnvollen Anwendungsfall…<\/p>\n
Das \u201enormale\u201c Skript kann dann mit dem asynchron ausgef\u00fchrten Code mittels Nachrichtenaustausch kommunizieren. Allerdings scheint das alles noch sehr frisch zu sein, ich konnte auf die Schnelle keine gute Anleitung daf\u00fcr finden.<\/p>\n
Auf die Verbreitung darf man hier noch lange nicht setzen. Insofern ist dieses Attribut wohl leider noch nicht interessant. \u00c4hnlich wie beim dritten Kandidaten…<\/p>\n
Nicht blockierendes Laden dank <script defer><\/code><\/h2>\n
Ein bekanntes Problem ist es, dass das Laden einer Javascript-Datei das Rendern der Website blockiert. Dies f\u00e4llt vor allem beim klassischem Script-im-Head-Prinzip auf. Mit dem neuen Attribut defer<\/code> gibt es endlich Abhilfe: Ist dieses mit angegeben, wei\u00df der Browser, dass er auch w\u00e4hrend das Skript geladen wird schon einmal weitermachen kann.<\/p>\n
Solange die breite Masse der Browser dies nicht unterst\u00fctzen, gibt es hier einen simplen und effektiven Workaround: Man packt die Scripts einfach ans Ende, direkt vor den schlie\u00dfenden Body:<\/p>\n
  <!-- content... -->\r\n  <script src=\"script.js\"><\/script>\r\n<\/body><\/pre>\n
Funktioniert \u00fcberall und tut nicht weh. So gesehen dr\u00e4ngt die Verbreitung des Defer-Attributs nicht wirklich…<\/p>\n
Links<\/h2>\n