Zellhöhe mit <hr> Linie

[Hacke Peter]

Mahlzeit Zusammen,

ich habe ein Problem mit der Zeilenhöhe, wenn ein Linie mittels <hr noshade> in einer Zelle eingebettet wird.
In nachfolgendem Beispiel soll die Linie direkt unter dem Text platziert werden. Ich bekomme die Zeilenhöhe nicht reguliert. Gibts dafür eine Lösung ?

Beispiel:

<table width="100%" border="1" cellspacing="0" cellPadding="0">
<tr height="1">
<td width="100%">Text</td>
</tr>
<tr height="1">
<td width="100%"><hr noshade="noshade"></td>
</tr>
</table>

Vielen Dank

Hackers Peter

[Cheatah]

Hi,

ich habe ein Problem mit der Zeilenhöhe, wenn ein Linie mittels <hr noshade> in einer Zelle eingebettet wird.

dann ist das doch der ideale Augenblick, um endlich das Tabellenlayout des letzten Jahrtausends zu eliminieren, meinst Du nicht?

In nachfolgendem Beispiel soll die Linie direkt unter dem Text platziert werden.

Also ein border-bottom auf das <p>-Element angewendet, in dem sich der Text befindet. Oder welche Struktur auch immer semantisch sinnvoll ist.

Cheatah

[Gernot Back]

Hallo Cheatah,

dann ist das doch der ideale Augenblick, um endlich das Tabellenlayout des letzten Jahrtausends zu eliminieren, meinst Du nicht?

Oh, ob es hier um reines Tabellenlayout geht, wage ich anhand Hacke Peters Code-Fragment nicht zu beurteilen, vorausgesetzt es war tatsäächlich nur ein Fragment, um den Blick auf sein Problem zu konzentrieren.

In nachfolgendem Beispiel soll die Linie direkt unter dem Text platziert werden.

Also ein border-bottom auf das <p>-Element angewendet, in dem sich der Text befindet. Oder welche Struktur auch immer semantisch sinnvoll ist.

... und das ginge natürlich auch in Bezug auf ein TD- oder TR-Element.

Strukturell wenig sinnvoll ist es natürlich, ein HR-Element als einzigen "Inhalt" in einer Tabellenzelle zu haben, es sei denn, wenn man gerade mit dem horizontalen Strich verdeutlichen will, dass es in dieser Spalten-/Zeilenkombination halt kein Angebot gibt. Dann sollte das aber auch durch eine Tabellenzeilenhöhe von mindestens 1em und durch einen Abstand des HR-Elements zum umgebenden TD-Elternelement klar werden.

Unmöglich ist es aber nicht, die Mindesthöhe einer Tabellenzelle abzuschalten, auch wenn spätestens das dann offensichtlich nur noch Gestaltungszwecken "von hinten durch die Brust ins Auge" dient:

  
table {  
  width:100%;  
  border:solid 1px black;  
  border-collapse:collapse;  
}  
  
td {  
  border:solid 1px black;  
}  
  
td hr {  
  border:solid #FA0;  
  border-width:1px 0 0 0;  
  margin:0;  
}  
  
* html td hr {  
  position:absolute;  
}

Gruß Gernot

[Efchen]

es sei denn, wenn man gerade mit dem horizontalen Strich verdeutlichen will, dass es in dieser Spalten-/Zeilenkombination halt kein Angebot gibt.

Ich möchte behaupten, dass das nicht dem semantischen Sinn einer *strukturellen* Trennlinie entspricht.

Oder?

[Gernot Back]

Hallo Efchen,

es sei denn, wenn man gerade mit dem horizontalen Strich verdeutlichen will, dass es in dieser Spalten-/Zeilenkombination halt kein Angebot gibt.

Ich möchte behaupten, dass das nicht dem semantischen Sinn einer *strukturellen* Trennlinie entspricht.

Oder?

Hältst du 20 — hintereinander für sinnvoller?

Meinem HR-Element kann ich wenigstens ein Attribut title="kein Angebot" verpassen.

Gruß Gernot

[Efchen]

Hältst du 20 — hintereinander für sinnvoller?

Eines reicht doch auch schon.
Unter einem <hr> verstehe ich einen inhaltlichen Bruch. Nicht ein inhaltliches Minus oder ein inhaltlicher Strich.

Meinem HR-Element kann ich wenigstens ein Attribut title="kein Angebot" verpassen.

Das kannst Du bei Deinem <p>, in den Du den Strich stellst, auch.

[Gernot Back]

Hallo Efchen,

Hältst du 20 — hintereinander für sinnvoller?

Eines reicht doch auch schon.
Unter einem <hr> verstehe ich einen inhaltlichen Bruch. Nicht ein inhaltliches Minus oder ein inhaltlicher Strich.

Meinem HR-Element kann ich wenigstens ein Attribut title="kein Angebot" verpassen.

Das kannst Du bei Deinem <p>, in den Du den Strich stellst, auch.

Sicher, nur welche Styles empfiehlst du darüber hinaus für dieses P-Element, wenn der darin enthaltene einfache — die 20fache Länge bei einfacher Höhe haben soll?

Gruß Gernot

[Efchen]

Sicher, nur welche Styles empfiehlst du darüber hinaus für dieses P-Element, wenn der darin enthaltene einfache — die 20fache Länge bei einfacher Höhe haben soll?

Hä?

Ich dachte, wir reden nur darüber, ob eine <hr> sinnvoll zu benutzen ist, wenn man einen Strich darstellen will, der zeigen soll, dass "kein Angebot" vorliegt.

Ich klink mich besser aus.

[Gernot Back]

Hallo Efchen,

Ich dachte, wir reden nur darüber, ob eine <hr> sinnvoll zu benutzen ist, wenn man einen Strich darstellen will, der zeigen soll, dass "kein Angebot" vorliegt.

Ganz genau, das ist ja meine Rede: Gerade da halte ich das HR-Element für besonders sinnvoll. Ich würde eigentlich denken, dass es auch deinem und Cheatahs Bestreben nach Trennung von Inhalt und Gestaltung viel mehr zuwiderläuft, ein HR-Element als Trenner zu missbrauchen, denn das kann man ja durch Zuweisung entsprechender Margins, Paddings und Borders an das aktuelle oder folgende Element immer viel besser machen.

Welche strukturelle Bedeutung ein HR-Element haben soll, wird mir im Übrigen auch durch die entsprechende W3C-Empfehlung nicht klar.

Ich klink mich besser aus.

Schade, jetzt wo's interessant wird ...

Gruß Gernot

[Efchen]

Ich würde eigentlich denken, dass es auch deinem und Cheatahs Bestreben nach Trennung von Inhalt und Gestaltung viel mehr zuwiderläuft, ein HR-Element als Trenner zu missbrauchen

Ehm...für mein Befinden IST ein <hr> ein Trenner. Ein struktureller Trenner, der einen Bruch zwischen zwei Elementen einfügt.

denn das kann man ja durch Zuweisung entsprechender Margins, Paddings und Borders an das aktuelle oder folgende Element immer viel besser machen.

Das wäre ja reine Optik und würde im Kontext keinen Bruch erzeugen.

Offensichtlich haben wir irgendwie ein bisschen aneinander vorbeigeredet :-)

[Gernot Back]

Hallo Efchen,

Ehm...für mein Befinden IST ein <hr> ein Trenner. Ein struktureller Trenner, der einen Bruch zwischen zwei Elementen einfügt.

Anders als bei DIV-(=Division; engl. für "Abteilung") und SPAN-Elementen wird das aber in der W3C-Empfehlung bei HR-Elementen nicht explizit so beschrieben:

"The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents."

denn das kann man ja durch Zuweisung entsprechender Margins, Paddings und Borders an das aktuelle oder folgende Element immer viel besser machen.

Das wäre ja reine Optik und würde im Kontext keinen Bruch erzeugen.

Doch, die ergeben sich ja aus den (gruppierenden) Elementen selbst, denen ich diese Formatierungen zuweise:

Ein P-Element (Paragraph) ist ein Absatz, und der setzt sich von anderen Absätzen per definitionem ab.

Offensichtlich haben wir irgendwie ein bisschen aneinander vorbeigeredet :-)

Naja vielleicht nicht ganz; um zu unterstreichen, dass man Fünfe auch mal gerade sein lassen kann, spiel ganz gern auch mal den Teufelsadvokaten.

Gruß Gernot

[Efchen]

Ehm...für mein Befinden IST ein <hr> ein Trenner. Ein struktureller Trenner, der einen Bruch zwischen zwei Elementen einfügt.

"The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents."

Da steht aber nicht, dass ein div oder span dazu da ist, einen strukturellen Bruch in den Inhalt zu bringen, also eine Trennung. "a generic mechanism for adding structure" ist hier ja offensichtlich das Gruppieren, zumal das W3C schreibt, "Grouping elements".

Das wäre ja reine Optik und würde im Kontext keinen Bruch erzeugen.
Doch, die ergeben sich ja aus den (gruppierenden) Elementen selbst, denen ich diese Formatierungen zuweise:
Ein P-Element (Paragraph) ist ein Absatz, und der setzt sich von anderen Absätzen per definitionem ab.

Ja, aber zwei aufeinanderfolgende Absätze gehören normalerweise dazu. Ein <hr> trennt diese Absätze voneinander. Denke dabei an die Trennlinien in Büchern, z.B. "* * *"

[Gernot Back]

Hallo Efchen,

"The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents."

Da steht aber nicht, dass ein div oder span dazu da ist, einen strukturellen Bruch in den Inhalt zu bringen, also eine Trennung. "a generic mechanism for adding structure" ist hier ja offensichtlich das Gruppieren, zumal das W3C schreibt, "Grouping elements".

Und was ist das anderes als ein struktureller Bruch?

Das wäre ja reine Optik und würde im Kontext keinen Bruch erzeugen.

Übrigens genau deswegen handelt das W3C HR-Elemente in einem HTML-Dokument ab, das sie graphics.html getauft haben, reine Optik!

Ein P-Element (Paragraph) ist ein Absatz, und der setzt sich von anderen Absätzen per definitionem ab.

Ja, aber zwei aufeinanderfolgende Absätze gehören normalerweise dazu. Ein <hr> trennt diese Absätze voneinander. Denke dabei an die Trennlinien in Büchern, z.B. "* * *"

Webdesign ist nicht Printdesign; Im Webdesign halte ich umschließende Elemente für das zur Gruppierung von anderen Elementen einzig Sinnvolle.

Gruß Gernot

[Efchen]

Da steht aber nicht, dass ein div oder span dazu da ist, einen strukturellen Bruch in den Inhalt zu bringen, also eine Trennung. "a generic mechanism for adding structure" ist hier ja offensichtlich das Gruppieren, zumal das W3C schreibt, "Grouping elements".

Und was ist das anderes als ein struktureller Bruch?

Kein Bruch, eine Trennung. So wie nach einem Absatz. Ein Bruch ist no0ch ne Stufe mehr.

Ja, aber zwei aufeinanderfolgende Absätze gehören normalerweise dazu. Ein <hr> trennt diese Absätze voneinander. Denke dabei an die Trennlinien in Büchern, z.B. "* * *"

Webdesign ist nicht Printdesign; Im Webdesign halte ich umschließende Elemente für das zur Gruppierung von anderen Elementen einzig Sinnvolle.

Schwieriger Satz. Zum Gruppieren hältst Du nur umschießende Elemente für sinnvoll?

So langsam weiß ich, worauf Du hinaus willst.

Du würdest nicht
  <p>Lorem ipsum</p>
  <p>dolor sit amet</p>
  <hr>
  <p>Lorem ipsum</p>
machen, sondern
  <div style="border-bottom:1px dashed;">
    <p>Lorem ipsum</p>
    <p>dolor sit amet</p>
  </div>
  <div>
    <p>Lorem ipsum</p>
  </div>

Naja, wenn das W3C ein <hr> offensichtlich doch als rein optisch einordnet, dann sind wir wohl am Ende der Diskussion angekommen. Dann ist ein <hr> genauso wie ein <b> nicht mehr einsatzfähig.

[Gernot Back]

Hallo Efchen,

Webdesign ist nicht Printdesign; Im Webdesign halte ich umschließende Elemente für das zur Gruppierung von anderen Elementen einzig Sinnvolle.

Schwieriger Satz. Zum Gruppieren hältst Du nur umschießende Elemente für sinnvoll?

So langsam weiß ich, worauf Du hinaus willst.

Du würdest nicht
  <p>Lorem ipsum</p>
  <p>dolor sit amet</p>
  <hr>
  <p>Lorem ipsum</p>
machen, sondern
  <div style="border-bottom:1px dashed;">
    <p>Lorem ipsum</p>
    <p>dolor sit amet</p>
  </div>
  <div>
    <p>Lorem ipsum</p>
  </div>

Nein, wie gesagt spiele ich gerne den Teufelsadvokaten: Aber ja, wenn man das mit dem strukturellen Markup auf die Spitze treiben will, dann ist erstere die einzig konsequente Variante.

Im Zweifel würde ich mir das Leben aber nicht immer ganz so schwer machen und schrecke deswegen in manchen Fällen sogar auch vor Tabellenlayout nicht zurück.

Um an meinen Ausgangspunkt zurückzukommen: Tabellenlayout kann genauso "von hinten durch die Brust ins Auge" sein wie manche Lösung, die krampfhaft versucht, es zu vermeiden.

Da bin ich Pragmatiker.

Gruß Gernot

[Efchen]

Du würdest nicht
  <p>Lorem ipsum</p>
  <p>dolor sit amet</p>
  <hr>
  <p>Lorem ipsum</p>
machen, sondern
  <div style="border-bottom:1px dashed;">
    <p>Lorem ipsum</p>
    <p>dolor sit amet</p>
  </div>
  <div>
    <p>Lorem ipsum</p>
  </div>

Nein, wie gesagt spiele ich gerne den Teufelsadvokaten: Aber ja, wenn man das mit dem strukturellen Markup auf die Spitze treiben will, dann ist erstere die einzig konsequente Variante.

Jetzt sprichst Du wieder für die erste Variante? Du machst mich wahnsinnig :-)
Und ich dachte, jetzt hätte ich kapiert, dass Du die zweite Variante für einzig sinnvoll hältst, weil Du überzeugt bist, dass <hr> eine rein optische Sache ist.

Argl...es ist zu heiß für sowas ;-)

Im Zweifel würde ich mir das Leben aber nicht immer ganz so schwer machen und schrecke deswegen in manchen Fällen sogar auch vor Tabellenlayout nicht zurück.

Das gibts bei mir nicht.

Um an meinen Ausgangspunkt zurückzukommen: Tabellenlayout kann genauso "von hinten durch die Brust ins Auge" sein wie manche Lösung, die krampfhaft versucht, es zu vermeiden.

Tabellenlayout ist für mich nur ein Hack, der nicht mehr nötig ist. Layout mit CSS ist die einzig verfügbare Methode für mich.

[Gernot Back]

Hallo Efchen,

Das gibts bei mir nicht.

Um an meinen Ausgangspunkt zurückzukommen: Tabellenlayout kann genauso "von hinten durch die Brust ins Auge" sein wie manche Lösung, die krampfhaft versucht, es zu vermeiden.

Tabellenlayout ist für mich nur ein Hack, der nicht mehr nötig ist. Layout mit CSS ist die einzig verfügbare Methode für mich.

Na ich habe da vor kurzem mal etwas gebastelt (war auch nicht für mich).

Versuch das doch mal ohne Tabellenlayout:

http://www.sprachlernspiele.de/selftests/tablelayout/complex2.html

Vielleicht ist das sogar machbar, aber was wollen wir wetten, dass dein Quellcode dann noch viel umfänglicher wird, als dieser hier ohnehin schon ist?

Gruß Gernot

[Efchen]

Versuch das doch mal ohne Tabellenlayout:

Nee, lieber nicht :-)

Aber das sollte schon gehen, mit schrecklicher div-Suppe. Lesbar ist der Code dann allerdings auch nicht mehr, aber wenigstens ist er in Sachen Barrierefreiheit besser als die Tabelle.

Wobei...wenn die Rahmen nicht mehrfarbig sein müssen, kann man das ja mit border-radius wunderbar machen, dann sollte es auch keine div-Suppe mehr werden :-)

[Ashura]

Hallo Gernot.

Versuch das doch mal ohne Tabellenlayout:

http://www.sprachlernspiele.de/selftests/tablelayout/complex2.html

Funktioniert übrigens im Opera 8.02 nicht mehr. *g*

Zum Vergleich noch einmal der alte Screenshot (Version 8.0 denke ich):

(Die beiden linken Ecken waren am Ende deine Bastelarbei korrekt an Ort und Stelle, nur hatte ich keinen neuen Screenshot gemacht.)

Einen schönen Freitag noch.

Gruß, Ashura

[Gernot Back]

Hallo Ashura,

Versuch das doch mal ohne Tabellenlayout:

http://www.sprachlernspiele.de/selftests/tablelayout/complex2.html

Funktioniert übrigens im Opera 8.02 nicht mehr. *g*

In Opera 8.01 sieht es super aus!

Diese Browserversionen sind noch mal mein Tod!

Gruß Gernot

[Ashura]

Hallo Gernot.

Funktioniert übrigens im Opera 8.02 nicht mehr. *g*

In Opera 8.01 sieht es super aus!

http://www.sprachlernspiele.de/selftests/tablelayout/operascreen.gif

Sehr schön. Funktioniert wieder...

Bis zu Opera 8.03. >;-)

Diese Browserversionen sind noch mal mein Tod!

Weiterentwicklung muss sein. (Auch wenn ich ehrlich gesagt nicht weiß, was sich hier so gravierend von V. 8.0 zu v. 8.02 geändert hat...)

Einen schönen Freitag noch.

Gruß, Ashura

[Gunnar Bittersmann]

Ein <hr> trennt diese Absätze voneinander. Denke dabei an die Trennlinien in Büchern, z.B. "* * *"

Efchen, das sehe ich genauso.

Webdesign ist nicht Printdesign;

Gernot, das auch.

Im Webdesign halte ich umschließende Elemente für das zur Gruppierung von anderen Elementen einzig Sinnvolle.

Das nicht! Und das W3C tut es auch nicht.

Naja, wenn das W3C ein <hr> offensichtlich doch als rein optisch einordnet,

Das schon …

Dann ist ein <hr> genauso wie ein <b> nicht mehr einsatzfähig.

… deshalb wird es XHTML 2 kein hr mehr geben. Aber separator.

“Separators: in previous versions of HTML, the hr element was used to separate sections of a text from each other. In retrospect, the name hr (for horizontal rule) was misleading, because an hr was neither necessarily horizontal (in vertical text it was vertical), nor necessarily a rule (books often use other typographical methods such as a line of three asterisks to represent separators, […]).”

Aha, "* * *"

“([…] and style sheets can be used to give you this freedom). In order to emphasize its structuring nature, to make it more widely usable, and to make it clearer that it has no essential directionality, hr has been renamed separator.” [XHTML2 §1,2]

Live long and prosper,
Gunnar

[Gernot Back]

Hallo Gunnar,

… deshalb wird es XHTML 2 kein hr mehr geben. Aber separator.

“Separators: in previous versions of HTML, the hr element was used to separate sections of a text from each other. In retrospect, the name hr (for horizontal rule) was misleading, because an hr was neither necessarily horizontal (in vertical text it was vertical), nor necessarily a rule (books often use other typographical methods such as a line of three asterisks to represent separators, […]).”

Du wirst dir denken können, dass ich das für eine falsche Entscheidung des W3C halte, so sie sich denn durchsetzt.

Meinen Einfluss würde ich jedenfalls aus den genannten Gründen dagegen setzen, so ich denn welchen habe. Ich mache ihn ja leider bisher nur in diesem Forum geltend, aber vielleicht überlege ich mir das mal anders. Des Englischen bin ich ja leidlich mächtig!

Gruß Gernot

[Gunnar Bittersmann]

Separators
Du wirst dir denken können, dass ich das für eine falsche Entscheidung des W3C halte, so sie sich denn durchsetzt.

Gernot,
Dann schau die mal dieses Theater an:

Ein Stück in vier Akten

1. Akt

Alice: Foo?
  Bob: Bar.

2. Akt

Alice: Bar?
  Bob: Baz.

* * *

3. Akt

Alice: Foo?
  Bob: Baz.

4. Akt

Alice: Baz?
  Bob: Quz!

In XHTML 2:

~~~html <h1>Ein Stück in vier Akten</h1>

<h2>1. Akt</h2>
  <dl>
    <dt>Alice</dt><dd>Foo?</dd>
    <dt>Bob</dt><dd>Bar.</dd>
  </dl>

<h2>2. Akt</h2>
  <dl>
    <dt>Alice</dt><dd>Bar?</dd>
    <dt>Bob</dt><dd>Baz.</dd>
  </dl>

<separator/>

<h2>3. Akt</h2>
  <dl>
    <dt>Alice</dt><dd>Foo?</dd>
    <dt>Bob</dt><dd>Baz.</dd>
  </dl>

<h2>4. Akt</h2>
  <dl>
    <dt>Alice</dt><dd>Baz?</dd>
    <dt>Bob</dt><dd>Quz!</dd>
  </dl>

  
Du würdest also meinen, die Pause zwischen 2. und 3. Akt verdient keine Auszeichnung in HTML? Sie wäre nur ein optischer Effekt und als solches mit CSS zu realisieren? Gehört die Pause dann zum 2. oder zum 3. Akt dazu? Und warum genau zu diesem?  
  
Live long and prosper,  
Gunnar

-- 
„Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen Versuchs, sie zu erwerben.“ (Albert Einstein)

[Gernot Back]

Hallo Gunnar,

Du würdest also meinen, die Pause zwischen 2. und 3. Akt verdient keine Auszeichnung in HTML? Sie wäre nur ein optischer Effekt und als solches mit CSS zu realisieren? Gehört die Pause dann zum 2. oder zum 3. Akt dazu? Und warum genau zu diesem?

Nein, im Gegenteil; natürlich können auch Trenner ihre Berechtigung haben.

Ich bin nur entschieden dagegen, dass man einer horizontalen Linie andere Bedeutungen von vornherein abspricht.

Gruß Gernot

[Efchen]

Nein, im Gegenteil; natürlich können auch Trenner ihre Berechtigung haben.

Ich bin nur entschieden dagegen, dass man einer horizontalen Linie andere Bedeutungen von vornherein abspricht.

Zumal der <separator /> wohl auch nicht mehr nur noch eine horizontale Trennung sein soll, wenn ich mich an die Sezifikation noch richtig erinnere. (Ich wusste doch, dass ich das mit den "* * *" irgendwo gelesen habe ;-)

[at]

Hallo.
Igitt, Definitionslisten für Dialoge.
MfG, at

[Gernot Back]

Hallo at,

Igitt, Definitionslisten für Dialoge.

Das ist aber eine der vom W3C explizit vorgeschlagenen Anwendungen für sogenannte Definitionslisten.

Scroll an diesem Anker mal zwei Zeilen hoch.

Gruß Gernot

[at]

Hallo.

Igitt, Definitionslisten für Dialoge.

Das ist aber eine der vom W3C explizit vorgeschlagenen Anwendungen für sogenannte Definitionslisten.

Das weiß ich, und es war auch schon das eine oder andere Mal Anlass für eine Diskussion. Ich bin der Meinung, dass man Definitionslisten in diesem Fall nur deshalb einsetzt, weil sie zufällig eine gewisse grafische Ähnlichkeit mit Dialogen haben. Semantisch finde ich geordnete Listen sehr viel besser, denn der Sinn eines Dialoges ergibt sich ja zu einem nicht unbedeutenden Maß auch aus der Reihenfolge. Ich verwende jedenfalls eine Kombination aus <ol>, <li>, <cite>, <blockquote> und <p>. Das mag manchen als zuviel des Guten erscheinen, bringt es aber meines Erachtens auf den Punkt.

Scroll an diesem Anker mal zwei Zeilen hoch.

Vielleicht wird dieser Fehler ja irgendwann korrigiert.
MfG, at

[Cheatah]

Hi,

Ehm...für mein Befinden IST ein <hr> ein Trenner. Ein struktureller Trenner, der einen Bruch zwischen zwei Elementen einfügt.
Anders als bei DIV-(=Division; engl. für "Abteilung") und SPAN-Elementen wird das aber in der W3C-Empfehlung bei HR-Elementen nicht explizit so beschrieben:

der Grund, weshalb bei <div> und <span> die "structure" genannt wird, ist das Hervorheben der Tatsache, dass sie "generic" ist. Man muss nicht bei jedem Strukturelement - also bei jedem Element - erwähnen, dass er Teil der Struktur ist, genauso wenig wie man bei jedem Buchstaben des Alphabets dazu sagen muss, dass er zur Erzeugung von Text dienen kann.

Ein P-Element (Paragraph) ist ein Absatz, und der setzt sich von anderen Absätzen per definitionem ab.

Nein. *Nichts* in HTML sagt, wie etwas dargestellt wird. Es gibt allenfalls Darstellungen, die sich anbieten - wie auch z.B. Fettdruck bei <strong>. Damit ist der Sinn von <strong> aber noch lange nicht, etwas fett darszustellen, genau so wenig wie es der Sinn von <hr> ist, eine durchgezogene Linie zu erzeugen. Dazu ist die border-Eigenschaft von CSS da. Um genau zu sein, bietet sich für <hr> ganz pauschal der CSS-Code

hr { display: none; }

an; gegenteilige Codes dürften eher die Ausnahme sein.

Cheatah

[Efchen]

Ein P-Element (Paragraph) ist ein Absatz, und der setzt sich von anderen Absätzen per definitionem ab.

Nein. *Nichts* in HTML sagt, wie etwas dargestellt wird.

Jetzt muss ich mich auf die Seite von Gernot gegen Dich wenden :-)
Ich denke, Du hast ihn in Deinem Trennungswahn ;) falsch verstanden.
Natürlich heben sich Textabsätze voneinander ab. Nicht optisch. Inhaltlich. Es ist immer ein kleiner Gedankenbruch dabei. Sonst würde man den gesamten Text in EIN <p> stellen. Dass das kein optisches Verhalten ist, merkt man ja beim Vorlesen. Ob der Absatz nun groß ist, oder klein, man macht eine Pause.

genau so wenig wie es der Sinn von <hr> ist, eine durchgezogene Linie zu erzeugen.

Jetzt sind wir aber gespannt, WAS der Sinn von <hr> ist. Um so eine Aussage hast Du dich perfekt gedrückt! :-)

[Gernot Back]

Hallo Cheatah,

Ein P-Element (Paragraph) ist ein Absatz, und der setzt sich von anderen Absätzen per definitionem ab.

Nein. *Nichts* in HTML sagt, wie etwas dargestellt wird.

Ich sprach auch nicht von der Darstellung: Neue P-Elemente mache ich auf, wennich damit markieren will, dass sich Textteile _inhaltlich_ voneinander absetzen. Ich halte auch nichts davon, wenn man dann über display:inline jeden optischen Hinweis auf dieses Absetzen wieder entfernt. Dann muss zumindest etwas anderes wie etwa border her um das wieder deutlich zu machen. Ansonsten hat man das P-Element höchstwahrscheinlich auch strukturell missbraucht.

Gruß Gernot

[wahsaga]

hi,

Nein. *Nichts* in HTML sagt, wie etwas dargestellt wird. Es gibt allenfalls Darstellungen, die sich anbieten - wie auch z.B. Fettdruck bei <strong>. Damit ist der Sinn von <strong> aber noch lange nicht, etwas fett darszustellen,´

sondern, es als "stark", "derb", "kräftig" zu kennzeichnen, wenn wir mal ziemlich direkt übersetzen wollen.

genau so wenig wie es der Sinn von <hr> ist, eine durchgezogene Linie zu erzeugen.

hr steht doch m.W. für "horizontal rule".
was, wenn nicht eine horizontale (durchgezogene) linie soll es verkörpern?

gruß,
wahsaga

[Efchen]

genau so wenig wie es der Sinn von <hr> ist, eine durchgezogene Linie zu erzeugen.

hr steht doch m.W. für "horizontal rule".
was, wenn nicht eine horizontale (durchgezogene) linie soll es verkörpern?

Dann ist es aber Layout/Design und gehört nicht ins HTML. So wie <b>, <u> und Konsorten.

[Gernot Back]

Hallo Efchen,

genau so wenig wie es der Sinn von <hr> ist, eine durchgezogene Linie zu erzeugen.

hr steht doch m.W. für "horizontal rule".
was, wenn nicht eine horizontale (durchgezogene) linie soll es verkörpern?

Dann ist es aber Layout/Design und gehört nicht ins HTML. So wie <b>, <u> und Konsorten.

Auch wenn ich mich wiederhole, doch:

Z.B., wenn ich mit einer 5em langen Linie (20 war etwas übertrieben) in einer Tabellenzelle symbolisieren will, dass es in dieser Spalten-Zeilenkombination kein Angebot oder keine Information gibt. Da ist <hr class="noOffer" title="kein Angebot"> besser, als wenn mir ein Screenreader "GedankenstrichGedankenstrichGedankenstrichGedankenstrichGedankenstrich" vorliest.

Gruß Gernot

[Efchen]

Dann ist es aber Layout/Design und gehört nicht ins HTML. So wie <b>, <u> und Konsorten.

Da ist <hr class="noOffer" title="kein Angebot"> besser, als wenn mir ein Screenreader "GedankenstrichGedankenstrichGedankenstrichGedankenstrichGedankenstrich" vorliest.

Nein, entweder oder. Wenn Du das nur zu optischen Zwecken machst, musst Du CSS verwenden. Und ein "kein Angebot" ist bei mir ein inhaltlicher Strich, ich würde dann ohnehin nur einen Strich machen und nicht viele.

So, jetzt sind wir aber definitiv in einer Sackgasse angekommen. Unsere beider Meinungen sind nun klar und wir stimmen nicht ganz überein :-)

[wahsaga]

hi,

Da ist <hr class="noOffer" title="kein Angebot"> besser, als wenn mir ein Screenreader "GedankenstrichGedankenstrichGedankenstrichGedankenstrichGedankenstrich" vorliest.

weißt du denn, wie (bzw. ob) screenreader HR "vorlesen"?
ohne das zu wissen, ist die diskussion über diesen punkt m.E. müßig.

gruß,
wahsaga

[Efchen]

weißt du denn, wie (bzw. ob) screenreader HR "vorlesen"?

Ich würde erwarten, dass ein Screenreader hier eine größere Pause macht.

[Gernot Back]

Hallo wahsaga,

weißt du denn, wie (bzw. ob) screenreader HR "vorlesen"?

Ein title-Attribut sollte er jedenfalls nicht ignorieren, sonst taugt er nichts.

Gruß Gernot

[Efchen]

Ein title-Attribut sollte er jedenfalls nicht ignorieren, sonst taugt er nichts.

Werden diese Attribute überall vorgelesen? Das halte ich irgendwie aber auch nicht für passend, bzw. sollte man diese dann sparsamer einsetzen.

[Gernot Back]

Hallo Efchen,

Werden diese Attribute überall vorgelesen? Das halte ich irgendwie aber auch nicht für passend, bzw. sollte man diese dann sparsamer einsetzen.

Vielleicht kann man das als Nutzer konfigurieren.

Tja, das wüsste ich auch alles mal gerne. Vielleicht erbarmt sich hier ja mal ein stolzer Besitzer eines gängigen Screenreaders, testet das und berichtet uns darüber. Sonst ist tatsächlich alles Spekulation.

Gruß Gernot

[at]

Hallo.

Z.B., wenn ich mit einer 5em langen Linie (20 war etwas übertrieben) in einer Tabellenzelle symbolisieren will, dass es in dieser Spalten-Zeilenkombination kein Angebot oder keine Information gibt. Da ist <hr class="noOffer" title="kein Angebot"> besser, als wenn mir ein Screenreader "GedankenstrichGedankenstrichGedankenstrichGedankenstrichGedankenstrich" vorliest.

Der Screenreader könnte auch einfach "kein Angebot" vorlesen, wenn er die semantisch korrekte Auszeichnung <p>kein Angebot</p> vorfindet. Alles andere ist dann Sache des CSS.
MfG, at

[Gernot Back]

Hallo at,

Der Screenreader könnte auch einfach "kein Angebot" vorlesen, wenn er die semantisch korrekte Auszeichnung <p>kein Angebot</p> vorfindet. Alles andere ist dann Sache des CSS.

Da brauche ich aber doch wieder zwei Elemente; eines, das zwar vorgelesen  aber nicht angezeigt wird und ein anderes, von dem nur ein Border angezeigt wird. Beides zusammen geht doch wohl nicht, oder?

Aber davon abgesehen würde ich das ja alles gerne mal testen, wenn ich nur meine Window-Eyes Testversion mal innerhalb der 30 Minuten, die sie jeweils nach Systemstart theoretisch nur läuft auch praktisch mal dazu brächte zu laufen.

Gruß Gernot

[at]

Hallo.

Der Screenreader könnte auch einfach "kein Angebot" vorlesen, wenn er die semantisch korrekte Auszeichnung <p>kein Angebot</p> vorfindet. Alles andere ist dann Sache des CSS.

Da brauche ich aber doch wieder zwei Elemente; eines, das zwar vorgelesen  aber nicht angezeigt wird und ein anderes, von dem nur ein Border angezeigt wird. Beides zusammen geht doch wohl nicht, oder?

Warum nicht?
Ein wenig HTML:

<table summary="Angaben"><thead><tr><th>1</th><th>2</th><th>3</th></tr></thead>  
<tfoot></tfoot>  
<tbody><tr><td><p class="nix">keine Angabe</p></td><td>Angabe</td><td>Angabe</td></tr>  
<tr><td>Angabe</td><td><p class="nix">keine Angabe</p></td><td>Angabe</td></tr>  
<tr><td>Angabe</td><td>Angabe</td><td><p class="nix">keine Angabe</p></td></tr>  
</tbody>  
</table>

Und ein wenig CSS:

.nix {width: 1em; height: 1em; overflow: hidden; visibility: hidden;}  
.nix:before {content: '—'; visibility: visible;}

Das habe ich jetzt zwar nur in Opera getestet, aber mehr als ein paar kleine Anpassungen sollten für andere Browser kaum nötig sein. Nur vor den IE<7 sollte man das Ganze verstecken und stattdessen "keine Angabe" ausgeben lassen.

Aber davon abgesehen würde ich das ja alles gerne mal testen, wenn ich nur meine Window-Eyes Testversion mal innerhalb der 30 Minuten, die sie jeweils nach Systemstart theoretisch nur läuft auch praktisch mal dazu brächte zu laufen.

Wieso "Bahnhof"?
MfG, at

[Gernot Back]

Hallo at,

Wieso "Bahnhof"?

Klartext; ich lerne es binnen der mir zur Verfügung stehenden 30 Minuten nie, Windoweyes anzuwerfen, sodass es mir irgendetwas vorliest. Da gibt es irre viele Einstellmöglichkeiten der Sprachausgabe und die richtige Kombination zu finden ist innerhalb von 30 Minuten, die diese Testversion überhaupt nur jeweils am Stück läuft, nicht einfach.

Überhaupt scheint mir Windoweyes nur auf Microsoft-Produkte abgestellt zu sein. Bei der Installation konnte ich auswählen, ob ich es für den IE und Outlook Express, das Office-Paket etc. haben wollte. Als einziges Nicht-MS-Produkt war glaube ich der Acrobat Reader noch dabei.

Ich habe dann ausgewählt, dass ich es ausschließlich für den IE installieren wollte. (Andere Browser waren ohnehin nicht im Angebot) Vielleicht war das mein Fehler und jetzt fehlen wichtige Steuerungsteile. Ich werde es einfach noch einmal komplett installieren.

Barrierefreiheit ist da jedenfalls sogar für mich als Sehenden Fehlanzeige.

Gruß Gernot

[at]

Hallo.

Barrierefreiheit ist da jedenfalls sogar für mich als Sehenden Fehlanzeige.

Ich verstehe. Man sollte sich überlegen, das Testen mit der ausgewachsenen Vollversion als Dienstleistung anzubieten.
MfG, at

[wahsaga]

hi,

Dann ist es aber Layout/Design und gehört nicht ins HTML. So wie <b>, <u> und Konsorten.

sehe ich genauso.
ich bezog mich lediglich auf Cheatahs aussage, dass es _nicht_ sinn von hr sei, eine durchgehende linie zu erzeugen.

gruß,
wahsaga

[Cheatah]

Hi,

Oh, ob es hier um reines Tabellenlayout geht, wage ich anhand Hacke Peters Code-Fragment nicht zu beurteilen, vorausgesetzt es war tatsäächlich nur ein Fragment, um den Blick auf sein Problem zu konzentrieren.

ich war so frei, aus den vielen Attributen des <table>-Tags, solchen Dingen wie height="1" und der Tatsache, dass _überhaupt_ ein <hr> in ein <td> gepackt wird (zudem mit noshade-Attribut), diese Annahme zu wagen.

Strukturell wenig sinnvoll ist es natürlich, ein HR-Element als einzigen "Inhalt" in einer Tabellenzelle zu haben, es sei denn, wenn man gerade mit dem horizontalen Strich verdeutlichen will, dass es in dieser Spalten-/Zeilenkombination halt kein Angebot gibt. Dann sollte das aber auch durch eine Tabellenzeilenhöhe von mindestens 1em und durch einen Abstand des HR-Elements zum umgebenden TD-Elternelement klar werden.

Insbesondere gäbe es dann mindestens eine Zelle in der Zeile, die besagt, um welches Angebot es sich handelte, würde es dazu etwas geben. Ich bezweifele aber, dass ein Trenner hierzu der semantisch sinnvolle Inhalt(!) wäre; meiner Ansicht nach wäre eher eine Klassifizierung der Zeile sinnvoll.

Unmöglich ist es aber nicht, die Mindesthöhe einer Tabellenzelle abzuschalten, auch wenn spätestens das dann offensichtlich nur noch Gestaltungszwecken "von hinten durch die Brust ins Auge" dient:

Ja. Es wäre viel Aufwand, der dadurch entstanden ist, dass man mit viel Aufwand das Falsche gemacht hat. Über den Sinn dessen brauchen wir vermutlich keinen Duskurs zu führen ;-)

Cheatah