Tabellenzeile soll bei hover eine infobox anzeigen

[theatermacher]

Hallo

Ich will in einer Tabelle bei jeder Tabellenzeile <tr> bei hover die Farbe des background verändern und gleichzeitig bei jeder Tabellenzeile eine jeweils andere Infobox anzeigen. Jede dieser Infoboxen soll immer am gleichen Ort absolut positioniert sein und neben Text auch Grafiken enthalten. Die Hintergrundfarbe der ganzen Zeile zu verändern habe ich geschafft.
Wie das mit Div's geht, habe ich, dank dem Thread http://aktuell.de.selfhtml.org/artikel/css/infobox/Beispiel 3, soweit begriffen.
Meine Frage nun, kann ich das auch auf eine Tabellenzeile anwenden? Und wie müsste ich da rangehen?

Danke für hilfreiche Tips

LG Harry

[Matthias Apsel]

Om nah hoo pez nyeetz, theatermacher!

z.B. statt "<div id="box">" "<tr id="Zeile_5">"

Matthias

[theatermacher]

Om nah hoo pez nyeetz, theatermacher!

z.B. statt "<div id="box">" "<tr id="Zeile_5">"

Matthias

Hallo Matthias

Danke für Deine Antwort. Mit Tabellenzellen habe ich es hingekriegt, nur mit der ganzen Zeile habe ich Probleme.

<table width="670" cellspacing="0" cellpadding="0" border="0" align="left">  
    <thead>  
        <tr class="titel">  
            <th scope="col">&nbsp;</th>  
            <th scope="col">Whg-Nr.</th>  
            <th scope="col">Etage</th>  
            <th scope="col">Gr&ouml;sse</th>  
            <th scope="col">Fl&auml;che</th>  
            <th scope="col">Terrasse</th>  
            <th scope="col">Balkon</th>  
            <th scope="col">Verkauspreis</th>  
            <th scope="col">Status</th>  
            <th scope="col">Info</th>  
        </tr>  
    </thead>  
    <tbody>  
         <tr class="evenrow">  
            <td class="leer">&nbsp;</td>  
            <td class="infobox" id="box">  
            <div><img width="330" height="550" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" alt="infobox" /></div>  
            1.5</td>  
            <td>Attika</td>  
            <td>5.5</td>  
            <td>179m2</td>  
            <td>100m2</td>  
            <td>12m2</td>  
            <td>1'750'000.00</td>  
            <td>verkauft</td>  
            <td><a target="_blank" href="http://www.herti-6.ch/media/grundrisse-haus-9/0911_101_GR_EG-5OG_VP-09_0_1.pdf"><img width="16" height="16" border="0" align="left" alt="Grundriss" src="http://www.herti-6.ch/media/grafiken/pdf.gif" /></a></td>  
        </tr>  
        <tr class="oddrow">  
            <td class="leer">&nbsp;</td>  
            <td class="infobox" id="box">  
            <div><img width="330" height="550" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" alt="infobox" /></div>  
            1.5</td>  
            <td>1.OG</td>  
            <td>5.5</td>  
            <td>179m2</td>  
            <td>100m2</td>  
            <td>12m2</td>  
            <td>1'750'000.00</td>  
            <td>frei</td>  
            <td><a target="_blank" href="http://www.herti-6.ch/media/grundrisse-haus-9/0911_101_GR_EG-5OG_VP-09_1_2.pdf"><img width="16" height="16" border="0" alt="Grundriss" src="http://www.herti-6.ch/media/grafiken/pdf.gif" /></a></td>  
        </tr>  
        <tr class="evenrow">  
            <td class="leer">&nbsp;</td>  
            <td class="infobox" id="box">  
            <div><img width="330" height="550" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" alt="infobox" /></div>  
            1.5</td>  
            <td>1.OG</td>  
            <td>5.5</td>  
            <td>179m2</td>  
            <td>100m2</td>  
            <td>12m2</td>  
            <td>1'750'000.00</td>  
            <td>frei</td>  
            <td><a target="_blank" href="http://www.herti-6.ch/media/grundrisse-haus-9/0911_101_GR_EG-5OG_VP-09_1_1.pdf"><img width="16" height="16" border="0" alt="Grundriss" src="http://www.herti-6.ch/media/grafiken/pdf.gif" /></a></td>  
        </tr>  
        <tr class="oddrow">  
            <td class="leer">&nbsp;</td>  
            <td class="infobox" id="box">  
            <div><img width="330" height="550" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" alt="infobox" /></div>  
            1.5</td>  
            <td>1.OG</td>  
            <td>5.5</td>  
            <td>179m2</td>  
            <td>100m2</td>  
            <td>12m2</td>  
            <td>1'750'000.00</td>  
            <td>frei</td>  
            <td><a target="_blank" href="http://www.herti-6.ch/media/grundrisse-haus-9/0911_101_GR_EG-5OG_VP-09_1_2.pdf"><img width="16" height="16" border="0" alt="Grundriss" src="http://www.herti-6.ch/media/grafiken/pdf.gif" /></a></td>  
        </tr>  
        <tr class="evenrow">  
            <td class="leer">&nbsp;</td>  
            <td class="infobox" id="box">  
            <div><img width="330" height="550" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" alt="infobox" /></div>  
            1.5</td>  
            <td>Attika</td>  
            <td>5.5</td>  
            <td>179m2</td>  
            <td>100m2</td>  
            <td>12m2</td>  
            <td>1'750'000.00</td>  
            <td>reserviert</td>  
            <td><a target="_blank" href="http://www.herti-6.ch/media/grundrisse-haus-9/0911_101_GR_EG-5OG_VP-09_2_1.pdf"><img width="16" height="16" border="0" alt="Grundriss" src="http://www.herti-6.ch/media/grafiken/pdf.gif" /></a></td>  
        </tr>  
    </tbody>  
</table>

Nur mit ganzen Zeilen habe ich Probleme. Farbwechsel der ganzen Zeile bei hover geht. Aber mit css eine ganze Zeile zu verlinken krieg ich nicht hin. Auch mit googeln usw. habe ich keine Lösung gefunden. Ausser natürlich mit Javascript onclick. Aber ich möchte es mit css machen.
Geht das überhaupt?

[Gunther]

Hallo!

Mit Tabellenzellen habe ich es hingekriegt, nur mit der ganzen Zeile habe ich Probleme.

Was hast du, und vorallem wie "hingekriegt"?
Es ist ja schon mal hilfreich, dass du uns deinen HTML-Code gezeigt hast. Noch hilfreicher wäre es, wenn du uns jetzt auch noch den zugehörigen CSS-Code zeigen würdest.

Nur mit ganzen Zeilen habe ich Probleme. Farbwechsel der ganzen Zeile bei hover geht. Aber mit css eine ganze Zeile zu verlinken krieg ich nicht hin.

Was verstehst du denn unter "mit css eine ganze Zeile zu verlinken"?
Soweit ich dein Anliegen bisher verstanden habe, möchtest du doch etwas "bewirken", wenn eine Tabellenzeile 'gehovert' wird, oder? Wo ist da jetzt der Unterschied, bzw. das Problem gegenüber dem Wechsel der Hintergrundfarbe?

Gruß Gunther

[Gunnar Bittersmann]

@@theatermacher:

nuqneH

<table width="670" cellspacing="0" cellpadding="0" border="0" align="left">

Keins dieser Attribute sollte in HTML verwendet werden. Gib sämtlich Darstellung per CSS an!

<thead>
        <tr class="titel">

Die Klasse ist überflüssig. Dieses tr-Element ist das einzige innerhalb von thead; in CSS per [code lang=css]thead > tr

  
  

>     <tbody>  
>         <tr class="evenrow">  
>         ⋮  
>         <tr class="oddrow">  
  
Auch diese Klassen sind überflüssig. [Zebrastreifen](http://bittersmann.de/articles/zebra)  
  
Qapla'  
  
PS: Ich seh grad, ich sollte die Expressions mal auf `runtimeStyle`{:.language-javascript} umschreiben.

-- 
„Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann.“ (Antoine de Saint-Exupéry)

[theatermacher]

@@theatermacher:

nuqneH

<table width="670" cellspacing="0" cellpadding="0" border="0" align="left">

Keins dieser Attribute sollte in HTML verwendet werden. Gib sämtlich Darstellung per CSS an!

<thead>
        <tr class="titel">

Die Klasse ist überflüssig. Dieses tr-Element ist das einzige innerhalb von thead; in CSS per [code lang=css]thead > tr

>   
>   
> >     <tbody>  
> >         <tr class="evenrow">  
> >         ⋮  
> >         <tr class="oddrow">  
>   
> Auch diese Klassen sind überflüssig. [Zebrastreifen](http://bittersmann.de/articles/zebra)  
>   
> Qapla'  
>   
> PS: Ich seh grad, ich sollte die Expressions mal auf `runtimeStyle`{:.language-javascript} umschreiben.  
  
  
  
Danke für Eure Antworten.  
  
@gunther  
  
Damit mein Ziel deutlicher wird, hier der Link zu meiner Testseite:  
<http://uedlige.dramatik.ch>  
Die Funktionen der Zellen in der Kolonne Whg.-Nr. sollen über die ganze Zeile gehen. Also, egal in welche Zelle in der Zeile ich hovere, soll sich die Infobox öffnen. Und egal wo ich in der Zeile hinklicke soll das entsprechende Dokument geöffnet werden.  
Und hier noch das CSS für den betreffenden Tabellenbereich:  
~~~css
  
table {  
        float: left;  
        width: 670px;  
        margin-top: 0px;  
        margin-bottom: 10px;  
        background:#e4e4e4;  
}  
  
tr {  
       font-family: Arial, Verdana, Helvetica, sans-serif;  
       height:18px;  
       font-size:12px;  
       curser:pointer;  
}  
  
tr.titel th {  
       color:#ffffff;  
       text-align:left;  
       background: #236a9e;  
  
}  
tr.titel:hover {  
background: #236a9e;  
}  
tr.evenrow {  
 background-color: #e4e4e4;  
}  
tr.oddrow{  
        background-color: #ffffff;  
}  
tr:hover {  
background:#abcde5;  
}  
td  {  
        font-size: 12px;  
        color:#000;  
        font-weight:400;  
       /* background-color: #e4e4e4; */  
}  
td a:hover {  
color: #ec761e;  
}  
td.leer {  
width:50px;  
}  
  
/* --- Test für Infobox --- */  
  
#box{  
height:18px;  
width:60px;  
padding:0;  
margin:0px;  
border:0px solid red;  
}  
  
#box div{display:none;}  
  
#box:hover div{  
display:block;  
width:300px;  
height:550px;  
position:absolute;top:200px;left:0px;  
border:0px dashed black;  
padding:0px;  
font:normal 14px verdana, sans-serif;  
z-index:9910;  
}  
  
td.infobox {  
background:#abcde5;  
}  
  
td.infobox:hover {  
background:#64a8d7;  
color:#fff;  
}  

@gunnar

<table width="670" cellspacing="0" cellpadding="0"

border="0" align="left">

> Keins dieser Attribute sollte in HTML verwendet werden. Gib sämtlich  
> Darstellung per CSS an!  
  
Danke für diesen Hinweis. Ja, das werde ich tun. Ich bin halt kein Hirsch in Tabellen. Ich tu mich immer sehr schwer mit css und Tabellen.  
  
Ich werde auch Deine übrigen Hinweise betr. css Klassen umsetzen. Das mit den Zebrastreifen habe ich nicht gleich geschnallt, werde es aber ausprobieren.  
  
LG Harry  
  
  
  

[Gunther]

@@theatermacher:

nuqneH

@gunther

Damit mein Ziel deutlicher wird, hier der Link zu meiner Testseite:
http://uedlige.dramatik.ch
Die Funktionen der Zellen in der Kolonne Whg.-Nr. sollen über die ganze Zeile gehen. Also, egal in welche Zelle in der Zeile ich hovere, soll sich die Infobox öffnen. Und egal wo ich in der Zeile hinklicke soll das entsprechende Dokument geöffnet werden.

Dein Ziel ist schon klar, nur dein Weg der Umsetzung nicht ...! ;-)

Zunächst einmal darf eine ID nur _einmal_ pro HTML vorkommen (td id="box").
Und die Klasse "infobox" wäre bei den jeweiligen DIV_Elementen ggf. auch hilfreicher, als bei den TDs.

Im Augenblick blendest du die DIVs mit den Bildern ja über #box:hover div {...} ein. Abgesehen von der falschen Mehrfachverwendung der ID. ist #box aber ein TD-Element. Und wie ich schon geschrieben habe, willst du ja nicht eine einzelne Tabellenzelle (TD) als Auslöser, sondern die Tabellenreihe (TR). Ergo tr:hover .infobox {...} (wenn die DIV-Elemente die Klasse "infobox" bekommen haben).

Gruß Gunther

[theatermacher]

@@theatermacher:

nuqneH

@gunther

Damit mein Ziel deutlicher wird, hier der Link zu meiner Testseite:
http://uedlige.dramatik.ch
Die Funktionen der Zellen in der Kolonne Whg.-Nr. sollen über die ganze Zeile gehen. Also, egal in welche Zelle in der Zeile ich hovere, soll sich die Infobox öffnen. Und egal wo ich in der Zeile hinklicke soll das entsprechende Dokument geöffnet werden.

Dein Ziel ist schon klar, nur dein Weg der Umsetzung nicht ...! ;-)

Zunächst einmal darf eine ID nur _einmal_ pro HTML vorkommen (td id="box").
Und die Klasse "infobox" wäre bei den jeweiligen DIV_Elementen ggf. auch hilfreicher, als bei den TDs.

Im Augenblick blendest du die DIVs mit den Bildern ja über #box:hover div {...} ein. Abgesehen von der falschen Mehrfachverwendung der ID. ist #box aber ein TD-Element. Und wie ich schon geschrieben habe, willst du ja nicht eine einzelne Tabellenzelle (TD) als Auslöser, sondern die Tabellenreihe (TR). Ergo tr:hover .infobox {...} (wenn die DIV-Elemente die Klasse "infobox" bekommen haben).

Gruß Gunther

Hallo Gunther

Danke für Deine Antwort.

Zunächst einmal darf eine ID nur _einmal_ pro HTML vorkommen (td
id="box").

Viel schäm!
Ich hoffe, Dein Hinweis mit tr:hover .infobox {...} klappt. Ich werde es umgehend ausprobieren.

LG Harry

Ich bin's nochmal. Ich habe mal die #box in .box geändert. es funktioniert weiterhin.
Dann wollte ich die Funktion auf die Tabellenzeile anwenden. Es geht aber nicht.

tr.box{  
height:18px;  
width:100%;  
padding:0;  
margin:0px;  
border:0px solid red;  
/*font:bold 14px verdana, sans-serif; */  
}  
  
tr.box div{display:none;}  
  
tr.box:hover div{  
display:block;  
width:300px;  
height:550px;  
position:absolute;top:200px;left:0px;  
border:0px dashed black;  
padding:0px;  
font:normal 14px verdana, sans-serif;  
z-index:9910;  
}  
tr:hover {  
background:#abcde5;  
}  
tr.infobox {  
background:#abcde5;  
}  
  
tr.infobox:hover {  
background:#64a8d7;  
color:#fff;  
}

<tr class="evenrow box infobox"><a href="http://uedlige.dramatik.ch/media/pdf/Dok1.pdf">&nbsp;</a>  
            <div><img width="330" height="550" alt="infobox" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" /></div>  
            <td class="leer">&nbsp;</td>  
            <td>1.5</td>  
            <td>Attika</td>  
            <td>5.5</td>  
            <td>179m2</td>  
            <td>100m2</td>  
            <td>12m2</td>  
            <td>1'750'000.00</td>  
            <td>verkauft</td>  
        </tr>

Liegt wahrscheinlich daran, dass dass schliessende Tag </tr> erst nach der letzten Tabellenzelle kommt.

Rein theoretisch könnte ich ja den Code den ich vorher auf die Zelle "Whg--Nr." angewandt hatte, in jede Zelle einbauen. Aber das würde bei 50 Zeilen à 8 Zellen einen recht aufgeblähten Code ergeben.

Tabellen treiben mich in den Wahnsinn ;-)

LG Harry

[Matthias Apsel]

Om nah hoo pez nyeetz, theatermacher!

#1# Bitte unterlasse es, einen Großteil des Vorpostings zu zitieren, dies ist hier weder notwendig noch erwünscht. Nach einer Anmeldung könntest du dir das Forum so einstellen, dass der komplette Thread auf einer Seite ist.

#2# Lass doch deine Testseite online, so brauchst du nicht ellenlangen Code posten, den andere dann ihrerseits kopieren müssen.

Matthias

[theatermacher]

Hallo

Ich habe betreffend Tabellenzeile verlinken über Tage gegoogelt. Leider ohne ein Ergebnis. Die Vermutung, dass es unmöglich ist, bestätigt ein Thread, auf den ich soeben gestossen bin.
http://forum.de.selfhtml.org/archiv/2008/2/t167180/

Ich werde also notgedrungen den Code in jede Zelle einbauen. Dabei natürlich Eure Ratschläge betreffend sauberes CSS berücksichtigen.

Ich danke für Eure Ratschläge.

LG Harry

[Der Martin]

Hi,

Ich habe betreffend Tabellenzeile verlinken über Tage gegoogelt. Leider ohne ein Ergebnis. Die Vermutung, dass es unmöglich ist, bestätigt ein Thread, auf den ich soeben gestossen bin.
http://forum.de.selfhtml.org/archiv/2008/2/t167180/

du scheinst hier zwei Dinge durcheinanderzubringen. Richtig ist, dass eine ganze Tabellenzeile nicht Inhalt eines Links (also eines a-Elements) sein darf. Aber darum ging es doch gar nicht, oder?

Denn ich habe den Thread bisher so verstanden, dass es nur um Anzeigeeffekte (Einblenden einer Infobox) ging. Und das ist mit CSS basierend auf tr:hover selbstverständlich möglich - außer vielleicht in IE6 und älter, aber das muss dich nun wirklich nicht mehr jucken.

So long,
 Martin

[theatermacher]

Hi Martin

ich habe den Thread bisher so verstanden, dass es nur um
Anzeigeeffekte (Einblenden einer Infobox) ging.

Ich habe mich wahrscheinlich etwas ungenau ausgedrückt. Bei hover auf einer Zeile soll die Infobox angezeigt werden. Bei Klick auf eine Zeile soll ein Dokument runtergeladen werden.
Im Moment so zu sehen auf meiner Testinstallation http://uedlige.dramatik.ch
Wobei ich jede Zelle einzeln verlinkt habe. Der Aufwand ist gar nicht so riesig. Nur eben... der aufgeblähte Code.

LG Harry

[Gunther]

Hi Harry!

ich habe den Thread bisher so verstanden, dass es nur um
Anzeigeeffekte (Einblenden einer Infobox) ging.

Ich habe mich wahrscheinlich etwas ungenau ausgedrückt. Bei hover auf einer Zeile soll die Infobox angezeigt werden. Bei Klick auf eine Zeile soll ein Dokument runtergeladen werden.
Im Moment so zu sehen auf meiner Testinstallation http://uedlige.dramatik.ch
Wobei ich jede Zelle einzeln verlinkt habe. Der Aufwand ist gar nicht so riesig. Nur eben... der aufgeblähte Code.

Es gäbe da auch noch einen komplett anderen Ansatz. Das hängt aber von diversen Faktoren ab, die ich nicht kenne, wie z.B. welche Browser unterstützt werden sollen? Der Ansatz mit 'display: table[-...] funktioniert in allen modernen Browsern und dem IE8+.

Hier ist das Beispiel (welches nur das System verdeutlichen soll, weshalb u.a. die CSS-Selektoren sehr allgemein gehalten sind).

Gruß Gunther

[theatermacher]

Hi Gunther

Hier ist das Beispiel (welches
nur das System verdeutlichen soll, weshalb u.a. die CSS-Selektoren sehr
allgemein gehalten sind).

Ich sehe und staune!! Das ist ja absolut genial! Ich hatte keine Ahnung, dass man Tabellen auch mit Listen realisieren kann. Ich habe es zwar noch nicht ganz durchschaut, werde es aber nachzubauen versuchen und hoffe, dass mir dabei der Groschen fällt.
Betreffend Browser: Benutzt noch irgendwer im deutschsprachigen Europa den IE6 oder IE7? Ich glaube kaum, oder irre ich mich da?

LG und ein grosses Dankeschön für Deinen genialen Lösungsansatz!!!
Harry

[Matthias Apsel]

Om nah hoo pez nyeetz, theatermacher!

Hier ist das Beispiel (welches
nur das System verdeutlichen soll, weshalb u.a. die CSS-Selektoren sehr
allgemein gehalten sind).

Ich sehe und staune!! Das ist ja absolut genial!

Nein. Und zwar aus semantischen Gründen. Du verlierst die Zuordnung, welche Zahl zu welcher Größe gehört.

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Nein. Und zwar aus semantischen Gründen. Du verlierst die Zuordnung, welche Zahl zu welcher Größe gehört.

Könntest du das bitte mal etwas näher erläutern?

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

Könntest du das bitte mal etwas näher erläutern?

In deinem Beispiel gibt es <span>179 m²</span> in einem li. Abgesehen davon, dass es nicht sinnvoll ist, die 2 per Markup hochzustellen, was sind die 179 Größe, Fläche, Terasse, Balkon? In einer Tabelle (zur Darstellung tabellarischer Daten!) hast du entsprechende Spaltenüberschriften, die diese Zuordnung (bereits im Markup!) eindeutig liefern.

Nützlich und äußerst sinnvoll ist das vor allem für Screenreader und andere non-CSS-Besucher: Suchmaschinen.

Was es _ist_ und nicht was es _sein soll_ ist die Frage bei HTML. Und es sind tabellarische Daten, die zudem auch noch wie eine Tabelle dargestellt werden sollen.

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Vorweg: Ich bin durchaus ein Freund von semantisch korrektem Markup!

In deinem Beispiel gibt es <span>179 m²</span> in einem li. Abgesehen davon, dass es nicht sinnvoll ist, die 2 per Markup hochzustellen, was sind die 179 Größe, Fläche, Terasse, Balkon? In einer Tabelle (zur Darstellung tabellarischer Daten!) hast du entsprechende Spaltenüberschriften, die diese Zuordnung (bereits im Markup!) eindeutig liefern.

Der einzige Punkt, wo ich deinem Argument noch halbwegs folgen würde, betrifft nicht visuelle Ausgabemedien. Ansonsten "interessiert" sich kein Mensch für irgendeine "Zurodnung im Markup". Denn diese "Zuordnung" ergibt sich ja gerade aus der Darstellung. Und das tut sie hier genauso!

Nützlich und äußerst sinnvoll ist das vor allem für Screenreader und andere non-CSS-Besucher: Suchmaschinen.

Screenreader sind zugegebenermaßen ein echtes Problem.
Ich könnte mir aber zumindest vorstellen, dass man es ggf. mit einigen <fieldset> und <label> Elementen für andere Ausgabemedien wenigstens etwas "entschärfen" könnte. Allerdings reicht mein Kenntnisstand u.a. Screenreader betreffend dahingehend nicht aus.

Was es _ist_ und nicht was es _sein soll_ ist die Frage bei HTML. Und es sind tabellarische Daten, die zudem auch noch wie eine Tabelle dargestellt werden sollen.

Richtig! Und wer sagt, dass es sich hier um "tabellarische Daten" handelt?
IMHO würde es sich primär um tabellarische Daten handeln, wenn es bspw. um einen Bezug der jeweiligen Daten einer Spalte untereinander handeln würde - tut es aber nicht.

IMHO habe ich hier eine Reihe (Liste) von untereinander unabhängigen Objekten (Wohnungen), zu denen jeweils die gleichen Informationen bezüglich des jeweiligen Objekts vorliegen.
Demnach wäre bspw. auch eine Darstellung in der Form:

Whg-Nr.: 1.5  
Etage: Attika  
  Grösse: 5.5  
  Fläche: 179 qm  
  ...  
  
Whg-Nr.: 1.5  
  Etage: Attika  
  Grösse: 5.5  
  Fläche: 179 qm  
  ...

denkbar/ möglich. Dennoch halte ich in diesem Fall eine tabellarische Darstellung für am geeignetsten.

Dasselbe "System" findest du doch im Prinzip auch bei jedem Drop-Down Menü und da käme auch keiner (jedenfalls kein "normaler" Mensch) auf die Idee, das als Tabelle auszuzeichnen.

Was ich damit sagen will ist, dass nicht "automatisch" alle Daten, deren geeignetste visuelle Darstellung eine tabellarische Darstellung ist, deshalb auch tabellarische Daten im semantischen Sinn sein müssen!

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

IMHO würde es sich primär um tabellarische Daten handeln, wenn es bspw. um einen Bezug der jeweiligen Daten einer Spalte untereinander handeln würde - tut es aber nicht.

Weil im Original beispielsweise die Preise alle untereinander standen.

Demnach wäre bspw. auch eine Darstellung in der Form:

Whg-Nr.: 1.5
Etage: Attika
  Grösse: 5.5
  Fläche: 179 qm
  ...

Whg-Nr.: 1.5
  Etage: Attika
  Grösse: 5.5
  Fläche: 179 qm
  ...[/code]

denkbar/ möglich.

Ja. aber dann nicht

<li>  
  <span>Whg-Nr.</span>  
  <span>Etage</span>  
  <span>Größe</span>  
  <span>Fläche</span>  
</li>  
<li>  
  <span>1.5</span>  
  <span>Attika</span>  
  <span>5.5</span>  
  <span>179 m²</span>  
</li>

sondern

<dl>  
  <dt>Whg-Nr.</dt>  
  <dd>1.5</dd>  
  ...  
</dl>

und das für jede Wohnung, meinetwegen in einer ul

Dasselbe "System" findest du doch im Prinzip auch bei jedem Drop-Down Menü und da käme auch keiner (jedenfalls kein "normaler" Mensch) auf die Idee, das als Tabelle auszuzeichnen.

Nein, ein Menü ist eher eine baumartige Struktur.

Was ich damit sagen will ist, dass nicht "automatisch" alle Daten, deren geeignetste visuelle Darstellung eine tabellarische Darstellung ist, deshalb auch tabellarische Daten im semantischen Sinn sein müssen!

Was es _ist_, nicht was es _sein soll_

Kümmere dich beim HTML _ausschließlich_ um die Inhalte. Überlege nicht, wie es aussehen soll.

Bei einer Struktur

<article>  
  <h1>...</h1>  
  <p>...<a>...</a></p>  
</article>  

würdest du das doch auch machen.

Ziel eines Markups ist es, unabhängig von CSS eine inhaltlich gebundene Darstellung zu erreichen. Bedenke, dass theoretisch aber auch praktisch, deine CSS-Vorgaben allerhöchstens empfehlenden Charakter haben.

Jeder User kann
* das CSS deaktivieren
* besondere Farbkontraste einstellen
* Mindestschriftgrößen verwenden
* User-Stylesheets verwenden

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

IMHO würde es sich primär um tabellarische Daten handeln, wenn es bspw. um einen Bezug der jeweiligen Daten einer Spalte untereinander handeln würde - tut es aber nicht.

Weil im Original beispielsweise die Preise alle untereinander standen.

Versteh' ich jetzt nicht!
Das ist ja u.a. der Vorteil der tabellarischen_Darstellung_, dass gleiche Informationen "übersichtlich" in einer Spalte dargestellt werden.

Du folgerst aber scheinbar immer aus der "Art der Darstellung" auf die "Art der Daten". Das halte ich aus den bereits genannten Gründen für falsch.

Demnach wäre bspw. auch eine Darstellung in der Form:

Whg-Nr.: 1.5
Etage: Attika
  Grösse: 5.5
  Fläche: 179 qm
  ...

Whg-Nr.: 1.5
  Etage: Attika
  Grösse: 5.5
  Fläche: 179 qm
  ...[/code]

denkbar/ möglich.

Ja. aber dann nicht

<li>

<span>Whg-Nr.</span>
  <span>Etage</span>
  <span>Größe</span>
  <span>Fläche</span>
</li>
<li>
  <span>1.5</span>
  <span>Attika</span>
  <span>5.5</span>
  <span>179 m²</span>
</li>

>   
> sondern  
> ~~~html

<dl>  

>   <dt>Whg-Nr.</dt>  
>   <dd>1.5</dd>  
>   ...  
> </dl>

und das für jede Wohnung, meinetwegen in einer ul

Ja, darauf habe ich schon gewartet ...! ;-)
Persönlich halte ich das semantisch gesehen nicht für richtiger. Aber diese Diskussion wann eine Definitionsliste semantisch "richtiger" als eine (unsortierte) Liste ist, kannst du bis in alle Ewigkeit führen, und trotzdem bleibt es in vielen Fällen eine rein "philosophische Frage" auf die es nicht_die_eine_einzige_richtige_Antwort_gibt!

Dasselbe "System" findest du doch im Prinzip auch bei jedem Drop-Down Menü und da käme auch keiner (jedenfalls kein "normaler" Mensch) auf die Idee, das als Tabelle auszuzeichnen.

Nein, ein Menü ist eher eine baumartige Struktur.

Nö, nicht "baumartiger" als die Liste hier (abhängig von der Anzahl der Level).
Und letztendlich ist jedes HTML Dokument immer eine "baumartige Struktur".

Was ich damit sagen will ist, dass nicht "automatisch" alle Daten, deren geeignetste visuelle Darstellung eine tabellarische Darstellung ist, deshalb auch tabellarische Daten im semantischen Sinn sein müssen!

Was es _ist_, nicht was es _sein soll_

Kümmere dich beim HTML _ausschließlich_ um die Inhalte. Überlege nicht, wie es aussehen soll.

Ja, genau das habe ich ja getan!
Ich habe eine Liste mit Wohnungen, bei der es (zumindest nach meinem Verständnis) nicht auf die Reihenfolge ankommt. Ergo habe ich eine unsortierte Liste für mein Markup gewählt, bei der jeder Listenpunkt für eine Wohnung steht und alle Informationen beinhaltet.

Bei einer Struktur

<article>

<h1>...</h1>
  <p>...<a>...</a></p>
</article>

>   
> würdest du das doch auch machen.  
  
Ich kann den Zusammenhang nicht sehen, bzw. nicht nachvollziehen, was du damit sagen willst.  
Wo ist der "Unterschied" zu:  
~~~html
  
<ul>  
  <li>...<a>...</a></li>  
  <li>...<a>...</a></li>  
</ul>  

Ziel eines Markups ist es, unabhängig von CSS eine inhaltlich gebundene Darstellung zu erreichen.

Und inwieweit siehst du die bei einer unsortierten Liste als nicht gegeben?

Bedenke, dass theoretisch aber auch praktisch, deine CSS-Vorgaben allerhöchstens empfehlenden Charakter haben.

Jeder User kann
* das CSS deaktivieren
* besondere Farbkontraste einstellen
* Mindestschriftgrößen verwenden
* User-Stylesheets verwenden

Jetzt "vermengst" du aber die Semantik des Inhalts mit der Darstellung.
Und ich hatte bereits geschrieben, dass "ich in diesem Fall eine tabellarische Darstellung für am geeignetsten" halte. Natürlich ist das nur eine "Empfehlung" und wenn jemand aus welchen Gründen auch immer ... - deshalb bleibt es trotzdem eine Liste innerhalb derer alle zusammengehörigen Informationen jeweils genau innerhalb eines Listenpunkts stehen!
Und das sogar inklusive dem jeweils zugehörigen Image und komplett verlinkt mit der jeweils zugehörigen PDF-Datei.

Also bevor du hier weiter auf der Semantik "rumreitest", zeig' mir doch bitte mal (d)ein valides Beispiel mit Tabellen-Markup. Und dann unterhalten wir uns weiter über "eine inhaltlich gebundene Darstellung".

"In an ideal world ..." gäbe es für jeden Anwendungsfall genau_das_semantisch korrekte Element. Wir leben aber nicht in so einer idealen Welt, daher sehe ich das grundsätzlich so, dass man letztendlich immer das Element auswählen sollte, welches am "passendsten" ist, d.h. es gibt kein Element, das objektiv betrachtet passender wäre.

Und im Gegensatz zur Validität, die ein Muss darstellt, bin ich dann schon eher geneigt, dabei Kompromisse einzugehen, wenn diese für die absolute Mehrheit der Seitenbesucher einen "Vorteil" in der "Lesbarkeit & Benutzbarkeit" der Seite darstellt.

Gruß Gunther

[Der Martin]

Hallo,

Du folgerst aber scheinbar immer aus der "Art der Darstellung" auf die "Art der Daten". Das halte ich aus den bereits genannten Gründen für falsch.

nein, sowohl Matthias als auch Gunnar schließen aus der Art und dem inneren Zusammenhang der Daten auf die in HTML geeignete Struktur, die diesen Zusammenhang am besten wiedergibt. Die typische oder sinnvolle Art der Darstellung folgt in zweiter Stufe daraus.
Und ich schließe mich ihrer Ansicht an.

Kümmere dich beim HTML _ausschließlich_ um die Inhalte. Überlege nicht, wie es aussehen soll.
Ja, genau das habe ich ja getan!

Mag sein - und du bist zu einer Dokumentstruktur gekommen, die IMHO passend, aber nicht optimal passend ist.

Ich habe eine Liste mit Wohnungen, bei der es (zumindest nach meinem Verständnis) nicht auf die Reihenfolge ankommt. Ergo habe ich eine unsortierte Liste für mein Markup gewählt, bei der jeder Listenpunkt für eine Wohnung steht und alle Informationen beinhaltet.

Eben, und das ist nur die halbe Miete, wenn wir schon bei den Wohnungen sind. ;-)
Der entscheidende Punkt ist doch: Alle deine Listeneinträge sind nach dem gleichen Muster aufgebaut und enthalten ihrerseits wieder immer gleichartige Felder in der gleichen Reihenfolge. Und dieses Datenmodell wird mit einer Tabelle einfach am besten abgebildet. Du hast ja im ersten Listenpunkt sogar die Spaltenüberschriften formuliert, die ebenfalls eine Tabelle nahelegen.

Ziel eines Markups ist es, unabhängig von CSS eine inhaltlich gebundene Darstellung zu erreichen.
Und inwieweit siehst du die bei einer unsortierten Liste als nicht gegeben?

Gegeben schon, aber es gibt eine andere Grundstruktur, nämlich die Tabelle, die dein Datenmodell noch besser trifft. Eine Tabelle ist sozusagen eine Liste gleichartiger Listen. Ein zweidimensionales Array, wenn du es so willst.

Bedenke, dass theoretisch aber auch praktisch, deine CSS-Vorgaben allerhöchstens empfehlenden Charakter haben.
[...]
Jetzt "vermengst" du aber die Semantik des Inhalts mit der Darstellung.

Nein. Eine mit CSS nachempfundene Tabelle löst sich visuell in ihre Bestandteile auf, sobald CSS deaktiviert ist oder das Stylesheet aus technischen Gründen mal nicht geladen werden kann. Dann sieht's aus wie Kraut und Rüben, die Übersicht geht verloren. Bei einer echten HTML-Tabelle leidet zwar die Ästhetik, aber es bleibt auch dann noch klar erkennbar eine Tabelle, wenn das CSS nicht angewendet wird.

So long,
 Martin

[Gunther]

Hallo Martin!

Du folgerst aber scheinbar immer aus der "Art der Darstellung" auf die "Art der Daten". Das halte ich aus den bereits genannten Gründen für falsch.

nein, sowohl Matthias als auch Gunnar schließen aus der Art und dem inneren Zusammenhang der Daten auf die in HTML geeignete Struktur, die diesen Zusammenhang am besten wiedergibt. Die typische oder sinnvolle Art der Darstellung folgt in zweiter Stufe daraus.
Und ich schließe mich ihrer Ansicht an.

Und worauf würdest du bei:

  
Whg-Nr.: 1.5  
  Etage: Attika  
  Grösse: 5.5  
  Fläche: 179 qm  

schließen (wenn das der einzige vorhandene Eintrag wäre)?

Kümmere dich beim HTML _ausschließlich_ um die Inhalte. Überlege nicht, wie es aussehen soll.
Ja, genau das habe ich ja getan!

Mag sein - und du bist zu einer Dokumentstruktur gekommen, die IMHO passend, aber nicht optimal passend ist.

Jetzt kommen wir der eigentlichen Sache schon näher ... ;-)
Denn das Markup (und seine Semantik) ist die eine Sache, und die Darstellung die andere. Beide sind aber miteinander verbunden, bzw. die Darstellung vom Markup abhängig (vom Grundsatz her kann ich nichts darstellen, was im Quelltext nicht vorhanden ist - jegliche DOM Manipulationen oder Sachen wie "content" im CSS mal außen vor gelasssen).

Somit kommen wir da imho an den Punkt, wo sich Theorie und Praxis voneinander trennen. Denn es kann imho in der Praxis eben vorkommen, dass sich mein Markup auch nach der gewünschten Art der Darstellung richten muss (ja ich weiß - ist Ansichtssache und kann jeder gerne so halten, wie er es mag, bzw. für richtig hält).

Ich habe eine Liste mit Wohnungen, bei der es (zumindest nach meinem Verständnis) nicht auf die Reihenfolge ankommt. Ergo habe ich eine unsortierte Liste für mein Markup gewählt, bei der jeder Listenpunkt für eine Wohnung steht und alle Informationen beinhaltet.

Eben, und das ist nur die halbe Miete, wenn wir schon bei den Wohnungen sind. ;-)
Der entscheidende Punkt ist doch: Alle deine Listeneinträge sind nach dem gleichen Muster aufgebaut und enthalten ihrerseits wieder immer gleichartige Felder in der gleichen Reihenfolge. Und dieses Datenmodell wird mit einer Tabelle einfach am besten abgebildet.

Du hast ja im ersten Listenpunkt sogar die Spaltenüberschriften formuliert, die ebenfalls eine Tabelle nahelegen.

Ja, für die visuelle tabellarische Darstellung (die bspw. bei einem Screenreader zu Gunsten eines jeweiligen Labels weggelassen werden könnten), die wie bereits mehrfach erwähnt der besseren "Erkennbarkeit/ Übersichtlichkeit" dient, also ein rein visuelles Instrument ist, was nichts mit der Semantik im HTML zu tun hat, da wir uns hier rein auf der Darstellunsseite befinden.

Ziel eines Markups ist es, unabhängig von CSS eine inhaltlich gebundene Darstellung zu erreichen.
Und inwieweit siehst du die bei einer unsortierten Liste als nicht gegeben?

Gegeben schon, aber es gibt eine andere Grundstruktur, nämlich die Tabelle, die dein Datenmodell noch besser trifft. Eine Tabelle ist sozusagen eine Liste gleichartiger Listen. Ein zweidimensionales Array, wenn du es so willst.

Und wieder ... "in an ideal world ..."
In dem hier vorliegenden Fall lässt sich aber mit einem Tabellen-Markup nicht die gewünschte Darstellung und Usability (für vermutlich 99% der künftigen Seitenbesucher) erreichen. Inwieweit also dann jemand "Kompromisse" im Bezug auf die Semantik eingehen will, kann er ja selbst entscheiden ...!

Bedenke, dass theoretisch aber auch praktisch, deine CSS-Vorgaben allerhöchstens empfehlenden Charakter haben.
[...]
Jetzt "vermengst" du aber die Semantik des Inhalts mit der Darstellung.

Nein. Eine mit CSS nachempfundene Tabelle löst sich visuell in ihre Bestandteile auf, sobald CSS deaktiviert ist oder das Stylesheet aus technischen Gründen mal nicht geladen werden kann. Dann sieht's aus wie Kraut und Rüben, die Übersicht geht verloren. Bei einer echten HTML-Tabelle leidet zwar die Ästhetik, aber es bleibt auch dann noch klar erkennbar eine Tabelle, wenn das CSS nicht angewendet wird.

Nach dem Motto "Ein Bild sagt mehr als tausend Worte ...!"

Ist schon "enorm" der Unterschied (wenn man mal von der Schriftgröße absieht) ...!
Und nochmal:"... dient mein Beispiel dazu, eine bestimmte Form der visuellen Präsentation zu verdeutlichen und erhebt keinesfalls den Anspruch im Bezug auf Accessibility "perfekt" zu sein.". Da gibt es sicherlich noch viel Raum für Optimierungen/ Verbesserungen.

Nein. Eine mit CSS nachempfundene Tabelle löst sich visuell in ihre Bestandteile auf, sobald CSS deaktiviert ist oder das Stylesheet aus technischen Gründen mal nicht geladen werden kann.

Wenn ich bei der Darstellung rein auf CSS setze, ist das Argument für mich genauso "vielsagend" wie:"Wenn bei deinem Auto mal kein Sprit im Tank ist, oder der Motor kaputt ist, dann ...!".
Ja, dann ist derjenige in den "Arsch gekniffen!"

Zum Abschluss (ich mag nämlich langsam nicht mehr): Rein von der Theorie her habt ihr sicherlich und unwidersprochen Recht!
Meine (bescheidene) praktische Erfahrung hat mir aber gezeigt, dass es in der Praxis nicht immer nach der Theorie geht!

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

Nach dem Motto "Ein Bild sagt mehr als tausend Worte ...!"

Heh heh, nicht Äpfel und Birnen miteinander vergleichen!

Meine Infobox enthält mehrere Überschriften, deine nur ein Bild.

Wenn du richtig vergleichen möchtest:

http://selfhtml.apsel-mv.de/test/wohnung3.html, http://selfhtml.apsel-mv.de/test/wohnung4.html

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Heh heh, nicht Äpfel und Birnen miteinander vergleichen!
Wenn du richtig vergleichen möchtest:

... dann baust du auch noch den Link zu der/den PDF-Datei(en) ein! ;-)

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

... dann baust du auch noch den Link zu der/den PDF-Datei(en) ein! ;-)

Mit viel Getrickse: http://selfhtml.apsel-mv.de/test/wohnung5.html

Nachteil: die Texte in den Tabellen sind nicht markierbar.

Wenn das als Kundenwunsch an mich herangetragen würde, würde ich auch hier aus Gründen der Bedienungsfreundlichkeit ablehnend argumentieren:

Linktext stimmt nicht mit Linkziel überein. Besser eine eigene Tabellenspalte mit einem eindeutig identifizierbaren Link. Etwa: "Beschreibung als PDF".

Matthias

[Matthias Apsel]

Om nah hoo pez nyeetz, Matthias Apsel!

Mit viel Getrickse: http://selfhtml.apsel-mv.de/test/wohnung5.html

Version für alte Browser: http://selfhtml.apsel-mv.de/test/wohnung5-altebrowser.html

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Mit viel Getrickse: http://selfhtml.apsel-mv.de/test/wohnung5.html

Version für alte Browser: http://selfhtml.apsel-mv.de/test/wohnung5-altebrowser.html

OK, lassen wir das "Gefrickel" mal durchgehen ...! ;-)
Und jetzt bitte noch die Variante für small screen devices (ausgehend von der tatsächlichen Anzahl, nicht von deiner "verkürzten" Variante) - Stichwort "Responsive Design".

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

Und jetzt bitte noch die Variante für small screen devices (ausgehend von der tatsächlichen Anzahl, nicht von deiner "verkürzten" Variante) - Stichwort "Responsive Design".

Sollte die Tabelle nicht auf den Bildschirm passen, verhält sich deine Lösung genau wie meine: Scrollbalken

In einer "Übergangsphase" ist meine Lösung sogar fluider als deine.

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Und jetzt bitte noch die Variante für small screen devices (ausgehend von der tatsächlichen Anzahl, nicht von deiner "verkürzten" Variante) - Stichwort "Responsive Design".

Sollte die Tabelle nicht auf den Bildschirm passen, verhält sich deine Lösung genau wie meine: Scrollbalken

In einer "Übergangsphase" ist meine Lösung sogar fluider als deine.

Ich bin aber aufgrund des verwendeten Markups "wesentlich" flexibler ...!
Und aktuell war mein Beispiel ja auch nicht darauf ausgelegt.

Aber darum ging und geht es mir gar nicht, sondern vielmehr darum aufzuzeigen, dass die Verwendung von semantisch korrektem Markup durchaus sehr "arge" Probleme bei der Darstellung mit sich bringen kann - auch und insbesondere bei Tabellen!

Hier findet man eine ziemlich komplette Übersicht samt Beispielen über die diversen "Verrenkungen", um Tabellen(-Markup) halbwegs "responsive" zu machen.

Und noch eine Anmerkung:
Aktuell haben die Wohnungen in dem Fall vom OP "zufällig" alle die gleichen Eigenschaften.
Was wenn morgen oder übermorgen andere Wohnungen mit (zum Teil) anderen Eigenschaften mit ins Portfolio aufgenommen werden sollen?
Dann füge ich nicht nur die neuen Wohnungen in den Quelltext ein, sondern ändere auch noch den von jeder schon vorhandenen Wohnung!
Und wie "sinnvoll" es ist bei 100 Wohnungen eine leere Spalte zu haben, weil die entsprechende Eigenschaft nur für eine Wohnung zutrifft, halte ich zumindest für "fragwürdig".

Und selbst mit HTML5 bleibt das Problem, dass man keine komplette Tabellenzeile verlinken kann, also

  
... <a href="#"><tr> ... </tr></a> ...  

nach wie vor nicht valide ist.

"Abhilfen", wie du sie z.B. angewandt hast, oder per JS haben größtenteils erhebliche Nachteile im Bezug auf Accessibility & Usability!

Aber Hauptsache semantisch korrektes Markup! ;-)

BTW: Ich will die Diskussion weder neu entfachen, noch fortsetzen, aber wenn doch per Definition jede Tabelle auch eine Liste ist, wie kann dann eigentlich die Verwendung einer Liste semantisch falsch sein? ;-)

Ich möchte mich an dieser Stelle aber auch mal ausdrücklich bei dir und den anderen Teilnehmern an der Diskussion bedanken, und bei allen anderen dafür, dass es keinen "Threaddrift" gab! :-)

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

BTW: Ich will die Diskussion weder neu entfachen, noch fortsetzen, aber wenn doch per Definition jede Tabelle auch eine Liste ist, wie kann dann eigentlich die Verwendung einer Liste semantisch falsch sein? ;-)

Ist sie ja auch nicht. Was mich aber stört, ist die fehlende Wiederholung der Spaltennamen. In einem von dir verlinkten Beispiel passiert übrigens auch genau das: Spaltenüberschriften werden wiederholt, damit nicht irgendwelche Werte mutterseelenallein in der Gegend rumstehen. ;-)

So, nu aber eod. ;-)

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Was mich aber stört, ist die fehlende Wiederholung der Spaltennamen. In einem von dir verlinkten Beispiel passiert übrigens auch genau das: Spaltenüberschriften werden wiederholt, damit nicht irgendwelche Werte mutterseelenallein in der Gegend rumstehen. ;-)

_Das_ließe sich auch auf jede andere "Variante" übertragen ...!
Aber verstößt die Verwendung von "content" im CSS nicht eigentlich gegen die strikte Trennung von Inhalt und Design!? ;-)

So, nu aber eod. ;-)

Dass du immer das letzte Wort haben musst ...! :-P

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

Dass du immer das letzte Wort haben musst ...! :-P

Woher soll ich denn wissen, dass du noch was sagen wolltest?

Matthias

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

IMHO würde es sich primär um tabellarische Daten handeln, wenn es bspw. um einen Bezug der jeweiligen Daten einer Spalte untereinander handeln würde - tut es aber nicht.

[1]

Weil im Original beispielsweise die Preise alle untereinander standen.

[2]

Versteh' ich jetzt nicht!
Das ist ja u.a. der Vorteil der tabellarischen_Darstellung_, dass gleiche Informationen "übersichtlich" in einer Spalte dargestellt werden.

Vielleicht reden wir hier aneinander vorbei.

[1] Du schriebst: Es handelt sich nicht um tabellarische Daten, weil es keinen Bezug zwischen den Daten einer Spalte gibt.

[2] Der Bezug ist, dass gleichartige Daten untereinander stehen

Du folgerst aber scheinbar immer aus der "Art der Darstellung" auf die "Art der Daten".

Nein, umgekehrt.

Das halte ich aus den bereits genannten Gründen für falsch.

Ist es auch

Persönlich halte ich das semantisch gesehen nicht für richtiger. Aber diese Diskussion wann eine Definitionsliste semantisch "richtiger" als eine (unsortierte) Liste ist, kannst du bis in alle Ewigkeit führen,

Eine Definitionsliste (HTML4) - Beschreibungsliste (HTML5) stellt (in unserem Beispiel) eine Verbindung zwischen "Größe" und "175m²" her. Das tut deine Konstruktion nicht.

Ja, genau das habe ich ja getan!
Ich habe eine Liste mit Wohnungen, bei der es (zumindest nach meinem Verständnis) nicht auf die Reihenfolge ankommt. Ergo habe ich eine unsortierte Liste für mein Markup gewählt, bei der jeder Listenpunkt für eine Wohnung steht und alle Informationen beinhaltet.

Nein, hast du nicht, denn die (entscheidenden!) Bezeichnungen kommen bei deinen Wohnungen garnicht vor, sie stehen als eigenes Listenelement. Du hast also
<ul>
  <li>Beschreibung als ganz viele Spans</li>
  <li>Werte von Wohnung 1 als ganz viele Spans</li>
  <li>Werte von Wohnung 2 als ganz viele Spans</li>
...

Ich kann den Zusammenhang nicht sehen, bzw. nicht nachvollziehen, was du damit sagen willst.

Es sollte einfach ein weiteres Beispiel sein, das mit dem ursprünglichen nichts zu tun hat.

Ziel eines Markups ist es, unabhängig von CSS eine inhaltlich gebundene Darstellung zu erreichen.

Und inwieweit siehst du die bei einer unsortierten Liste als nicht gegeben?

s.o.

innerhalb derer alle zusammengehörigen Informationen jeweils genau innerhalb eines Listenpunkts stehen!

eben nicht, weil du nicht weißt, welche Größe zu welchem Wert gehört.

Und das sogar inklusive dem jeweils zugehörigen Image und komplett verlinkt mit der jeweils zugehörigen PDF-Datei.

Also bevor du hier weiter auf der Semantik "rumreitest", zeig' mir doch bitte mal (d)ein valides Beispiel mit Tabellen-Markup. Und dann unterhalten wir uns weiter über "eine inhaltlich gebundene Darstellung".

http://selfhtml.apsel-mv.de/test/wohnung.html

Weder bei deinem, noch bei meinem Beispiel kann man in der Hinweisbox Links anklicken.

Matthias

[Matthias Apsel]

Om nah hoo pez nyeetz, Matthias Apsel!

http://selfhtml.apsel-mv.de/test/wohnung.html

Weder bei deinem, noch bei meinem Beispiel kann man in der Hinweisbox Links anklicken.

Basierend auf meiner zweiten Lösungsidee sind die Inhalte der Info-Box erreichbar. Etwa zum Markieren oder Anklicken.

Matthias

[Matthias Apsel]

Om nah hoo pez nyeetz, Matthias Apsel!

Basierend auf meiner zweiten Lösungsidee sind die Inhalte der Info-Box erreichbar. Etwa zum Markieren oder Anklicken.

http://selfhtml.apsel-mv.de/test/wohnung2.html

Matthias

[Kai345]

[latex]Mae  govannen![/latex]
'

In deinem Beispiel gibt es <span>179 m²</span> in einem li. Abgesehen davon, dass es nicht sinnvoll ist, die 2 per Markup hochzustellen, was sind die 179 Größe, Fläche, Terasse, Balkon? In einer Tabelle (zur Darstellung tabellarischer Daten!) hast du entsprechende Spaltenüberschriften, die diese Zuordnung (bereits im Markup!) eindeutig liefern.

Der einzige Punkt, wo ich deinem Argument noch halbwegs folgen würde, betrifft nicht visuelle Ausgabemedien.

Alleine das *muß* Grund genug sein. Genau deshalb ist semantisches Markup *unverzichtbar* . Blinde bspw. sind darauf angewiesen, da ansonsten der Inhalt nur relativ unverständliches und unzusammenhängendes „Gebrabbel“ wäre. Wenn vom Reader nur stumpf irgendwelche Daten ausgegeben werden, wird auf Dauer kaum jemand in der Lage sein, zuzuordnen, welcher Dateninhalt zu welcher Wohnung jetzt gerade ausgegeben wird.

Ansonsten "interessiert" sich kein Mensch für irgendeine "Zurodnung im Markup".

Das ist irrelevant und keine Entschuldigung, es nicht vernünftig zu machen.

Denn diese "Zuordnung" ergibt sich ja gerade aus der Darstellung. Und das tut sie hier genauso!

Nicht für jemanden, der die Daten nicht visuell erfassen *kann*.

Screenreader sind zugegebenermaßen ein echtes Problem.
Ich könnte mir aber zumindest vorstellen, dass man es ggf. mit einigen <fieldset> und <label> Elementen für andere Ausgabemedien wenigstens etwas "entschärfen" könnte. Allerdings reicht mein Kenntnisstand u.a. Screenreader betreffend dahingehend nicht aus.

Tabellen sind genau dazu da. Außerdem: Warum _keine_ Tabelle? Es interessiert sich doch laut deiner Aussage kein Mensch für irgendeine "Zuordnung im Markup"“

IMHO würde es sich primär um tabellarische Daten handeln, wenn es bspw. um einen Bezug der jeweiligen Daten einer Spalte untereinander handeln würde - tut es aber nicht.

„Datensätze von Wohnungen“ *ist* ein Bezug. Würde man hier eine Liste verwenden, müßte für jeden Datensatz eine Tabelle mit Überschriften etc. erstellt werden. Das ist unsinnig.
Man kann, wenn man will, innerhalb der Tabelle durchaus eine bedingte Trennung über multiple tbody-Elemente erreichen.

Stur lächeln und winken, Männer!
Kai

[Gunther]

Hallo!

Der einzige Punkt, wo ich deinem Argument noch halbwegs folgen würde, betrifft nicht visuelle Ausgabemedien.

Alleine das *muß* Grund genug sein. Genau deshalb ist semantisches Markup *unverzichtbar* . Blinde bspw. sind darauf angewiesen, da ansonsten der Inhalt nur relativ unverständliches und unzusammenhängendes „Gebrabbel“ wäre. Wenn vom Reader nur stumpf irgendwelche Daten ausgegeben werden, wird auf Dauer kaum jemand in der Lage sein, zuzuordnen, welcher Dateninhalt zu welcher Wohnung jetzt gerade ausgegeben wird.

Sorry, aber du argumentierst hier gerade so, dass man sein Markup nach den "technischen Unzulänglichkeiten" bestimmter Ausgabmedien richten soll/muss, und das unter dem "Deckmäntelchen" der Semantik.

Nur weil bestimmte Ausgabemedien mit einem bestimmten Markup ein "besseres" Ergebnis liefern, heißt das doch noch lange nicht, dass dieses deshalb semantisch gesehen korrekter ist!

Außerdem darf ich auf mein bereits Geschriebenes verweisen:"Ich könnte mir aber zumindest vorstellen, dass man es ggf. mit einigen <fieldset> und <label> Elementen für andere Ausgabemedien wenigstens etwas "entschärfen" könnte. Allerdings reicht mein Kenntnisstand u.a. Screenreader betreffend dahingehend nicht aus."

Denn diese "Zuordnung" ergibt sich ja gerade aus der Darstellung. Und das tut sie hier genauso!

Nicht für jemanden, der die Daten nicht visuell erfassen *kann*.

Also erstmal dient mein Beispiel dazu, eine bestimmte Form der visuellen Präsentation zu verdeutlichen und erhebt keinesfalls den Anspruch im Bezug auf Accessibility "perfekt" zu sein. Im Gegenteil - diese spielt für das was es verdeutlichen soll keine Rolle.

Im Übrigen hast du hier wieder den Fall, dass es immer schwierig ist, Informationen deren ideale Form der Aufnahme von bestimmten Sinnen abhängig ist, alternativ so zu präsentieren, dass sie auch noch "verständlich" sind, wenn dieser Sinn nicht, oder nur eingeschränkt zur Verfügung steht.

Nur um es zu verdeutlichen:

• Musikportal für Taube
• Bildergalerie für Blinde

Das sind natürlich Extrem-Beispiele, sollen aber nur die grundsätzliche Problematik verdeutlichen, denn die ist imho bei Informationen, deren geeignetste visuelle Darstellung eine tabellarische ist, genau dieselbe.

Womit ich mit keinem Wort gesagt habe, dass sie nicht trotzdem zugänglich sein sollten!!!

Screenreader sind zugegebenermaßen ein echtes Problem.
Ich könnte mir aber zumindest vorstellen, dass man es ggf. mit einigen <fieldset> und <label> Elementen für andere Ausgabemedien wenigstens etwas "entschärfen" könnte. Allerdings reicht mein Kenntnisstand u.a. Screenreader betreffend dahingehend nicht aus.

Tabellen sind genau dazu da.

Wozu?

Außerdem: Warum _keine_ Tabelle? Es interessiert sich doch laut deiner Aussage kein Mensch für irgendeine "Zuordnung im Markup"“

Erstens weil es sich_nicht_um tabellarische Daten handelt, jedenfalls nicht so weit, als dass man zwingend Tabellen-Markup dafür verwenden müsste.
Und zweitens weil bisher noch keiner ein valides Beispiel mit Tabellen-Markup präsentiert hat, was die gleichen "Vorzüge" im Bezug auf die Einblendung der Grafiken und die Verlinkungen der PDF-Dateien bietet.

IMHO würde es sich primär um tabellarische Daten handeln, wenn es bspw. um einen Bezug der jeweiligen Daten einer Spalte untereinander handeln würde - tut es aber nicht.

„Datensätze von Wohnungen“ *ist* ein Bezug.

Was kommt jetzt? Die "alte" Geschichte "jede Liste ist auch eine Tabelle ..." oder was?
Die Diskussion ist doch müßig ..., nur soviel vielleicht noch: Für mich besteht einer der wesentlichen Unterschiede darin, dass es bei tabellarischen Daten darauf ankommt, dass sie nur als "Ganzes" betrachtet "Sinn machen". Das sehe ich hier nicht als gegeben, denn ich kann jede Wohnung mit ihren Daten auch alleine betrachten. Es handelt sich hier also mehr um das mehrfache Auftreten verschiedener voneinander unabhängiger Objekte, die alle dieselben Eigenschaften haben. Daher "optimiert" die tabellarische Darstellung die Übersichtlichkeit und somit die optische Wahrnehmung der Informationen.

Würde man hier eine Liste verwenden, müßte für jeden Datensatz eine Tabelle mit Überschriften etc. erstellt werden. Das ist unsinnig.

Sorry, aber du hast es schon selbst gesagt:"Das ist unsinnig"!
Erstens wird die Liste deshalb ja tabellarisch dargestellt, um zum einen die entsprechenden Überschriften zu haben, und zum anderen um eine permanente Wiederholung selbiger zu vermeiden (was die Übersichtlichkeit wohl eher negativ beeinflussen dürfte).
Und zweitens bräuchte man keine "Tabelle mit Überschriften", was ja semantisch vollkommen verkehrt wäre, sondern ein Label für jede Eigenschaft. Und ja, bei einer Liste wiederholen sich diese. Was ist daran verkehrt?

Man kann, wenn man will, innerhalb der Tabelle durchaus eine bedingte Trennung über multiple tbody-Elemente erreichen.

Ja, wenn eine Tabelle das geeignete Mittel der Wahl ist ...!

Stur winkend,
Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

• Musikportal für Taube
• Bildergalerie für Blinde

falsch formuliert:

• Musikportal, das Taube nicht ausschließt
• Bildergalerie, die Blinde nicht ausschließt

Bei den Bildern läuft es auf eine ausführliche Bildbeschreibung hinaus. Minimum als alt-Attribut, das dann ggf. vorgelesen wird. Ich habe schon Seiten mit sehr ausführlichen Bildbeschreibungen gesehen.

Matthias

[Gunnar Bittersmann]

@@Matthias Apsel:

nuqneH

[…] entsprechende Spaltenüberschriften, die diese Zuordnung (bereits im Markup!) eindeutig liefern.
Nützlich und äußerst sinnvoll ist das vor allem für Screenreader und andere non-CSS-Besucher: Suchmaschinen.

Suchmaschinen ordnen Werte in Tabellenzellen den Spaltenüberschriften zu? Wirklich?

Ich glaube, für Suchmaschinen müsste man die Zuordnung mit Mikroformaten (RDFa, microdata, …) herstellen – und zwar für jedes Item. Und dabei ist es egal, ob table/tr/td oder ul/li/span verwendet wird.

<ul vocab="http://vocab.example.net/wohnung/>  
  <li typeof="Wohnung">  
    <a property="url" href="http://uedlige.dramatik.ch/media/pdf/Dok1.pdf">  
      <span property="nummer">1.5</span>  
      <span property="etage" >Attika</span>  
      <span property="groesse" >5.5</span>  
      <span property="flaeche">179 m²</span>  
      <span property="terrasse">100 m²</span>  
      <span property="balkon">12 m²</span>  
      <span property="verkaufspreis">750'000.00</span>  
      <span property="status">reserviert</span>  
    </a>  
    <img width="330" height="550" src="http://uedlige.dramatik.ch/media/hoverbox/hoverbild-2.jpg" alt="infobox" />  
  </li>  
</ul>

Wobei Suchmaschinen auch nur dann damit was anfangen können, wenn ihnen das Vokabular bekannt ist. Bei schema.org ist das eher der Fall, bei vocab.example.net/wohnung wohl nicht.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, Der Martin!

Denn ich habe den Thread bisher so verstanden, dass es nur um Anzeigeeffekte (Einblenden einer Infobox) ging. Und das ist mit CSS basierend auf tr:hover selbstverständlich möglich - außer vielleicht in IE6 und älter, aber das muss dich nun wirklich nicht mehr jucken.

Bei Tabellen nicht ganz so selbstverständlich, denn es fehlt an "einfachen" Nachfahrenelementen, da die Struktur der Tabelle vorgegeben ist. ::after ist imho auch ungeeignet, da die Infobox ja mehrere Elemente enthalten soll.

Matthias

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Richtig ist, dass eine ganze Tabellenzeile nicht Inhalt eines Links (also eines a-Elements) sein darf.

<table>  
  <tr href="http://example.net">  
    <th>foo</th>  
    <td>42</td>  
  </tr>  
</table>

Wann ist der HTML5-Hype endlich vorbei und die vielen guten Ideen von XHTML 2 werden aufgegriffen?

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Ja! href for universal attribute.

Das ist doch mal ne Petition.

Matthias

[Der Martin]

Hallo,

Wann ist der HTML5-Hype endlich vorbei und die vielen guten Ideen von XHTML 2 werden aufgegriffen?

bis dahin werden wir wohl noch viel träumen dürfen ...

Ciao,
 Martin

[Matthias Apsel]

Om nah hoo pez nyeetz, theatermacher!

Ich werde also notgedrungen den Code in jede Zelle einbauen. Dabei natürlich Eure Ratschläge betreffend sauberes CSS berücksichtigen.

Nur so ne Idee.

html:

<table>
  <tr class="auslöser"><td..........
  <tr colspan="Spaltenzahl"><td>Inhalt der Box</td></tr>
  <tr class="auslöser"><td..........
  <tr colspan="Spaltenzahl"><td>Inhalt der Box</td></tr>
</table>

css:

[colspan] {position: absolute; top: irgendwo; left: irgendwo;
           display: none;}

.auslöser:hover+[colspan] {display: block;}

• ungetestet
• Ich weiß nicht, ob sich eine Tabelle so zerreißen lässt
• IE6 kann das nicht
• tbody, table muss position:static behalten

Matthias

[Matthias Apsel]

Om nah hoo pez nyeetz, Matthias Apsel!

<table>
  <tr class="auslöser"><td..........
  <tr colspan="Spaltenzahl"><td>Inhalt der Box</td></tr>
  <tr class="auslöser"><td..........
  <tr colspan="Spaltenzahl"><td>Inhalt der Box</td></tr>
</table>

suboptimal. Wenn das funktioniert, kann man auch ebensogut das jeweils erste td-Element als Info-Box missbrauchen. Die Klasse "auslöser" ist übrigens nur für alte Browser vonnöten.

<table>
  <tr><td>Infobox</td><td>....

css:

td:first-child {position: absolute; top: irgendwo; left: irgendwo;
                display: none;}

tr:hover>td:first-child {display: block;}

aber wie gesagt

• Ich weiß nicht, ob sich eine Tabelle so zerreißen lässt

Die Beispiele unterscheiden sich im Aussehen, wenn das CSS in alten Browsern versagt oder ausgeschaltet ist.

ebenfalls ungetestet.

Was einem so alles durch den Kopf geht, wenn man eigentlich schlafen sollte...

Matthias

[Kai345]

[latex]Mae  govannen![/latex]

<tr class="evenrow">
        ⋮
        <tr class="oddrow">

Auch diese Klassen sind überflüssig. Zebrastreifen

„Der IE 8 ist dazu im 7er Modus zu betreiben“

Das will man nicht wirklich => „Um die von Internet Explorer 8 unterstütze CSS-Eigenschaften (die, die im IE 8 neu sind) verwenden zu können, muss eine Webseite im Modus IE8 oder höher gerendert werden“

Dann doch lieber Klassen, bzw. reicht Eine.

Stur lächeln und winken, Männer!
Kai

[Gunnar Bittersmann]

@@Kai345:

nuqneH

„Der IE 8 ist dazu im 7er Modus zu betreiben“
Das will man nicht wirklich

Hm, ja, will man nicht.

Eigentlich will man den gar nicht betreiben.

Dann doch lieber Klassen, bzw. reicht Eine.

Das will man auch nicht!

Dann schon eher ein kleines Nur-IE8-JavaScript.

Oder progressive enhancemant. Wenn IE 8 keine Zebrastreifen darstellt, geht die Welt nicht unter.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Oder progressive enhancemant. Wenn IE 8 keine Zebrastreifen darstellt, geht die Welt nicht unter.

Zwar nicht, aber ...
Zebrastreifen in großen Tabellen erleichtern die Orientierung, sie sind weit entfernt von schicki-micki-klicki-bunti.

Matthias

[Kai345]

[latex]Mae  govannen![/latex]

Dann doch lieber Klassen, bzw. reicht Eine.

Das will man auch nicht!

Kommt meines Erachtens auch/hauptsächlich auf den Inhalt der hervorzuhebenden Liste an; siehe unten.

Dann schon eher ein kleines Nur-IE8-JavaScript.

Sollte meist genügen. IEs mit ohne ;) Javascript sind eher selten. Klassen also nur, wenn man davon ausgehen kann, daß auch IE ohne JS aufschlagen könnten (also eher Sites im kommerziellen Umfeld); siehe noch untener ^^

Oder progressive enhancemant. Wenn IE 8 keine Zebrastreifen darstellt, geht die Welt nicht unter.

…aber eine längere und/oder breitere Liste kann dadurch sehr unübersichtlich werden. Man kann schnell in der Zeile verrutschen.

Je nach enthaltener Information liegt das zwischen vernachlässigbar lästig und übel (bspw. falsche Bestellnummer erwischt).

Und bevor ich in solche einem Fall den Nutzer mit einem Blatt Papier am Bildschirm herumfuchteln ließe, würde ich _dann_ doch eher Klassen verwenden.

Stur lächeln und winken, Männer!
Kai