nicht angemeldet
HTML5 Meinung
0 
Matthias Apsel
0 0 1 0 Matthias Apsel
0 0 0 0 0 0 Matthias Apsel
0 
Gunnar Bittersmann
0
HTML5 Meinung
Hallo zusammen,
mal ganz ehrlich, wie steht ihr zu HTML5? Ich finde es gut, dass der ganze semantische Kram jetzt seine eigenen Tags bekommt, aber aus gestalterischen und beschreibenden Punkten ist doch für Hund und Katz Tor und Tür geöffnet worden. Fehler in der Verwendung sind vorprogrammiert. Warum gibt es überhaupt noch H1 bis H6 und warum braucht man ein main, article und section, die sich dann auch noch in der Art der Verwendung unterscheiden, wobei allein section hier semantische Bedeutung hat, weil es explizit nicht zum layouten gedacht ist? Den mehrfachen Gebrauch von header und footer lasse ich einfach mal aus, das ist im entsprechenden Kontext sinnvoll.
Und von i, b, em und strong ... ja jetzt drehe ich vollends durch. Warum hat man sich nur entschlossen, diese Elemente noch zu übernehmen? Einem Taubstummen ist das doch völlig egal. Sorry, ich musste das mal loswerden.
-
Om nah hoo pez nyeetz, micha2013!
mal ganz ehrlich, wie steht ihr zu HTML5? Ich finde es gut, dass der ganze semantische Kram jetzt seine eigenen Tags bekommt,
HTML ist eine Beschreibungssprache, braucht also Semantik. "Semantischer Kram" ist schlecht formuliert. h1 hat die semantische Bedeutung einer Überschrift. Zudem verwechsle nicht Element und Tag.
aber aus gestalterischen und beschreibenden Punkten ist doch für Hund und Katz Tor und Tür geöffnet worden. Fehler in der Verwendung sind vorprogrammiert.
"Vorprogrammiert" ist ein Pleonasmus. Semantische Fehler, wenn sie denn nicht gravierend sind (etwa small statt h1) stören die Ausgabe mit Sicherheit nicht. Eine gute Übersicht liefert mdn. Wenn man sich daran orientiert und im Zweifelsfall sich für eine Möglichkeit entscheidet und dies dann konsequent durchzieht, macht man bestimmt nichts falsch.
Warum gibt es überhaupt noch H1 bis H6
h6 hab ich noch nie gebraucht.
und warum braucht man ein main, article und section, die sich dann auch noch in der Art der Verwendung unterscheiden, wobei allein section hier semantische Bedeutung hat, weil es explizit nicht zum layouten gedacht ist?
Warum sollten main und article keine semantische Bedeutung haben? Die imho einzigen Elemente ohne Semantik sind b, i, u, s. Span und Div haben die semantische Bedeutung keine besondere semantische Bedeutung zu haben.
Und von i, b, em und strong ... ja jetzt drehe ich vollends durch. Warum hat man sich nur entschlossen, diese Elemente noch zu übernehmen?
Auch wenn i genauso dargestellt wird wie em, b wie strong und s wie del, haben die jeweils Zweitgenannten auch vor HTML5 eine semantische Bedeutung. i und b hat man imho in HTML5 eine fragwürdige gegeben.
Was zum Lesen: http://blog.selfhtml.org/2013/02/02/html5-serie-der-weg-zu-html5/
Matthias
--
1/z ist kein Blatt Papier.
-
Hallo,
ich merke einfach mal an: Apps erfreuen sich größter Beliebtheit und scheren sich einen Dreck um Semantik. Die versuchen in erster Linie dem Nutzer einen Vorteil zu bringen und nicht maschinenanalysierbar und -lesbar zu sein. Da kann man sich schon mal fragen, ob HTML5 in erster Linie dazu da sein sollte um Google-Bots glücklich zu machen.
Und wie man sieht haben sie (die Apps) trotzdem einen Weg gefunden, sich zu verbreiten.
Viele Grüße
Siri-
Die versuchen in erster Linie dem Nutzer einen Vorteil zu bringen und nicht maschinenanalysierbar und -lesbar zu sein.
Du weisst aber, dass es Nutzer gibt, die auf eine "Lesemaschine" angewiesen sin?
Du schliesst aber beides gegeneinader aus, was in meinen Augen völlig falsch ist.-
Die versuchen in erster Linie dem Nutzer einen Vorteil zu bringen und nicht maschinenanalysierbar und -lesbar zu sein.
Du weisst aber, dass es Nutzer gibt, die auf eine "Lesemaschine" angewiesen sin?
Du schliesst aber beides gegeneinader aus, was in meinen Augen völlig falsch ist.Ich schließe nicht beides gegeneinander aus, ich kritisiere die aus meiner Sicht einseitige Stoßrichtung von HTML5 in Richtung Semantik. Das gehen mir die Ansprüche und Wünsche der Webentwickler und Anwender zu sehr unter. Die scheinen nicht im Fokus gestanden zu sein.
Alles was jetzt als toll gerühmt wird ("Wow, es kann drag and drop!" "Mehrere Files auf einmal uploaden!") ist schon seit Jahren überfällig und noch immer nicht genug (Anmerkung: zu HTML5 gehören für mich auch die neuen JS-Features und CSS). Der Hype ist ein Hypchen...
Warum kein Element <tree> onder <menu>? Ungeordente Listen haben sich etabliert, aber ein Menu oder ein Tree sind keinesfalls ungeordente Listen.
Und zu beiden Elementen die zugehörigen CSS-Features, die vernünftige WebApps auch ohne JS-Frickelei ermöglichen?Dazu das Chaos mit den Browser, man kann ja nichts mehr machen ohne auf caniuse nachzuschauen. Schrecklich!
Und btw: "in erster Linie dem Nutzer einen Vorteil" schließt alle User ein. Allerdings müssen sich da die App-Entwickler Gedanken machen.
Viele Grüße
Siri-
Om nah hoo pez nyeetz, Siri!
Warum kein Element <tree> onder <menu>? Ungeordente Listen haben sich etabliert, aber ein Menu oder ein Tree sind keinesfalls ungeordente Listen.
menu gibt es.
Elemente sollte man ohne Tag-Begrenzer schreiben, wenn man denn die Elemente meint.
Matthias
--
1/z ist kein Blatt Papier.
-
Hallo,
guter Hinweis, ist mir bisher entgangen. Aber die Einsatzmöglichkeit scheint doch wieder sehr begrenzt. Ist das jetzt im entwurfsmodus oder schon offiziell verabschiedet?
Viele Grüße
Siri-
Moin Siri,
guter Hinweis, ist mir bisher entgangen. Aber die Einsatzmöglichkeit scheint doch wieder sehr begrenzt.
Alle Browser können mit ihnen unbekannten Elementen umgehen. Bei den älteren Modellen muss man ggfls. etwas nachhelfen mit JavaScript (Stichwort html5shim, was die IE-Leute sich damals dabei gedacht haben ist mir wirklich schleierhaft), aber das funktioniert schon ganz gut.
LG,
CK-
Hallo
guter Hinweis, ist mir bisher entgangen. Aber die Einsatzmöglichkeit scheint doch wieder sehr begrenzt.
Alle Browser können mit ihnen unbekannten Elementen umgehen. Bei den älteren Modellen muss man ggfls. etwas nachhelfen mit JavaScript (Stichwort html5shim, was die IE-Leute sich damals dabei gedacht haben ist mir wirklich schleierhaft), aber das funktioniert schon ganz gut.
Das menu-Element ist ein uraltes Element, das auch ohne JavaScript im IE6 richtig geparst wird.
CanIuse bezieht sich lediglich auf die neue Funktionalität, die dem vormals missbilligten Element durch HTML5 zugedacht wird.Gruß
-
Hallo,
Alle Browser können mit ihnen unbekannten Elementen umgehen. Bei den älteren Modellen muss man ggfls. etwas nachhelfen mit JavaScript (Stichwort html5shim, was die IE-Leute sich damals dabei gedacht haben ist mir wirklich schleierhaft), aber das funktioniert schon ganz gut.
Der Support ist aber derzeit bei 0%, auch bei modernen Browsern. Und ich bin ja von dem HTML5-Chaos und der Langsamkeit der Verabschiedung auch deshalb so genervt, weil man dann wieder eine Lösung drumrum bauen muss (z.B. mit JS).
Viele Grüße
Siri-
Moin Siri,
Der Support ist aber derzeit bei 0%, auch bei modernen Browsern.
Und ich bin ja von dem HTML5-Chaos und der Langsamkeit der Verabschiedung auch deshalb so genervt, weil man dann wieder eine Lösung drumrum bauen muss (z.B. mit JS).
Ich setze viele HTML5-Features bereits erfolgreich ein. Polyfills gibts fertige bereits genug. Weniger verkrampft sein, dann geht das schon.
LG,
CK
-
-
-
-
Moin Matthias,
Elemente sollte man ohne Tag-Begrenzer schreiben, wenn man denn die Elemente meint.
na ob die beim W3C das auch wissen? Immerhin lese ich auch mal sowas wie
The <main> element is a semantic element not unlike other new semantic elements
such as <header>, <footer>, <aside>, <article>, <nav>, or <section>.Ja ok, ich gebe dir da schon recht.
Ok, zurück zum Thema ... main.
The main content area of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form).
Also main == content - trash. Und jetzt bitte ich um die Erklärung der semantischen Bedeutung. Mein "main" enthält auch trash, nur weiter unten.
-
Hallo,
ich find ja das man <main> in einem Satz leichter lesen kann als main Element und @href besser erkennt als href Attribut. Das hebt sich dann doch besser ab.
Viele Grüße
Siri
-
-
-
Warum kein Element <tree> onder <menu>? Ungeordente Listen haben sich etabliert, aber ein Menu oder ein Tree sind keinesfalls ungeordente Listen.
Und zu beiden Elementen die zugehörigen CSS-Features, die vernünftige WebApps auch ohne JS-Frickelei ermöglichen?Was sollte ein tree-Element denn deiner Meinung können?
Ich habe vor kurzer Zeit mal fiddle erstellt, wie man mit HTML+CSS und ohne Javascript Baumansichten realisieren kann. Das CSS ließe sich garantiert auch noch vereinfachen und das Markup versieht man im besten Fall noch mit WAI-ARIA-Roles, aber dann hat man ein ganz passables Widget.
Menu gibt es wie gesagt auch schon.
Dazu das Chaos mit den Browser, man kann ja nichts mehr machen ohne auf caniuse nachzuschauen. Schrecklich!
Ich fahre gerade mit prefix-free und webshims auf einer Schiene, dir mir so manche caniuse-lookups erspart. Dabei setze ich natürlich JS voraus.
-
Was sollte ein tree-Element denn deiner Meinung können?
Ich habe vor kurzer Zeit mal fiddle erstellt, wie man mit HTML+CSS und ohne Javascript Baumansichten realisieren kann. Das CSS ließe sich garantiert auch noch vereinfachen und das Markup versieht man im besten Fall noch mit WAI-ARIA-Roles, aber dann hat man ein ganz passables Widget.
Weil ein Tree oder ein Menu eben keine ungeordneten Listen sind sondern sehr wohl geordnet sind. Und wenn mann die Semantik konsequent durchzieht, dann bitteschön auch diese Elemente. Deshalb begrüße ich die Wiederbelebung von menu (wobei man dank der "veralteten" Doku in selfhtml sehr schön sehen kann, dass die Ursprungsversion nie von Browsern <http://de.selfhtml.org/html/text/listen.htm#verzeichnis_menue@title=so umgesetzt> wurde wie gedacht) ausdrücklich, befürchte aber, dass es denselben Tod wie das "alte" menu sterben wird und/oder dass eine ziemliche Verwirrung im Zusammenhang mit nav entsteht.
Und man kann dann auch dass entsprechende CSS dazu bereitstellen:
behaviour: popup;
behaviour: menubar;etc.
Viele Grüße
Siri-
Weil ein Tree oder ein Menu eben keine ungeordneten Listen sind sondern sehr wohl geordnet sind. Und wenn mann die Semantik konsequent durchzieht, dann bitteschön auch diese Elemente.
Da kann ich dir nicht ganz folgen. Eine geordnete Liste zeichnet nach meinem Verständnis eine Sequenz aus. Angenommen ich möchte eine Ordner-Struktur durch eine Baumansicht darstellen lassen, inwiefern würde die Reihenfolge der Ordner (und ich spreche nicht von der Verschachtelungstiefe) die Semantik der Liste beeinflussen?
Deshalb begrüße ich die Wiederbelebung von menu [...] ausdrücklich
Der Bezug ist mir nicht an dieser Stelle nicht ganz klar.
befürchte aber, dass es denselben Tod wie das "alte" menu sterben wird und/oder dass eine ziemliche Verwirrung im Zusammenhang mit nav entsteht.
Bleibt abzuwarten, ich teile die Befürchtung nicht.
Und man kann dann auch dass entsprechende CSS dazu bereitstellen:
behaviour: popup;
behaviour: menubar;Ist behaviour eine standartisierte CSS-Eigenschaft? Ich konnte in der Spezifkation nichts dazu finden.
-
Hallo,
Da kann ich dir nicht ganz folgen. Eine geordnete Liste zeichnet nach meinem Verständnis eine Sequenz aus. Angenommen ich möchte eine Ordner-Struktur durch eine Baumansicht darstellen lassen, inwiefern würde die Reihenfolge der Ordner (und ich spreche nicht von der Verschachtelungstiefe) die Semantik der Liste beeinflussen?
Ein Menu bildet die Struktur des Inhaltes ab, allein deshalb sollte sie sich von einer "Stichpunktliste" unterscheiden. Es ist nicht nur eine Auflistung von Stichpunkten im Content.
Man sollte hierbei nicht darauf schauen, was man mit einer Liste abbilden kann (weil sie zufällig verschachtelt wird) sondern was inhaltlich dahinter steckt.behaviour: popup;
behaviour: menubar;Ist behaviour eine standartisierte CSS-Eigenschaft? Ich konnte in der Spezifkation nichts dazu finden.
Nein, das wären meine Vorschläge zur Erweiterung des CSS hinsichtlich <menu> ;-)
Viele Grüße
Siri-
Da kann ich dir nicht ganz folgen. Eine geordnete Liste zeichnet nach meinem Verständnis eine Sequenz aus. Angenommen ich möchte eine Ordner-Struktur durch eine Baumansicht darstellen lassen, inwiefern würde die Reihenfolge der Ordner (und ich spreche nicht von der Verschachtelungstiefe) die Semantik der Liste beeinflussen?
Ein Menu bildet die Struktur des Inhaltes ab, allein deshalb sollte sie sich von einer "Stichpunktliste" unterscheiden.
"The menu element represents a list of commands."[1]
Man sollte hierbei nicht darauf schauen, was man mit einer Liste abbilden kann (weil sie zufällig verschachtelt wird) sondern was inhaltlich dahinter steckt.
Da bin ich genau deiner Meinung. Und (um bei meinem Beispiel zu bleiben) eine Ordnerstruktur besteht aus _ungeordneten_, verschachtelten Listen. Eine Datei innerhalb eines Ordners ändert ihre Bedeutung nicht, weil sie vor bzw. nach einer anderen Datei gelistet ist. Besser ausgedrückt: Es gibt keine Abhängigkeiten bezüglich der Reihenfolge, in der Dateien in einem Ordner liegen.
So Schluss jetzt mit der Korinthenkackerei ;)
[1] http://www.w3.org/TR/html51/interactive-elements.html#the-menu-element
-
Da kann ich dir nicht ganz folgen. Eine geordnete Liste zeichnet nach meinem Verständnis eine Sequenz aus. Angenommen ich möchte eine Ordner-Struktur durch eine Baumansicht darstellen lassen, inwiefern würde die Reihenfolge der Ordner (und ich spreche nicht von der Verschachtelungstiefe) die Semantik der Liste beeinflussen?
Ein Menu bildet die Struktur des Inhaltes ab, allein deshalb sollte sie sich von einer "Stichpunktliste" unterscheiden.
"The menu element represents a list of commands."[1]
Das wär ja nun nicht neu, dass an der definierenden Stelle nicht verstanden wird, was an der ausführenden und praktische Seite erforderlich ist ;-)
-
-
Om nah hoo pez nyeetz, Siri!
Ein Menu bildet die Struktur des Inhaltes ab,
verwechsle nicht menu und nav.
Matthias
--
1/z ist kein Blatt Papier.
-
Hallo,
Ein Menu bildet die Struktur des Inhaltes ab,
verwechsle nicht menu und nav.
Aber mit Sicherheit nicht:
"Mit Implementierung des <nav> Elements in die HTML5 Spezifikation wurde eine Möglichkeit geschaffen, eine oder mehrere Navigationsleisten oder auch einen Bereich für zusätzliche Informationen semantisch korrekt auszuzeichnen. Der Inhalt des Navigationsbereichs enthält beispielsweise Hyperlinks auf andere Seiten beziehungsweise Verweise auf Inhalte innerhalb der Seite." http://html5-webdesign.de/nav.html
"One of the new elements for HTML 5 is the <nav> element which allows you to group together links, resulting in more semantic markup and extra structure which may help screenreaders" http://html5doctor.com/nav-element/
"The <nav> element represents a section with navigation links.
Navigation links:
links to other pages [Example A]
links to parts within the page"
http://www.w3.org/wiki/HTML/Elements/navDas kann also eine nahezu beliebige Sammlung von Links sein, das bildet aber noch nicht die Struktur der Seite ab (wenn's auch in der Praxis eher so sein wird). Außerdem (Mißverständnis vorbehalten) dient es doch eher zur Strukturierung einer Seite, damit dämliche Maschinen erkennen, ob sie es mit Content oder Verlinkungen zu tun haben. "main" möchte ich da gar nicht erst erwähnen.
Viele Grüße
Siri-
Das kann also eine nahezu beliebige Sammlung von Links sein, das bildet aber noch nicht die Struktur der Seite ab
Und ein Menü sollte das unter keinen Umständen tun. Die klassische Toolbar mit den Einträgen "Datei","Hilfe" und co. wäre ein sinngemäßer Einsatz des Menü-Elements.
Aber vielleicht reden wir auch aneinander vorbei?! Wenn du von "Struktur einer Seite" sprichst, sprichst du dann vom Outlining einer Seite? Und wenn du von der Abbildung einer Struktur sprichst, dann von einem klassischen Inhaltsverzeichnis? Das würde ich auf jedenfall mit dem nav-Element auszeichnen.
Außerdem (Mißverständnis vorbehalten) dient es doch eher zur Strukturierung einer Seite, damit dämliche Maschinen erkennen, ob sie es mit Content oder Verlinkungen zu tun haben.
Ich finde es auch als Webentwickler angenehm gleich zu sehen "Ah da, da zwischen nav-Tags, da ist die Navigation". Und auch Benutzer von Screenreadern werden sich über eine semantisch ausgezeichnete Seite freuen.
-
-
-
-
@@1UnitedPower:
nuqneH
Ist behaviour eine standartisierte CSS-Eigenschaft?
Nö. Sieht man doch schon on der Schreibweise mit ‘ou’.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Ist behaviour eine standartisierte CSS-Eigenschaft?
Nö. Sieht man doch schon on der Schreibweise mit ‘ou’.
Ja, die Briten haben hier wohl eher weniger zu melden oder dazu beizutragen ;-)
-
-
-
-
-
-
-
-
mal ganz ehrlich, wie steht ihr zu HTML5?
HTML5 umfasst ja deutlich mehr als die neuen semantischen Elemente. Obwohl diese natürlich einen wesentlichen Teil ausmachen. Ich finde den Schritt sich auf Semantik zurück zu besinnen sehr begrüßenswert; ich würde sogar soweit gehen, dass damit einige Design-Fehler von früheren HTML-Versionen ausgeräumt wurden, ich erwähne nur mal eben das font-Element oder marquee.
Aber HTML5 spielt sich nicht nur hinter der Bühne ab. Native Video-Unterstützung ist zum Beispiel ein weiterer großer Schritt in Richtung offene Standards, an dem man nur schwer etwas auszusetzen findet. Als großer Indie-Spielefan konnte ich auch das Canvas-Element nur bejubeln.
-
@@1UnitedPower:
nuqneH
ich würde sogar soweit gehen, dass damit einige Design-Fehler von früheren HTML-Versionen ausgeräumt wurden, ich erwähne nur mal eben das font-Element oder marquee.
Das wurde bereits in HTML 4 Strict getan.
Andere Design-Fehler von früheren HTML-Versionen wurden nicht ausgeräumt (fehlendes di-Element; Alternativtext für Bilder als Attributwert anstatt als Elementinhalt; …).
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Andere Design-Fehler von früheren HTML-Versionen wurden nicht ausgeräumt (fehlendes di-Element; Alternativtext für Bilder als Attributwert anstatt als Elementinhalt; …).
Na,
imgplötzlich als Element mit Inhalt umzudefinieren wäre nicht praktikabel.Und das
object-Element gibt es weiterhin in HTML5.Und nicht zuletzt soll es ein picture-Element geben.
Mathias
-
@@molily:
nuqneH
Na,
imgplötzlich als Element mit Inhalt umzudefinieren wäre nicht praktikabel.Stimmt. Die Diskussion hatten wir letztens.
Und das
object-Element gibt es weiterhin in HTML5.Und nicht zuletzt soll es ein picture-Element geben.
WHAT? Will Hixie Add This?
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
@@Gunnar Bittersmann:
nuqneH
Andere Design-Fehler von früheren HTML-Versionen wurden nicht ausgeräumt (fehlendes di-Element; Alternativtext für Bilder als Attributwert anstatt als Elementinhalt; …).
Na,
imgplötzlich als Element mit Inhalt umzudefinieren wäre nicht praktikabel.Stimmt. Die Diskussion hatten wir letztens.
„Design-Fehler wurden nicht ausgeräumt“ war auch ganz neutral gemeint, nicht als „hätten ausgeräumt werden sollen“.
Im Fall von di hätte es tatsächlich getan werden sollen. Und es war auch zwischendurch mal angedacht. Keine Ahnung, welcher Teufel Hixie da wieder geritten hat, di wieder aus der Spec rauszunehmen.
Im Fall von img ist es wegen Abwärtskompatibilität (ein zweifelhaftes Ziel von HTML5) nicht möglich. Dennoch bleibt es ein grundlegender Designfehler in HTML.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer) -
Und nicht zuletzt soll es ein picture-Element geben.
WHAT? Will Hixie Add This?
Hixie hat nichts zu sagen hinsichtlich der W3C-Spezifikation. Die W3C HTML WG hat zunächst entschieden, picture und srcset in die HTML-5.x-Spezifikation aufzunehmen, strebt seit kurzem aber erst einmal eine separate Veröffentlichung als »extension specs« an. Erste Working Drafts sind schon erschienen.
(Ich hoffe, ich bin da auf dem aktuellen Stand. Siehe auch twitter.com/respimg.)
Mathias
-
-
-
-