nicht angemeldet Eddie
Gunnar Bittersmann
Gunnar Bittersmann
at
Gunnar Bittersmann
at
Eddie
Der Martin
Gunnar Bittersmann
Eddie
Hallo allerseits,
irgendwie hat sich vor einigen Jahren schon bei mir die Philosophie festgesetzt, dass jedes einzelne HTML-Element seinen Zweck hat und nicht zweckentfremdet eingesetzt werden sollte. Bin mir nicht sicher, ob ich das jemals richtig verstanden habe, und hinterfrage darum heute meinen Code von vor 2 Jahren, den ich gerade überarbeiten muss.
Da tauchen dann zum Beispiel solche Sachen auf, die mir eigentlich hoechst redundant erscheinen, aber auf obiger falsch/richtig (?) verstandener Philosophie basieren:
<td style="vertical-align:middle;padding:3px 0;">
<span style="font-size:0.75em;color:#000;">
Wenn Sie fliegen wollen,
</span>
<label for"...">
<span style="font-weight:bold;font-size:0.75em;color:#000;">
klicken Sie hier:
</span>
</label>
</td>
Dabei habe ich mir offenbar gedacht:
- Positionierung dem <td>-Tag,
- Schriftformatierung dem <span>-Tag,
- und dem <label>-Tag garnichts (da es "keine sichtbare Wirkung am Bildschirm" hat).
Dabei hätte folgende, wesentlich kürzere Version doch dieselbe Wirkung:
<td style="vertical-align:middle;padding:3px 0;font-size:0.75em;color:#000;">
Wenn Sie fliegen wollen,
<label for"..." style="font-weight:bold;">
klicken Sie hier:
</label>
</td>
Der <td>-Tag übernimmt Schriftformatierung, <label> auch, <span> fällt weg... Habt ihr Einwände?
Und was ist überhaupt der heutige StatusQuo in Sachen "gutes HTML"?
Waer schoen, da ein paar Meinungen zu hoeren! Danke euch,
Eddie
Hi,
irgendwie hat sich vor einigen Jahren schon bei mir die Philosophie festgesetzt, dass jedes einzelne HTML-Element seinen Zweck hat und nicht zweckentfremdet eingesetzt werden sollte.
das ist gut.
Der <td>-Tag übernimmt Schriftformatierung,
Nein. Das <td>-Element übernimmt die Aufgabe, eine Tabellenzelle zu strukturieren. Das bedeutet, dass ihr Inhalt zu einem Datensatz gehört und den Wert einer Spalte darstellt. Die Aufgabe der Schriftformatierung übernimmt CSS, was exakt 0% Auswirkungen auf den HTML-Code hat. Der HTML-Code wird Jahrzehnte bevor überhaupt an irgend eine Darstellung _gedacht_ wird verfasst.
Und was ist überhaupt der heutige StatusQuo in Sachen "gutes HTML"?
Siehe oben. HTML ist eine Strukturbeschreibungssprache. Es beschreibt eine Struktur. HTML hat *nichts* mit Darstellung zu tun. Das Stichwort hierzu lautet "semantisches Markup".
Cheatah
Hello out there!
Der HTML-Code wird Jahrzehnte bevor überhaupt an irgend eine Darstellung _gedacht_ wird verfasst.
Du arbeitest nicht besonders schnell, was? ;-)
Das Stichwort hierzu lautet "semantisches Markup".
Grmpf, die Bezeichnung wird mir missfallen, sonlage sie verwendet wird.
See ya up the road,
Gunnar
Hi,
Grmpf, die Bezeichnung wird mir missfallen, sonlage sie verwendet wird.
Darf man fragen wieso?
Falls ja: Wieso? ;)
Den Begriff "semantisches Markup" hört man schließlich ständig und überall.
Hello out there!
Grmpf, die Bezeichnung [„semantisches Markup“] wird mir missfallen, sonlage sie verwendet wird.
Darf man fragen wieso?
Klar.
Falls ja: Wieso? ;)
Mal schnell ein paar Postings von mir aus’m Archiv gefischt:
2005-01-15 20:29, 2005-06-30 14:17, 2005-07-30 11:52, 2006-05-23 14:58, 2006-05-23 20:36.
Den Begriff "semantisches Markup" hört man schließlich ständig
Eben. :-(
und überall.
Übertreibtst du nicht das Ausmaß dieses Forums? ;-)
See ya up the road,
Gunnar
Hi,
Mal schnell ein paar Postings von mir aus’m Archiv gefischt:
Danke. Vorallem 2005-07-30 11:52 und 2006-05-23 20:36 fand ich sehr anschaulich und aufschlussreich.
Den Begriff "semantisches Markup" hört man schließlich ständig
Eben. :-(
Und damit ist dann wohl meistens die semantisch korrekte Auszeichnung der Struktur und nicht des Inhalts eines Dokuments gemeint.
(Ich hoffe, ich hab das so jetzt richtig aufgefasst)
und überall.
Übertreibtst du nicht das Ausmaß dieses Forums? ;-)
Naja "überall" war vielleicht etwas hoch gegriffen. Aber es geht doch nichts über eine krönend abschließende Hyperbel. ;-)
(Und zwar absolut nichts!)
;-)
Noreg
Hi,
Siehe oben. HTML ist eine Strukturbeschreibungssprache. Es beschreibt eine Struktur. HTML hat *nichts* mit Darstellung zu tun. Das Stichwort hierzu lautet "semantisches Markup".
wie ist denn JavaScript in diesem Kontext (Nutzdaten in HTML eingebettet/Strukturbeschreibung derselben mit HTML/deren Darstellung mit CSS) einzuordnen? JavaScript aendert Nutzdaten, Struktur derselben und deren Darstellung? Oder laesst sich JavaScript in diesem Zusammenhang nicht "philosophisch" einordnen?
Bockwurst
Hallo Bockwurst.
Siehe oben. HTML ist eine Strukturbeschreibungssprache. Es beschreibt eine Struktur. HTML hat *nichts* mit Darstellung zu tun. Das Stichwort hierzu lautet "semantisches Markup".
wie ist denn JavaScript in diesem Kontext (Nutzdaten in HTML eingebettet/Strukturbeschreibung derselben mit HTML/deren Darstellung mit CSS) einzuordnen?
Siehe SELFHTML Aktuell Weblog: „Der sinnvolle Einsatz von JavaScript“.
Dies ist für mich der Optimalzustand.
Einen schönen Donnerstag noch.
Gruß, Mathias
Hello out there!
Oder laesst sich JavaScript in diesem Zusammenhang nicht "philosophisch" einordnen?
Doch: als Präsentationslogik (das soll mal Reaktionen auf Nutzeraktionen mit einschließen).
„Kunst besteht aus drei Säulen: Text, Musik und Jonglage.“ (Felix Jentsch, Moderator der offenen Bühne im Zimmer 16) ;-)
Im übertragenen Sinne:
Text – HTML
Musik – CSS
Jonglage – JavaScript
Was für CSS gilt, dass die Angaben nicht inline in 'style'-Attributen, sondern zentral gemacht werden sollten, gilt auch für JavaScript. Also nicht
<foo onclick="[code lang=javascript]bar(); baz()">[/code]
sondern
<foo id="quz">
und im zentralen Script-Bereich
~~~javascript
window.onload = function() {
document.getElementById("quz").onclick = function() {
bar();
baz();
};
};
was sich dann auch in eine externe JavaScript-Datei auslagern lässt, so dass im HTML wirklich nur noch steht (Doctype und Namensraum spar ich jetzt mal):
~~~html
<html>
<head>
<title>Lorem ipsum</title>
<!-- Meta-Angaben -->
<link rel="Stylesheet" href="myStyle.css" />
<script type="text/javascript" src="myScript.js"></script>
</head>
<body>
<h1>Lorem ipsum dolor sit amet</h1>
<!-- und was sonst noch zu sagen ist -->
</body>
</html>
See ya up the road,
Gunnar
Hallo.
„Kunst besteht aus drei Säulen: Text, Musik und Jonglage.“ (Felix Jentsch, Moderator der offenen Bühne im Zimmer 16) ;-)
Dann fällt Malerei vermutlich unter Jonglage.
MfG, at
Hello out there!
„Kunst besteht aus drei Säulen: Text, Musik und Jonglage.“ (Felix Jentsch, Moderator der offenen Bühne im Zimmer 16) ;-)
Dann fällt Malerei vermutlich unter Jonglage.
Malerei wird selten auf einer offenen Bühne präsentiert, aber ja, SONSTIGES == JONGLAGE. ;-)
Und, wie Sebastian Krämer* singt: „Die Welt braucht keine Jongleure“ (anzuhören unter „Kostproben“).
See ya up the road,
Gunnar
* Das ist der, von dem ich dir mal den Text von dem „Bauern“ geschickt hatte.
Hallo.
* Das ist der, von dem ich dir mal den Text von dem „Bauern“ geschickt hatte.
Ich erinnere mich. Muss ich mal wieder rauskramen.
MfG, at
Hallo,
Und was ist überhaupt der heutige StatusQuo in Sachen "gutes HTML"?
Siehe oben. HTML ist eine Strukturbeschreibungssprache. Es beschreibt eine Struktur. HTML hat *nichts* mit Darstellung zu tun. Das Stichwort hierzu lautet "semantisches Markup".
Ich könnte dir fast zustimmen, aber nur fast.
HTML ist nunmal eine präsentationale Auszeichnungssprache (Strukturbeschreibungssprache? Nur bedingt). Es ist ziemlich egal wie semantisch der Code geschreiben wird, jedes HTML-Element hat nunmal eine bestimmte Darstellungsfunktion, die in den Browsern von Haus aus auf die eine oder andere Art implementiert ist (z.B. ob jemand jetzt <b> oder <strong> schreibt, mag aus der Sicht der Semantik etwas bedeuten, aber im Endergebnis wird der Text einfach nur fett dargestellt.)
Und wenn "semantisches Markup" noch überhaupt eine Rolle spielen würde, wäre uns das Ganze Web 0.2, ehm ... Web 2.0, erspart geblieben, denn dort wird alles gebraucht und benutzt, nur nicht semantisches Markup.
Grüße
Thomas
Hallo Thomas,
auch wenn man ajax und dhtml einsetzt, also WEB 2.0,
muss man auf semantisch richtiges HTML verzichten, für mich ist es sogar Bedingung.
Lieb Grüße,
Bernd
Hallo,
auch wenn man ajax und dhtml einsetzt, also WEB 2.0,
muss man auf semantisch richtiges HTML verzichten, für mich ist es sogar Bedingung.
Ja, so ist es! ;-)
Grüße
Thomas
Hi,
z.B. ob jemand jetzt <b> oder <strong> schreibt, mag aus der Sicht der Semantik etwas bedeuten, aber im Endergebnis wird der Text einfach nur fett dargestellt.
Wie du dir wahrscheinlich schon gedacht hast ist das eben _nicht_ unbedingt der Fall. <strong> beispielsweise wird bei mir rot und nicht fett dargestellt.
Hallo,
z.B. ob jemand jetzt <b> oder <strong> schreibt, mag aus der Sicht der Semantik etwas bedeuten, aber im Endergebnis wird der Text einfach nur fett dargestellt.
Wie du dir wahrscheinlich schon gedacht hast ist das eben _nicht_ unbedingt der Fall.
<strong>beispielsweise wird bei mir rot und nicht fett dargestellt.
Wenn du an den Einstellungen die die Browser von Haus aus mitbringen selbst was änders (user.css) ist es deine Sache. Hat aber nichts mit dem zu tun was ich gesagt habe.
Grüße
Thomas
Hi,
z.B. ob jemand jetzt <b> oder <strong> schreibt, mag aus der Sicht der Semantik etwas bedeuten, aber im Endergebnis wird der Text einfach nur fett dargestellt.
Wie du dir wahrscheinlich schon gedacht hast ist das eben _nicht_ unbedingt der Fall.
<strong>beispielsweise wird bei mir rot und nicht fett dargestellt.Wenn du an den Einstellungen die die Browser von Haus aus mitbringen selbst was änders (user.css) ist es deine Sache. Hat aber nichts mit dem zu tun was ich gesagt habe.
Stimmt natürlich. Dennoch kann man als Webautor wohl davon ausgehen, dass ein <b>old auch fett dargestellt wird (es sei denn der User will das nicht, aber das ist dann wirklich dessen Sache), bei <strong> dagegen hat man als Autor einer Webseite keinen Hinweis, wie das Element standardmäßig dargestellt wird.
Das Endergebnis _kann_ also zufälligerweise das selbe sein (gerade, weil es gerade Mode unter den Mainstreambrowsern ist, <strong> fett darzustellen), muss es aber ganz und gar nicht (aber so hatte ich deinen Satz verstanden).
Hallo,
Wenn du an den Einstellungen die die Browser von Haus aus mitbringen selbst was änders (user.css) ist es deine Sache. Hat aber nichts mit dem zu tun was ich gesagt habe.
Stimmt natürlich. Dennoch kann man als Webautor wohl davon ausgehen, dass ein
<b>old auch fett dargestellt wird (es sei denn der User will das nicht, aber das ist dann wirklich dessen Sache), bei<strong>dagegen hat man als Autor einer Webseite keinen Hinweis, wie das Element standardmäßig dargestellt wird.
Das Endergebnis _kann_ also zufälligerweise das selbe sein (gerade, weil es gerade Mode unter den Mainstreambrowsern ist,<strong>fett darzustellen), muss es aber ganz und gar nicht (aber so hatte ich deinen Satz verstanden).
Vom sprachlichen gesehen bietet sich ja die fette Darstellung für <strong> an.
Bei <em> würde ich dir eher zustimmen, dass die Darstellung dort durchaus unter den Browsern varieren könnte.
Natürich müssen die von einem Borserhersteller impelmentiere Darstellungen für die HTML-Elemente nicht von einem anderen Browserhersteller genau so impelmentiert sein. Aber die Unterschiede sind dabei eher marginal, was uns dazu zurückbringt, dass in HTML die Elemente schon mit einer bestimmten Darstellungsvorgabe in den Browser "behaftet" sind.
Diese Vorbelegung ist auch zumeist semantisch sinnvoll, z.B. h1, h2, etc. für Überschrift usw. Was im endeffekt heisst, eine wie auch immer getroffene Trennug zischen sematisches Markup und "normalen"-HTML ist irreführend, da die HTML-Elemente bringen bereits ihre eigene Semantik mit, weil die Browserhersteller .... aber das habe ich ja schon gesagt.
Grüße
Thomas
habe d'ehre Thomas
Und wenn "semantisches Markup" noch überhaupt eine Rolle spielen würde
Ketzer!
man liest sich
Wilhelm
Hallo Wilhelm.
Und wenn "semantisches Markup" noch überhaupt eine Rolle spielen würde
Ketzer!
„Spalter!“ heißt das.
Einen schönen Freitag noch.
Gruß, Math*scnr*ias
Hallo Wilhelm!
Und wenn "semantisches Markup" noch überhaupt eine Rolle spielen würde
Ketzer!
Nomen est omen! ;-)
Grüße
Thomas
Hallo Cheatah,
habe ich dich richtig verstanden: CSS kann ich einsetzen, wie's mir gefällt, egal bei welchem tag?
Ausserdem kann ich mir in obigem Beispiel das <span>-Tag komplett sparen und einfach die zweite Version meines Beispiels nehmen - ohne Einwände eurerseits (mal abgesehen vom Inline-CSS):
<td style="vertical-align:middle;padding:3px 0;font-size:0.75em;color:#000;">
Wenn Sie fliegen wollen,
<label for"..." style="font-weight:bold;">
klicken Sie hier:
</label>
</td>
Dann trotzdem noch die blöde Frage: was ist dann der Sinn von <span>?
Eddie
Hallo Eddie.
habe ich dich richtig verstanden: CSS kann ich einsetzen, wie's mir gefällt, egal bei welchem tag?
Ja. Jedes Element verfügt jederzeit über einen Wert für jede Eigenschaft. Diese Eigenschaften kannst du nach gusto manipulieren.
Fernab davon ist jedoch nicht sicher, dass jede Eigenschaft bei jedem Element in jedem Browser funktioniert.
Dann trotzdem noch die blöde Frage: was ist dann der Sinn von <span>?
Das span-Element dient als strukturelle Hilfe wenn absolut kein anderes Element passt. Mit Hilfe von Klassifizierungen kann man hierdurch strukturelle „Behelfs-Elemente“ einsetzen. (Siehe auch Spec.)
Einen schönen Samstag noch.
Gruß, Mathias
Hallo,
habe ich dich richtig verstanden: CSS kann ich einsetzen, wie's mir gefällt, egal bei welchem tag?
im Prinzip ja.
Dann trotzdem noch die blöde Frage: was ist dann der Sinn von <span>?
Derselbe wie beim div-Element. Beides sind "neutrale" Elemente, die im HTML keinen eigenen Zweck haben, außer andere Inhalte (Text und/oder weitere HTML-Elemente) zu gruppieren. Der einzige Unterschied ist, dass div ein Block-Element ist und span ein Inline-Element.
Dass vor allem div-Elemente aufgrund eines weit verbreiteten Irrglaubens fast ausschließlich mit der Erstellung eines Layouts in Verbindung gebracht werden, ist eine andere Geschichte. Die führt bei vielen HTML-Schreibern dazu, dass sie jedes Element, das sie irgendwie formatieren wollen, nochmal in ein sinnloses div verpacken.
Tatsache ist, dass es oft sinnvoll ist, die mit CSS zu formatierenden Elemente anhand ihres Kontextes zu selektieren. Wenn man *sinnvoll* gruppiert hat, sind das häufig div-Elemente. Dass es aber je nach Struktur des Dokuments ebensogut p, ul, form, dl, ... sein könnten, wird gern übersehen.
So long,
Martin
Hi,
Dann trotzdem noch die blöde Frage: was ist dann der Sinn von <span>?
Derselbe wie beim div-Element. Beides sind "neutrale" Elemente, die im HTML keinen eigenen Zweck haben, außer andere Inhalte (Text und/oder weitere HTML-Elemente) zu gruppieren. Der einzige Unterschied ist, dass div ein Block-Element ist und span ein Inline-Element.
Wenn der einzige Unterschied im Defaultstylsheet des Browsers liegt, ist der Unterschied zwischen <span> und <div> doch von rein darstellerischer Natur und hat nichts mit der strukturellen Auszeichnung an für sich zu tun. Wieso dann zwei verschiedene Elemente?
War jetzt nur so ein Gedanke, würde mich aber wirklich interessieren.
Hallo Noreg
... Wieso dann zwei verschiedene Elemente?
Trenne CSS (Darstellung) von HTML (Struktur)!
Per Default ist Div ein Blockelement, darf also nur in Elementen vorkommen, in denen Blockelemente erlaubt sind.
Span ist per Default ein Inlineelement, es darf also nur dort erscheinen, wo Inlineelemente erlaubt sind und keine Blockelemente enthalten.
Du hast damit also im HTML ein neutrales Blockelement (Div), mit dem du nahezu beliebige Elemente (auch Blockelemente) gruppieren kannst, und das ohne extra CSS einen Block bildet.
Außerdem hast du ein neutrales Inlineelement, mit dem du (Inline-)Inhalte innerhalb von Elementen markieren oder gruppieren kannst, die keine Blockelemente enthalten dürfen, und das ohne extra CSS auch keinen Zeilenumbruch bewirkt.
Welche Elemente innerhalb welcher anderen Elemente erlaubt sind, kannst du sehr gut in der HTML-Elementreferenz nachlesen.
Auf Wiederlesen
Detlef
Hi,
Per Default ist Div ein Blockelement, darf also nur in Elementen vorkommen, in denen Blockelemente erlaubt sind.
Span ist per Default ein Inlineelement, es darf also nur dort erscheinen, wo Inlineelemente erlaubt sind und keine Blockelemente enthalten.
Stimmt. Ich hatte nicht bedacht, dass HTML von sich aus schon Block- und Inline-Elemente mitbringt und dass ein wie auch immer geartetes Zwitterelement da wohl ziemliche Probleme bringen würde.
Danke für deine Antwort!
Hello out there!
Wenn der einzige Unterschied im Defaultstylsheet des Browsers liegt, ist der Unterschied zwischen
<span>und<div>doch von rein darstellerischer Natur und hat nichts mit der strukturellen Auszeichnung an für sich zu tun. Wieso dann zwei verschiedene Elemente?
Es gibt in (X)HTML Block- und Inline-Elemente. Die Bezeichnung kommt ursprünglich von der Darstellung, und in der Tat dürften in allen Browser-Stylesheet HTML-Blockelemente auch CSS-Blockelemente und HTML-Inline-Elemente auch CSS-Inline-Elemente sein.
'div' darf HTML-Blockelemente enthalten, 'span' nicht. 'span' darf in HTML-Inline-Elementen vorkommen, 'div' nicht.
Gäbe es nur ein gruppierendes Element, müsste dieses HTML-Blockelemente enthalten dürfen und auch in HTML-Inline-Elementen vorkommen dürfen. Damit könnten HTML-Blockelemente Enkel von HTML-Inline-Elementen sein, was nicht erwünscht ist.
Also muss es zwei verschiedene gruppierende Elemente geben: ein gruppierendes HTML-Blockelement und ein gruppierendes HTML-Inline-Element.
See ya up the road,
Gunnar
Hi,
Gäbe es nur ein gruppierendes Element, müsste dieses HTML-Blockelemente enthalten dürfen und auch in HTML-Inline-Elementen vorkommen dürfen. Damit könnten HTML-Blockelemente Enkel von HTML-Inline-Elementen sein, was nicht erwünscht ist.
Das ist natürlich ein Argument. Da hatte ich gar nicht dran gedacht.
Danke für die Erklärung!
Hello out there!
habe ich dich richtig verstanden: CSS kann ich einsetzen, wie's mir gefällt, egal bei welchem tag?
Ja. Das heißt aber nicht, dass jede Eigenschaft auch bei jedem Element wirkt (von fehlender Implementierung in Browsern abgesehen). Schreibst du beispielsweise
span {
width: 42em;
}
dann bewirkt gar nichts (außer in Brow^W IEs, die entgegen der Spezifikation implementiert sind), da im browserinternen Stylesheet
span {
display: inline;
}
angegeben ist und die 'width'-Eigenschaft auf nicht-ersetzte Inline-Elemente nicht angewendet wird. [CSS2 §10.2]
Wenn du diesen Wert überschreibst
span {
display: block;
width: 42em;
}
hast du aus dem 'span' ein Blockelement gemacht und die 'width'-Eigenschaft wirkt.
See ya up the road,
Gunnar
Sehr cool,
jetzt habe nicht nur mehr von der "Philosophie" verstanden (in den anderen Ästen des Threads), sondern auch mein aktuelles Problem geloest.
Thanx!
Eddie