Tabelle lässt sich zwar drehen, aber nicht zurückdrehen

[André Bräkling]

Hallo zusammen,

ich habe ein Schachbrett zusammengeschustert und möchte nun eine Funktion implementieren, die es ermöglicht, dass Brett umzudrehen. Per Default ist weiß unten, durch einen Klick auf einen Button soll schwarz unten stehen. Immerhin soll es Spieler geben, die grundsätzlich von unten nach oben spielen wollen - ungeachtet ihrer Farbe.

Das "Drehen an sich" funktioniert mit dieser Funktion einwandfrei:

function rotatetab () {

gameTab = document.getElementById("gametab");

var aryRows = gameTab.rows;
 var intRows = aryRows.length;
 var aryNew = new Array(intRows);

for (var i = 0; i < intRows; i++) {
  aryNew[intRows-i-1] = aryRows[0];
  gameTab.deleteRow(0);
 }

for (var i = 0; i < intRows; i++) {
  gameTab.appendChild(aryNew[i]);
 }
}

Leider kann ich diese Funktion aber nicht benutzen, um die Tabelle "zurückzudrehen", da durch appendChild keine neuen Rows angelegt werden (gameTab.rows bleibt leer), obwohl die Objekte der Tabelle hinzugefügt werden.

Zwar gibt es eine Funktion HTMLTableElement.insertRow, doch diese erzeugt eine leere Zeile, zu der ich dann wieder einzeln meine Zellen hinzufügen muss. Ich möchte jedoch möglichst unkompliziert meine in aryNew gespeicherten HTMLTableRowElement-Objekte an die Tabelle anhängen.

Aktuell sehe ich also nur folgende Möglichkeiten:
1. Die HTMLTableRowElement-Objekte komplett zerlegen (Cells, Attributes, ...), per insertRow eine neue Zeile erzeugen und diese dann aus dem zuvor zerlegten Objekt neu erstellen. (Ich hoffe man versteht, was ich meine.) -> Umständlich.
2. Per appendChild das gesamte HTMLTableRowElement einfügen. -> Es werden keine wirklichen Rows angelegt (siehe oben erläutertes Problem).

Ich suche also eine Möglichkeit, ein bestehendes HTMLTableRowElement-Objekt als ganzes in eine bestehende Tabelle als "echte Row" einzufügen, so dass meine obige Funktion auch umgekehrt funktioniert. Oder halt eine alternative Lösung ;-)

Wäre Klasse, wenn hier jemand eine passende Idee hat, durch die ich den JavaScript-Code auf der Seite nicht unnötig aufblähe. Ich kann mir irgendwie nicht vorstellen, dass es dafür keine brauchbare Lösung gibt.

Danke im vorraus!

[Vinzenz Mai]

Hallo

Das "Drehen an sich" funktioniert mit dieser Funktion einwandfrei:

function rotatetab () {

gameTab = document.getElementById("gametab");

var aryRows = gameTab.rows;
var intRows = aryRows.length;
var aryNew = new Array(intRows);

for (var i = 0; i < intRows; i++) {
  aryNew[intRows-i-1] = aryRows[0];
  gameTab.deleteRow(0);
}

for (var i = 0; i < intRows; i++) {
  gameTab.appendChild(aryNew[i]);
}
}

Leider kann ich diese Funktion aber nicht benutzen, um die Tabelle "zurückzudrehen", da durch appendChild keine neuen Rows angelegt werden (gameTab.rows bleibt leer), obwohl die Objekte der Tabelle hinzugefügt werden.

der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:

</2006/7/t133604/#m866116>
</archiv/2007/2/t146811/#m952738>

Freundliche Grüße

Vinzenz

[André Bräkling]

der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:

Argh, vielen lieben Dank! Manchmal ist die Lösung so nah...

Wenn mal wieder jemand das Problem hat - so geht's natürlich:

function switchtab () {

gameTab = document.getElementById("gametabbody");

var aryRows = gameTab.rows;
 var intRows = aryRows.length;
 var aryNew = new Array(intRows);

for (var i = 0; i < intRows; i++) {
  aryNew[intRows-i-1] = aryRows[0];
  gameTab.deleteRow(0);
 }

for (var i = 0; i < intRows; i++) {
  gameTab.appendChild(aryNew[i]);
 }
}

<table id="gametab">
<tbody id="gametabbody">
<tr>...</tr>
...
<tr>...</tr>
</tbody>
</table>

[Timo "God's Boss" Reitz]

der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:
</2006/7/t133604/#m866116>
</archiv/2007/2/t146811/#m952738>

Diese Aussage ist in ihrer Absolutheit leider falsch. In HTML gilt das zweifelsfrei und ohne Ausnahme, in XHTML kann tr jedoch Kind von table sein, dort gibt es keine optionale Notation von Elementen, entweder sie sind da oder nicht.

[ChrisB]

Hi,

tr ist kein Kind von table sondern von tbody [...]
Diese Aussage ist in ihrer Absolutheit leider falsch. In HTML gilt das zweifelsfrei und ohne Ausnahme, in XHTML kann tr jedoch Kind von table sein, dort gibt es keine optionale Notation von Elementen, entweder sie sind da oder nicht.

Kommt auf die Betrachtungsweise an - aus HTML-DOM-Sicht, und damit der heute ueblicher Implementierungen in HTML-UAs stimmt Vinzenz' Aussage, denn http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_11 besagt:

"1. User agents that access XHTML documents served as Internet media type text/html via the DOM can use the HTML DOM [...]"

Sofern der UA das macht, stimmt das gesagte also aus DOM-Sicht m.E.

Wenn wirklich XML-DOM genutzt wird, sieht es anders aus:

"2. [...] Also, some XHTML elements may or may not appear in the object tree because they are optional in the content model (e.g. the tbody element within table). This occurs because in HTML 4 some elements were permitted to be minimized such that their start and end tags are both omitted (an SGML feature). This is not possible in XML. Rather than require document authors to insert extraneous elements, XHTML has made the elements optional. User agents need to adapt to this accordingly."

Ich habe allerdings noch nicht ausprobiert, wie real existierende, X(HT)ML verarbeitende UAs das in der Praxis umsetzen.

MfG ChrisB

[Vinzenz Mai]

Hallo

der Fehler, den Du begehst, ist bekannt. tr ist kein Kind von table sondern von tbody, siehe z.B:
</archiv/2006/7/t133604/#m866116>
</archiv/2007/2/t146811/#m952738>
Diese Aussage ist in ihrer Absolutheit leider falsch.

die Aussage ist nicht absolut, sie bezieht sich auf den vorliegenden Code, sie
steht im Kontext der verlinkten Threads und steht unter der Kategorie "Javascript" und nicht unter der Kategorie HTML/XHTML.

Sie bezieht sich auf die heutige Umsetzung von DOM/Javascript in heute üblichen Browsern.

Freundliche Grüße

Vinzenz

[Timo "God's Boss" Reitz]

Diese Aussage ist in ihrer Absolutheit leider falsch.
die Aussage ist nicht absolut, sie bezieht sich auf den vorliegenden Code, sie
steht im Kontext der verlinkten Threads und steht unter der Kategorie "Javascript" und nicht unter der Kategorie HTML/XHTML.

Und wie sollte nun jemand darauf kommen, dass es in XHTML eben anders sein kann?

Sie bezieht sich auf die heutige Umsetzung von DOM/Javascript in heute üblichen Browsern.

Wenn ich in XHTML kein tbody-Element verwende, ist im Firefox (ein heute üblicher Browser) auch keines im DOM-Baum.

[Vinzenz Mai]

Hallo Timo,

Wenn ich in XHTML kein tbody-Element verwende, ist im Firefox (ein heute üblicher Browser) auch keines im DOM-Baum.

das kann ich nicht nachvollziehen:
Die Forumshauptdatei hier verwendet XHTML 1.0 strict, es gibt eine Tabelle mit
der id="kopf", diese enthält im XHTML-Quelltext _kein_ tbody-Element, im DOM-Baum meines Firefox 2.0.0.10 sehe ich hingegen das tbody-Element, die tr-Elemente sind Kindelemente dieses tbody-Elementes.

Deswegen gehe ich davon aus, dass Du schon wieder daneben liegst :-)

Grüße

Vinzenz

[Timo "God's Boss" Reitz]

das kann ich nicht nachvollziehen:
Die Forumshauptdatei hier verwendet XHTML 1.0 strict, es gibt eine Tabelle mit
der id="kopf", diese enthält im XHTML-Quelltext _kein_ tbody-Element, im DOM-Baum meines Firefox 2.0.0.10 sehe ich hingegen das tbody-Element, die tr-Elemente sind Kindelemente dieses tbody-Elementes.
Deswegen gehe ich davon aus, dass Du schon wieder daneben liegst :-)

Ich liege nicht daneben, schon gar nicht wieder. Das tbody-Element wird hinzugefügt, weil die Seite vom Firefox als text/html verarbeitet wird.
Vergleiche folgende Seiten:
http://www.godsboss.de/test/tbody/table_tbody.html
http://www.godsboss.de/test/tbody/table_tbody.xhtml
Beide Dokumente sind vom Inhalt her identisch, beide sind valide. Die generierten DOM-Bäume unterscheiden sich allerdings im Firefox. Insbesondere wird beim als text/html gesendeten Dokument ein tbody-Element generiert, beim als application/xhtml+xml gesendeten Dokument hingegen nicht.