Spans nebeneinander in einer Html-Seite darstellen

[Messmar]

Hallo,

ich will zwei Spans (In jedem Span habe ich eine Html-Tabelle) nebeneinander in einer Html-Seite darstellen.

Ich habe mehrmals versucht aber leider ohne erfolg.
Der Code:

<span>
  <table border="1" cellspacing="0" cellpadding="0">
    <tr><td>dhghghhghghgh</td></tr>
  </table>
</span>
<span>
  <table border="1" cellspacing="0" cellpadding="0">
    <tr><td>dhghghhghghgh</td></tr>
  </table>
</span>

Und selbst mit CSS-Klassen lässt sich das nicht bewältigen.

Danke + Gruß
Messmar

[MudGuard]

Hi,

ich will zwei Spans (In jedem Span habe ich eine Html-Tabelle) nebeneinander in einer Html-Seite darstellen.

Das geht schon allein deshalb nicht, weil Du in dem Moment, wo Du Tabellen in spans packst, keine HTML-Seite mehr hast - in HTML dürfen in spans keine Tabellen enthalten sein.

Wozu willst Du überhaupt die spans um die Tabellen haben?

Nutze float für die Tabellen.

cu,
Andreas

[Messmar]

Wozu willst Du überhaupt die spans um die Tabellen haben?

Ich bin schon ( Wenn ich das sagen darf;-) ) profi in Frontend, aber das Problem ist, daß ich die Spans brauche für ein Intranet-Tool, das halt mit PHP dann programmiert wird.

Es m+üssen spans sein. Leider ;-(

Nutze float für die Tabellen.

???

Danke und Gruß
Messmar

[egon]

Es m+üssen spans sein. Leider ;-(

div, per CSS als inline-Element definiert? In divs sind halt auch Tabellen erlaubt, div ist also die bessere Alternative.

Nutze float für die Tabellen.

???

Was gibt es da nicht zu verstehen?

[Messmar]

div, per CSS als inline-Element definiert? In divs sind halt auch Tabellen erlaubt, div ist also die bessere Alternative.

Danke schon mal.

Sie haben Recht, das könnte eine Lösung sein. Aber...
Divs helfen mir auch nicht, da der Code schon andere Divs enthält, die in diesen Spans eingebunden sind und das wird meinen code total
zerschiessen und ich muss dann fast alles ändern.
(Ich werde es aber machen müssen, wenn es aber gar keine andere Lösung gibt.)

Was gibt es da nicht zu verstehen?

Ich dachte, daß es float für span gemeint ist.

Schöne Grüße
Messmar

[MudGuard]

Hi,

Divs helfen mir auch nicht, da der Code schon andere Divs enthält, die in diesen Spans eingebunden sind

Wirklich professionell, was Du als Profi da machst.
spans dürfen natürlich auch keine divs enthalten.

und das wird meinen code total
zerschiessen

Für mich klingt das so, als wäre der schon ziemlich zerschossen.

cu,
Andreas

[Messmar]

Hi,

Wirklich professionell, was Du als Profi da machst.
spans dürfen natürlich auch keine divs enthalten.

Ich hae das Gefühl als hättest Du ein Problem mit meiner Aussage (profi)
Bevor Du was da schreibst, sollstest erst nach den Hintergrüden fragen, und ich glaube wie Du antwortest kann ich auf deine Hilfe wirklich verzichten.

Für mich klingt das so, als wäre der schon ziemlich zerschossen.

Ich weiße daß der code einige Mängeln hat, aber das habe ich leider nicht viel zu bestimmen, deswegen veruchte ich es irgendwie zu korrigieren ohne da ganze zu ändern.
Wenn ich die Whal hätte würde ich das ganze neu schreiben.

Aber das nächste mal solltest Du einbißel mit deinen Aussagen vorsichtig sein.

Jetzt muss ich gehen aber ich werde heute abend nachschauen.

schönen Abend noch und Gruß
Messmar

[egon]

Wirklich professionell, was Du als Profi da machst.
spans dürfen natürlich auch keine divs enthalten.

Ich hae das Gefühl als hättest Du ein Problem mit meiner Aussage (profi)

Dass du dich als solcher ausgibst, ist ja nicht verboten, es muss nur der Wahrheit entsprechen. Und eine Tabelle in spans; und div in spans sind nicht standardkonform - und wenn du das für richtig hältst, dann bist du wirklich _kein Profi_.

Bevor Du was da schreibst, sollstest erst nach den Hintergrüden fragen, und ich glaube wie Du antwortest kann ich auf deine Hilfe wirklich verzichten.

Wenn du standardkonform geschrieben und das hier nicht als _unbedingt notwendig_ angeprangert hättest, dann hättest du jetzt den Ärger nicht! Er ist wirklich nicht dran Schuld, eher schon du!

Für mich klingt das so, als wäre der schon ziemlich zerschossen.

Ich weiße daß der code einige Mängeln hat,[..]

Ich will (jetzt bitte nicht böse sein) nicht den Rest des Quelltextes sehen, wenn ich schon zwei gravierenden Fehler im Voraus weiß. Ich denke, es verstecken sich noch mehr Fehler im Quelltext.

Tipp: http://validator.w3.org
      http://jigsaw.w3.org:80/css-validator/validator-uri.html

Der zeigt dir die gesamten Fehler an die sich in deinem Quelltext verstecken. Korrigiere sie, danach darfst du wiederkommen und hier weiterfragen.

[..] aber das habe ich leider nicht viel zu bestimmen, deswegen veruchte ich es irgendwie zu korrigieren ohne da ganze zu ändern.

Das würde ich dir auch empfehlen.

Wenn ich die Whal hätte würde ich das ganze neu schreiben.

Ach, hast du nicht die Wahl? Ist das zeitbegrenzt?

Aber das nächste mal solltest Du einbißel mit deinen Aussagen vorsichtig sein.

s.o.

Jetzt muss ich gehen aber ich werde heute abend nachschauen.

Freue mich schon drauf ;-)

[fireeye]

Hi

Wirklich professionell, was Du als Profi da machst.
spans dürfen natürlich auch keine divs enthalten.

Ich hae das Gefühl als hättest Du ein Problem mit meiner Aussage (profi)
Bevor Du was da schreibst, sollstest erst nach den Hintergrüden fragen, und ich glaube wie Du antwortest kann ich auf deine Hilfe wirklich verzichten.

Ich bin zwar kein Profi, aber eine Sache nutze ich reichlich, in meinen Bookmarks sind bestimmte Seiten gelogt. So z.B. die Kurzreferenz für HTML-Elemente, ich möchte es fast buchstabieren, es liegt mir so auf der Zunge und an anderer Stelle ist die Feststellung zum Verhältnis von Span und Div schon gepostet worden. Also kleiner Tip: die HTML-Kurzreferenz anwählen, nach Span suchen und dann schau mal, ob es vorgesehen ist, daß im Geltungsbereich eines Span die Verwendung von Div vorgesehen ist? Da die Browserhersteller eh schon Schwierigkeiten haben, den Standard zu realisieren, werden sie dir nicht zum Gefallen eine Funktionalität von Div innerhalb eines Span-Geltungsbereichs projektiert haben. Was dabei herauskommt ist zufallsbedingt und weit entfernt vom gewünschten Ergebnis!

Die Sache mit dem Profi im Frontendbreich war ein Eigentor.

Da ich viele Textseiten mache, benutze ich z.B. Div in Verbindung mit CSS um der gesamten Seite einen bestimmten Schriftstil zuzuweisen. Wenn ich dann innerhalb des Fließtextes für eine Passage eine Änderung des Schriftstils bewirken will, dann kommt Span in Verwendung und dann auch wieder in Verbindung mit CSS.

Gruß f

[daniel84]

Hallo fireeye,

Da ich viele Textseiten mache, benutze ich z.B. Div in Verbindung mit CSS um der gesamten Seite einen bestimmten Schriftstil zuzuweisen.

Entschuldige die Anmerkung, die die vielleicht gar nicht so interessiert, aber: Warum weist du den bestimmten Schrifstil nicht einfach dem HTML-Element BODY zu? Dann kannst du dir das DIV sparen...

Wenn ich dann innerhalb des Fließtextes für eine Passage eine Änderung des Schriftstils bewirken will, dann kommt Span in Verwendung

Im schlechtesten Fall, ja. Besser ist, wenn du dafür vorgesehene HTML-Elemente wie EM, STRONG etc. einsetzt - je nachdem welches semantisch am sinnvollsten ist.

Gruss aus Luzern,
Daniel

[fireeye]

Hi Daniel

» »» Da ich viele Textseiten mache, benutze .....

Entschuldige die Anmerkung, die die vielleicht gar nicht so interessiert, aber: Warum weist du den bestimmten Schrifstil nicht einfach dem HTML-Element BODY zu? Dann kannst du dir das DIV sparen...

Danke, man lernt eben nie aus, kann man somit noch 2 Zeilen sparen :-) aber guter Einwand...

Wenn ich dann innerhalb des Fließtextes für eine Passage eine Änderung des Schriftstils bewirken will, dann kommt Span in Verwendung

Im schlechtesten Fall, ja. Besser ist .......

Viele Wege führen nach Rom, sag ich mal so ;-)
Bei der SPAN-Attributreferenz steht: _Markiert einen inline-Bereich zur Formatierung_. Das war damals für mich die ausschlaggebende Aussage, SPAN für mein Vorhaben zu wählen.

Ich hatte die Mächtigkeit von CSS zu Anfang des Projektes noch nicht in voller Breite erfaßt, trotzdem erschien für mich CSS der geeignete Weg zu sein, für das Projekt homogene Seiten erstellen zu können, ich wollte keinen kunterbunten Affenstall zusammenschustern, das war mir wichtig. Die Möglichkeit, SPAN über CSS beeinflussen zu können, war somit zu Beginn des Projektes das Mittel meiner Wahl, hiermit hatte ich die Möglichkeit, seitenübergreifend einen homogenen Stil zu pflegen. SPAN hat selbst keine Eigenschaften, EM hat eine Defaulteinstellung, die mit CSS überschrieben werden kann, also was macht da den Unterschied?

In einer zentralen CSS-Datei bot sich mir die Möglichkeit, alle Textformatierungen auszulagern und die entsprechenden Klassen dafür einzurichten, die so von CSS gebotenen Möglichkeiten waren für mich passend wie die Faust auf's Auge...Ich mußte nicht sofort entscheiden welche Stile ich verwenden wollte, lediglich mußte ich Klassen für die verschiedenen Anwendungszwecke definieren, um eine einheitliche Semantik zu erreichen. Aber wie ich schon sagte: Viele Wege... :-)

Gruß f

[daniel84]

Hallo fireeye,

SPAN hat selbst keine Eigenschaften, EM hat eine Defaulteinstellung, die mit CSS überschrieben werden kann, also was macht da den Unterschied?

Der Unterschied ist, dass z.B. ein Textbrowser eine Hervorhebung (und das sind wohl unterschiedliche Formatierungen in einem Fliesstext meist) mit <STRONG> </STRONG> ebenfalls hervorhebt - eine mit <SPAN STYLE="font-weight:bold;"> </SPAN> hingegen nicht! Natürlich sieht es für den Benutzer mit CSS-fähigem Client gleich aus - nur sagt ein SPAN nichts über die Struktur des Textes (bzw. den Sinn des ausgezeichneten Teils) aus, was du aber insgeheim sehr wohl willst...

Gruss aus Luzern,
Daniel

[fireeye]

Hallo Daniel,

SPAN hat selbst keine Eigenschaften, EM hat eine Defaulteinstellung, die mit CSS überschrieben werden kann, also was macht da den Unterschied?

Der Unterschied ist, dass z.B. ein Textbrowser eine Hervorhebung (und das sind wohl unterschiedliche Formatierungen in einem Fliesstext meist) mit <STRONG> </STRONG> ebenfalls hervorhebt - eine mit <SPAN STYLE="font-weight:bold;"> </SPAN> hingegen nicht! Natürlich sieht es für den Benutzer mit CSS-fähigem Client gleich aus - nur sagt ein SPAN nichts über die Struktur des Textes (bzw. den Sinn des ausgezeichneten Teils) aus, was du aber insgeheim sehr wohl willst...

Ich sagte ja bereits, viele Wege f..... ;-)
Wenn aber der Client nicht CSS-fähig ist, dann... ja, was dann...
Aber im vorliegenden Fall muß ich nicht jeden und wirklich nicht jeden Browser berücksichtigen. Die bisher durchgeführten Tests auf IE/FF/Mozilla/Opera haben jeweils unter Windows + Mac die gewünschten Ergebnisse bestätigt. Es bleibt daher immer abzuwägen SPAN contra EM/STRONG usw.usf. Der Weg mit SPAN hat mehr Freiheiten für mich. Ich kann zur Abrundung des Gesamtbildes im CSS die abschließenden Einstellungen vornehmen.

Ich habe zB. in einer CSS-Datei die Klasse "msrtags" definiert. Diese Definition erfolgte, um eine gewisse Semantik zu erreichen. Demzufolge steht im HTML die Zuweisung <span class="msrtags">blabla</span>. Die Anwendung der Klasse "msrtags" sagt für mich etwas aus und der User bekommt einen gleichbleibenden Eindruck über die gesamte Doku vermittelt.

Wie würde es dagegen erscheinen, wenn ich nachträglich STRONG durch eine CSS-Defintion die Strong-Eigenschaft aberkenne, falls das überhaupt möglich ist (ich hab's nicht probiert).

Gruß f

[wahsaga]

hi,

Ich habe zB. in einer CSS-Datei die Klasse "msrtags" definiert. Diese Definition erfolgte, um eine gewisse Semantik zu erreichen.

das ist aber eine ziemlich schwache "semantik".

Demzufolge steht im HTML die Zuweisung <span class="msrtags">blabla</span>. Die Anwendung der Klasse "msrtags" sagt für mich etwas aus und der User bekommt einen gleichbleibenden Eindruck über die gesamte Doku vermittelt.

Wie würde es dagegen erscheinen, wenn ich nachträglich STRONG durch eine CSS-Defintion die Strong-Eigenschaft aberkenne, falls das überhaupt möglich ist (ich hab's nicht probiert).

warum solltest du das denn tun wollen?
die argumentation in diese richtung ist unsinnig.
klar kannst du auch das strukturell sinnvollste HTML mit CSS so "kaputtformatieren", dass nur noch eine gleichförmige textsuppe herauskommt.

der "mehrwert" entsteht aber andersherum:

du willst einen textteil als "stark betont" auszeichnen, also benutzt du dafür <strong>.
vorgabewert für font-weight in CSS ist idR. bold, also wird dieser text fett angezeigt. der user erkennt hier eine starke betonung.
nun könnte der user CSS abschalten oder einen nicht-CS-fähigen browser benutzen. was sieht er?
immer noch gesondert dargestellten text, idR. ebenfalls in fetter schrift.
was sieht er bei deinem span? absolut keinen unterschied zum rest des textes.
gruß,
wahsaga

[fireeye]

hi

Wie würde es dagegen erscheinen, wenn ich nachträglich STRONG durch eine CSS-Defintion die Strong-Eigenschaft aberkenne, falls das überhaupt möglich ist (ich hab's nicht probiert).

warum solltest du das denn tun wollen?

Die Fragestellung liefert doch schon gleich die Antwort mit: ich würde es nicht tun wollen!

klar kannst du auch das strukturell sinnvollste HTML mit CSS so "kaputtformatieren", dass nur noch eine gleichförmige textsuppe herauskommt.

auch meine Meinung, das besser nicht zu tun!

nun könnte der user CSS abschalten oder einen nicht-CS-fähigen browser benutzen. was sieht er?

kommt bei meiner Zielgruppe weil nicht öffentlich nicht vor. Ich muß zwar den IE berücksichtigen, aber das was ich anwende, wird vom IE anstandslos ausgeführt.

Grundsätzlich waren deine Einwände aber berechtigt, soweit es sich um eine öffentlich zugängliche Seite geht. Bei meinen Überlegungen stellt sich für mich immer wieder die Frage, was sollen alle die schönen neuen Features bewirken, wenn ältere Browser nicht fähig sind diese darzustellen? Wenn man gründsätzlich abwärts kompatibel sein will, dann dürften IMHO keine neuen Features angewendet werden, was dann machen mit den neuen Features? Bei CSS stellt sich für mich aber nicht diese Frage, zumindest ein Teil gängiger CSS-Features dürfte in der Verbreitung einen gewissen Grad erreicht haben. Sonst ergibt das alles keinen Sinn mehr. Barrierefreiheit bis zum Exzess würde bedeuten, daß man heute noch mit Netscape 2.0 alle Seiten erreichen würde. Ist dem so?

Gruß f

[wahsaga]

hi,

Barrierefreiheit bis zum Exzess würde bedeuten, daß man heute noch mit Netscape 2.0 alle Seiten erreichen würde. Ist dem so?

bei einer sinnvoll strukturierten HTML-seite sollte das eigentlich noch (größtenteils) der fall sein - auch ohne darauf angewendetes CSS.

und gerade das ist einer der punkte, der textauszeichnungen wie <strong> etc. wesentlich sinnvoller macht als ein formatiertes <span>.

gruß,
wahsaga

[fireeye]

hi,

Barrierefreiheit bis zum Exzess würde bedeuten, daß man heute noch mit Netscape 2.0 alle Seiten erreichen würde. Ist dem so?

bei einer sinnvoll strukturierten HTML-seite sollte das eigentlich noch (größtenteils) der fall sein - auch ohne darauf angewendetes CSS.

und gerade das ist einer der punkte, der textauszeichnungen wie <strong> etc. wesentlich sinnvoller macht als ein formatiertes <span>.

Bei all dem stellt sich bei mir die Vermutung ein, daß dies alles Grundsatzdebatten sind zwischen Theorie und Wirklichkeit. Bis vor einiger Zeit war ich noch wegen älterer Hardware mit ältern Browsern unterwegs, nicht ganz alte aber auch nicht die neuesten. Somit waren manche Seiten für mich verschlossen. Das hat sich schlagartig mit neuerer Hardware geändert, da nun auch neuere Browserversionen anwendbar wurden.

Somit liegt mir die Frage auf der Zunge, warum CSS, wenn doch alles mit reinem HTML erreichbar sein sollte? Warum dann neue Features? Ich werd das Gefühl nicht los, das sich in dieser Hinsicht eine Zwickmühle auftut.

Nicht das ich jetzt mit CSS das STRONG-Element vergewaltigen möchte (das ergibt für mich keinen Sinn) aber zweifelsohne besteht die Möglichkeit per CSS. Ich sagte ja schon, viele Wege führen nach Rom... Wozu die ganze Dualität?

STRONG macht etwas, was ich mit SPAN incl. CSS ebenfalls erreiche? Klar, wenn es nur um die Eigenschaft von STRONG geht, würde es keinen Sinn ergeben, das nur zu diesem Zweck mit SPAN nachempfinden zu wollen. Im Gegensatz zu STRONG kann ich bei SPAN aber varieren und kombinieren, was eben den Einsatz von CSS interessant macht.

Der geübte Insider legt sich offenbar auf seine Vorgangsweisen und seine Vorlieben fest. Der weniger Geübte steht vor einer Anzahl von Möglichkeiten, für deren Auswahl er eine glückliche Hand haben muß.
In meinem Falle erschien die Anwendung von SPAN mehr angebracht als z.B. die Anwendung von STRONG. Und gleich hinterher die Frage <STRONG> contra <B>?
Ich bin schon mächtig stolz auf mich, daß ich nun auch meine letzte Browserweiche (wegen IE bei URL) ausbauen kann und damit nicht mehr auf spezielle Eigentümlichkeiten von Browsern abstellen muß.
Aber die Diskussion kann man noch weiter treiben. FRAMES ja oder nein? Auch da gibt es viele Ansichten, die total auseinander divergieren.
Als nächstes steht dann die Frage an, Javascript ja oder nein?
Es gibt offensichtlich kein Patentrezept. Bei meinem Start in das Projekt sind mir die Elemente STRONG&Co schon untergekommen, ich habe mich dann doch für SPAN entschieden. Und ich empfinde nicht, daß meine Entscheidung falsch ist, aber ich lasse mich gerne eines Besseren belehren.

Gruß f

[Struppi]

Nicht das ich jetzt mit CSS das STRONG-Element vergewaltigen möchte (das ergibt für mich keinen Sinn) aber zweifelsohne besteht die Möglichkeit per CSS. Ich sagte ja schon, viele Wege führen nach Rom... Wozu die ganze Dualität?

Was heißt denn vergewaltigen?

strong soll doch genau deshalb (anstelle von b) verwendet werden, nicht um den Text fett zu machen, sondern um einen Abschnitt zu betonen.

STRONG macht etwas, was ich mit SPAN incl. CSS ebenfalls erreiche? Klar, wenn es nur um die Eigenschaft von STRONG geht, würde es keinen Sinn ergeben, das nur zu diesem Zweck mit SPAN nachempfinden zu wollen. Im Gegensatz zu STRONG kann ich bei SPAN aber varieren und kombinieren, was eben den Einsatz von CSS interessant macht.

Strong hat eine Sematik, nur darum geht es.

Der geübte Insider legt sich offenbar auf seine Vorgangsweisen und seine Vorlieben fest. Der weniger Geübte steht vor einer Anzahl von Möglichkeiten, für deren Auswahl er eine glückliche Hand haben muß.

Du musst dich lediglich Fragen, was soll dieser Abschnitt bedeuten?
Und gibt es dafür ein HTML tag?

In meinem Falle erschien die Anwendung von SPAN mehr angebracht als z.B. die Anwendung von STRONG. Und gleich hinterher die Frage <STRONG> contra <B>?

Wenn in deinem Fale es kein passendes HTML Tag gibt ist ein span das Mittel der wahl. Strong heiß stark und meint betont, b heiß bold und heißt fett. Du willst mit CSS Design und Struktur voneinander trennen insofern macht b keinen Sinn.

Es gibt offensichtlich kein Patentrezept. Bei meinem Start in das Projekt sind mir die Elemente STRONG&Co schon untergekommen, ich habe mich dann doch für SPAN entschieden. Und ich empfinde nicht, daß meine Entscheidung falsch ist, aber ich lasse mich gerne eines Besseren belehren.

Falsch wäre es nur, wenn diese Abschnitte eine besondere Bedeutung haben sollen.

Struppi.

[fireeye]

Hi Struppi

STRONG macht etwas, was ich mit SPAN incl. CSS ebenfalls erreiche? Klar, wenn es nur um die Eigenschaft von STRONG geht, würde es keinen Sinn ergeben, das nur zu diesem Zweck mit SPAN nachempfinden zu wollen. Im Gegensatz zu STRONG kann ich bei SPAN aber varieren und kombinieren, was eben den Einsatz von CSS interessant macht.

Strong hat eine Sematik, nur darum geht es.

Die Diskussion um STRONG steht doch symbolisch auch für andere HTML-Elemente, die gleichermaßen eine feste Semantik (wenn man mal davon absieht, das sich auch diese Elemente durch CSS beeinflußen lassen) haben. Nur zur Aufhellung mal ein Stück Text:

Die Leistungssignale <span class="msrtags">T34415U18</span> und <span class="msrtags">T30415U18</span> werden den Wandtemperaturbegrenzungsregelungen <a class="doclink" href="../book_02/vdff_Leitfaden.html#M34415">TC34415</a> und <a class="doclink" href="../book_02/vdff_Leitfaden.html#M30415">TC30415</a> zugef&uuml;hrt. Wie bereits ebenfalls weiter oben f&uuml;r die Zone&nbsp;1......usw.usf.

T34415U18 ist z.B. ein Symbol aus der Verfahrenstechnik, abgeleitet aus einer Norm und angewendet in der Automatisierungstechnik. Mit dem Symbol wird konkret eine technische Funktion verbunden, um deren Beschreibung es hier geht. Wenn ich die grundsätzliche Absicht gehabt hätte, solche Symbole nur durch STRONG oder B hervorzuheben, dann wäre es damit auch ausreichend gewesen. So erscheint das Symbol im Fließtext mit folgender Definition:

.msrtags { font-style:italic; color:#006666; }

Es wäre eine Variante gewesen CITE oder DFN zur verwenden, es wäre aber auch hier auf ein Ergänzung durch CSS hinausgelaufen, um den farblichen Aspekt zu berücksichtigen. Aber damit wäre eine sematische Festlegung auf kursive Schriftauszeichnung festgelegt worden. Ich war mir zu Beginn des Projektes nicht einig darüber, welche entgültige Schriftauszeichnung ich verwenden sollte, darum die Anwendung von SPAN, da inhaltslos. Die Zuordnung der Semantik erfolgt erst durch die Zuordnung der Klasse "msrtags". Diese Klasse wird z.Zt. insgesamt genau 5307 mal angewendet. Es kommen zwei weitere Klassen hinzu, die eine Textunterscheidung machen sollen. Eine, wo ein Begriff in einem Glossary erläutert wird (glossarlink) und eine Klasse, die dem Leser einen Link auf eine andere Stelle (doclink) im Dokument verweisen soll. Das alles muß in ein rundes Bild passen, es soll den Text nicht unlesbar machen und ihn nicht verunstalten, es soll aber dennoch für den Leser einen Hinweis geben, was er mit der Textauszeichnung verbinden kann. Diese Abstimmung habe ich zum Schluß gemacht, aber nicht im stillen Kämmerlein, sondern mit Leuten aus meiner Zielgruppe.

Gruß f

[Struppi]

Strong hat eine Sematik, nur darum geht es.

Die Diskussion um STRONG steht doch symbolisch auch für andere HTML-Elemente, die gleichermaßen eine feste Semantik (wenn man mal davon absieht, das sich auch diese Elemente durch CSS beeinflußen lassen) haben. Nur zur Aufhellung mal ein Stück Text: .....

Klingt eigentlich alles ganz vernünftig. Ich glaub du hängst dich bei der Diskussion ein bisschen zu sehr an die CSS Formatierung fest.
Wenn du einen Text Fett darstellen willst, ist es nicht angebracht strong zu verwenden, sondern wenn der Textabschnitt eine besondere Bedeutung hat, dann solltest du strong oder em verwenden. In deinem Fall, seh ich zumindest, keine besondere Bedeutung in den Abschnitten, sondern du willst nur etwas optisch hervorheben und genau dafür ist das Span Tag da. Insofern würd ich sagen dass es so wie du es machst absolut richtig ist.

Aber wie gesagt in dem Falle geht es nicht um die Frage <strong> oder font-weight:bold dass soind zwei völlig verschiedenen Dinge.

Struppi.

[wahsaga]

hi,

Es wäre eine Variante gewesen CITE oder DFN zur verwenden [...]
Aber damit wäre eine sematische Festlegung auf kursive Schriftauszeichnung festgelegt worden.

wieso das? font-style hättest du auch auf diese elemente anwenden können.

gruß,
wahsaga

[fireeye]

hi

Es wäre eine Variante gewesen CITE oder DFN zur verwenden [...]
Aber damit wäre eine sematische Festlegung auf kursive Schriftauszeichnung festgelegt worden.

wieso das? font-style hättest du auch auf diese elemente anwenden können.

sag ich doch die ganze Zeit!

Aber wäre das guter Stil, z.B. CITE anzuwenden, das von hause aus für kursiv steht, um hernach bei nicht gefallen mit CSS den Stil "kursiv" abzuerkennen?

So ähnlich war meines Wissens der Ausgangspunkt der Dikussion, anstelle von SPAN andere Element mit einer entsprechenden Voreinstellung zu verwenden.

Das Argument, das voreingestellte Elemente bei fehlender Verfügbarkeit von CSS einen Vorteil haben, ist sicher richtig. Aber warum sollte jemand CSS abschalten wollen. Der, der dafür seine Gründe hat, muß dann eben damit leben. Was soll's. Wenn darauf Rücksicht genommen werden sollte, kann man CSS auch gleich abschaffen.

Gruß f

[MudGuard]

Hi,

Aber wäre das guter Stil, z.B. CITE anzuwenden,

Wenn es sich um ein Zitat handelt: ja.

das von hause aus für kursiv steht,

nicht, wenn es Dir um das "kursiv" geht.
Man wählt Elemente nicht wegen irgendeiner (Default-) Darstellung aus, sondern wegen ihrer Bedeutung.

cu,
Andreas

[fireeye]

Hi Andreas

Aber wäre das guter Stil, z.B. CITE anzuwenden,

Wenn es sich um ein Zitat handelt: ja.

das von hause aus für kursiv steht,

nicht, wenn es Dir um das "kursiv" geht.
Man wählt Elemente nicht wegen irgendeiner (Default-) Darstellung aus, sondern wegen ihrer Bedeutung.

Mom, da muß ich doch glatt nachfragen :-)
Den normalen User interessiert es normalerweise herzlichst wenig, was sich hinter seinem Bildschirm befindet, auf dem eine Seite sichtbar gemacht wird. Will sagen, ob nun z.B. CITE angewendet wird, oder eine CSS-Definition mit "font-style:italic" den kursiven Effekt auslöst, kann der User nicht riechen, wenn er nicht gerade in den Quelltext schaut. CITE als Übermittler einer Bedeutung, die anders ist als die Assoziation mit kursiv, dringt bis zum User nicht vor.
Semantik als grob vereinfachter Oberbegriff für Bedeutung und Sinn kommt nur beim Betrachter eines HTML-Scriptes an, nicht aber beim User, der sieht nur das Ergebnis von vielen Funktionsaufrufen, mit denen eine HTML-Seite gecodet wurde.

Also wähle ich CITE, da ich damit die Bedeutung des Kursiven verbinde. Oder glaubst Du, daß der User, der mit CITE erzeugten kursiven Text zu Gesicht bekommt, das mit "Markiert ein Zitat" verbindet? Nicht alle User lesen SELFHTML!

Gruß f

[daniel84]

Hallo fireeye,

Den normalen User interessiert es normalerweise herzlichst wenig, was sich hinter seinem Bildschirm befindet, auf dem eine Seite sichtbar gemacht wird. Will sagen, ob nun z.B. CITE angewendet wird, oder eine CSS-Definition mit "font-style:italic" den kursiven Effekt auslöst, kann der User nicht riechen, wenn er nicht gerade in den Quelltext schaut.

Der User, der einen CSS-fähigen Client benutzt, kann das in der Tat nicht. Der User, der einen nicht CSS-fähigen Client benutzt, kann dies hingegen sehr wohl - für den ist nämlich der font-style:italic-Bereich nicht vom Rest des Textes zu unterscheiden, der CITE-Bereich sehr wohl. Und das ist genau der Punkt!

Gruss aus Luzern,
Daniel

[at]

Hallo.

Also wähle ich CITE, da ich damit die Bedeutung des Kursiven verbinde. Oder glaubst Du, daß der User, der mit CITE erzeugten kursiven Text zu Gesicht bekommt, das mit "Markiert ein Zitat" verbindet? Nicht alle User lesen SELFHTML!

Dir ist aber schon klar, dass etwa Suchmaschinen HTML interpretieren und unterschiedliche Auszeichnungen unterschiedlich stark gewichten, während sie CSS-Formatierungen prinzipiell außer Acht lassen?
MfG, at

[daniel84]

Hallo fireeye,

Aber warum sollte jemand CSS abschalten wollen. Der, der dafür seine Gründe hat, muß dann eben damit leben. Was soll's. Wenn darauf Rücksicht genommen werden sollte, kann man CSS auch gleich abschaffen.

Lies mal den letzten Abschnitt in diesem Posting und überlege dir, ob du diesen Besuchern wirklich einen Teil der Bedeutung deiner Seite vorenthalten willst, wenn du das auch ganz einfach verhindern kannst.

Gruss aus Luzern,
Daniel

[wahsaga]

hi,

Bei all dem stellt sich bei mir die Vermutung ein, daß dies alles Grundsatzdebatten sind zwischen Theorie und Wirklichkeit.

nein, um die unterscheidung zwischen sinnvoll angewendeten HTML und CSS, und weitgehend beliebiger textauszeichnung.

Somit liegt mir die Frage auf der Zunge, warum CSS, wenn doch alles mit reinem HTML erreichbar sein sollte?

weil HTML die struktur beschreiben soll, und CSS für das (aktuell gewünschte) aussehen sorgen soll.

dein span beschreibt nicht, dass es sich beim inhalt um etwas besonderes/betontes handelt - strong tut dies.

Nicht das ich jetzt mit CSS das STRONG-Element vergewaltigen möchte (das ergibt für mich keinen Sinn) aber zweifelsohne besteht die Möglichkeit per CSS.

nein, die möglichkeit der strukturellen auszeichnung des inhaltes besteht per CSS _nicht_ - für diese ist HTML verantwortlich.

STRONG macht etwas, was ich mit SPAN incl. CSS ebenfalls erreiche?

nein, s.o.
bitte beschränke dich in der betrachtung nicht nur auf das, was _optisch_ letztendlich herauskommt.

Im Gegensatz zu STRONG kann ich bei SPAN aber varieren und kombinieren, was eben den Einsatz von CSS interessant macht.

ich verstehe nicht, was du damit meinst.
du kannst den inhalt von strong ebenso frei formatieren wie den eines span.

Der geübte Insider legt sich offenbar auf seine Vorgangsweisen und seine Vorlieben fest.

nein, der hat einfach das grundprinzip der trennung von inhalt und layout verstanden ;-)

Der weniger Geübte steht vor einer Anzahl von Möglichkeiten, für deren Auswahl er eine glückliche Hand haben muß.

er steht vor der gefahr, den sinn der verschiedenen logischen/strukturellen auszeichnungselemente zu verwechseln/nicht zu verstehen.
deshalb ist für ihn noch eine eingehendere beschäftigung mit den grundlegenden prinzipien von HTML erforderlich.

In meinem Falle erschien die Anwendung von SPAN mehr angebracht als z.B. die Anwendung von STRONG.

warum?

gruß,
wahsaga

[at]

Hallo.

Grundsätzlich waren deine Einwände aber berechtigt, soweit es sich um eine öffentlich zugängliche Seite geht.

Interessant ist, dass man in solchen Grundsatzdiskussionen fast niemals mit öffentlichen Seiten zu tun hat. Fast immer geht es um Intranets und geschlossene Nutzerkreise. Seltsam.
MfG, at

[Struppi]

Es bleibt daher immer abzuwägen SPAN contra EM/STRONG usw.usf. Der Weg mit SPAN hat mehr Freiheiten für mich. Ich kann zur Abrundung des Gesamtbildes im CSS die abschließenden Einstellungen vornehmen.

Das ist mit em/strong und Konsorten durchaus auch möglich.

Ich habe zB. in einer CSS-Datei die Klasse "msrtags" definiert. Diese Definition erfolgte, um eine gewisse Semantik zu erreichen.

Was für eine Semantik steckt hinter "msrtags"?

Demzufolge steht im HTML die Zuweisung <span class="msrtags">blabla</span>. Die Anwendung der Klasse "msrtags" sagt für mich etwas aus und der User bekommt einen gleichbleibenden Eindruck über die gesamte Doku vermittelt.

Du hast Glück das du allein an dem Projekt arbeitest und "msrtags" für dich etwas aussagt, aber ist prinizipiell die Bedeutung von <strong> oder <em> nicht einfacher zu verstehen?

Wie würde es dagegen erscheinen, wenn ich nachträglich STRONG durch eine CSS-Defintion die Strong-Eigenschaft aberkenne, falls das überhaupt möglich ist (ich hab's nicht probiert).

Eine Hervorhebung in der Bedeutung muss nicht durch font-weight:bold erfolgen, sie kann genauso gut durch z.b. color:red dargestellt werden.
Wird die HTML Seite vorgelesen, wird man es vielleicht durch eine Sprechpause deutlich machen. Das Span bleibt ein Inhaltsleeres Element, das nur bei der optischen Umsetzung eine Bedeutung haben kann.

Struppi.

[fireeye]

Hi Struppi

Ich habe zB. in einer CSS-Datei die Klasse "msrtags" definiert. Diese Definition erfolgte, um eine gewisse Semantik zu erreichen.

Was für eine Semantik steckt hinter "msrtags"?

Das Ziel war, Symbole aus der MSR-Technik vom übrigen Text abzugrenzen. Die Entscheidung, wie der Stil für die Klasse "msrtags" entgültig zu definieren war, hab ich mir bis zum Schluß aufgehoben, da ich sehr viel Wert auf ein ausgewogenes Schriftbild lege. Viel buntes und viele Schriftarten machen eben noch kein gutes Dokument, eher das Gegenteil ist der Fall. Bei EM/STRONG hätte ich mich schon vorher festlegen müssen. <span class="msrtags"> bietet mir aber die Möglichkeit, den Eindruck des gesamten Dokumentes nachzubessern.

Klar, mit STRONG ist eine eindeutige Semantik verbunden. Das ist es aber bei "msrtags" aber auch, nur eben nicht für jeden sichtbar, was es auch nicht unbedingt sein muß, denn "msrtags" läßt eine Variation zu, die man bei STRONG sinnigerweise NICHT ausführen sollte, gleichermaßen würde es keinen Sinn ergeben, eine Klasse ROT zu definieren, wenn tatsächlich innerhalb der Defintion der Farbcode für blau zur Anwendung kommen würde (das mal so als hypothetisches Beispiel).

Ganz davon abgesehen habe ich SPAN nicht verwendet, um einen Text mit Bold auszuzeichnen, das geht mit <b> leichter und ist mit weniger Aufwand verbunden.

Gruß f

[Struppi]

Was für eine Semantik steckt hinter "msrtags"?

Das Ziel war, Symbole aus der MSR-Technik vom übrigen Text abzugrenzen. Die Entscheidung, wie der Stil für die Klasse "msrtags" entgültig zu definieren war, hab ich mir bis zum Schluß aufgehoben, da ich sehr viel Wert auf ein ausgewogenes Schriftbild lege. Viel buntes und viele Schriftarten machen eben noch kein gutes Dokument, eher das Gegenteil ist der Fall. Bei EM/STRONG hätte ich mich schon vorher festlegen müssen. <span class="msrtags"> bietet mir aber die Möglichkeit, den Eindruck des gesamten Dokumentes nachzubessern.

Für mich klingt es eher so (ich weiß aber nicht genau was MSR-Technik ist) als ob du am sinnvollsten <code> verwendet hättest.

Wie gesagt es geht lediglich darum, wie du einen Text von der Bedeutung auszeichnest und für mich klingt das stark nach einem Abschnitt mit einem Code Beispiel.

Struppi.

[fireeye]

Hi Struppi

Wie gesagt es geht lediglich darum, wie du einen Text von der Bedeutung auszeichnest und für mich klingt das stark nach einem Abschnitt mit einem Code Beispiel.

:-) dafür hab ich eh das CODE-Element verwendet...

Gruß f

[Ingo Turski]

Hi,

Das Ziel war, Symbole aus der MSR-Technik vom übrigen Text abzugrenzen. Die Entscheidung, wie der Stil für die Klasse "msrtags" entgültig zu definieren war, hab ich mir bis zum Schluß aufgehoben, da ich sehr viel Wert auf ein ausgewogenes Schriftbild lege. Viel buntes und viele Schriftarten machen eben noch kein gutes Dokument, eher das Gegenteil ist der Fall. Bei EM/STRONG hätte ich mich schon vorher festlegen müssen. <span class="msrtags"> bietet mir aber die Möglichkeit, den Eindruck des gesamten Dokumentes nachzubessern.

das ist Unsinn, sorry.
Du willst die Symbole abgrenzen, also besonders betonen. Gut. <em> tut dies für Dich - in jedem Browser, egal ob und wieviel CSS er umsetzen kann. (Wenn Du sie hervorheben wolltest, wäre <strong> angebracht).

Du willst diese Symbole klassifizieren, um sie über CSS besonders kenntlich zu machen. Gut. <em class="msrtags"> tut dies für Dich. Wie Du die Formatierung letztendlich machst und ob Du die meist vorhandene Vorgabe der Schrägstellung übernimmst, bleibt Dir überlassen. Nur eben mit dem Unterschied zu span, daß die Elemente auch ohne CSS abgegrenzt sind.

Ich glaube, Du hast einfach die Erklärung zu span mißversanden.
"Markiert einen inline-Bereich zur Formatierung" will lediglich sagen, daß es einen Bereich markiert, aber nicht dem Inhalt in irgend einer Weise eine Bedeutung gibt. Das ist doch der eigentliche Sinn von span: ein bedeutungsloses Element zu sein.

freundliche Grüße
Ingo

[fireeye]

Hi Ingo

Ich glaube, Du hast einfach die Erklärung zu span mißversanden.
"Markiert einen inline-Bereich zur Formatierung" will lediglich sagen, daß es einen Bereich markiert, aber nicht dem Inhalt in irgend einer Weise eine Bedeutung gibt. Das ist doch der eigentliche Sinn von span: ein bedeutungsloses Element zu sein.

:-( Was mach ich mit einem Element, das keine Bedeutung hat? Sinnloses tun? Sorry. So ganz komm ich mit deiner Aussage nicht klar. Einen Bereich mit einem bedeutungslosen Element markieren? Wozu?

Elemente wie STRONG/B/EM usw.usf. haben eben ihre Bedeutung und ihren Sinn, die Bedeutung läßt sich (fast) direkt aus dem Wort (bzw. aus dem Begriff für den die Abkürzung steht) ableiten, die Ableitung des Sinns ist da aber ohne weiteres nicht gegeben. Diese Elemente, die ich hier mal beispielhaft verwende, symbolisieren Funktionen, die von Browsern  ausgeführt werden sollen. Damit ist die wirkliche (hier im Sinne von wirken) Bedeutung definiert. Diese Funktionen haben Eigenschaften, die in einer Voreinstellung festgelegt worden sind. Damit wird die Vererbung bestimmter übergeordneter Schriftmerkmale verhindert bei gleichzeitigem Ersatz dieser Merkmale, die diesen Funktionen zu eigen sind. Das ergibt den Sinn.

Aber Teufel auch, mit CSS kann man doch tatsächlich diese Eigenschaften der Funktionen verändern, was dann einen andern Sinn ergibt!

Und nun zu SPAN. Das ist auch eine Funktion, die auch von Browsern ausgeführt wird. SPAN steht also synonym für den Aufruf einer Funktion und kann somit NICHT bedeutungslos sein, das wird auch dadurch nicht anders, weil der Funktion angeblich keine Eigenschaften mitgegeben wurden. Zu denken, daß SPAN deshalb bedeutungslos ist, ist schlichtweg und ergreifend FALSCH! SPAN anzuwenden ohne eine Eigenschaft zu konfigurieren, DAS ist sinnlos. Aber die Funktion mit einer eingestellten Eigenschaft anzuwenden, das ergibt dann plötzlich einen Sinn. Und wie man STRONG verändern kann, kann man auch die Eigenschaften von SPAN einstellen. Genau genommen verhalten sich STRONG und SPAN ähnlich, beide lassen die gleichen Universalattribute zu, die Grundeinstellung bei SPAN ist "plaintext", während bei STRONG  die Eigenschaft "font-weight" auf "bold" eingestellt ist!

Es kommt so ziemlich auf das gleiche hinaus, was in der letzten Konsequenz angewendet wird. Bei einfacher Textauszeichung ist es sicher günstiger STRONG&Co anzuwenden, das auch unter dem Aspekt, das CSS nicht verfügbar sein könnte. Nur dann frag ich mich wirklich, was soll dann der ganze Schnickschnack mit CSS?  Bleiben wir doch beim guten alten HTML! ROFL Ich finde diese Diskussion um das Abschalten von CSS widersinnig.

BTW bei SELFHTML steht die BEDEUTUNG zu SPAN: "Markiert einen inline-Bereich zur Formatierung, z.B. mit CSS" und nicht wie oben aus dem Kontext gerissen und verkürzt wiedergegeben.

Gruß f

[daniel84]

Hallo fireeye,

Aber die Funktion mit einer eingestellten Eigenschaft anzuwenden, das ergibt dann plötzlich einen Sinn. Und wie man STRONG verändern kann, kann man auch die Eigenschaften von SPAN einstellen. Genau genommen verhalten sich STRONG und SPAN ähnlich, beide lassen die gleichen Universalattribute zu, die Grundeinstellung bei SPAN ist "plaintext", während bei STRONG  die Eigenschaft "font-weight" auf "bold" eingestellt ist!

Genau. Der grosse Unterschied ist aber, dass ein nicht-CSS-fähiger Client mit den Eigenschaften, die du im CSS dem SPAN zuweist, nichts anfangen kann - mit dem HTML-Element STRONG aber sehr wohl!

Nur dann frag ich mich wirklich, was soll dann der ganze Schnickschnack mit CSS?

Der ist für Benutzer eines CSS-fähigen Clients.

ROFL Ich finde diese Diskussion um das Abschalten von CSS widersinnig.

Es geht nicht gross um das Abschalten von CSS, sondern vielmehr um die Tatsache, dass es Clients gibt, die CSS von Natur aus nicht unterstützen. Beispiele dafür sind Screenreader, Textbrowser, vielleicht Browser auf PDAs, Suchmaschinen-Bots, ...

Gruss aus Luzern,
Daniel

[fireeye]

Hallo Daniel

....Der grosse Unterschied ist aber, dass ein nicht-CSS-fähiger Client mit den Eigenschaften, die du im CSS dem SPAN zuweist, nichts anfangen kann - mit dem HTML-Element STRONG aber sehr wohl!

Nur dann frag ich mich wirklich, was soll dann der ganze Schnickschnack mit CSS?

Der ist für Benutzer eines CSS-fähigen Clients.

ROFL Ich finde diese Diskussion um das Abschalten von CSS widersinnig.

Es geht nicht gross um das Abschalten von CSS, sondern vielmehr um die Tatsache, dass es Clients gibt, die CSS von Natur aus nicht unterstützen. Beispiele dafür sind Screenreader, Textbrowser, vielleicht Browser auf PDAs, Suchmaschinen-Bots, ...

Ich denke, man kann die Diskussion nicht mit der Vehemenz führen, die alleine seeligmachende eierlegende Wollmilchsau finden zu wollen. Dies ist eine unlösbare Aufgabe, solange Fortschritt bei der Entwicklung von Browsern besteht. Somit klingt es für mich absurd, zu wissen, daß es CSS gibt, das auch von CSS-fähigen Browsern angewendet werden könnte, aber aus Rücksicht auf Clients, die CSS nicht verstehen, dann dieses hervorragende Mittel nicht anzuwenden. Hier muß jeder für sich sehen, welche Zielgruppe er vor Augen hat. Gut, ich bin in der glücklichen Lage zu wissen, daß das von mir gestaltete Produkt sicher immer mit CSS-fähigen Browsern dargestellt werden wird. Es würde auch keinen Sinn ergeben, sich einzuschränken, da die Darstellung meines Produktes auf einem Textbrowser nur einen Bruchteil der vorhandenen Informationen übermitteln würde. Screenreader kenn ich nicht. Für Browser auf PDAs gilt gleiches wie bei Textbrowsern. Suchmaschinen sind in dem Falle bedeutungslos.

Aber es bleibt bei einer grundsätzlichen Divergenz in den Ansichten. Ich verfolge aufmerksam die Diskussionen um FRAMES, JAVASCRIPT und jetzt auch noch CSS. Es erscheint mir, daß sich die Lager sehr polarisieren. So kann Ich kann auf Javascript nicht verzichten, eine Navigation von mehr als 1300 Menüeinträgen, dazu noch hierachisch unter purem HTML zu gestalten, kommt einem aussichtslosem Vorhaben gleich. Würde ich der Religion des reinen HTML's folgen wollen, könnte ich mein Projekt gleich in die Rundablage schieben. Somit würde ich auf ein hervorragendes Medium verzichten wollen, mit dem es möglich ist, Dokumentationen in einer bisher nie da gewesenen Qualität zu präsentieren. Alleine 2957 Links sind als Querverweise in meinem Produkt enthalten, die in Papierform den Text mit Passagen wie "siehe Seite sowieso" unlesbar machen würden. Meine Zielgruppe kann an jeder nur erdenklichen Stelle über einen Rechner in die Doku Einsicht nehmen, die sonst irgendwo in den Aktenschränken eines Sachbearbeiters verstauben würde. Also heißt die klare Entscheidung Javascript, egal, ob eine Puristengemeinde ständig mit dem Finger den Staub in der Luft durchwirbelt, um auf die Abschaltmöglichkeit von Javascript hinzuweisen. Da man ein solch großes Menu schwierig auf einer Seite gemeinsam unterbringen kann, es müßte ständig neu geladen werden, wenn die Seite wechselt, kommt auch die klare Entscheidung für FRAMES. Bleibt noch CSS! Wenn ich also alle drei Dinge zusammennehme, dann komme ich IMMER zu der Entscheidung, den eleganteren Weg zu wählen. Und CSS ist nun einmal eleganter.

Gruß f

[daniel84]

Hallo fireeye,

ich bleibe jetzt einfach mal bei meiner Meinung, dass du noch immer nicht ganz verstanden hast, was wir dir mitteilen wollen.

Somit klingt es für mich absurd, zu wissen, daß es CSS gibt, das auch von CSS-fähigen Browsern angewendet werden könnte, aber aus Rücksicht auf Clients, die CSS nicht verstehen, dann dieses hervorragende Mittel nicht anzuwenden.

Du sollst _nicht_ auf CSS verzichten (das hat dir im ganzen Thread noch niemand geraden). Ich versuchs mal mit einem etwas anderen Ansatz. Du hast in deinem konkreten Fall zwei Möglichkeiten:

A) Du verwendest <SPAN class="irgendwas">Begriff</SPAN>, um den Begriff hervorzuheben
B) Du verwendest <EM>Begriff</EM> (oder auch <EM class="irgendwas">Begriff</EM>), um den Begriff hervorzuheben

Variante A erlaubt CSS-fähigen Clients (die zweifelsohne die Mehrheit der Zugriffe auf deine Seiten ausmachen werden - zumindest im Jahre 2005 noch) die Hervorhebung des Begriffs nach deinen Wünschen - du kannst eine Farbe zuweisen, den Begriff unterstreichen, mit einem Hintergrund versehen; die Möglichkeiten sind schier unbegrenzt. Ist der Benutzer deiner Seite nun aber blind, verwendet er einen Screenreader (eine Software, die u.a. Websites vorliest). Screenreader können mit Schriftformatierungen nichts anfangen - einleuchtenderweise. Screenreader interessieren sich ebenfalls nicht für dein <SPAN> - da es ein Element ohne logische Bedeutung ist (per Definition).

Variante B erlaubt CSS-fähigen Clients _genau das gleiche_ wie Variante A. Du kannst genau die gleichen Eigenschaften zuweisen, wie du das in Variante A kannst. Ev. musst du zudem eine oder zwei Eigenschaften definieren, da dir die gängigen Default-Werte dieser Elemente nicht gefallen. Schlussendlich bekommt aber der sehende Mensch, der einen Firefox oder einen IE benutzt, _genau_ das gleiche zu sehen wie in Variante A. Nun kommen wir aber zum blinden Benutzer, der einen Screenreader benutzt. Die Software stösst auf ein EM-Element und - nun kommt es - weiss, dass der damit ausgezeichnete Abschnitt eine besondere Bedeutung hat. Auch der Screenreader hat Default-Werte, die nun z.B. dazu führen, dass der Begriff betont wird. Somit hat der Blinde die Möglichkeit, mehr Informationen aus dem ihm vorgelesenen Text zu entnehmen - er weiss nämlich, dass du den Begriff hervorheben wolltest.

Summa summarum bietest du dem "normalen", sehenden, einen modernen Browser benutzenden Besucher genau den gleichen Wert. Darüber hinaus hast du aber die Möglichkeit, weiteren Benutzergruppen ohne Mehraufwand erheblichen Mehrwert zu bieten! Gibt es einen plausiblen Grund, auf diese Möglichkeit zu verzichten?!

So kann Ich kann auf Javascript nicht verzichten, eine Navigation von mehr als 1300 Menüeinträgen, dazu noch hierachisch unter purem HTML zu gestalten, kommt einem aussichtslosem Vorhaben gleich.

Das ist wiederum eine falsche Perspektive. Es geht nicht darum, so etwas _entweder_ mit Javascript _oder_ mit HTML zugänglich zu machen - du hast die Möglichkeit, beides auf einen Schlag zu erledigen! Schau dir z.B. dieses Beispiel von Gernot an - einmal mit aktiviertem Javascript, einmal mit deaktiviertem. Du erkennst, dass es mit Javascript viel übersichtlicher dargestellt wird, weil nicht schon zu Beginn alle Unter-Unter-Punkte sichtbar sind. Das ist schön für den Benutzer, der mit einem Javascript-fähigen Client die Seite besucht. Kommt nun aber jemand - aus welchen Gründen auch immer - ohne Javascript-Unterstützung auf die Seite, stehen ihm immer noch 100% der Informationen zur Verfügung!

Beide Techniken (CSS und Javascript) haben eins gemeinsam: Sie sind zwar faszinierend und man sollte sie natürlich einsetzen, um Mehrwert anzubieten - die Inhalte der Seiten sollten aber _immer_ auch ohne diese Techniken vollständig zugänglich sein!

Gruss aus Luzern,
Daniel

[fireeye]

Hallo Daniel,

ich bleibe jetzt einfach mal bei meiner Meinung, dass du noch immer nicht ganz verstanden hast, was wir dir mitteilen wollen.

Ich hab das schon verstanden, auch wenn es nicht bei dir so ankommt.

Somit klingt es für mich absurd, zu wissen, daß es CSS gibt, das auch von CSS-fähigen Browsern angewendet werden könnte, aber aus Rücksicht auf Clients, die CSS nicht verstehen, dann dieses hervorragende Mittel nicht anzuwenden.

Variante B erlaubt CSS-fähigen Clients _genau das gleiche_ wie Variante A. Du kannst ....... Somit hat der Blinde die Möglichkeit, mehr Informationen aus dem ihm vorgelesenen Text zu entnehmen - er weiss nämlich, dass du den Begriff hervorheben wolltest.

Summa summarum bietest du dem "normalen", sehenden, einen modernen Browser benutzenden Besucher genau den gleichen Wert. Darüber hinaus hast du aber die Möglichkeit, weiteren Benutzergruppen ohne Mehraufwand erheblichen Mehrwert zu bieten! Gibt es einen plausiblen Grund, auf diese Möglichkeit zu verzichten?!

Bitte hier weiterlesen.

So kann Ich kann auf Javascript nicht verzichten, eine Navigation von mehr als 1300 Menüeinträgen, dazu noch hierachisch unter purem HTML zu gestalten, kommt einem aussichtslosem Vorhaben gleich.

Das ist wiederum eine falsche Perspektive. Es geht nicht darum, so etwas _entweder_ mit Javascript _oder_ mit HTML zugänglich zu machen - du hast die Möglichkeit, beides auf einen Schlag zu erledigen! Schau dir z.B. dieses Beispiel von Gernot an - einmal mit aktiviertem Javascript, einmal mit deaktiviertem.

If you are going to do something twice, you should think about ist and do it one time less.....

Hier bleibe ich bei meiner Meinung: 75 Menueinträge gegenüber 1300. Das fehlerfrei in HTML zu coden, oh weh!!!
Da stehen  in HTML 15536 Bytes in 157 Zeilen und das für 75 Einträge!!!!! Help, help, das umgerechnet auf 1300 macht etwa 269290 Bytes. Dem gegenüber stehen bei meiner Lösung real in Javascript 68430 Bytes in 1400 Zeilen. Ich komme netto auf etwa 38 Bytes an Nutzdaten pro Eintrag, der ganze Overhead mit Javascript hat etwa 19000 Bytes, d.h. etwa 28% der zu transportierenden Daten sind Overheaddaten. In den 19000 Bytes stecken aber auch noch andere Javascript-Funktionen, die nicht unbedingt direkt mit dem Navigationsverzeichnis zusammenhängen, hier sind noch Navigationshilfen drin, die zur Kapitel- und Abschnittweiterschaltung dienen, die Navigationsfunktionen liegen bei insgesamt 5800 Bytes. Gernots Beispiel dürfte etwa nur 2850 Bytes an Nutzdaten haben, der Overhead beträgt satte 82% das Verhältnis würde sich auch nicht ändern, wenn man die Anzahl der Menueinträge verdoppeln würde. Bei meinem System kämen pro Eintrag 10 Bytes Overhead dazu. Nöö, brauch ich nicht weiter drüber nachzudenken, wo die bessere Lösung ist. Allein die Pflege eines solchen Inhaltsverzeichnis in HTML wäre absoluter Wahnsinn. Nööö, wirklich nöö, das wäre falscher Ehrgeiz.

Aber danke für den Hinweis, werd ich mir nochmal unter die Lupe nehmen, getreu dem Motto: Lieber schauen und klauen als selber bauen :-)... sofern es was zu klauen gibt... ;-)

Gruß f

[at]

Hallo.

ich bleibe jetzt einfach mal bei meiner Meinung, dass du noch immer nicht ganz verstanden hast, was wir dir mitteilen wollen.

Ich darf dich berichtigen: Er hat noch weit weniger verstanden als das, was ihm hier bisher mitgeteilt worden ist.
MfG, at

[fireeye]

Hallo.

ich bleibe jetzt einfach mal bei meiner Meinung, dass du noch immer nicht ganz verstanden hast, was wir dir mitteilen wollen.

Ich darf dich berichtigen: Er hat noch weit weniger verstanden als das, was ihm hier bisher mitgeteilt worden ist.
MfG, at

Ich find's schon lustig, wenn sich Dritte in eine Diskussion einmischen und per Ferndiagnose und Kaffeesatz, den Verständnislevel ihres Gegenübers attestieren. Wirklich konstruktiv dein Beitrag, meiner hier auch nicht, aber was soll's

Gruß f

[at]

Hallo.

Ich find's schon lustig, wenn sich Dritte in eine Diskussion einmischen

Dieses Phänomen nennt sich "Forum".
MfG, at

[fireeye]

Hallo at

Ich find's schon lustig, wenn sich Dritte in eine Diskussion einmischen....

Dieses Phänomen nennt sich "Forum".

Ach nee, wirklich ?

Aber dein Zitat steht außerhalb des Kontexts...na ja, wer's braucht... so zu diskutieren...

Aber vielleicht hast du ja auch an einer Fernuniversität deinen Doktor gemacht, der dich befähigt, Ferndiagnosen zu stellen!! :-)

Gruß f

[at]

Hallo.

Aber dein Zitat steht außerhalb des Kontexts...

Dieses Phänomen nennt sich "Gesamtzusammenhang".

Aber vielleicht hast du ja auch an einer Fernuniversität deinen Doktor gemacht, der dich befähigt, Ferndiagnosen zu stellen!! :-)

Du kannst natürlich auch jeden einzelnen Nutzer dieses Forums persönlich besuchen, aber ich werde das auch weiterhin anders handhaben.
MfG, at

[fireeye]

Hallo at

Dieses Phänomen nennt sich "Gesamtzusammenhang".

aus dem selbigen gerissen......

Du kannst natürlich auch jeden einzelnen Nutzer dieses Forums persönlich besuchen, aber ich werde das auch weiterhin anders handhaben.

Seit wann spricht von dir in der 2. Person ?? *ganzfiesbreitgrins*

Gruß f

[at]

Hallo.

Dieses Phänomen nennt sich "Gesamtzusammenhang".
aus dem selbigen gerissen......

Du solltest Doppelpunkte nicht quer setzen.

Du kannst natürlich auch jeden einzelnen Nutzer dieses Forums persönlich besuchen, aber ich werde das auch weiterhin anders handhaben.

Seit wann spricht von dir in der 2. Person ??

Dieses Phänomen nennt sich "persönliche Anrede" und bezieht sich auf ein Gegenüber.

*ganzfiesbreitgrins*

Gut, dass du das hinzufügst. Man hätte dich sonst fast für zurechnungsfähig halten können.
MfG, at

[fireeye]

Hallo at

aus dem selbigen gerissen......

Du solltest Doppelpunkte nicht quer setzen.

»»
Meine Tastatur hat da leider ein Prob, muß ich mal reklamieren....

Seit wann spricht von dir in der 2. Person ??

Dieses Phänomen nennt sich "persönliche Anrede" und bezieht sich auf ein Gegenüber.

Du scheinst dich wohl in einer äußerst phänomenalen Umgebung zu befinden.. aber sag mal, wenn du dich so anredest, erwiderst du dir dann auch? das soll gelegentlich doch ... schon... ach...

...Man hätte dich sonst fast für zurechnungsfähig halten können.

ach ich komme mit mir ganz gut zurecht..die andern aber wohl auch...und  du?

Gruß f

[at]

Hallo.

ach ich komme mit mir ganz gut zurecht..die andern aber wohl auch...und  du?

Mit dir? Danke der Nachfrage, es geht.
MfG, at

[fireeye]

Hallo at

ach ich komme mit mir ganz gut zurecht..die andern aber wohl auch...und  du?

Mit dir? Danke der Nachfrage, es geht.

Ach, sind dir jetzt die Phänomene ausgegangen?
das verwundert mich!!!

Gruß f

[Ingo Turski]

Hi,

:-( Was mach ich mit einem Element, das keine Bedeutung hat? Sinnloses tun? Sorry. So ganz komm ich mit deiner Aussage nicht klar. Einen Bereich mit einem bedeutungslosen Element markieren? Wozu?

um es über CSS zu formatieren oder auch über Javascript ansprechen zu können. Dafür ist ein span geeignet - nicht aber, wenn das Element auch eine Bedeutung haben soll, die lediglich über CSS dargestellt werden soll.

Elemente wie STRONG/B/EM usw.usf. haben eben ihre Bedeutung und ihren Sinn, die Bedeutung läßt sich (fast) direkt aus dem Wort (bzw. aus dem Begriff für den die Abkürzung steht) ableiten, die Ableitung des Sinns ist da aber ohne weiteres nicht gegeben.

Doch. Im Falle von <em> ist der Sinn eine Betonung - auch unabhängig von CSS.

Zu denken, daß SPAN deshalb bedeutungslos ist, ist schlichtweg und ergreifend FALSCH!

Du verdrehst die Tatsachen. Es geht um vordefinierte Eigenschaften - völlig unabhängig von CSS.
So ist z.B. <h2> als Überschrift zweiter Ordnung definiert. Nutzer von Screenreadern bekommen hierdurch nicht nur die Information "dies ist eine Überschrift" sondern können diese auch je nach Sofware direkt ansteuern. Und auch wenn Du an anderer Stelle sagst:

ich bin in der glücklichen Lage zu wissen, daß das von mir gestaltete Produkt sicher immer mit CSS-fähigen Browsern dargestellt werden wird

könnte es nicht sein, daß doch mal ein Sehbehinderter diese Seiten zu lesen bekommt? Für den ist dann Dein <span> nicht vorhanden, ein <em> würde aber z.B. betont vorgelesen.

Das ganze nennt sich übrigens Barrierefreiheit und ist inzwischen auch bei uns gesetzlich geregelt. Aber selbst wenn man nicht hierunter fällt, sollte man doch nicht so engstirnig sein und Behinderte mutwillig ausgrenzen.

Nur dann frag ich mich wirklich, was soll dann der ganze Schnickschnack mit CSS?  Bleiben wir doch beim guten alten HTML! ROFL

Du brauchst es doch nicht zu nutzen. Aber was Du bedenken solltest ist, daß eine sinnvolle HTML-Auszeichnung absolut nichts mit CSS zu tun hat. HTML strukturiert den Inhalt und zeichnet ihn aus. CSS definiert hinterher das Aussehen. Erst hierbei kann es vorkomen, daß - um ein gewünschtes aussehen zu erreichen - bedeutungslose Elemente wie span oder div in das HTML eingefügt werden müssen. Nur war Dir bei den spans im vornherein klar, daß diese Elemente eine besondere Bedeutung haben.

freundliche Grüße
Ingo

[fireeye]

Hi Ingo

.......Und auch wenn Du an anderer Stelle sagst:

ich bin in der glücklichen Lage zu wissen, daß das von mir gestaltete Produkt sicher immer mit CSS-fähigen Browsern dargestellt werden wird....
könnte es nicht sein, daß doch mal ein Sehbehinderter diese Seiten zu lesen bekommt? Für den ist dann Dein <span> nicht vorhanden, ein <em> würde aber z.B. betont vorgelesen.

Sehbehinderte kommen nicht auf die Anlagen, das wäre ein glatter Verstoß gegen die Arbeitssicherheit. Ein Sehbehinderter im Stahlwerk? Neeeeeee.
Darüber hinaus ist die gesamte Doku für einen Sehbehinderten nutzlos, weil er keine Grafik erkennen würde. Eine technische Doku lebt mit und von grafischen technischen Darstellungen. Man könnte die Grafiken beschreiben, das wäre aber eher was für eine Tondatei, was aber den ganzen Sinn des Projektes in Frage stellen würde.

Das ganze nennt sich übrigens Barrierefreiheit und ist inzwischen auch bei uns gesetzlich geregelt. Aber selbst wenn man nicht hierunter fällt, sollte man doch nicht so engstirnig sein und Behinderte mutwillig ausgrenzen.

Klar, im normalen Umfeld würde ich dem zustimmen.
Ich denke die Diskussion dreht sich deswegen im Kreis, weil jeder der hier Beteiligten im Glauben zu sein scheint, HTML würde ausschließlich zur Darstellungen von Websites verwendet werden. Ein fataler Irrtum. Ich habe schon 1997 HTML-Scripte machen lassen, um Bedienhilfen an Bildschirmarbeitsplätzen für Prozeßleitstände in Stahlwerken zu realisieren.

Aber was Du bedenken solltest ist, daß eine sinnvolle HTML-Auszeichnung absolut nichts mit CSS zu tun hat.

HTML strukturiert den Inhalt und zeichnet ihn aus. CSS definiert hinterher das Aussehen.

Ich denke, das muß sich mal erst einmal auf der Zunge zergehen lassen. Also, ich bin ja kein Insider, aber so viel hab ich bis jetzt verstanden, daß man mit CSS alleine keine Seite machen kann. Mit HTML dagegen schon, Beide wirken aber zusammen, wenn's so gecodet ist, Demnach muß HTML eine Schnittstelle bereitstellen, damit CSS überhaupt wirksam werden kann. Das alleine reicht aber nicht aus, hinter der Schnittstelle verbergen sich innerhalb von HTML Mechanismen, damit die Parameter, die von CSS über die Schnittstelle bereitgestellt werden, verarbeitet werden können. Das ist übrigens nicht auf HTML alleine beschränkt. In anderen Sprachen verhält sich das in ähnlichem Umfang, so kann man in C z.B. ohne Probs externen Ojektcode anderer Programmiersprachen einbinden, wenn die Schnittstellenbedingungen beachtet werden. Man darf HTML, Javascript und CSS nicht mit einer Gemüsesuppe vergleichen, in die man alles mit der Einstellung hinwirft,  das nur durch kräftiges Kochen sie an Geschmack gewinnen würde. Nee, so wird das nix.

Wie und an welcher Stelle ein Text mit Auszeichnungen versehen wird, ist für die nach außen sichtbare Wirkung völlig belanglos. Der HTML-Parser muß in der Lage sein, alle mit CSS definierten Auszeichnungen auch interpretieren zu können, wenn das nicht der Fall ist, dann hat der Browserhersteller was falsch gemacht, was man bei IE im weiten Umfang beklagen kann. Will meinen, wenn die Implementierung von CSS zu wünschen übrig läßt, dann bezieht sich das nicht unbedingt auf CSS sondern auf die Schnittstelle im HTML-Parser und die Implementierung innerhalb des Parsers. Somit ist das widerlegt, daß eine Textauszeichnung, die direkt im HTML-Script erfolgt, keinen Counterpart im CSS hat. CSS alleine bewirkt nichts, es stellt nur die Parameter bereit, die vom HTML-Parser erfaßt werden. Dabei kann über CSS kein Parameter bereitgestellt werden, der ohnehin nicht schon von sich aus auf der HTML-Ebene verstanden wird.

Erst hierbei kann es vorkomen, daß - um ein gewünschtes aussehen zu erreichen - bedeutungslose Elemente wie span oder div in das HTML eingefügt werden müssen. Nur war Dir bei den spans im vornherein klar, daß diese Elemente eine besondere Bedeutung haben.

nochmals, es gibt keine bedeutungslose Elemente, es gibt allenfalls unterlassene Implementierungen seitens der Browserhersteller. Jedes Element hat eine Bedeutung, sieh mal nach, was unter Semantik bei Wikida steht. DIV und SPAN haben eben die Bedeutung, das man ihnen Eigenschaften zuweisen kann. Wenn man auch das nicht könnte, erst dann wären sie ohne Bedeutung. Es gibt in anderen Umgebungen Statements wie NOP (no operation). NOP macht nichts, aber wirklich rein gar nicht, aber es dennoch eine Bedeutung. So hat es in ASM die Bedeutung eines Platzhalters. usw. usf. Es gibt auch keine Elemente mit besonderen Bedeutungen. Ein Element hat immer die Bedeutung, für die es geschaffen wurde. Man kann natürlich einem Element eine besondere Bedeutung beimessen, dies ist dann aber eher eine sehr persönliche Ansichtsweise.

Gruß f

[Ingo Turski]

Hi,

Sehbehinderte kommen nicht auf die Anlagen, das wäre ein glatter Verstoß gegen die Arbeitssicherheit. Ein Sehbehinderter im Stahlwerk? Neeeeeee.

Punkt für Dich - nur: warum sagst Du das nicht gleich? Du weißt, daß Du hier in einem Forum bist, wo Barrierefreiheit groß geschrieben wird?

Aber was Du bedenken solltest ist, daß eine sinnvolle HTML-Auszeichnung absolut nichts mit CSS zu tun hat.

HTML strukturiert den Inhalt und zeichnet ihn aus. CSS definiert hinterher das Aussehen.

Ich denke, das muß sich mal erst einmal auf der Zunge zergehen lassen. Also, ich bin ja kein Insider, aber so viel hab ich bis jetzt verstanden, daß man mit CSS alleine keine Seite machen kann.

Logisch - wir reden ja auch von HTML-Seiten. ;-)
Nur hast Du das Konzept noch immer nicht ganz verstanden. Browser - oder allg. User Agents - interpretieren HTML. Hierzu nutzen CSS-fähige Browser ein internes CSS, welches entsprechend den vorgegebenen Bedeutungen der HTML-Elemente bestimmte optische Grund-Formatierungen vornimmt.
Über ein Autoren-CSS können diese Formatierungen nun ergänzt oder auch umgeschieben werden.

Das ändert aber nichts daran, daß eine sinnvolle HTML-Auszeichnung die Basis darstellt bzw. darstellen sollte. Eine gute HTML-Seite zeichnet sich dadurch aus, daß sie eben auch ohne das Autoren-CSS vernünftig dargestellt wrden kann.

nochmals, es gibt keine bedeutungslose Elemente, es gibt allenfalls unterlassene Implementierungen seitens der Browserhersteller.

Nein. span und div sind extra als "bedeutungslos" definiert und dürfen - abgesehen von der blockbildenden Eigenschaft von div - vom Browser-CSS nicht mit Eigenschaften versehen werden.
Der Grund für das Vorhandensein diese Elemente ist auch ganz simpel: Da die zur verfügung stehenden Elemente nicht jeden Fall abdecken können, sind diese eben für die "sonstigen" Fälle bestimmt.

Jedes Element hat eine Bedeutung, sieh mal nach, was unter Semantik bei Wikida steht. DIV und SPAN haben eben die Bedeutung, das man ihnen Eigenschaften zuweisen kann.

eine eigenwillige Interpretation, die vielleicht überarneitet werden sollte..;-)

Es gibt in anderen Umgebungen Statements wie NOP (no operation). NOP macht nichts, aber wirklich rein gar nicht, aber es dennoch eine Bedeutung. So hat es in ASM die Bedeutung eines Platzhalters.

Ok, dann sieh' die "Bedeutung" für span als Platzhalter für im Sprachumfang noch fehlende Elemente. Aber verwende es auch nur dafür.

freundliche Grüße
Ingo

[fireeye]

Hi Ingo

Jedes Element hat eine Bedeutung, sieh mal nach, was unter Semantik bei Wikida steht. DIV und SPAN haben eben die Bedeutung, das man ihnen Eigenschaften zuweisen kann.
eine eigenwillige Interpretation, die vielleicht überarneitet werden sollte..;-)

Es gibt in anderen Umgebungen Statements wie NOP (no operation). NOP macht nichts, aber wirklich rein gar nicht, aber es dennoch eine Bedeutung. So hat es in ASM die Bedeutung eines Platzhalters.
Ok, dann sieh' die "Bedeutung" für span als Platzhalter für im Sprachumfang noch fehlende Elemente. Aber verwende es auch nur dafür.

ich mach's mal kurz.
Grundsätzlich verstehe ich deine Einwände und ich denke, wir sind in den Standpunkten ziemlich ähnlich.
IMHO besteht der Unterschied offensichtlich nur in der Anwendung einer bestimmten Terminologie.
Das was du mit "bedeutungslos" übersetze ich mit "eigenschaftslos". Ich denke mehr ist es nicht.

Ich hab da mal was ausgegraben:

The <span> and <div> tags were introduced later in the HTML game that are very useful when dealing with Cascading Style Sheets. People tend to use them in similar fashion, but they serve different purposes.

The <div> tag defines logical divisions in your Web page. In terms of layout, the <div> tag does only one thing, it determines the alignment of that section of your page.

<div> also gives you the chance to define the style of whole sections of HTML. You could define a section of your page as a call out and give that section a different style from the surrounding text.

But that's not all it does! The <div> tag gives you the ability to name certain sections of your documents so that you can affect them with style sheets or Dynamic HTML.

One thing to keep in mind when using the <div> tag is that it breaks paragraphs. It acts as a paragraph end/beginning, and while you can have paragraphs within a <div> you can't have a <div> inside a paragraph.

The <span> tag has very similar properties to the <div> tag, in that it affects the style of the text it encloses. Items in the <span> can be aligned or given specific style attributes.

The primary difference between the <span> and <div> tags is that <span> doesn't do any formatting of it's own. The <div> tag acts as a paragraph break, because it is defining a logical division in the document. The <span> tag simply tells the browser to apply the style and align rules to whatever is within the <span>.

Use <span> when you want to change the style of elements without naming them in a separate division within the document.
nachzulesen hier

oder aber auch dieses:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

Suppose, for example, that we wanted to generate an HTML document based on a database of client information. Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc., we use DIV and SPAN to achieve the desired structural and presentational effects.

nachzulesen hier bei W3C

Na, es liegt da offensichtlich sehr viel Interpretationsfreiheit drin. Ich übersetzte _attributes_ mit Eigenschaften. Man mag sich drüber streiten, ob Tags ohne voreingestellte Eigenschaften grundsätzlich eigenschaftslos sind, aber die Möglichkeit ein Tag mit Eigenschaften zu überladen ist nach meiner Ansicht auch eine Eigenschaft, wenn auch nicht im technischen Sinne der Eigenschaften selbst, mit der man ein TAG überladen kann.

Auf jeden Fall hat mir die Diskussion sehr viel Spaß gemacht, zumal hier niemand vorhatte dem anderen ans Bein zu Pinkeln. Wenn das so bleibt, bin ich gerne in diesem Forum

Gruß f

[Struppi]

Na, es liegt da offensichtlich sehr viel Interpretationsfreiheit drin. Ich übersetzte _attributes_ mit Eigenschaften. Man mag sich drüber streiten, ob Tags ohne voreingestellte Eigenschaften grundsätzlich eigenschaftslos sind, aber die Möglichkeit ein Tag mit Eigenschaften zu überladen ist nach meiner Ansicht auch eine Eigenschaft, wenn auch nicht im technischen Sinne der Eigenschaften selbst, mit der man ein TAG überladen kann.

Es geht nicht um CSS- oder Darstellungseigenschaften. Bedeutung bzw. Bedeutungslos meint die Bedeutung im Textkörper.

<p>, <hx>, <ol>, <ul>, <dl>, <table> sind Blockelemente mit denen du Abschnitte Kennzeichnest, die eine dem Tag entsprechende Bedeutung haben.
<em>, <strong>, <cite> ... sind Inlineelemente mit denen du Textabschnitte innerhalb eines Blocks entpsrechend der Bedeutung des Tags kennzeichnest.

D.h. wenn du ein Zitat hast nimmst du <cite> hast du einen Abschnitt der wichtig ist nimmst du <em> ist der Abschnitt sehr wichtig <strong>.

Das ist z.b. auch für Screenreader interessant, die diese Abschnitte dann entsprechend betonen oder mit einer Pause vorlesen können.

Möchtest du einem Absatz oder einem Abschnitt lediglich ein anderes Layout geben, ohne das dieser eine besondere Bedeutung hat, dann sollst du <span> oder <div> verwenden.

Aus deinem Beispiel geht nicht klar hervor, ob der von dir mit <span> markierte Bereiche eine besondere Bedeutung hat und somit evtl. besser mit <em> oder <strong> markiert würde oder ob es dir lediglich um eine visuelle Verbesserung geht.
Ich finde man kann sowas am besten feststellen, wenn du dir den Text mit abgeschalteten CSS anschaust und du denkst das die Darstellung dem entspricht wie du den Inhalt vermitteln möchtest, dann hast du dir richtigen HTML Elemente verwendet.

Struppi.

[fireeye]

Hi Struppi

Bedeutung bzw. Bedeutungslos meint die Bedeutung im Textkörper.

Das ist ein Aspekt, den ich bisher in dieser Form nicht gesehen habe. Die gleichen Schwierigkeiten dürfte aber auch jeder andere Anfänger haben, das mit der notwendigen Tiefe zu erkennen. In erster Näherung ist man auf die Erstellung eines Layouts fixiert, wobei es so scheint, daß zum Erreichen eines adäquaten Ergebnisses, es mehrere Wege gibt. Was sich tatsächlich hinter den verschiedenen Lösungswegen verbirgt, bleibt für den Anfänger erst einmal im Hinterbrund verborgen.

Das ist z.b. auch für Screenreader interessant, die diese Abschnitte dann entsprechend betonen oder mit einer Pause vorlesen können.

Hier lag das Problem im Verständnis, wenn sich jemandem die Hintergründe verschließen, weil man z.B. mit dem Begriff Screenreader nichts anzufangen weiß - jetzt schon, wenn man aus dem Rathaus kommt ist man immer schlauer :-)

Gruß f

[Ingo Turski]

Hi,

nachzulesen hier

schlechter Text. Sehr oberflächlich und ungenau. Was hierin stimmt ist lediglich die Tatsache, daß <div> nicht nur die blockbildende Eigenschaft hat, sondern zur Gruppierung von Elementen gedacht ist.

Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc., we use DIV and SPAN to achieve the desired structural and presentational effects.

nachzulesen hier bei W3C

besser. Und vor allem belegst Du hiermit genau meine Argumentation. ;-)
Weil es eben kein Element <telephone> gibt, kann und sollte <span> eingesetzt werden.

freundliche Grüße
Ingo

[daniel84]

Hallo fireeye,

Das Ziel war, Symbole aus der MSR-Technik vom übrigen Text abzugrenzen. Die Entscheidung, wie der Stil für die Klasse "msrtags" entgültig zu definieren war, hab ich mir bis zum Schluß aufgehoben, da ich sehr viel Wert auf ein ausgewogenes Schriftbild lege. Viel buntes und viele Schriftarten machen eben noch kein gutes Dokument, eher das Gegenteil ist der Fall. Bei EM/STRONG hätte ich mich schon vorher festlegen müssen. <span class="msrtags"> bietet mir aber die Möglichkeit, den Eindruck des gesamten Dokumentes nachzubessern.

Obwohl es dir Struppe und wahsaga nun eigentlich schon zur Genüge zu erklären versucht haben, klinke ich mich nochmals kurz ein. So wie du argumentierst, hast du nicht verstanden, dass du auch ein STRONG-Element nach Belieben formatieren kannst. Im Moment steht bei dir

<SPAN class="msrtags"> und im CSS .msrtags { font-style:italic; color:#006666; }

Besser ist, wenn du schreibst:

<EM class="msrtags"> und im CSS .msrtags { font-style:italic; color:#006666; }

Eigentlich kannst du statt EM auch STRONG nehmen, dann ergänzt du einfach im CSS noch um font-weight:normal; (wenn dich der Fettdruck, den STRONG in den meisten Browsern per Default hat, stört).

In den meisten grafischen Browsern (auch im IE, gegen den du erfolgreich gekämpft hast) wird das Resultat genau gleich aussehen, ob du nun SPAN oder EM verwendest! Ich wiederhole: <SPAN class="msrtags"> und <EM class="msrtags"> wird den betroffenen Textabschnitt genau gleich erscheinen lassen!

Wenn du dir die Seite allerdings in einem Textbrowser (z.B. Lynx) anschaust, wird die Passage mit SPAN nicht von "normalem" Text zu unterscheiden sein. Wenn du die Passage aber mit EM formatierst, wird auch in einem Textbrowser eine Hervorhebung vorgenommen! Und das ist genau der Unterschied, den du erkennen solltest! Wie ein Textbrowser versteht nämlich z.B. auch ein Screenreader kein CSS, sodass auch dort nur eine Betonung vorgenommen wird, wenn du EM verwendest, nicht aber bei einem mit CSS noch so hübsch formatierten SPAN!

Mir ist übrigens klar, dass das bei deinem aktuellen Projekt nicht so relevant ist - du solltest aber erkennen, warum das allgemein durchaus einen Unterschied macht - und zwar nicht nur in der Theorie!

Gruss aus Luzern,
Daniel

[fireeye]

Hallo Daniel,

Obwohl es dir Struppe und wahsaga nun eigentlich schon zur Genüge zu erklären versucht haben, klinke ich mich nochmals kurz ein. So wie du argumentierst, hast du nicht verstanden, dass du auch ein STRONG-Element nach Belieben formatieren kannst. Im Moment steht bei dir

<SPAN class="msrtags"> und im CSS .msrtags { font-style:italic; color:#006666; }

Besser ist, wenn du schreibst:

<EM class="msrtags"> und im CSS .msrtags { font-style:italic; color:#006666; }

Ich will dir dein Besser nicht nehmen. Aber vielleicht versuchst du doch einmal der Diskussion von Anbeginn zu folgen, dann würde dein Schluß, ich hätte etwas nicht verstanden, nicht erfolgen. Irgendwo an einer anderen Stelle in diesem Thread habe ich ein Beweisführung gegen das Argument der Bedeutungslosigkeit von SPAN aufgebaut. Du hast recht, wenn du darstellst, daß EM genauso wie SPAN überladen wwerden könnte. Doch will sdas jemand wirklich? Nun mal eine ketzerische Frage: Würde es denn sinnvoll sein, EM so zu überladen, daß es bei der Ausführung die gleichen Eigenschaften von STRONG präsentieren würde?
Nein, es wird nicht sinnvoll sein und so wie wahsaga ausführt, ist es äußerst dümlich, das HTML kaputt zu formatieren. Das Überladen von HTML-Elementen ist da sinnvoll, wo es darum geht Eigenschaften hinzuzufügen, nicht aber eine voreingestellte Eigenschaft zu entfernen!

Und damit erreichen wir die nächste Ebene der Diskussion (auch schon mal irgendwo beschrieben). Die Frage ob es sinnvoll ist, EM, STRONG oder andere gleichartige Elemente mit anderen Eigenschaften zu überladen, orientiert sich innerhalb DIESER Diskussion doch an dem Argument der Verfügbarkeit von CSS auf diversen Browsern. Die Diskussion um die Verfügbarkeit von CSS gleicht einer Diskussion um die 10. Nachkommastelle bei einer Zahl, die mindestens 10 Stellen vor dem Komma hat.

Wenn ich einmal meine speziellen Bedürfnisse außer acht lasse und nur auf die Verfügbarkeit von CSS abstelle, dann verbietet sich jegliches Überladen von HTML-Elementen, somit wäre der Einsatz von SPAN absolut sinnlos. Argumentiere ich mit der Möglichkeit der Überladung von Elementen wie zB. STRONG oder EM, da ich die Frage der CSS-Verfügbarkeit außer acht lasse, dann gilt dies gleichermaßen für SPAN.

Meine Rede ist, SPAN in bestimmten Fällen universal zu verwenden, wenn Überladung mit CSS-Formaten ohnehin stattfindet. SPAN, das semantisch nur auf das Vorhandensein einer Funktion hinweist, ist mir da bedeutend sympatischer, als z.B. EM zusätztlich noch mit der Klasse "msrtags" zu überladen, so wie du oben anführst. Um bei diesem Beispiel zu bleiben, müßte, um das gleiche Ergebnis wie bei  <SPAN class="msrtags"> zu erreichen, bei der Anwendung von EM die Klasse "msrtags" erweitert werden, statt
.msrtags { font-style:italic; color:#006666; } für die Anwendung mit SPAN, erfordert es die Definition in der folgenden Form
.msrtags { font-style:italic; color:#006666; font-weight:normal; } abzuändern!!!!!!!!!
Das ist für mich eine glatte Vergewaltigung eines voreingestellten HTML-Elements, was daran besser sein soll kann ich nicht erkennen. EM bringt normalerweise die Hervorhebung durch eine fetter Schriftdarstellung, in dem vorangegangen Beispiel ist diese Eigensschaft überladen worden, semantisch halte ich dies für völlig daneben.

Gruß f

[Detlef G.]

Hallo fireeye

... Irgendwo an einer anderen Stelle in diesem Thread habe ich ein Beweisführung gegen das Argument der Bedeutungslosigkeit von SPAN aufgebaut.

Nein!
Das hast du nicht.

Genauso gut könnte ich argumentieren, zwei Bleistiftstriche auf einer Wand
hätten eine besondere strukturelle oder bauphysikalische Bedeutung, weil der
Maler ja weiß (weil ich es ihm gesagt habe), dass die Wand dazwischen in
einer anderen Farbe gestrichen werden soll.
Wenn diese (dünne) Wand aber eine Verstärkung in Form einer tragenden Säule
enthält, dann hat diese Säule sehr wohl eine strukturelle, bauphysikalische
Bedeutung.
Jetzt kann ich den Maler (Browser) diese Säule so streichen lassen, entweder
wie er will (Browserstylesheet), oder ich sage ihm (mein CSS), wie ich das
Aussehen dieser Säule gern hätte.

Du hast recht, wenn du darstellst, daß EM genauso wie SPAN überladen wwerden könnte.

Was ist das für ein Quatsch?

CSS ist dafür gedacht, dass ich nicht auf das Browserstylesheet angewiesen
bin, sondern die HTML-Elemente entsprechend ihrer strukturellen Bedeutung
verwenden kann, auch wenn die optische Umsetzung in meinem Layout eine
andere sein soll, als sich die Browserprogrammierer für dieses Element
dachten.

Doch will sdas jemand wirklich? Nun mal eine ketzerische Frage: Würde es denn sinnvoll sein, EM so zu überladen, daß es bei der Ausführung die gleichen Eigenschaften von STRONG präsentieren würde?

Warum nicht?
Das hängt doch vom Layout ab.

Stelle dir ein sehr (vielleicht übertrieben) kontrastreiches Layout vor, die
verwendete Schriftart sieht kursiv total bescheiden aus.
Warum sollte dort für em (wichtigen Text) nicht font-weight:bold; ohne kursive
Schrift und für strong (stark betont) nicht font-weight:bold; font-size:1.2em;
verwendet werden oder eine andere dominierendere Schriftart?

Nein, es wird nicht sinnvoll sein und so wie wahsaga ausführt, ist es äußerst dümlich, das HTML kaputt zu formatieren.

Da gebe ich dir ein wenig Recht.

  
h1 {  
margin:0;   /* nur damit der IE nicht */  
padding:0;  /* auf dumme Gedanken kommt */  
display:inline;  
font-weight:normal;  
font-size:0.4em;  
}  

dürfte wohl selten sinnvoll sein. ;)

Das Überladen von HTML-Elementen ist da sinnvoll, wo es darum geht Eigenschaften hinzuzufügen, nicht aber eine voreingestellte Eigenschaft zu entfernen!

Das wiederum kann nicht so absolut gesagt werden.

Es kann bei einem entsprechen Design z.B. durchaus sinnvoll sein, dem <p>
seine Ränder (oben und unten) zu nehmen, und stattdessen die erste Zeile
einzurücken oder den ersten Buchstaben größer, fett oder/und in einer
anderen Farbe anzuzeigen.
Oder ein Text, der so aufgebaut ist, dass die Überschrift des Abschnitts
gleichzeitig die ersten Worte sind. Dort kann es durchaus sinnvoll sein,
dieser Überschrift ihre Ränder zu nehmen und sie zum Inlineelement zu
machen. Sie steht dann in der ersten Zeile des Textes, im Textfluss und wird
durch Schriftart, -farbe, -größe oder einfach bold hervorgehoben.

... Die Frage ob es sinnvoll ist, EM, STRONG oder andere gleichartige Elemente mit anderen Eigenschaften zu überladen, ...

Schon wieder dieses "überladen"

Es hat nichts mit Überladen zu tun, wenn du das Browserstylesheet mit für
dein Design sinnvollen Werten überschreibst. Es ist sogar oft notwendig,
weil diese in manchen Eigenschaften doch unterschiedlich sind.
(z.B. Verwendung von margin oder padding und die Größe dieser)

... orientiert sich innerhalb DIESER Diskussion doch an dem Argument der Verfügbarkeit von CSS auf diversen Browsern. Die Diskussion um die Verfügbarkeit von CSS gleicht einer Diskussion um die 10. Nachkommastelle bei einer Zahl, die mindestens 10 Stellen vor dem Komma hat.

Bei diesem deinen Projekt vielleicht, du kennst die Nutzer und ihre Browser.
Meist sind die Nutzer aber unbekannt.
Ich kenne z.B. Leute, die nur einen langsamen Internetzugang haben, die
haben Grafiken und CSS deaktiviert oder benutzen Lynx, damit sie schnell die
Informationen finden. Wenn sie dann eine interessante Seite gefunden haben,
gönnen sie sich den Luxus, CSS und Grafiken zu aktivieren.
Ob sie sich bei der Suche und Auswahl auf einer Seite ohne logisch
(semantisch) sinnvoller HTML-Struktur zurechtfinden ...
Es gibt auch verschiedene Sehstörungen, auf bestimmte Farben oder
Farbkontraste bezogen, nicht nur Blinde, die auf Screenreader oder
Braillezeile angewiesen sind. Auch diese dürften das Autorenstylesheet
deaktiviert haben oder eventuell deaktivieren.

Wenn ich einmal meine speziellen Bedürfnisse außer acht lasse und nur auf die Verfügbarkeit von CSS abstelle, dann verbietet sich jegliches Überladen von HTML-Elementen, somit wäre der Einsatz von SPAN absolut sinnlos.

Jain

Der Einsatz von <span> für irgendeine Bedeutung des damit Ausgezeichneten
ist sinnlos!
Die logische Struktur der Seite wird mit HTML-Elementen ausgezeichnet:
Was ist _die_ Überschrift? -> h1
Was eine untergeordnete Überschrift? -> h2
Was ist noch eine Überschrift, die dieser aber untergeordnet ist? -> h3
...
Was ist eine Liste? -> ul, ol, dl (je nachdem)
Was ein Absatz? -> p
Tabellarische Daten? -> table
Welche Teile des Fließtextes haben eine besondere Bedeutung?
Und wie stark bzw. welche? -> em, srong, code, cite, dfn ...

Also, welches HTML-Element entspricht am besten der logischen, der
strukturellen Bedeutung?
Absolut unabhängig davon, wie irgendein Browser dieses darstellt!

Damit ist das Dokument ganz ohne CSS benutzbar, übersichtlich und
verständlich (im Rahmen der Möglichkeiten des jeweiligen User-Agenten).

Nun kommen wir zum "Überladen".

Nun gibt es durch CSS die Möglichkeit, das Aussehen jedes Elementes so zu
verändern, dass es zum gewünschten Design passt. Dabei kann es passieren,
dass designbedingt bestimmte Teile der Seite eine andere Formatierung
benötigen, ohne dass genau diese bereits in einem eigenen  HTML-Element
eingeschlossen sind, dass mehrere Elemente zusammengefasst werden müssen,
um einen Angriffspunkt für CSS zu bekommen, oder dass irgendwelche Browser
ohne ein zusätzliches Element spinnen. Genau dann, und nur dann wird <span>
oder <div> verwendet.

... SPAN, das semantisch nur auf das Vorhandensein einer Funktion hinweist, ...

Es weist in der logischen Struktur des Dokumentes auf nichts hin.
Es sagt nur: "Hier zwischen den Strichen grün streichen."
Es hat mit dem HTML-Dokument und seinem Inhalt eigentlich nichts zu tun.

Das ist für mich eine glatte Vergewaltigung eines voreingestellten HTML-Elements, ...

Was hat irgendeine Voreinstellung mit _deinem_ Design zu tun?
Die Browser haben ähnliche Voreinstellungen für die Elemente, die sollen
verwendet werden, wenn _du_ nichts anderes sagst, oder wenn dem User die
Voreinstellung besser gefällt als dein Design, sonst nicht!

Auf Wiederlesen
Detlef

PS: Habe dieses Posting bereits 20:45 begonnen.

[MudGuard]

Hi,

Das Überladen von HTML-Elementen ist da sinnvoll, wo es darum geht Eigenschaften hinzuzufügen, nicht aber eine voreingestellte Eigenschaft zu entfernen!
Das wiederum kann nicht so absolut gesagt werden.

Insbesondere da dadurch CSS ad absurdum geführt würde.
Jedes Element hat für jede CSS-Eigenschaft jederzeit einen Wert (entweder aus irgendeinem browserinternen, webdesignergegebenen oder usergegebenen Stylesheet oder aus dem initial value), auch wenn einige Werte gerade keine Auswirkung haben (weil sie nur dann berücksichtigt werden dürfen, wenn andere Eigenschaften bestimmte Werte haben, z.B. wird left nur ausgewertet, wenn position nicht den Wert static hat).

Wann auch immer der Designer Werte für CSS-Eigenschaften angibt, werden also Werte überschrieben …

Da das Überschreiben von Werten laut fireeye nicht sinnvoll ist, muß er konsequenterweise komplett auf CSS verzichten.

Also, welches HTML-Element entspricht am besten der logischen, der
strukturellen Bedeutung?
Absolut unabhängig davon, wie irgendein Browser dieses darstellt!

Genau das ist es, was fireeye nicht versteht - daß diese (mehr oder weniger zufällige) Default-Darstellung eines Elementes keine Rolle bei der Auswahl des Elements spielt, sondern nur die strukturelle Bedeutung des Elements.

fireeye richtet sich NUR nach der (mehr oder weniger zufälligen) Default-Darstellung des Elementes - er will cite-Elemente benutzen, weil er kursive Schrift haben will (wenn es wirklich um kursive Schrift ginge - was fast nur in einer Abhandlung über Schriftsetzerei der Fall sein dürfte - , wäre i angebracht, welches explizit für kursive Schrift vorgesehen ist).

cu,
Andreas

[fireeye]

Hi Andreas

Ich glaube hier liegt ein Mißverständnis vor.

Das Überladen von HTML-Elementen ist da sinnvoll, wo es darum geht Eigenschaften hinzuzufügen, nicht aber eine voreingestellte Eigenschaft zu entfernen!

Da das Überschreiben von Werten laut fireeye nicht sinnvoll ist, muß er konsequenterweise komplett auf CSS verzichten.

Meine Ansicht: es ergibt keinen Sinn, z.B. ein B-Tag in der Art zu überschreiben, so daß die Eigenschaft "bold" nicht mehr zur Anwendung kommt. Mehr hab ich damit nicht ausdrücken wollen!

Genau das ist es, was fireeye nicht versteht - daß diese (mehr oder weniger zufällige) Default-Darstellung eines Elementes keine Rolle bei der Auswahl des Elements spielt, sondern nur die strukturelle Bedeutung des Elements.

Ich glaube nicht, daß z.B. die Eigenschaft "bold" bei dem B-Tag eine mehr oder weniger zufällige Default-Einstellung ist!
Wenn man darauf abstellen müßte, daß beim B-Tag die Default-Einstellung zufällig wäre, dann wäre der Einsatz unter purem HTML fragwürdig, weil nicht sichergestellt ist, daß auch beim x-beliebigen user agent die Textauszeichnung "bold" zur Anwendung kommt.
Oder sehe ich das falsch?

Gruß f

[Ingo Turski]

Hi,

Meine Ansicht: es ergibt keinen Sinn, z.B. ein B-Tag in der Art zu überschreiben, so daß die Eigenschaft "bold" nicht mehr zur Anwendung kommt.

in diesen konkreten Fall gebe ich Dir (ausnahmsweise) recht. ;-)
Denn <b> und auch <i> sind äußerst umstrittene Elemente. Denn sie geben dem Inhalt eben _keine_ Bedeutung, sondern legen implizit das Aussehen fest. Da das Aussehen aber Sache von CSS ist, wurde schon häufig die Abschaffung dieser beiden Elemente gefordert.

Hättest Du dagegen Bedenken geäußert, die Vorgaben für <em> oder <strong> zu ändern, könnte ich Dir nicht zustimmen. Die Bedeutung dieser Elemente ist die Betonung bzw. Hervorhebung. _Wie_ diese geschieht, darf der Seitenautor genauso festlegen wie die Größe der Überschriften oder die Abstände der Absätze.

freundliche Grüße
Ingo

[fireeye]

Hi Ingo

in diesen konkreten Fall gebe ich Dir (ausnahmsweise) recht. ;-)

Balsam für mein Ego... :-)

Hättest Du dagegen Bedenken geäußert, die Vorgaben für <em> oder <strong> zu ändern, könnte ich Dir nicht zustimmen. Die Bedeutung dieser Elemente ist die Betonung bzw. Hervorhebung. _Wie_ diese geschieht, darf der Seitenautor genauso festlegen wie die Größe der Überschriften oder die Abstände der Absätze.

Bin ja schon dabei, mein Verständnis dafür aufzuwerten.
Nur liege ich immer noch im Streit mit den Argumenten wegen des abschaltbaren CSS...
Scheint wohl mehr ein Richtungsstreit zu sein ;-)

Die Abstände von Absätzen regelt aber jeder user agent irgendwie anders. Besonders fällt mir das auf bei der Verwendung eines UL-Tags.

Gruß f

[daniel84]

Hallo fireeye,

Nur liege ich immer noch im Streit mit den Argumenten wegen des abschaltbaren CSS...

Wenn du mal das "abschaltbar" durch "nicht vorhanden" ersetzt, wird eine Schlichtung des "Streits" wohl schon greifbarer...

Gruss aus Luzern,
Daniel

[fireeye]

Hallo Daniel,

Wenn du mal das "abschaltbar" durch "nicht vorhanden" ersetzt, wird eine Schlichtung des "Streits" wohl schon greifbarer...

Nö, versteh ich nicht! Nicht vorhanden - das klingt für mich genauso wie: Du sollst CSS nicht verwenden!
Aber vielleicht bin ich ja auch nur zu fixiert.
Du solltest aber nicht vergessen, ich mache keine Seiten für die Öffentlichkeit, ich habe eine bestimmte Klientel, wo die Randbedingungen in bestimmten Grenzen vorhersehbar sind. Auch habe ich nicht vor, zukünftig öffentliche Websites zu coden. Das überlaß ich anderen.

Gruß f

[Ashura]

Hallo fireeye.

Wenn du mal das "abschaltbar" durch "nicht vorhanden" ersetzt, wird eine Schlichtung des "Streits" wohl schon greifbarer...

Nö, versteh ich nicht! Nicht vorhanden - das klingt für mich genauso wie: Du sollst CSS nicht verwenden!

Oder: Du hast kein CSS zur Verfügung;

Beispiel gefällig? -> Lynx

Auch habe ich nicht vor, zukünftig öffentliche Websites zu coden. Das überlaß ich anderen.

Also willst du grundsätzlich ausschließen, dass du _jemals_ etwas ins Internet stellst?

Gruß, Ashura

[fireeye]

Hallo Ashura.

Auch habe ich nicht vor, zukünftig öffentliche Websites zu coden. Das überlaß ich anderen.

Also willst du grundsätzlich ausschließen, dass du _jemals_ etwas ins Internet stellst?

Bin zur Zeit nur auf Besuch hier in Old Europe. Wenn ich hier fertig bin, dann leg ich mich 7000 km weiter südlich wieder in die Sonne :-)

Gruß f

[Ingo Turski]

Hi,

Nur liege ich immer noch im Streit mit den Argumenten wegen des abschaltbaren CSS...
Scheint wohl mehr ein Richtungsstreit zu sein ;-)

Nö, sehe ich nicht so. Wenn Du einen Text verfaßt, würdest Du ihn dann mit selbsterfundenen Begriffen spicken (zu denen es dann ein Anhang mit Erläuterungen gibt), oder würdest Du wo immer möglich Dich mit dem vorhandenen Vokabular begnügen?

Abgesehen vom abschaltbaren CSS - es gibt auch User-CSS. So könnte es sein, daß ein User gerne alle betonten Texte selbst in einer bestimmten Art hervorheben möchte. Auch diese Möglichkeit verwehrst Du, wenn Du einfach span verwendest.

Die Abstände von Absätzen regelt aber jeder user agent irgendwie anders. Besonders fällt mir das auf bei der Verwendung eines UL-Tags.

Ja leider. Und das fängt schon beim body an - manche Browser setzen ein margin, andere ein padding. Auch padding für html statt für body wäre denkbar. Vieles ist halt nicht genau festgelegt und den Browsern wird ein gewisser Spielraum gegeben. Aber auch das ist ein Punkt gegen Dich - denn um das Aussehen einer Seite selbst festzulegen, mußt Du etliche Vorgaben der Browser überschreiben.

freundliche Grüße
Ingo

[fireeye]

Hi Ingo

Abgesehen vom abschaltbaren CSS - es gibt auch User-CSS. So könnte es sein, daß ein User gerne alle betonten Texte selbst in einer bestimmten Art hervorheben möchte. Auch diese Möglichkeit verwehrst Du, wenn Du einfach span verwendest.

Wäre somit eine Chance dafür, wenn man was erzwingen wollte.... :-)

Aber auch das ist ein Punkt gegen Dich - denn um das Aussehen einer Seite selbst festzulegen, mußt Du etliche Vorgaben der Browser überschreiben.

How to do? Hab ich da was übersehen, was ich wissen sollte? Das Schema verwende ich in allen HTML-Seiten:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<html lang="de">
<head>
  <title>Kapitel&uuml;bersicht zur allgemeine Beschreibung der Ofenanlage</title>
  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
  <script language = "JavaScript1.5" src = "../../resources/js/guidebook.js" type = 'text/javascript'></script>
  <link rel="stylesheet" href="../../resources/css/MathModPage.css">
</head>
<body class="doc">

blablabla.....

</body>
</html>

Gruß f

[Ashura]

Hallo fireeye.

How to do? Hab ich da was übersehen, was ich wissen sollte? Das Schema verwende ich in allen HTML-Seiten:

Bei mir fängt mittlerweile nahezu jedes CSS so an:

*{margin:0;padding:0;} /* Nichts dem Zufall überlassen */  
html, body{height:100%;}

Darauf lässt sich immer bestens aufbauen.

Gruß, Ashura

[fireeye]

Hallo Ashura.

Bei mir fängt mittlerweile nahezu jedes CSS so an:

{margin:0;padding:0;} / Nichts dem Zufall überlassen */

html, body{height:100%;}

>   

Danke, schon geklaut und eingebaut :-)  
  
Aber klär mich bitte mal auf (aber Vorsicht, ich hab schon 2 Kinder!!!):  
Was bedeutet der Asterix (\*) in der Anweisung?  
  
Gruß f  

[Ashura]

Hallo fireeye.

Hallo Ashura.

Bei mir fängt mittlerweile nahezu jedes CSS so an:

{margin:0;padding:0;} / Nichts dem Zufall überlassen */

html, body{height:100%;}

> >   
> [...]  
> Was bedeutet der Asterix (\*) in der Anweisung?  
  
Das ist der Universalselektor. Das heißt, das damit auf alle Elemente im verwendeten Dokument zugegriffen werden kann.  
Mit dieser Zeile stelle ich immer zuallererst jegliche Abstände ab, so dass ich sie nachher für jedes Element so definieren kann, wie ich es haben möchte, ohne auf browserseitige Formatierungen Rücksicht nehmen zu müssen.  
  
  
Gruß, Ashura

-- 
Selfcode: sh:( fo:) ch:? rl:( br:^ n4:& ie:{ mo:) va:) de:> zu:) fl:( ss:| ls:[ js:|  
[30 Days to becoming an Opera8 Lover](http://tntluoma.com/opera/lover/8/) -- [Day 19: Notes](http://operalover.tntluoma.com/8/day_19_notes)  
Meine Browser: Opera 8.01 | Firefox 1.0.4 | Lynx 2.8.3 | Netscape 4.7 | IE 6.0  
[\[Deshalb frei! - Argumente pro freie Software\]](http://deshalbfrei.org/)

[fireeye]

Hallo Ashura.

Was bedeutet der Asterix (*) in der Anweisung?

Das ist der Universalselektor. Das heißt, das damit auf alle Elemente im verwendeten Dokument zugegriffen werden kann.
Mit dieser Zeile stelle ich immer zuallererst jegliche Abstände ab, so dass ich sie nachher für jedes Element so definieren kann, wie ich es haben möchte, ohne auf browserseitige Formatierungen Rücksicht nehmen zu müssen.

Danke, man lernt eben nie aus :-)

Gruß f

[at]

Hallo.

[code lang=css]*{margin:0;padding:0;} /* Nichts dem Zufall überlassen */

[...]

Darauf lässt sich immer bestens aufbauen.

Das bedeutet aber auch, dass man so alle Formular-Elemente formatiert. Und die Standardwerte bekommt man ja leider nicht wieder.
MfG, at

[Ashura]

Hallo at.

Das bedeutet aber auch, dass man so alle Formular-Elemente formatiert. Und die Standardwerte bekommt man ja leider nicht wieder.

Ich verstehe gerade nicht, wo das Problem liegen soll.
Welche Standardwerte meinst du, die ich nicht nachträglich selbst festlegen könnte?

Gruß, Ashura

[at]

Hallo.

Welche Standardwerte meinst du, die ich nicht nachträglich selbst festlegen könnte?

Gegenfrage: Was stellst du an, damit padding und margin zum Beispiel für <input>-Elemente wieder ihre Standardwerte annehmen?
MfG, at

[Ashura]

Hallo at.

Gegenfrage: Was stellst du an, damit padding und margin zum Beispiel für <input>-Elemente wieder ihre Standardwerte annehmen?

Ich definiere eigene. Ich lege die Innen- und Außenabstände individuell selbst fest.
Hierfür würde ja im Grunde die Selektion über das type-Attribut genügen, aber für den IE bedürfte es dann entweder einer Klasse für das umliegende Element oder eine ID / Klasse für das jeweilige input-Element.

Ich sehe nach wie vor kein Problem.

Gruß, Ashura

[Ingo Turski]

Hi,

Ich definiere eigene. Ich lege die Innen- und Außenabstände individuell selbst fest.
Hierfür würde ja im Grunde die Selektion über das type-Attribut genügen, aber für den IE bedürfte es dann entweder einer Klasse für das umliegende Element oder eine ID / Klasse für das jeweilige input-Element.

Dir ist klar, daß es weitaus mehr Aufwand ist, für wirklich alle Elemente wieder sinnvolle Werte zu definieren, als nur die Elemente zu formatieren, bei denen das tatsächlich erforderlich ist?
Mal abgesehen von den zusätzlich nötigen Klassen oder IDs.
Außerdem könnte es doch auch sein, daß sich gerade bei Formularelementen in bestimmten Browsern nicht alle Eigenschaften definieren lassen. Somit könntest Du hier mit Deinen Vorgaben scheitern.

freundliche Grüße
Ingo

[Ashura]

Hallo Ingo.

Dir ist klar, daß es weitaus mehr Aufwand ist, für wirklich alle Elemente wieder sinnvolle Werte zu definieren, als nur die Elemente zu formatieren, bei denen das tatsächlich erforderlich ist?

Ich habe dies deshalb integriert, weil ich mich nicht auf Initialwerte der Browser verlassen will, sondern selbst erst einmal für den Status Quo sorgen wollte. Inwieweit ich dadurch tatsächlich einen Mehraufwand habe, ist von meinem Layout und dem Umfang des Inhaltes abhängig.
Ich habe sowieso erst vor Kurzem damit angefangen. Wenn es sich nicht auszahlt, lasse ich es sowieso bald wieder bleiben.

Mal abgesehen von den zusätzlich nötigen Klassen oder IDs.

Hauptsächlich für den IE.

Außerdem könnte es doch auch sein, daß sich gerade bei Formularelementen in bestimmten Browsern nicht alle Eigenschaften definieren lassen. Somit könntest Du hier mit Deinen Vorgaben scheitern.

Sofern Klassen und IDs vergeben wurden (jedes einzelne Formularelement hat bei mir sowieso eine ID, da die Daten sonst nicht für das Empfängerskript zur Verarbeitung zur Verfügung stünden) muss ein Browser nur den Nachkommenselektor beherrschen, damit die Formatierungen in Kraft treten können.
Ganz alte Browser erhalten bei mir sowieso kein CSS, da ist mir die Gefahr der Unbrauchbarkeit aufgrund vermurkster Darstellung zu hoch.

Gruß, Ashura

[Ingo Turski]

Hi,

Außerdem könnte es doch auch sein, daß sich gerade bei Formularelementen in bestimmten Browsern nicht alle Eigenschaften definieren lassen. Somit könntest Du hier mit Deinen Vorgaben scheitern.

Sofern Klassen und IDs vergeben wurden

Das hat damit nichts zu tun.
Was ist, wenn ein sich Browser den voreingestellten margin nicht überschreiben läßt und Du dann mit einem padding ankommst, der für margin:0 gedacht ist?

freundliche Grüße
Ingo

[Ashura]

Hallo Ingo.

Was ist, wenn ein sich Browser den voreingestellten margin nicht überschreiben läßt und Du dann mit einem padding ankommst, der für margin:0 gedacht ist?

Dann wird das Element eben etwas breiter, auch kein Problem. Mein Design ist insofern flexibel genug, um diese Kleinigkeit ausgleichen zu können.

(Sicher gibt es Grenzen, aber dann könnte man ja auch gleich sagen, dass mein Layout bei 500%-iger Vergrößerung nicht mehr benutzbar ist.)

Gruß, Ashura

[at]

Hallo.

Dann wird das Element eben etwas breiter, auch kein Problem. Mein Design ist insofern flexibel genug, um diese Kleinigkeit ausgleichen zu können.

In Verbindung mit Schaltflächen, die sich in gar nicht verändern lassen, etwa denjenigen zum auswählen einer Datei, fallen solche Abweichungen aber leider ins Auge, und zwar negativ.
MfG, at

[at]

Hallo.
Okay, du kannst meine Frage also nicht beantworten. Gut, damit hatte ich gerechnet. Es bleibt also bei meiner Warnung vor deiner Vorgehensweise.
MfG, at

[Ashura]

Hallo at.

Okay, du kannst meine Frage also nicht beantworten.

Nein, weil ich das Wiederherstellen der Standardwerte nicht für notwendig erachte.

Es bleibt also bei meiner Warnung vor deiner Vorgehensweise.

Ich werde daran denken, wenn Probleme auftauchen sollten.

Gruß, Ashura

[Ashura]

Hallo.

Okay, du kannst meine Frage also nicht beantworten.

Nein, weil ich das Wiederherstellen der Standardwerte nicht für notwendig erachte.

Und dass ich die Standardwerte unmöglich wiederherstellen kann, wissen wir beide.
Was einmal überschrieben wurde, kann nicht wiederhergestellt werden.

Gruß, Ashura

[at]

Hallo.

Und dass ich die Standardwerte unmöglich wiederherstellen kann, wissen wir beide.
Was einmal überschrieben wurde, kann nicht wiederhergestellt werden.

Eben, und daher mahne ich zur Vorsicht. Nicht mehr und nicht weniger.
MfG, at

[Ingo Turski]

Hi,

Aber auch das ist ein Punkt gegen Dich - denn um das Aussehen einer Seite selbst festzulegen, mußt Du etliche Vorgaben der Browser überschreiben.

How to do? Hab ich da was übersehen, was ich wissen sollte? Das Schema verwende ich in allen HTML-Seiten:

<body class="doc">

hinter der Klasse (wieso eigentlich Klasse?) verbergen sich doch sicherlich die ersten CSS-Eigenschaften, oder? Mit einigen dürftest Du auch Browser- bzw. Uservorgaben überschreiben. Weiter geht es dann mit den Eigenschaften für die Elemente mit innewohnender Bedeutung.

freundliche Grüße
Ingo

[MudGuard]

Hi,

Ich glaube nicht, daß z.B. die Eigenschaft "bold" bei dem B-Tag eine mehr oder weniger zufällige Default-Einstellung ist!

Doch. Bei b ist es halt etwas weniger zufällig.

Rendering of font style elements depends on the user agent. The following is an informative description only.
[...]
    B: Renders as bold text style.

Aber auch für b ist es nicht vorgeschrieben, daß es tatsächlich bold dargestellt wird.

Du wolltest doch aber cite-Elemente benutzen, weil damit der Text kursiv dargestellt wird.
Dafür, daß cite kursiv dargestellt wird, gibt es aber keinerlei Hinweis im HTML-Standard.

cu,
Andreas

[fireeye]

Hallo Detlef

... Irgendwo an einer anderen Stelle in diesem Thread habe ich ein Beweisführung gegen das Argument der Bedeutungslosigkeit von SPAN aufgebaut.

Nein!
Das hast du nicht.

Da gibt es einen Hintergrund, den du so nicht kennen kannst. Ich habe ja nun im Laufe der Jahre etliche Programmiersprachen erlernt. Habe auch selber Programme für den Mac zum industriellen Einsatz geschrieben. Das mal so vorab. Bei mir hat eine Funktion (wie z.B. auch in Javascript) eine _Bedeutung_, die ich mit deren Wirkung assoziiere. HTML-Tags habe ich bisher in dem Sinne als Funktionen angesehen, deren Bedeutung ich gleichfalls mit der Wirkung der Tags verbunden habe. Die Auschließlichkeit meiner Ansicht mag falsch sein, aber soweit hergeholt ist sie dennoch nicht, wenn es sich auf die sichtbare Wirkung reduzieren läßt. Wie auch anderswo lassen sich Bedeutung/Wirkung über die Namen der Funktionen assoziieren. Ich beginne zu verstehen, daß im Bereich des HTML der Begriff Bedeutung abstrakter ist, als von mir in dieser einfachen Form bisher angenommen wurde.

Du hast recht, wenn du darstellst, daß EM genauso wie SPAN überladen wwerden könnte.

Was ist das für ein Quatsch?

Quatsch? grummel grummel Nö, seh ich nicht so, alle können mit den gleichen Universalattributen "überladen" werden!!!

Nun kommen wir zum "Überladen".

In allen objektorientierten Sprachen ist das "Überladen" ein gängiger Begriff, er ist wahrscheinlich bei HMTL nicht im richtigen Kontext verwendet, aber das Ergebnis der Handlungsweise präsentiert sich nach außen in vergleichbarer Form. Also bitte nicht so eng sehen :-)

Aber vielen Dank für deine Ausführungen

Gruß f

[MudGuard]

Hi,

Wozu willst Du überhaupt die spans um die Tabellen haben?
Ich bin schon ( Wenn ich das sagen darf;-) ) profi in Frontend,

Aha.

aber das Problem ist, daß ich die Spans brauche für ein Intranet-Tool, das halt mit PHP dann programmiert wird.

Als Profi setzt Du auf Konstruktionen, die gegen die Spezifikationen verstoßen, wo man sich also nicht drauf verlassen kann, daß sie in der nächsten Browsergeneration noch so interpretiert werden wie jetzt?

Und wenn das PHP-Tool erst noch programmiert wird, sollte es doch kein Problem sein, daß so zu machen, daß die span-Elemente nicht notwendig sind.

Es m+üssen spans sein. Leider ;-(

Nutze float für die Tabellen.
???

Als Profi im Frontend weißt Du nicht mal, daß es eine CSS-Eigenschaft namens float gibt?

cu,
Andreas