<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Kommentare zu: Das Endoskelett einer Webseite</title>
	<atom:link href="http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/</link>
	<description>Für mehr Qualität im Web</description>
	<lastBuildDate>Fri, 20 Jan 2012 15:36:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.3</generator>
	<item>
		<title>Von: Links der Woche &#124; Wordpress-Plugin &#124; HTML5-Standard &#124; Farben im Web &#124; Yaml Builder offline &#171; eckladen24</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26773</link>
		<dc:creator>Links der Woche &#124; Wordpress-Plugin &#124; HTML5-Standard &#124; Farben im Web &#124; Yaml Builder offline &#171; eckladen24</dc:creator>
		<pubDate>Fri, 09 Oct 2009 11:34:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26773</guid>
		<description>[...] und haben zu diesem Thema gleich mehrere Beiträge in der Pipeline. Da wäre zum einen, das Endoskelett einer Webseite von Michael Jendryschik. Zum anderen stellt Olaf Gleba in seinem Artikel Sehen und Hören die [...]</description>
		<content:encoded><![CDATA[<p>[...] und haben zu diesem Thema gleich mehrere Beiträge in der Pipeline. Da wäre zum einen, das Endoskelett einer Webseite von Michael Jendryschik. Zum anderen stellt Olaf Gleba in seinem Artikel Sehen und Hören die [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Markus Schlegel</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26745</link>
		<dc:creator>Markus Schlegel</dc:creator>
		<pubDate>Thu, 01 Oct 2009 14:21:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26745</guid>
		<description>@Michael
http://www.zeldman.com/2009/09/04/html5-redefines-footer/
http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/

Das war ein Beispiel für die notwendigen Dispute, die dann letztlich auch etwas an der Spec verändern können.</description>
		<content:encoded><![CDATA[<p>@Michael<br />
<a href="http://www.zeldman.com/2009/09/04/html5-redefines-footer/" >http://www.zeldman.com/2009/09/04/html5-redefines-footer/</a><br />
<a href="http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/" >http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/</a></p>
<p>Das war ein Beispiel für die notwendigen Dispute, die dann letztlich auch etwas an der Spec verändern können.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Michael Jendryschik</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26744</link>
		<dc:creator>Michael Jendryschik</dc:creator>
		<pubDate>Thu, 01 Oct 2009 12:11:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26744</guid>
		<description>@Markus

&lt;blockquote&gt;Das &lt;code&gt;footer&lt;/code&gt;-Element halte ich beispielsweise in der derzeitigen Form für absolut unpraktisch, denn es erlaubt nicht das, was man mit einem footer, im Allgemeinen Sinn, anstellen möchte.&lt;/blockquote&gt;

Kannst du das bitte etwas weiter ausführen? Was möchtest du denn mit einem Footer »anstellen«, was dir das vorgeschlagene &lt;code&gt;footer&lt;/code&gt;-Element nicht gestattet?</description>
		<content:encoded><![CDATA[<p>@Markus</p>
<blockquote><p>Das <code>footer</code>-Element halte ich beispielsweise in der derzeitigen Form für absolut unpraktisch, denn es erlaubt nicht das, was man mit einem footer, im Allgemeinen Sinn, anstellen möchte.</p></blockquote>
<p>Kannst du das bitte etwas weiter ausführen? Was möchtest du denn mit einem Footer »anstellen«, was dir das vorgeschlagene <code>footer</code>-Element nicht gestattet?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Michael Jendryschik</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26743</link>
		<dc:creator>Michael Jendryschik</dc:creator>
		<pubDate>Thu, 01 Oct 2009 12:05:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26743</guid>
		<description>@Guther

&lt;blockquote&gt;»[Ich habe] zu zwei Beiträgen (hier und in &quot;Malen nach Zahlen&quot;), die sich mit HTML 5 und seinen neuen Elementen beschäftigen, einen Kommentar geschrieben. Dass führt nun leider dazu, dass sich die sehr anregende und interessante Diskussion, an der mir sehr viel liegt, teilweise überschneidet.«&lt;/blockquote&gt;

Um diese Diskussion nicht an zwei Stellen zu führen, beschränke ich mich hier auf die Teile deines Kommentars, die sich konkret auf meinen Artikel beziehen. Deine grundlegende Kritik an der Vorgehensweise bei der Entwicklung von Standards kommentiere ich hier nicht. Lass uns an anderer Stelle darüber diskutieren.

&lt;blockquote&gt;Im übrigen sehe ich nicht, was mit diesem Konzept möglich sein sollte, was nicht auch mit meinem Vorschlag nur ein H-Element einzuführen, dessen Wertigkeit über ein entsprechendes neues Attribut gesetzt wird, möglich wäre.&lt;/blockquote&gt;

Dein Vorschlag, &lt;code&gt;h&lt;/code&gt;-Elemente als Überschriften zu etablieren und deren Ordnung über ein Attribut festzulegen, löst nicht den zweiten Nachteil, den ich im Abschnitt »Sektionen und Überschriften« anführe. Es ist nämlich häufig nicht klar, in welchem Überschriftenkontext ein »Markup-Schnipsel« steht. HTML5 bietet eine Lösung dafür an.

An dieser Stelle räume ich aber gern ein, dass ich die im XHTML2-Entwurf vorgeschlagenen &lt;code&gt;h&lt;/code&gt;-Elemente ohne bestimmte Ordnung konsequenter finde. &lt;code&gt;h1&lt;/code&gt;-Elemente in &lt;code&gt;section&lt;/code&gt;-Elemente zu verschachteln, entspricht demselben Gedanken, aber mich stört die &lt;code&gt;1&lt;/code&gt; an dieser Stelle.</description>
		<content:encoded><![CDATA[<p>@Guther</p>
<blockquote><p>»[Ich habe] zu zwei Beiträgen (hier und in &#034;Malen nach Zahlen&#034;), die sich mit HTML 5 und seinen neuen Elementen beschäftigen, einen Kommentar geschrieben. Dass führt nun leider dazu, dass sich die sehr anregende und interessante Diskussion, an der mir sehr viel liegt, teilweise überschneidet.«</p></blockquote>
<p>Um diese Diskussion nicht an zwei Stellen zu führen, beschränke ich mich hier auf die Teile deines Kommentars, die sich konkret auf meinen Artikel beziehen. Deine grundlegende Kritik an der Vorgehensweise bei der Entwicklung von Standards kommentiere ich hier nicht. Lass uns an anderer Stelle darüber diskutieren.</p>
<blockquote><p>Im übrigen sehe ich nicht, was mit diesem Konzept möglich sein sollte, was nicht auch mit meinem Vorschlag nur ein H-Element einzuführen, dessen Wertigkeit über ein entsprechendes neues Attribut gesetzt wird, möglich wäre.</p></blockquote>
<p>Dein Vorschlag, <code>h</code>-Elemente als Überschriften zu etablieren und deren Ordnung über ein Attribut festzulegen, löst nicht den zweiten Nachteil, den ich im Abschnitt »Sektionen und Überschriften« anführe. Es ist nämlich häufig nicht klar, in welchem Überschriftenkontext ein »Markup-Schnipsel« steht. HTML5 bietet eine Lösung dafür an.</p>
<p>An dieser Stelle räume ich aber gern ein, dass ich die im XHTML2-Entwurf vorgeschlagenen <code>h</code>-Elemente ohne bestimmte Ordnung konsequenter finde. <code>h1</code>-Elemente in <code>section</code>-Elemente zu verschachteln, entspricht demselben Gedanken, aber mich stört die <code>1</code> an dieser Stelle.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Gunther</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26736</link>
		<dc:creator>Gunther</dc:creator>
		<pubDate>Wed, 30 Sep 2009 17:29:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26736</guid>
		<description>@Michael
Leider muss ich zu meiner Schande gestehen, dass ich einige Zeit hier nicht vorbeigeschaut habe, und dann heute für mich gleich einige neue Artikel vorhanden waren. Daraufhin habe ich jetzt gleich zu zwei Beiträgen (hier und in &quot;Malen nach Zahlen&quot;), die sich mit HTML 5 und seinen neuen Elementen beschäftigen, einen Kommentar geschrieben. Dass führt nun leider dazu, dass sich die sehr anregende und interessante Diskussion, an der mir sehr viel liegt, teilweise überschneidet.

Zu deiner Antwort:
&lt;blockquote&gt;... sondern vielmehr damit, dass Klagen darüber bisher nichts brachten.&lt;/blockquote&gt;
Mag sein. Woran liegt das? Und ist das nicht erst recht ein Grund, den Protest gerade zu verstärken, bzw. lauter werden zu lassen, als sich über die paar mit HTML 5 &quot;dahingeworfenen Brotkrumen&quot; zu freuen?

&lt;blockquote&gt;Nicht nachvollziehen kann ich allerdings, was du über Überschriften schreibst.&lt;/blockquote&gt;
&lt;blockquote&gt;Darin erklärt Tomas, weshalb ein stimmiges Überschriftenkonzept wichtig ist; gerade für Leute, die auf die nicht-visuelle Orientierung angewiesen sind. Daher läuft deine Kritik an dieser Stelle ins Leere.&lt;/blockquote&gt;
Keineswegs. Gerade der beschriebene Artikel und deine eigene Aussage
&lt;blockquote&gt;Aber was ist, wenn doch einmal weitere Ebenen notwendig sind, beispielsweise in sehr langen, für den Druck aufbereiteten Dokumenten? Es gibt kein Element h7, kein Element h8 und so weiter, also müssen Webautoren sich mit Hilfskonstruktionen behelfen.&lt;/blockquote&gt; bestärken mich doch eher in der Annahme, dass sich das bisherige Konzept mit H1 - H6 Elementen schon nicht bewährt hat, und somit das Festhalten an den Elementen es genauso wenig tun wird. Im Gegenteil: Das Outline-Konzept ist eine dermaßene Verkomplizierung einer semantisch eigentlich sehr einfachen Sache, dass invalider Code und/ oder Browserbugs imho schon vorprogrammiert sind. Im übrigen sehe ich nicht, was mit diesem Konzept möglich sein sollte, was nicht auch mit meinem Vorschlag nur ein H-Element einzuführen, dessen Wertigkeit über ein entsprechendes neues Attribut gesetzt wird, möglich wäre. Über die Varianten, die Überschriften nach dem neuen System per CSS zu stylen, möchte ich dann im Moment lieber auch noch nicht nachdenken!

&lt;blockquote&gt;Auch dein Fazit kann ich nicht teilen. Ich denke, dass diese Artikelreihe ganz gut zeigt, was HTML5 für Möglichkeiten bieten wird, die Webautoren in Zukunft ihre Arbeit vereinfachen wird.&lt;/blockquote&gt;Dein Wort in Gottes Ohr. Nur teile ich nach mittlerweile 15 Jahren Erfahrung deinen Optimismus nicht. Es wird in der Praxis nur wieder eine elend lange &quot;Umstiegsphase&quot; geben, in der die ganzen Neuerungen mangels entsprechender Browserunterstützung nicht, oder nur teilweise verwendet werden können. Auch lassen sie die meisten der real existierenden Anforderungen des täglichen &quot;Weballtages&quot; genauso unangetastet und ungelöst, wie ihre Vorgänger. Was sicherlich zu Teilen auch darin begründet sein mag, dass sich diese mit HTML in der jetzigen Form auch gar nicht lösen ließen.

&lt;blockquote&gt;Es ist immer einfach, etwas schlecht zu reden oder komplett abzulehnen. Aber das Ganze in Frage zu stellen, kommt mir ein wenig »kleingeistig« vor. Ich denke, jeder von uns sollte offen für Innovationen und neue Entwicklungen sein.&lt;/blockquote&gt;
Ja, netter Satz. Den unterschreibe ich auch sofort. Nur sehe ich die Kleingeistigkeit und dien mangelnde Offenheit für wirkliche Innovation und neue Entwicklungen woanders als du.

Außerdem lege ich schon wert auf die Feststellung, dass ich nicht nur einfach etwas schlecht geredet habe, sondern zu diversen Dingen auch Alternativvorschläge gemacht habe. Und in vielen Dingen sehe ich eben auch keine wirkliche Neuentwicklung, sondern eben lediglich eine &quot;Flickschusterei&quot;. Wie du meinem Kommentar als Antwort auf Jens in dem anderen Beitrag entnehmen kannst, bin ich sicherlich der Letzte, der etwas gegen wirkliche Innovation hat - ganz im Gegenteil. Das in meinen Augen sture Festhalten an einem längst untauglichen Gesamtsystem, welches den Anforderungen um Jahre hinterhinkt, und dessen Weiterentwicklung auch noch unter der Doktrin der strikten Abwärtskompatibilität betrieben wird, das erachte ich als »kleingeistig« und »innovationshemmend«.

Und nicht zuletzt hat man ja kürzlich erst seinen Fortschrittswillen mit dem zu Grabe tragen der XHTML2 Workinggroup unter Beweis gestellt.

BTW: Ich habe die Entstehung des jetzigen HTML 5 Entwurfs eine ganze Zeit lang als sog. Invited Expert auf der Mailingliste verfolgt, bis ich von der teilweisen Engstirnigkeit und Ignoranz die Nase voll hatte. Mir sind also auch durchaus die einen oder anderen Vorschläge bekannt, die im Vorfeld gemacht wurden.

Und wie bereits schon angeschnitten, kann man imho heutzutage einen HTML Standard nicht isoliert als Einzelstück betrachten, sondern muss diesen immer im Zusammenhang/ -spiel mit CSS betrachten. Und auch hier brauchen wir uns wohl nicht über Fortschritt oder Innovationen unterhalten. Dafür dass alle Standards aus demselben Hause kommen, merkt man für meinen Geschmack recht wenig &quot;Zusammenspiel&quot; zwischen den einzelnen Standards. Es wirkt auf mich immer eher als ob die linke Hand nicht wüsste, was die Rechte tut.

Mag sein, dass ich das Ganze kritischer oder argwöhnischer sehe, als viele andere. Aber mich stört mittlerweile die Art, wie die Standards entwickelt werden, so dermaßen, dass ich entschieden der Meinung bin, dass sich im Web langsam mal wieder eine entsprechende Protestbewegung formieren sollte, wie es sie ja u.a. mit WASP schon einmal gegeben hat und noch gibt (allerdings ohne den nötigen Protest). Und ich mag mich von daher auch nicht über solche &quot;Fortschritte&quot; wie aktuell mit HTML 5 freuen oder immer versuchen, jeder Neuerung immer noch etwas Positives abzugewinnen. Denn wie gesagt, für mich sitzt die &quot;Wurzel des Übels&quot; mittlerweile eindeutig woanders.

Um mich aber nicht erneut dem Vorwurf auszusetzen, ich würde einfach nur alles ablehnen und schlecht reden, hier ganz kurz, wie ich mir das z.B. vorstellen könnte:
- Einen klaren Strich unter das bisherige HTML-Konzept ziehen und ein komplett neues System, aufbauend auf den Erfahrungen der letzten 15 Jahre entwickeln. Browser mit zwei separaten Rendering-Engines ausstatten, um die Abwärtskompatibilität zu gewährleisten.
- CSS auf dem jetzigen Stand einfrieren, bzw. ggf. sogar im Layout-Bereich zurückstutzen.
- Für das Layout einen neuen eigenständigen Standard einführen, der aus einer Art Kombination von Javascript und CSS besteht.
- Alle Browserhersteller hätten dieselben Ausgangsbedingungen jeweils einen neuen Browser gemäß den neuen Standards zu entwickeln. Ferner sollten sie sich verpflichten, auf die Implementierung eigener proprietärer Features zu verzichten.

Willkommen du schöne neue Webpublishing Zukunft!

Ich weiß, die Hoffnung stirbt immer zuletzt - aber träumen wird ja noch erlaubt sein. ;-)

Gruß Gunther</description>
		<content:encoded><![CDATA[<p>@Michael<br />
Leider muss ich zu meiner Schande gestehen, dass ich einige Zeit hier nicht vorbeigeschaut habe, und dann heute für mich gleich einige neue Artikel vorhanden waren. Daraufhin habe ich jetzt gleich zu zwei Beiträgen (hier und in &#034;Malen nach Zahlen&#034;), die sich mit HTML 5 und seinen neuen Elementen beschäftigen, einen Kommentar geschrieben. Dass führt nun leider dazu, dass sich die sehr anregende und interessante Diskussion, an der mir sehr viel liegt, teilweise überschneidet.</p>
<p>Zu deiner Antwort:</p>
<blockquote><p>&#8230; sondern vielmehr damit, dass Klagen darüber bisher nichts brachten.</p></blockquote>
<p>Mag sein. Woran liegt das? Und ist das nicht erst recht ein Grund, den Protest gerade zu verstärken, bzw. lauter werden zu lassen, als sich über die paar mit HTML 5 &#034;dahingeworfenen Brotkrumen&#034; zu freuen?</p>
<blockquote><p>Nicht nachvollziehen kann ich allerdings, was du über Überschriften schreibst.</p></blockquote>
<blockquote><p>Darin erklärt Tomas, weshalb ein stimmiges Überschriftenkonzept wichtig ist; gerade für Leute, die auf die nicht-visuelle Orientierung angewiesen sind. Daher läuft deine Kritik an dieser Stelle ins Leere.</p></blockquote>
<p>Keineswegs. Gerade der beschriebene Artikel und deine eigene Aussage</p>
<blockquote><p>Aber was ist, wenn doch einmal weitere Ebenen notwendig sind, beispielsweise in sehr langen, für den Druck aufbereiteten Dokumenten? Es gibt kein Element h7, kein Element h8 und so weiter, also müssen Webautoren sich mit Hilfskonstruktionen behelfen.</p></blockquote>
<p> bestärken mich doch eher in der Annahme, dass sich das bisherige Konzept mit H1 &#8211; H6 Elementen schon nicht bewährt hat, und somit das Festhalten an den Elementen es genauso wenig tun wird. Im Gegenteil: Das Outline-Konzept ist eine dermaßene Verkomplizierung einer semantisch eigentlich sehr einfachen Sache, dass invalider Code und/ oder Browserbugs imho schon vorprogrammiert sind. Im übrigen sehe ich nicht, was mit diesem Konzept möglich sein sollte, was nicht auch mit meinem Vorschlag nur ein H-Element einzuführen, dessen Wertigkeit über ein entsprechendes neues Attribut gesetzt wird, möglich wäre. Über die Varianten, die Überschriften nach dem neuen System per CSS zu stylen, möchte ich dann im Moment lieber auch noch nicht nachdenken!</p>
<blockquote><p>Auch dein Fazit kann ich nicht teilen. Ich denke, dass diese Artikelreihe ganz gut zeigt, was HTML5 für Möglichkeiten bieten wird, die Webautoren in Zukunft ihre Arbeit vereinfachen wird.</p></blockquote>
<p>Dein Wort in Gottes Ohr. Nur teile ich nach mittlerweile 15 Jahren Erfahrung deinen Optimismus nicht. Es wird in der Praxis nur wieder eine elend lange &#034;Umstiegsphase&#034; geben, in der die ganzen Neuerungen mangels entsprechender Browserunterstützung nicht, oder nur teilweise verwendet werden können. Auch lassen sie die meisten der real existierenden Anforderungen des täglichen &#034;Weballtages&#034; genauso unangetastet und ungelöst, wie ihre Vorgänger. Was sicherlich zu Teilen auch darin begründet sein mag, dass sich diese mit HTML in der jetzigen Form auch gar nicht lösen ließen.</p>
<blockquote><p>Es ist immer einfach, etwas schlecht zu reden oder komplett abzulehnen. Aber das Ganze in Frage zu stellen, kommt mir ein wenig »kleingeistig« vor. Ich denke, jeder von uns sollte offen für Innovationen und neue Entwicklungen sein.</p></blockquote>
<p>Ja, netter Satz. Den unterschreibe ich auch sofort. Nur sehe ich die Kleingeistigkeit und dien mangelnde Offenheit für wirkliche Innovation und neue Entwicklungen woanders als du.</p>
<p>Außerdem lege ich schon wert auf die Feststellung, dass ich nicht nur einfach etwas schlecht geredet habe, sondern zu diversen Dingen auch Alternativvorschläge gemacht habe. Und in vielen Dingen sehe ich eben auch keine wirkliche Neuentwicklung, sondern eben lediglich eine &#034;Flickschusterei&#034;. Wie du meinem Kommentar als Antwort auf Jens in dem anderen Beitrag entnehmen kannst, bin ich sicherlich der Letzte, der etwas gegen wirkliche Innovation hat &#8211; ganz im Gegenteil. Das in meinen Augen sture Festhalten an einem längst untauglichen Gesamtsystem, welches den Anforderungen um Jahre hinterhinkt, und dessen Weiterentwicklung auch noch unter der Doktrin der strikten Abwärtskompatibilität betrieben wird, das erachte ich als »kleingeistig« und »innovationshemmend«.</p>
<p>Und nicht zuletzt hat man ja kürzlich erst seinen Fortschrittswillen mit dem zu Grabe tragen der XHTML2 Workinggroup unter Beweis gestellt.</p>
<p>BTW: Ich habe die Entstehung des jetzigen HTML 5 Entwurfs eine ganze Zeit lang als sog. Invited Expert auf der Mailingliste verfolgt, bis ich von der teilweisen Engstirnigkeit und Ignoranz die Nase voll hatte. Mir sind also auch durchaus die einen oder anderen Vorschläge bekannt, die im Vorfeld gemacht wurden.</p>
<p>Und wie bereits schon angeschnitten, kann man imho heutzutage einen HTML Standard nicht isoliert als Einzelstück betrachten, sondern muss diesen immer im Zusammenhang/ -spiel mit CSS betrachten. Und auch hier brauchen wir uns wohl nicht über Fortschritt oder Innovationen unterhalten. Dafür dass alle Standards aus demselben Hause kommen, merkt man für meinen Geschmack recht wenig &#034;Zusammenspiel&#034; zwischen den einzelnen Standards. Es wirkt auf mich immer eher als ob die linke Hand nicht wüsste, was die Rechte tut.</p>
<p>Mag sein, dass ich das Ganze kritischer oder argwöhnischer sehe, als viele andere. Aber mich stört mittlerweile die Art, wie die Standards entwickelt werden, so dermaßen, dass ich entschieden der Meinung bin, dass sich im Web langsam mal wieder eine entsprechende Protestbewegung formieren sollte, wie es sie ja u.a. mit WASP schon einmal gegeben hat und noch gibt (allerdings ohne den nötigen Protest). Und ich mag mich von daher auch nicht über solche &#034;Fortschritte&#034; wie aktuell mit HTML 5 freuen oder immer versuchen, jeder Neuerung immer noch etwas Positives abzugewinnen. Denn wie gesagt, für mich sitzt die &#034;Wurzel des Übels&#034; mittlerweile eindeutig woanders.</p>
<p>Um mich aber nicht erneut dem Vorwurf auszusetzen, ich würde einfach nur alles ablehnen und schlecht reden, hier ganz kurz, wie ich mir das z.B. vorstellen könnte:<br />
- Einen klaren Strich unter das bisherige HTML-Konzept ziehen und ein komplett neues System, aufbauend auf den Erfahrungen der letzten 15 Jahre entwickeln. Browser mit zwei separaten Rendering-Engines ausstatten, um die Abwärtskompatibilität zu gewährleisten.<br />
- CSS auf dem jetzigen Stand einfrieren, bzw. ggf. sogar im Layout-Bereich zurückstutzen.<br />
- Für das Layout einen neuen eigenständigen Standard einführen, der aus einer Art Kombination von Javascript und CSS besteht.<br />
- Alle Browserhersteller hätten dieselben Ausgangsbedingungen jeweils einen neuen Browser gemäß den neuen Standards zu entwickeln. Ferner sollten sie sich verpflichten, auf die Implementierung eigener proprietärer Features zu verzichten.</p>
<p>Willkommen du schöne neue Webpublishing Zukunft!</p>
<p>Ich weiß, die Hoffnung stirbt immer zuletzt &#8211; aber träumen wird ja noch erlaubt sein. <img src='http://www.webkrauts.de/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Gruß Gunther</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Markus Schlegel</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26735</link>
		<dc:creator>Markus Schlegel</dc:creator>
		<pubDate>Wed, 30 Sep 2009 17:07:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26735</guid>
		<description>Die Diskussion HTML5 vs. XHTML 2.0 (bzw. mittlerweile nur noch HTML5 vs. Nicht-HTML5) ist eine Diskussion zwischen Verfechtern zweier grundlegend verschiedener Denkweisen, ein Streit zwischen Ideologie und Pragmatik, ein Streit zwischen Fundis und Realos, aber auch ein Streit zwischen Integrität und Korrumption.

HTML5 schafft mit diesem Set an neuen Elementen Werkzeuge, die man schon seit Ewigkeiten bräuchte und auch noch eine Weile brauchen wird. Man spricht bei HTML immer noch von einem Dokument und Dokumente beherbergen eine endliche Anzahl an semantisch differenzierbaren Einheiten, darunter eben header, article, section etc.

Die andere Seite argumentiert mit Erweiterbarkeit, dem seinerzeits trendigen X (eXtensibility). Alles muss erweiterbar sein, eine typische Programmiererdenke, Skalierbarkeit ist wichtig. Das W3C hatte mit XHTML 2.0 weit in die Zukunft gezielt, man kann nicht sagen, was kommt, also hält man sich alle Optionen offen. Das X stand dabei im Mittelpunkt, denn auch wenn sich der XHTML-Standard irgendwann selbst nicht mehr weiterentwickelt, kann man die Sprache ohne Komplikationen erweitern. RDF, XForms, SVG und MathML sind die bekanntesten Beispiele und werden auch noch entwickelt.

XHTML 2.0 ist tot, wie man weiß, aber in meinen Augen steht auch HTML5 alles andere als mitten im Leben. Ja, man kann vieles heute schon einsetzen und ja, der Doctype schadet (noch) niemandem. Die wirklich wichtigen Neuerungen, z.B. lokale Datenbanken, sind aber wahrscheinlich erst dann wirklich implementiert, wenn man schon wieder etwas anderes bräuchte.

&lt;blockquote&gt;
We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future.
&lt;cite&gt;&lt;a href=&quot;http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44691&quot;&gt;Ian Hickson&lt;/a&gt;&lt;/cite&gt;
&lt;/blockquote&gt;

Das halte ich für eine gefährliche Einstellung. Wie lange dauert die Entwicklung von HTML5 nun schon? Und wie lange soll sie noch dauern? Und wann fängt die Zukunft an, bzw. hört die Gegenwart auf?

Dass man offen für Innovationen und Neuerungen sein sollte, ist klar und es wäre für mich als Siebzehnjährigen eine fatale Einstellung, das Gegenteil zu denken. Trotzdem finde ich es dreist, Kritiker als kleingeistig zu bezeichnen. Ich selbst vertrete nicht voll und ganz die Position, die ich hier zu vertreten scheine, ich will zu einer Diskussion und einer kritischen Auseinandersetzung anregen. Schaut man sich &lt;a href=&quot;http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/&quot;&gt;diesen Blogartikel&lt;/a&gt; und dessen Kommentare an, hat man eine kritische Diskussion vor sich, die es verdient, vom WHATWG beachtet zu werden. Im deutschen Sprachraum ist mir so eine Diskussion noch nie begegnet und das finde ich schade. Hier ist man immer gleich Kleingeist, Fundi, Purist und was weiß ich nicht alles.

Dabei verdient es HTML5 (im positiven Sinn), dass darüber gestritten wird, dass nicht alles einfach so hingenommen wird. Das footer-Element halte ich beispielsweise in der derzeitigen Form für absolut unpraktisch, denn es erlaubt nicht das, was man mit einem footer, im Allgemeinen Sinn, anstellen möchte. Finden die grundsätzlichen Diskussion nicht jetzt statt, hat man sie in fünf Jahren und dann ist es zu spät.</description>
		<content:encoded><![CDATA[<p>Die Diskussion HTML5 vs. XHTML 2.0 (bzw. mittlerweile nur noch HTML5 vs. Nicht-HTML5) ist eine Diskussion zwischen Verfechtern zweier grundlegend verschiedener Denkweisen, ein Streit zwischen Ideologie und Pragmatik, ein Streit zwischen Fundis und Realos, aber auch ein Streit zwischen Integrität und Korrumption.</p>
<p>HTML5 schafft mit diesem Set an neuen Elementen Werkzeuge, die man schon seit Ewigkeiten bräuchte und auch noch eine Weile brauchen wird. Man spricht bei HTML immer noch von einem Dokument und Dokumente beherbergen eine endliche Anzahl an semantisch differenzierbaren Einheiten, darunter eben header, article, section etc.</p>
<p>Die andere Seite argumentiert mit Erweiterbarkeit, dem seinerzeits trendigen X (eXtensibility). Alles muss erweiterbar sein, eine typische Programmiererdenke, Skalierbarkeit ist wichtig. Das W3C hatte mit XHTML 2.0 weit in die Zukunft gezielt, man kann nicht sagen, was kommt, also hält man sich alle Optionen offen. Das X stand dabei im Mittelpunkt, denn auch wenn sich der XHTML-Standard irgendwann selbst nicht mehr weiterentwickelt, kann man die Sprache ohne Komplikationen erweitern. RDF, XForms, SVG und MathML sind die bekanntesten Beispiele und werden auch noch entwickelt.</p>
<p>XHTML 2.0 ist tot, wie man weiß, aber in meinen Augen steht auch HTML5 alles andere als mitten im Leben. Ja, man kann vieles heute schon einsetzen und ja, der Doctype schadet (noch) niemandem. Die wirklich wichtigen Neuerungen, z.B. lokale Datenbanken, sind aber wahrscheinlich erst dann wirklich implementiert, wenn man schon wieder etwas anderes bräuchte.</p>
<blockquote><p>
We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future.<br />
<cite><a href="http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44691">Ian Hickson</a></cite>
</p></blockquote>
<p>Das halte ich für eine gefährliche Einstellung. Wie lange dauert die Entwicklung von HTML5 nun schon? Und wie lange soll sie noch dauern? Und wann fängt die Zukunft an, bzw. hört die Gegenwart auf?</p>
<p>Dass man offen für Innovationen und Neuerungen sein sollte, ist klar und es wäre für mich als Siebzehnjährigen eine fatale Einstellung, das Gegenteil zu denken. Trotzdem finde ich es dreist, Kritiker als kleingeistig zu bezeichnen. Ich selbst vertrete nicht voll und ganz die Position, die ich hier zu vertreten scheine, ich will zu einer Diskussion und einer kritischen Auseinandersetzung anregen. Schaut man sich <a href="http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/">diesen Blogartikel</a> und dessen Kommentare an, hat man eine kritische Diskussion vor sich, die es verdient, vom WHATWG beachtet zu werden. Im deutschen Sprachraum ist mir so eine Diskussion noch nie begegnet und das finde ich schade. Hier ist man immer gleich Kleingeist, Fundi, Purist und was weiß ich nicht alles.</p>
<p>Dabei verdient es HTML5 (im positiven Sinn), dass darüber gestritten wird, dass nicht alles einfach so hingenommen wird. Das footer-Element halte ich beispielsweise in der derzeitigen Form für absolut unpraktisch, denn es erlaubt nicht das, was man mit einem footer, im Allgemeinen Sinn, anstellen möchte. Finden die grundsätzlichen Diskussion nicht jetzt statt, hat man sie in fünf Jahren und dann ist es zu spät.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Michael Jendryschik</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26733</link>
		<dc:creator>Michael Jendryschik</dc:creator>
		<pubDate>Wed, 30 Sep 2009 14:25:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26733</guid>
		<description>@Gunther Danke für deinen ausführlichen Kommmentar. Ich finde es gut, dass du deine Bedenken gegen HTML5 mit uns teilst und uns so die Möglichkeit zur Diskussion gibst. Darauf gehe ich gern ein.

Wir unterscheiden uns in der Ansicht, ob der aktuelle HTML5-Entwurf sinnvolle neue Semantiken vorschlägt oder nicht.

Du bist der Ansicht, dass die neuen Elemente »keinerlei praktische Vorteile« mit sich bringen und schreibst stattdessen:

&lt;blockquote&gt;»Ich lese und höre so gut wie keine Beschwerden von Webdesignern über fehlende Elemente in HTML. Überhaupt scheint es wenig Grund zur Klage über HTML 4.01 zu geben.«&lt;/blockquote&gt;

Ich bin anderer Meinung. Dass sich niemand regelmäßig offen über die begrenzten Möglichkeiten des heutigen HTML beklagt, hat meiner Ansicht nach weniger damit zu tun, dass HTML kein Wünsche offen ließe, sondern vielmehr damit, dass Klagen darüber bisher nichts brachten. 

Dennoch hat Die Vergangenheit gezeigt, dass viele Webautoren mit den bisher vorhandenen Möglichkeiten unzufrieden waren. Anderes lässt sich beispielsweise der Hype um Mikroformate nicht erklären, die Semantiken dort hinzufügen, wo reines HTML keine bereit hält. Mikroformate sind aus meiner Sicht allerdings keine Lösung, weil sie Klassen und andere Attribute »zweckentfremden« bzw. mit Bedeutung überlasten. Aus demselben Grund funktioniert &lt;code&gt;&lt;div id=&quot;aside&quot;&gt;&lt;/code&gt; auch nicht so gut wie &lt;code&gt;&lt;aside&gt;&lt;/code&gt;.

Ich schreibe in meinem Artikel:

&lt;blockquote&gt;»Es liegt auf der Hand, dass HTML als Auszeichnungssprache, die nur auf eine Handvoll Elemente beschränkt ist, nicht für jeden denkbaren Fall das richtige Element parat hat. Hilfskonstruktionen mit semantisch bedeutungslosen div- und span-Elementen werden Webautoren in Zukunft weiter nutzen müssen, mit HTML5 allerdings weit weniger als bisher.«&lt;/blockquote&gt;

Die neuen Elemente sind sinnvoll, weil sie reale Bedürfnisse aus der täglichen Arbeit bedienen, nämlich den Aufbau einer grundlegenden Dokumentenstruktur.

Auch wenn wir anderer Meinung sind, kann ich deine Position in diesem Fall verstehen. Man kann immer darüber diskutieren, ob die Anzahl der Elemente, die eine Auszeichnungssprache zur Verfügung stellt, ausreichen oder nicht, ob es zu viele oder zu wenige sind, ob es die richtigen sind oder nicht. Nicht nachvollziehen kann ich allerdings, was du über Überschriften schreibst.

Hast du den Artikel &lt;a href=&quot;http://www.einfach-fuer-alle.de/artikel/ueberschriften-strukturen-in-html/&quot;&gt;Passende Überschrift hier einsetzen&lt;/a&gt; gelesen? Darin erklärt Tomas, weshalb ein stimmiges Überschriftenkonzept wichtig ist; gerade für Leute, die auf die nicht-visuelle Orientierung angewiesen sind. Daher läuft deine Kritik an dieser Stelle ins Leere.

Auch dein Fazit kann ich nicht teilen. Ich denke, dass diese Artikelreihe ganz gut zeit, was HTML5 für Möglichkeiten bieten wird, die Webautoren in Zukunft ihre Arbeit vereinfachen wird. Es geht uns nicht darum, etwas schön zu reden oder in Euphorie zuverfallen; schließlich empfehlen wir den Einsatz von HTML5 noch nicht.

Es ist immer einfach, etwas schlecht zu reden oder komplett abzulehnen. Aber das Ganze in Frage zu stellen, kommt mir ein wenig »kleingeistig« vor. Ich denke, jeder von uns sollte offen für Innovationen und neue Entwicklungen sein.</description>
		<content:encoded><![CDATA[<p>@Gunther Danke für deinen ausführlichen Kommmentar. Ich finde es gut, dass du deine Bedenken gegen HTML5 mit uns teilst und uns so die Möglichkeit zur Diskussion gibst. Darauf gehe ich gern ein.</p>
<p>Wir unterscheiden uns in der Ansicht, ob der aktuelle HTML5-Entwurf sinnvolle neue Semantiken vorschlägt oder nicht.</p>
<p>Du bist der Ansicht, dass die neuen Elemente »keinerlei praktische Vorteile« mit sich bringen und schreibst stattdessen:</p>
<blockquote><p>»Ich lese und höre so gut wie keine Beschwerden von Webdesignern über fehlende Elemente in HTML. Überhaupt scheint es wenig Grund zur Klage über HTML 4.01 zu geben.«</p></blockquote>
<p>Ich bin anderer Meinung. Dass sich niemand regelmäßig offen über die begrenzten Möglichkeiten des heutigen HTML beklagt, hat meiner Ansicht nach weniger damit zu tun, dass HTML kein Wünsche offen ließe, sondern vielmehr damit, dass Klagen darüber bisher nichts brachten. </p>
<p>Dennoch hat Die Vergangenheit gezeigt, dass viele Webautoren mit den bisher vorhandenen Möglichkeiten unzufrieden waren. Anderes lässt sich beispielsweise der Hype um Mikroformate nicht erklären, die Semantiken dort hinzufügen, wo reines HTML keine bereit hält. Mikroformate sind aus meiner Sicht allerdings keine Lösung, weil sie Klassen und andere Attribute »zweckentfremden« bzw. mit Bedeutung überlasten. Aus demselben Grund funktioniert <code>&lt;div id="aside"&gt;</code> auch nicht so gut wie <code>&lt;aside&gt;</code>.</p>
<p>Ich schreibe in meinem Artikel:</p>
<blockquote><p>»Es liegt auf der Hand, dass HTML als Auszeichnungssprache, die nur auf eine Handvoll Elemente beschränkt ist, nicht für jeden denkbaren Fall das richtige Element parat hat. Hilfskonstruktionen mit semantisch bedeutungslosen div- und span-Elementen werden Webautoren in Zukunft weiter nutzen müssen, mit HTML5 allerdings weit weniger als bisher.«</p></blockquote>
<p>Die neuen Elemente sind sinnvoll, weil sie reale Bedürfnisse aus der täglichen Arbeit bedienen, nämlich den Aufbau einer grundlegenden Dokumentenstruktur.</p>
<p>Auch wenn wir anderer Meinung sind, kann ich deine Position in diesem Fall verstehen. Man kann immer darüber diskutieren, ob die Anzahl der Elemente, die eine Auszeichnungssprache zur Verfügung stellt, ausreichen oder nicht, ob es zu viele oder zu wenige sind, ob es die richtigen sind oder nicht. Nicht nachvollziehen kann ich allerdings, was du über Überschriften schreibst.</p>
<p>Hast du den Artikel <a href="http://www.einfach-fuer-alle.de/artikel/ueberschriften-strukturen-in-html/">Passende Überschrift hier einsetzen</a> gelesen? Darin erklärt Tomas, weshalb ein stimmiges Überschriftenkonzept wichtig ist; gerade für Leute, die auf die nicht-visuelle Orientierung angewiesen sind. Daher läuft deine Kritik an dieser Stelle ins Leere.</p>
<p>Auch dein Fazit kann ich nicht teilen. Ich denke, dass diese Artikelreihe ganz gut zeit, was HTML5 für Möglichkeiten bieten wird, die Webautoren in Zukunft ihre Arbeit vereinfachen wird. Es geht uns nicht darum, etwas schön zu reden oder in Euphorie zuverfallen; schließlich empfehlen wir den Einsatz von HTML5 noch nicht.</p>
<p>Es ist immer einfach, etwas schlecht zu reden oder komplett abzulehnen. Aber das Ganze in Frage zu stellen, kommt mir ein wenig »kleingeistig« vor. Ich denke, jeder von uns sollte offen für Innovationen und neue Entwicklungen sein.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Gunther</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26731</link>
		<dc:creator>Gunther</dc:creator>
		<pubDate>Wed, 30 Sep 2009 11:49:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26731</guid>
		<description>Hallo!

Ich kann den Optimismus und die angepriesenen Vorteile der neuen Elemente in HTML 5 nicht ganz teilen. Ich schließe mich u.a. der Kritik von Adrian Bateman an. Bisher ging mein Verständnis von HTML eher in die Richtung, dass Elemente in erster Linie dazu da sind, ihrem jeweiligen Inhalt eine entsprechende (formale) und vorallem eindeutige Semantik zu verleihen.

Davon kann aber bei den allermeisten der neuen Elemente keine Rede sein. Denn was z.B. sollte die formale Semantik eines Header-Elementes sein, außer dass es am Beginn einer HTML Datei steht? Das ergibt sich aber bereits zwangsläufig aus dem linearen Aufbau einer solchen Datei.

Ich sehe keinerlei praktische Vorteile in den neuen Elementen - im Gegenteil! Imho &quot;verwässern&quot; sie das Konzept der Hypertext Markup Language nur und blähen diese dadurch unnötig auf.

Für eine rein der Strukturierung dienenden Aufgabe gibt und gab es bereits die beiden inhaltsleeren Elemente SPAN und DIV. Diese sind imho völlig ausreichend. Und anstatt neuer eigener Elemente, hätte ich hier die Einführung eines neuen Attributes für wesentlich sinnvoller und stimmiger erachtet.

Auch das unsägliche Problem der Hx Überschriften Thematik hätte man auf diese Art und Weise per Attribut einfach und elegant lösen können. Denn entweder ist Text eine Überschrift oder nicht. Die häufig geforderte Frage nach der Ordnung hätte man also ganz einfach per Attribut mit einem entsprechenden Zahlenwert zwischen 1 und ~ regeln können, und hätte somit auch das Problem der Begrenztheit gelöst. Denn mal rein praktisch betrachtet, spielt das jeweilige Element doch eigentlich eh nur eine untergeordnete Rolle, da kein Mensch in den Quelltext guckt, um zu sehen, um welche Überschrift welcher Ordnung es sich handelt. Vielmehr spielt doch nur die Darstellung(sgröße) eine Rolle (zumindest bei visuellen Ausgabemedien) und die wird ohnehin per CSS geregelt.

Nachteilig kommt bei diesem Thema noch dazu, dass es gegen die sich seit Jahren eingebürgerte vorherrschende Meinung läuft, dass jedes HTML Dokument bspw. nur eine H1 Überschrift haben sollte, die dem Seitentitel entspricht.

Ich bin auch imnmer wieder erstaunt darüber, dass man scheinbar aus der ganzen Problematik der Browserinkompatibilitäten aus den letzten Jahren nichts gelernt hat. Denn gerade auch unter diesem für die Praxis so wichtigen Aspekt, wären neue Attribute für bestimmte bestehende Elemente weitaus &quot;allgemeinverträglicher&quot;, als neue Elemente!

Ich finde es zunehmend erschreckend und gleichzeitig auch frustrierend, dass zumindest meinem Eindruck nach, die zuständigen Experten jeglichen Bezug zu den Anforderungen der täglichen Praxis des Webdesigns verloren zu scheinen haben. Anders kann ich mir die aktuellen Entwicklungen im Bereich HTML und CSS nicht mehr erklären.

Mal ehrlich: Ich lese und höre so gut wie keine Beschwerden von Webdesignern über fehlende Elemente in HTML. Überhaupt scheint es wenig Grund zur Klage über HTML 4.01 zu geben. Womit sich für mich schon mal die Frage der grundsätzlichen Notwendigkeit von HTML 5 stellt! Und wenn ich mir die Neuerungen dann so angucke, sehe ich bis auf neuerliche Probleme aufgrund unterschiedlicher Browserunterstützung wenig hilfreiches für die Praxis.

Nur kann und sollte man HTML ja auch nicht nur einzeln betrachten, gehört doch CSS untrennbar dazu. Aber auch hier kann ich wenig bis gar keine sinnvollen Neuerungen im aktuellen Entwurf von CSS 3 im Zusammenhang mit HTML 5 erkennen.

Mein Fazit:
HTML 5 ist absolut überflüssig, da es in der Praxis keinerlei wirklichen Vorteile/ Vorzüge bietet, nichts ermöglicht, was nicht vorher auch schon mit HTML 4.01 möglich gewesen wäre, sondern im Gegenteil nur wieder Probleme bezüglich der Browserimplementierungen mit sich bringt!

Und ich finde auch, dass es höchste Zeit ist, den Experten beim W3C &amp; Co. mal deutlich zu sagen, dass ihre Entwicklungen an den Anforderungen der Praxis vorbei zielen, anstatt jede noch so unsinnige Neuerung &quot;schön zu reden&quot; oder &quot;euphorisch&quot; zu feiern, als sei sie das Größte seit Erfindung des Rades!

Gruß Gunther</description>
		<content:encoded><![CDATA[<p>Hallo!</p>
<p>Ich kann den Optimismus und die angepriesenen Vorteile der neuen Elemente in HTML 5 nicht ganz teilen. Ich schließe mich u.a. der Kritik von Adrian Bateman an. Bisher ging mein Verständnis von HTML eher in die Richtung, dass Elemente in erster Linie dazu da sind, ihrem jeweiligen Inhalt eine entsprechende (formale) und vorallem eindeutige Semantik zu verleihen.</p>
<p>Davon kann aber bei den allermeisten der neuen Elemente keine Rede sein. Denn was z.B. sollte die formale Semantik eines Header-Elementes sein, außer dass es am Beginn einer HTML Datei steht? Das ergibt sich aber bereits zwangsläufig aus dem linearen Aufbau einer solchen Datei.</p>
<p>Ich sehe keinerlei praktische Vorteile in den neuen Elementen &#8211; im Gegenteil! Imho &#034;verwässern&#034; sie das Konzept der Hypertext Markup Language nur und blähen diese dadurch unnötig auf.</p>
<p>Für eine rein der Strukturierung dienenden Aufgabe gibt und gab es bereits die beiden inhaltsleeren Elemente SPAN und DIV. Diese sind imho völlig ausreichend. Und anstatt neuer eigener Elemente, hätte ich hier die Einführung eines neuen Attributes für wesentlich sinnvoller und stimmiger erachtet.</p>
<p>Auch das unsägliche Problem der Hx Überschriften Thematik hätte man auf diese Art und Weise per Attribut einfach und elegant lösen können. Denn entweder ist Text eine Überschrift oder nicht. Die häufig geforderte Frage nach der Ordnung hätte man also ganz einfach per Attribut mit einem entsprechenden Zahlenwert zwischen 1 und ~ regeln können, und hätte somit auch das Problem der Begrenztheit gelöst. Denn mal rein praktisch betrachtet, spielt das jeweilige Element doch eigentlich eh nur eine untergeordnete Rolle, da kein Mensch in den Quelltext guckt, um zu sehen, um welche Überschrift welcher Ordnung es sich handelt. Vielmehr spielt doch nur die Darstellung(sgröße) eine Rolle (zumindest bei visuellen Ausgabemedien) und die wird ohnehin per CSS geregelt.</p>
<p>Nachteilig kommt bei diesem Thema noch dazu, dass es gegen die sich seit Jahren eingebürgerte vorherrschende Meinung läuft, dass jedes HTML Dokument bspw. nur eine H1 Überschrift haben sollte, die dem Seitentitel entspricht.</p>
<p>Ich bin auch imnmer wieder erstaunt darüber, dass man scheinbar aus der ganzen Problematik der Browserinkompatibilitäten aus den letzten Jahren nichts gelernt hat. Denn gerade auch unter diesem für die Praxis so wichtigen Aspekt, wären neue Attribute für bestimmte bestehende Elemente weitaus &#034;allgemeinverträglicher&#034;, als neue Elemente!</p>
<p>Ich finde es zunehmend erschreckend und gleichzeitig auch frustrierend, dass zumindest meinem Eindruck nach, die zuständigen Experten jeglichen Bezug zu den Anforderungen der täglichen Praxis des Webdesigns verloren zu scheinen haben. Anders kann ich mir die aktuellen Entwicklungen im Bereich HTML und CSS nicht mehr erklären.</p>
<p>Mal ehrlich: Ich lese und höre so gut wie keine Beschwerden von Webdesignern über fehlende Elemente in HTML. Überhaupt scheint es wenig Grund zur Klage über HTML 4.01 zu geben. Womit sich für mich schon mal die Frage der grundsätzlichen Notwendigkeit von HTML 5 stellt! Und wenn ich mir die Neuerungen dann so angucke, sehe ich bis auf neuerliche Probleme aufgrund unterschiedlicher Browserunterstützung wenig hilfreiches für die Praxis.</p>
<p>Nur kann und sollte man HTML ja auch nicht nur einzeln betrachten, gehört doch CSS untrennbar dazu. Aber auch hier kann ich wenig bis gar keine sinnvollen Neuerungen im aktuellen Entwurf von CSS 3 im Zusammenhang mit HTML 5 erkennen.</p>
<p>Mein Fazit:<br />
HTML 5 ist absolut überflüssig, da es in der Praxis keinerlei wirklichen Vorteile/ Vorzüge bietet, nichts ermöglicht, was nicht vorher auch schon mit HTML 4.01 möglich gewesen wäre, sondern im Gegenteil nur wieder Probleme bezüglich der Browserimplementierungen mit sich bringt!</p>
<p>Und ich finde auch, dass es höchste Zeit ist, den Experten beim W3C &amp; Co. mal deutlich zu sagen, dass ihre Entwicklungen an den Anforderungen der Praxis vorbei zielen, anstatt jede noch so unsinnige Neuerung &#034;schön zu reden&#034; oder &#034;euphorisch&#034; zu feiern, als sei sie das Größte seit Erfindung des Rades!</p>
<p>Gruß Gunther</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Fabian</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26729</link>
		<dc:creator>Fabian</dc:creator>
		<pubDate>Wed, 30 Sep 2009 10:47:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26729</guid>
		<description>&lt;em&gt;Dankeschön!&lt;/em&gt; Ein sehr gelungener Beitrag zu HTML5. Gerade die Erklärung mit den Überschriften fand ich sehr verständlich. 
Das leidige Browser-Problem ist letztlich ja nichts neues. Aber immerhin gibt es Lösungsansätze, die zumindest im privaten Gebrauch machbar sind.</description>
		<content:encoded><![CDATA[<p><em>Dankeschön!</em> Ein sehr gelungener Beitrag zu HTML5. Gerade die Erklärung mit den Überschriften fand ich sehr verständlich.<br />
Das leidige Browser-Problem ist letztlich ja nichts neues. Aber immerhin gibt es Lösungsansätze, die zumindest im privaten Gebrauch machbar sind.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Der Chrome-Frame und das Browser-Dilemma &#124; + mzungu's weblog +</title>
		<link>http://www.webkrauts.de/2009/09/24/das-endoskelett-einer-webseite/comment-page-1/#comment-26725</link>
		<dc:creator>Der Chrome-Frame und das Browser-Dilemma &#124; + mzungu's weblog +</dc:creator>
		<pubDate>Tue, 29 Sep 2009 22:49:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.webkrauts.de/?p=591#comment-26725</guid>
		<description>[...] sich f&#252;r die neuen Standards  interessiert sollte sich den klasse Artikel  von Michael Jendryschik ansehen. Au&#223;erdem gibt es im Google Code Weblog ein Artikel mit Youtube Video dazu. Wer [...]</description>
		<content:encoded><![CDATA[<p>[...] sich f&#252;r die neuen Standards  interessiert sollte sich den klasse Artikel  von Michael Jendryschik ansehen. Au&#223;erdem gibt es im Google Code Weblog ein Artikel mit Youtube Video dazu. Wer [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

