HTML5: type="text/css" für <link> unnötig?

[Malin]

Hallo!

Ich habe irgendwo gelesen, dass in HTML5 die Angabe von type="text/css" im link-Tag nicht mehr nötig ist. Folglich reicht folgende Deklaration:

<link rel="stylesheet" href="screen.css" />

Ist das korrekt? Hat jemand dazu weiterführende Informationen?

Grüße
Malin

[dedlfix]

Hi!

Ich habe irgendwo gelesen, dass in HTML5 die Angabe von type="text/css" im link-Tag nicht mehr nötig ist. Folglich reicht folgende Deklaration:
<link rel="stylesheet" href="screen.css" />

Sie ist generell nicht nötig (im Sinne von vorgeschrieben), gibt aber dem Client die Möglichkeit anhand dieser Angabe von vorn herein zu entscheiden, sie zu laden oder nicht. Vielleicht kann er den Typ ja nicht verarbeiten. (Siehe HTML 4.01-Spezifikation, Abschnitt zu Links, weiter zum LINK-Element.)

Lo!

[molily]

Sie ist generell nicht nötig (im Sinne von vorgeschrieben), gibt aber dem Client die Möglichkeit anhand dieser Angabe von vorn herein zu entscheiden, sie zu laden oder nicht. Vielleicht kann er den Typ ja nicht verarbeiten.

Es wäre also sinnvoll, type anzugeben, wenn man als Stylesheet-Sprache nicht CSS verwendet, damit der Browser das Stylesheet erst gar nicht lät.
Nur gibt es eben keine andere Stylesheet-Sprache, außer vielleicht XSL-T/XSL-FO, welche aber ihre eigene Einbettungsweise haben.

Zudem gibt es Browser, die das Stylesheet auch im Falle von type="husseldiguggeldidu" laden, insofern wäre dort der etwaige Vorteil nicht gegeben.

Ergo gibt es so ziemlich keinen realistischen Fall, indem man type anzugeben braucht.

Mathias

[dedlfix]

Hi!

Sie ist generell nicht nötig (im Sinne von vorgeschrieben), gibt aber dem Client die Möglichkeit anhand dieser Angabe von vorn herein zu entscheiden, sie zu laden oder nicht. Vielleicht kann er den Typ ja nicht verarbeiten.
Es wäre also sinnvoll, type anzugeben, wenn man als Stylesheet-Sprache nicht CSS verwendet, damit der Browser das Stylesheet erst gar nicht lät.

In diesem Fall geht es zwar um CSS, aber das link-Element ist ja nicht nur darauf beschränkt.

[...]
Ergo gibt es so ziemlich keinen realistischen Fall, indem man type anzugeben braucht.

Insofern kann ich mir vorstellen, dass es insgasamt gesehen nicht ganz unsinnig ist.

Zudem gibt es Browser, die das Stylesheet auch im Falle von type="husseldiguggeldidu" laden, insofern wäre dort der etwaige Vorteil nicht gegeben.

Auf diese Weise kann man genausogut argumentieren, Standards zu ignorieren, weil einige sie sowieso nicht befolgen. Man kann es ja nicht ändern, dass einige doofe Teilnehmer mitspielen, aber deswegen muss man ja die anderen nicht auf deren Niveau herunterziehen.

Lo!

[molily]

Zudem gibt es Browser, die das Stylesheet auch im Falle von type="husseldiguggeldidu" laden, insofern wäre dort der etwaige Vorteil nicht gegeben.

Auf diese Weise kann man genausogut argumentieren, Standards zu ignorieren, weil einige sie sowieso nicht befolgen.

Das war kein Argument, nur eine Info über die Browserkompatibilität; man kann sich eben nicht darauf verlassen. Dieses Verhalten ist natürlich nicht standardkonform, sondern widerspricht HTML5 ausdrücklich (siehe das Beispiel unter »If a document contains style sheet links labeled as follows«). Die meisten Browser machen das m.W. richtig, aber Webkit bspw. falsch.

Mathias

[suit]

In diesem Fall geht es zwar um CSS, aber das link-Element ist ja nicht nur darauf beschränkt.

Ich denke, die meisten Browser werden wohl auf das rel-Attribut zielen, das type-Attribut ist denen vermutlich völlig egal.

[Cheatah]

Hi,

Ich habe irgendwo gelesen, dass in HTML5 die Angabe von type="text/css" im link-Tag nicht mehr nötig ist.

HTML5 ist der Ansatz des W3C, die gängige Praxis in etwas Praktikables umzusetzen. Das W3C hat festgestellt, dass Stylesheets in fast allen Fällen CSS sind, und dass Scripts in fast allen Fällen JavaScripts sind. Daher kann bei <link rel="stylesheet"> und bei <script> vom entsprechenden Typus ausgegangen werden, sofern dort nichts Gegenteiliges gesagt wird. Die Folge davon ist, dass ...

Folglich reicht folgende Deklaration:
<link rel="stylesheet" href="screen.css" />

... dies korrekt ist.

Cheatah

[molily]

HTML5 ist der Ansatz des W3C, die gängige Praxis in etwas Praktikables umzusetzen. Das W3C hat festgestellt, ...

*gg* Das war geschichtlich gesehen eher die WHATWG. Das W3C hat sich erst einmal viele Jahre dagegen gesträubt. Aber ja, nun ist es auch W3C-Position.

Mathias

[molily]

Hallo,

Ich habe irgendwo gelesen

Maßgeblich ist die HTML5-Spezifikation, die solltest du bei solchen Fragen zuerst konsultieren:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element – das link-Element
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-type – das type-Attribut des link-Elements
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-stylesheet – der Linktyp stylesheet

Alternativ kannst du den HTML5-Validator bemühen
http://html5.validator.nu/
Einfach mal dort auf »Text field« als Eingabequelle gehen und ein <link rel="stylesheet" href="test.css"> in den head einfügen.

Allgemein gibt es sehr wenige Attribute, die zwingend angegeben werden müssen, d.h. wenn, steht es ausdrücklich in der Spezifikation (»the xyz attribute must be present« o.ä.).

Mathias

[suit]

Maßgeblich ist die HTML5-Spezifikation, die solltest du bei solchen Fragen zuerst konsultieren:

Warum verlinkst du dann die flüssige HTML5-Brainstorming Seite und nicht die Spezifikation? ;)

[molily]

Maßgeblich ist die HTML5-Spezifikation, die solltest du bei solchen Fragen zuerst konsultieren:

Warum verlinkst du dann die flüssige HTML5-Brainstorming Seite und nicht die Spezifikation? ;)

Diese beiden Seiten sind m.W. identisch bis auf die bekannten Auslagerungen auf W3C-Seite (canvas 2D-API etc.) und den gekannzeichneten Ergänzungen auf WHATWG-Seite (device-Element, WebVTT etc.). An den fraglichen Abschnitten hat sich vermutlich schon seit Jahren nichts mehr inhaltlich geändert. Wieso sollte ich nicht darauf verweisen?

Wenn Ian Hickson eine Änderung macht, wird daraus m.W. www.whatwg.org/specs/web-apps/current-work/ genauso wie dev.w3.org/html5/spec/ kompiliert. Zumindest is dev.w3.org derzeit auf dem Stand von whatwg.org (vgl. http://html5.org/tools/web-apps-tracker).

Im Übrigen dürftest du mitbekommen haben, dass HTML5 bei der WHATWG als Living Standard entwickelt wird. Maßgeblich ist immer die neueste Version. Das W3C will irgendwann einen Snapshot veröffentlichen (bzw. macht das in Form von Working Drafts bereits). Wenn das passiert ist, dann könnte man vielleicht darauf verweisen. Die Working Drafts sind derweil einfach veraltet. Selbst wenn der Snapshot Recommendation wird, wird er bald veraltet sein. Denn die neuesten Korrekturen finden sich in der tagesaktuellen Version (Living Standard bei der WHATWG bzw. Editor’s Draft beim W3C). Beim W3C muss man dann auf die »Second Edition« warten bzw. immer noch die Errata dazu verlinken...

Mathias

[suit]

Im Übrigen dürftest du mitbekommen haben, dass HTML5 bei der WHATWG als Living Standard entwickelt wird.

Das meinte ich mit "flüssig" - man baut drauf und währenddessen fließt viel Wasser den Bach runter und schon ist alles anders ;)

[molily]

Im Übrigen dürftest du mitbekommen haben, dass HTML5 bei der WHATWG als Living Standard entwickelt wird.

Das meinte ich mit "flüssig" - man baut drauf und währenddessen fließt viel Wasser den Bach runter und schon ist alles anders ;)

Das ist ein verbreitetes Vorurteil. Vielleicht liest du mal die WHATWG-FAQ und die Design Principles. Natürlich gibt es Bereiche, in denen noch gearbeitet wird. Allerdings gilt, dass Änderungen abwärtskompatibel sein müssen, also kompatibel zu älteren Spec-Versionen und gleichsam kompatibel zu Browserimplementationen. Die Spec wird nicht plötzlich das Gegenteil behaupten und den Browsern eine ganz andere Verarbeitung von link@type vorschreiben. Das passiert natürlich bei noch nicht abgekühlten Spec-Teilen, aber nicht bei so grundlegenden Regeln, die bloß eine Kodifizierung der Praxis sind. Natürlich widersprich die Spec gegenwärtigem Browser-Verhalten punktuell absichtlich (wie gesagt hält sich Webkit nicht an die gegenwärtigen Regeln), aber das ist unvermeidlich, wenn man Browserverhalten durch Standardisierung vereinheitlichen will.

Mathias

[suit]

Das ist ein verbreitetes Vorurteil.

Ja, Vorurteile halten sich leider sehr lange - etwa "Apple-Betriebssysteme sind sicher" oder "Firefox ist ein schneller Browser" :D

Vielleicht liest du mal die WHATWG-FAQ

"People send e-mail to the mailing list. The editor then [ignores] that feedback[.]" - an diese vorgehensweise kann ich mich noch gut erinnern als es um audio/video vs. object ging. Da hat man sogar kommentarlos Beiträge im Forum gelöscht.

Natürlich gibt es Bereiche, in denen noch gearbeitet wird. Allerdings gilt, dass Änderungen abwärtskompatibel sein müssen, also kompatibel zu älteren Spec-Versionen und gleichsam kompatibel zu Browserimplementationen.

Das Problem ist dass hier ein Standard um die Möglichkeiten herum definiert wird und nicht um den Bedarf der dann in den Browser eingebaut werden muss.

Versteh mich nicht falsch - viele Dinge sind hilfreich und standardisieren das, was man als Webentwickler ständig braucht (a-Elemente sind endlich block, ordentliches Markup für Bild + Beschreibung), aber leider werden auch Dinge eingebaut die niemand wirklich braucht und Dinge standardisiert die jetzt schon total wirr und redundant zueinander sind oder man vergisst auf wichtige Dinge. z.B. sind Fußnoten ("small") keine block-Elemente, Dialoge/Interviews lassen sich nicht ordentlich auszeichnen anstelle der coolen dialog-Idee ist wieder dieser Dreck drin.

Die Spec wird nicht plötzlich das Gegenteil behaupten und den Browsern eine ganz andere Verarbeitung von link@type vorschreiben.

Das nicht - aber wie oben genannt werden plötzlich Features ohne nachvollziehbare Gründe entfernt oder durch andere ersetzt - wer garantiert, dass das im lebenden Standard nicht auch später so gemacht wird?

[molily]

suit, mittlerweile kennt man deine Abneigung und es ist hier ohnehin ein beliebter Sport, jeden HTML5-Thread in einen »im Übrigen finde ich HTML5 doof«-Thread umzubiegen, in dem dann oftmals FUD verbreitet wird. Aber vielleicht bleibst du einfach mal beim Thema, welches nämlich war, dass du moniert hast, dass ich WHATWG-Spezifikationen verlinkt habe anstatt die identische W3C-Spezifikation. In deinen jüngsten Äußerungen sehe ich keinen weiteren Beitrag zu diesem Thema. Wenn es dazu noch Argumente vorzubringen gibt, bitte, andernfalls habe ich keine Lust, über Hölzchen und Stöckchen zu diskutieren.

Mathias

[Malin]

Danke für die Antworten! Nachdem ich eure Beiträge gelesen habe, bin ich zu dem Schluss gekommen, dass nichts dagegen spricht, künftig auf type="text/css" zu verzichten.