onclick unhide <span>blabla</span>

F.L.X · 7 Dez. 2015

Hi,

ich hoffe, hier darf man nach Webtechnik fragen.

nunja ...
aaaalso: Ich bin auf der Suche nach einem Stückchen Code, das vor mehr als 15 Jahren schon ohne getElementbyID usw. funktioniert hat:

an was ich mich erinnere - da ich den code nicht selber geschrieben hab, sondern nur von irgendjemandem über den #gulli chat damals bekommen und dann einfach angewendet habe -
ungefähr sowas:

[src=html4strict]
<!DOCTYPE html>
<html>
<body>

Hier steht normaler Text und wenn man auf mich klickt ... <a onClick="show()"><span> erscheint dahinter/darunter plötzlich noch mehr.</span>

uuund noch mehr ... <a onClick="show()"><span> wird sichtbar </span>
</body>
</html>[/src]

ob das HTML -"Script" nun auch noch zwingend Javascript ( <script> </script> ) wegen dem onclick() enthielt, weiß ich leider nicht mehr. Aber das war "damals egal." Vor 15 Jahren war Javascript im IE4/5 je generell angestellt und hat man allerhöchstens ActiveX abgestellt.
Ich weiß nur, daß das äußerst wenig Code war - wie oben gezeigt, und daß in einer (1) Zeile oclick und <span> stand ...
[ganz wenig code, um den Klick und das Erscheinen zu realisieren. Wie oben gezeigt.]

und daß man bei der fertigen "HTML-Seite" (bestimmt weniger als 300-400 Zeichen) einfach auf den Text (mhh, html-Link? . k.a.) klicken mußte und dann der weitere erschien.

hachja ... dummerweise hab ich immer noch keine rechte Ahnung von Javascript - und "Programmieren in HTML" sonst hätt ich mir das jetzt aus dem Netz gesucht. Aber mit Stichworten wie span, show, onclick kommt man nicht weit bei den S-Maschinen.
Ok, ich habe Ergebnisse gefunden, wo mit 20-30 Zeilen Javascript sowas mit getElementby('ID') realsiert wird. Oder mit <detail>-Tag - welches aber derzeit nur chrome, Safari unterstützen, aber Firefox noch nicht. - aber das ist alles zuuu lang.

Ob das nun damals auch schon CSS war, kann ich auch nicht genau sagen.

Vielleicht schüttelt ja jemand sowas aus dem Handgelenk.
Herzlichen Dank jedenfalls und nen schönen Advent

°= Zeichen - nicht Zeilen !

KcDaRookie · 7 Dez. 2015

Das ist das kürzeste was ich gefunden habe:

[src=html4strict]<script type="text/javascript">
function show(id) {
document.getElementById(id).style.display = 'block';
}
</script>
<a href="#" onclick="show('span1')">Text</a><br>
<span id="span1" style="display: none;">Mehr text</span>[/src]

Okey, wenn du es nur mit CSS + HTML machen willst, dann kommt es deinem Text ziemlich Nahe:
[src=html4strict]<style>
span {
display: none;
}
.show:focus ~ span {
display: block;
}
</style>

<a href="#" class="show">Text</a><br>
<span>Mehr text</span>[/src]

Der <style>-Part kann in eine CSS ausgelagert werden, genauso wie die function in eine externe JS.
Also mit onClick und ohne das show als Funktion zu deklarieren geht es nicht. aber das sind keine 30 Zeilen code sondern nur die Paar da oben.

Ich würde die JS Version empfehlen, zumal du da einfach weitere spans erstellen kannst mit anderer ID und dann die ID in dem show Code nur anpassen musst und alle Texte offen bleiben nach dem anklicken. Beispiel für 2 Spans:
[src=html4strict]<script type="text/javascript">
function show(id) {
document.getElementById(id).style.display = 'block';
}
</script>
<a href="#" onclick="show('span1')">Text</a><br>
<span id="span1" style="display: none;">Mehr text</span>
<a href="#" onclick="show('span2')">Text2</a><br>
<span id="span2" style="display: none;">Mehr text2</span>[/src]

Beim anderen würde ich jetzt pseudoklassen errichten und die dann aufblenden, nachteil ist hier geht der vorherige zu wenn du den nächsten anklickst, oder wo anders hinklickst:
[src=html4strict]<style>
span {
display: none;
}
.show:focus ~ span {
display: block;
}
span1 {
display: none;
}
.show1:focus ~ span1 {
display: block;
}
</style>

<a href="#" class="show">Text</a><br>
<span>Mehr text</span><br>
<a href="#" class="show1">Text1</a><br>
<span1>Mehr text1</span1>[/src]

Oder du verschwurbelst beides und hast dann noch weniger Text im body Bereich und die Dinger bleiben auf:
[src=html4strict]<style>
span {
display: none;
}
</style>
<script type="text/javascript">
function show(id) {
document.getElementById(id).style.display = 'block';
}
</script>
<a href="#" onclick="show('span1')">Text</a><br>
<span id="span1">Mehr text</span>
<a href="#" onclick="show('span2')">Text1</a><br>
<span id="span2">Mehr text1</span>[/src]

Jemand mit mehr Ahnung bekommts wahrscheinlich schöner hin

theSplit · 7 Dez. 2015

Ich hatte mir auch eine Lösung überlegt, die könnte man mit einem Data-Attribute speißen, das wäre aber immer noch so das man nur das Element und nicht das "nebenstehende Nächste" einfach wieder einblenden könnte. Ginge auch mit "style.visiblity" = "hidden" != "visible".

Aber eine Klasse oder irgendwas muß die Elemente per CSS erst einmal "verstecken" ob es mit Display oder Visibility ist.

Dokumente einer klasse werden versteckt - "data-target="1", parseint(data-target), wird aufgebaut oder versteckt, je nach visibility-Wert gesetzt bzw. ungesetzt. ( "" != "visible").

Gibt es sowas wie "nextSibling" auch wie "nextNode" ? - Den Befehl hab ich beim testen nicht gefunden.

Aber ich bin glaube ich auch etwas verwirrt - auf die Uhr schiel

virtus · 8 Dez. 2015

Die kürzeste und früher durchaus übliche Lösung sieht wohl so aus:
[src=html5]<div>Bla bla bla <span onclick="function(){this.nextSibling.style.display="block";}">show</span><span style="display:none">hidden</span></div>[/src]

Allerdings: Das funktioniert nur, wenn unmittelbar das auf das show folgende Element der Spoiler ist. Sobald ein Leerzeichen (oder gar noch Text) dazu kommt, funktioniert das Script nicht mehr ohne Modifikation. Dieser Lösung ist man früher durchaus begegnet, heute ist das absolut tabu.

Schau dir aktuelle Implementierungen an.

Ob du 2 oder 20 Zeichen JS hast, spielt heute keine Rolle mehr. Die Übertragungsraten sichern dir trotz deutscher Pay-to-Netzneutralität und Dorfdsl, dass du da keine Probleme haben wirst. Andererseits sichert dir ein 20 Zeilen Code, dass jemand mit halbwegs Ahnung auch noch in 20 Jahren versteht, was du da damals zusammen gebaut hast und dass der Code in so ziemlich jedem Browser (antike IE Versionen außen vor gelassen) funktioniert und dich keinerlei Wartung/ Erweiterung kostet, wenn deine Seiten mal komplexer werden.

Frameworks wie Bootstrap können Spoiler bereits von Haus aus realisieren, es geht aber auch ohne Framework.

--- [2015-12-08 00:15 CET] Automatisch zusammengeführter Beitrag ---

theSplit schrieb:
Ich hatte mir auch eine Lösung überlegt, die könnte man mit einem Data-Attribute speißen, das wäre aber immer noch so das man nur das Element und nicht das "nebenstehende Nächste" einfach wieder einblenden könnte. Ginge auch mit "style.visiblity" = "hidden" != "visible".

Aber eine Klasse oder irgendwas muß die Elemente per CSS erst einmal "verstecken" ob es mit Display oder Visibility ist.

Dokumente einer klasse werden versteckt - "data-target="1", parseint(data-target), wird aufgebaut oder versteckt, je nach visibility-Wert gesetzt bzw. ungesetzt. ( "" != "visible").

Gibt es sowas wie "nextSibling" auch wie "nextNode" ? - Den Befehl hab ich beim testen nicht gefunden.

Aber ich bin glaube ich auch etwas verwirrt - auf die Uhr schiel

nextSibling gibt es, das ist aber wie du in meinem Post siehst, eine hässliche Lösung und erlaubt dir nicht den Öffnen-Link und den Spoiler zu trennen.

Meine Lösung, die ich hier jetzt nicht ausführlich poste, basiert darauf, dass ein Spoiler immer aus zwei Teilen besteht:
1. Einem Element, welches für's Öffnen zuständig ist.
2. Einem Element, das den versteckten Text enthält.

1 braucht ein data- Attribut, welches die Id von 2 enthält und eine Klasse, die es als Spoiler identifiziert.
Den Rest kann man mit JavaScript getElementsByClassName und classList.toggle realisieren.

Jester · 9 Dez. 2015

Das Problem kann man über Klassennamen auf dem Elternobjekt und ein Inline-Snippet lösen, Beispiel:

[src=html5]<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Unhide per CSS</title>

<style type="text/css">
.away{ display:none }
p.shown span{ display:none }
p.shown span.away{ display:inline }
</style>

<script type="text/javascript">
function unhide(obj){
obj.parentNode.className == '' ? obj.parentNode.className = 'shown' : obj.parentNode.className += ' shown';
}
</script>

</head>
<body>

<div>
<p>Hallo <span onclick="unhide(this)">...mehr</span><span class="away"> Hier kommt der weitere Text rein</span></p>
<p>Huhu</p>
<p>Tachauch <span onclick="unhide(this)">...mehr</span><span class="away"> Ergänzende Infos zu Absatz "Tachauch"</span></p>
</div>

</body>
</html>[/src]

(...)

Über die hinzugefügte Klasse wird auch gleich das Steuerungs-Element (<span onclick...) ausgeblendet.

Bei dieser Lösung muss lediglich den <span>-Kindelementen mit den weiterführenden Infos die Klasse "away" gegeben werden, wo und in welcher Reihenfolge die Elemente eingebracht werden, ist unerheblich.

F.L.X · 10 Dez. 2015

Danke Euch.

ich glaube, das, was ich meinte, war das von Virtus.
Das waren extrem wenige Zeilen.
Find's auch gerade nicht wieder ist auf irgendwelchen CD's gesichert. (falls die noch lesbar sind) - und vielleicht sogar in komprimierten Archiven

muß mir das alles mal in Ruhe durchprobieren.

Ist aber auch nur für mich privat. Von daher ist Webstandard und Lesbarkeit fast egal

Danke nochmals.

virtus · 13 Dez. 2015

@F.L.X: Melde dich mal per PN, dann schicke ich dir eine bessere Lösung, die keine inline-Scripts braucht und bei der du dich selbst nicht mit JavaScript auseinander setzen musst. Du musst nur HTML schreiben und das Script klinkt sich selbst an den passenden Stellen ein.

@Jester: Ziemlich ungeil, wenn ein Knoten mehrere Klassennamen haben soll:
[src=html5]<span class="away anythingelse">[/src]
Auch ziemlich ungeil potentiell zig mal das onclick-Attribut von Hand zu setzen.
[src=html5] onclick="unhide(this)"[/src]
Zusätzlich kannst du die Spoiler kaum auseinander ziehen, was auch nicht immer praktisch ist.

Jester · 14 Dez. 2015

@virtus:

1. Dann erklär mal, wo Du da eine realistische Kollisionsgefahr siehst. Bitte ausführlich.
2. Das hast Du in Deinen Posts zuvor ja sicherlich auch berücksichtigt, oder? Übrigens gehe ich davon aus, dass es sich um eine DB-gestütze Ausgabe handelt, ansonsten lulz. Wenn das der Fall ist, wie oft muss man den onclick-handler eingeben? Warte... ein Mal?
3. Was meinst Du mit "Spoiler auseinander ziehen"? Die Position des Spoilers im Elternelement ist unerheblich, so lange es sich im Eltern-<p> befindet.

Klar kann ich ein komplettes Framework bauen, das das lapidare Problem des TE (@TE: nicht angegriffen fühlen

) löst und gleichzeitig sogar für Leute verwendbar ist, die bei der Geburt leider die Nabelschnur um den Hals hatten (das war eine Metapher, die in Verbindung mit dem Stilmittel der Übertreibung einen gewissen Effekt erzielen soll).

Ist aber hier wohl nicht Sinn der Sache gewesen, oder? Soweit ich das erkennen kann, ist meine Lösung relativ elegant im Vergleich zu den Vorigen und inkl. Deiner Andeutungen für eine Lösung - und erfüllt die durch den TE gegebenen Kriterien vollständig.

Was also genau ist Dein Problem?

dexter · 14 Dez. 2015

Jester schrieb:
Soweit ich das erkennen kann, ist meine Lösung relativ elegant im Vergleich zu den Vorigen

Die is nicht eleganter als der weiter oben angegebene CSS-Schnipsel ohne JS.
Wenn Du da jetzt noch ein zuklappen einbauen könntest siehts vielleicht bisschen anders aus. Das geht nämlich in CSS ohne Rumgehampel oder unsemantisches Markup nicht.

virtus · 14 Dez. 2015

Jester schrieb:
1. Dann erklär mal, wo Du da eine realistische Kollisionsgefahr siehst. Bitte ausführlich.

Schön dass der Post nachträglich verändert wurde. Auf den ursprünglichen Beitrag kann ich mangels Quellensicherheit nicht mehr Bezug nehmen.

2. Das hast Du in Deinen Posts zuvor ja sicherlich auch berücksichtigt, oder?

Wie gesagt, habe ich ausdrücklich darauf hingewiesen, dass die Konstruktion früher durchaus üblich war, aber nichts mit einem sauberen, guten Code gemeinsam hat.

3. Was meinst Du mit "Spoiler auseinander ziehen"? Die Position des Spoilers im Elternelement ist unerheblich, so lange es sich im Eltern-<p> befindet.

Fällt dir beim markierten Teil etwas auf?

Klar kann ich ein komplettes Framework bauen, das das lapidare Problem des TE (@TE: nicht angegriffen fühlen ) löst und gleichzeitig sogar für Leute verwendbar ist, die bei der Geburt leider die Nabelschnur um den Hals hatten

Wenn du auf dem Niveau diskutieren willst: Boah warum programirt sich der Nutser nicht selbst denn Schpoiler, wen er was ausbländen wil ???? Kan doch e fol jeder oder is der behindert oder was ey? Ist nur ne fol geile Stilelement Übertreibung, weil ich mega kuhl bin und nicht als beleihdigung gemeind.
Ja, sorry, aber da kann ich echt nichts mehr zu sagen. :rolleyes:

Soweit ich das erkennen kann

Ich glaube genau da liegt der Teufel begraben.

Soweit ich das erkennen kann, ist meine Lösung relativ elegant im Vergleich zu den Vorigen und inkl. Deiner Andeutungen für eine Lösung

Was genau ist an deiner Lösung elegant?
Die strikte Trennung von JavaScript und HTML? - Nein, die hältst du nämlich nicht ein.
Dein exaktes Einhalten von "best practises" Guides für JavaScript? - Die hältst du ebenfalls nicht ein, kommt also ebenfalls nicht in Frage.
Die simple, wie auch universelle Lösung des Problems? - Siehe oben den Kommentar zur universellen Lösung, also ebenfalls nicht.
Achso, abgesehen davon kann deine Lösung Spoiler nicht mehr verstecken.

Was also genau ist Dein Problem?

Ich habe mehrere objektive Kritikpunkte genannt. Du könntest sie akzeptieren und versuchen deine persönlichen Fähigkeiten auszubauen. Du könntest natürlich auch dagegen argumentieren, wenn du überzeugt bist, dass die Kritik nicht gerechtfertigt ist. Alternativ kannst du dich natürlich auch von der Kritik persönlich angegriffen fühlen und rumweinen. Ich bin gerne bereit mich in den ersten beiden Fällen mit dir auseinander zu setzen und zu diskutieren, aber wenn du hier einen auf Kleinkind machst, dann musst du dir jemand anderes suchen.

Zusätzlich hier noch zwei Punkte aus dem bp-Guide von w3schools.

Avoid Global Variables
Minimize the use of global variables.
This includes all data types, objects, and functions.
Delay JavaScript Loading
Putting your scripts at the bottom of the page body, lets the browser load the page first.

Dein unhide ist eine globale Funktion.
Deine JS-Deklaration steht im Head der Seite.

Jester · 15 Dez. 2015

@virtus:
ad 1. In meinem ersten Post war in jedem "mehr"-Span eine direkte JS-Klassenzuweisung (onclick='this.parentNode.className=') an das Eltern-p enthalten. Unter dem Markup/Snippet schrieb ich im Text, dass - für den Fall, dass das Elternelement bereits Klassennamen habe - statt der direkten Zuweisung className = .. ein className += ... eingesetzt werden muss. Bereits in diesem Zustand war die Eventualität berücksichtigt und funktional.

In Deinem Rant

"Jester: Ziemlich ungeil, wenn ein Knoten mehrere Klassennamen haben soll:
Code (HTML5):
<span class="away anythingelse">"

beziehst Du Dich eindeutig auf das Kindelement, hier gibt es kein Problem mit eventuellen Klassennamen. Da die Problemstellung für das Elternelement berücksichtigt war, ist Deine Bemerkung völlig inhaltsleer. Die Frage ist an der Stelle: hast Du es nicht richtig gelesen oder nicht richtig verstanden? Und noch etwas: zum Zeitpunkt Deines Posts war die Änderung schon lange drin.

ad 3. Das war die Eingangsvoraussetzung laut TE. Moniert wurde später, dass in den vorigen Ansätzen das more-<span> wegen der Ansprache über nextSibling gezwungenermaßen direkt an den Trigger anschließen muss. Diese Behinderung habe ich mit meinem Ansatz gelöst. Dass ein more-Container nicht im Elternelement stehen müssen soll, lese ich beim OP nicht. Du?

Final - und das geht auch an Dexter: die Aufgabenstellung ist gelöst. Vollständig.

@virtus: was ist mit Deinen anderen Accounts? Geh doch auf denen pöbeln. Immerhin bietest Du eine gewisse Stringenz in Deinem Verhalten.

Nachtrag: genau diese Art von "Diskussonen" und genau diese Art von destruktivem und sinnlos-aggressivem Verhalten sind der Grund, warum viele neue User zurückschrecken und das Board mehr oder weniger stagniert. Ich lasse mich von Dir nicht dauerhaft auf die Schiene

Die Frage ist an der Stelle: hast Du es nicht richtig gelesen oder nicht richtig verstanden?

runterziehen, auf dieser Ebene hätte ich aufgrund Deiner Professionalität keine Chance. Es liegt mir auch nichts daran - für mich ist das Thema damit durch.

dexter · 15 Dez. 2015

Jester schrieb:
Final - und das geht auch an Dexter: die Aufgabenstellung ist gelöst. Vollständig.

Verstehe das Problem nicht. Die "Aufgabenstellung" hat doch KcDaRookie schon "vollständig gelöst".
Warum sollte man jetzt nicht weiterdiskutieren dürfen, wie man was besser oder anders oder umfangreicher oder sinnvoller machen kann?

Ich formuliere meine nicht gestellte Frage mal um:
Warum sollte man aktiviertes JS voraussetzen, wenn man "die Aufgabenstellung" per CSS lösen kann?

Jester · 15 Dez. 2015

@dexter: Kann man doch, darum gings doch gar nicht.

virtus · 16 Dez. 2015

dexter schrieb:
Verstehe das Problem nicht. Die "Aufgabenstellung" hat doch KcDaRookie schon "vollständig gelöst".
Warum sollte man jetzt nicht weiterdiskutieren dürfen, wie man was besser oder anders oder umfangreicher oder sinnvoller machen kann?

Ich formuliere meine nicht gestellte Frage mal um:
Warum sollte man aktiviertes JS voraussetzen, wenn man "die Aufgabenstellung" per CSS lösen kann?

Jester schrieb:
@dexter: Kann man doch, darum gings doch gar nicht.

Bla bla bla off topic gelaber.

beziehst Du Dich eindeutig auf das Kindelement, hier gibt es kein Problem mit eventuellen Klassennamen.

Das habe ich dann wohl falsch gesehen, macht deinen Code aber nicht per se besser.

Da die Problemstellung für das Elternelement berücksichtigt war, ist Deine Bemerkung völlig inhaltsleer.

Wie jetzt, weil dein Code Abhängigkeiten erzwingt, die nicht sein müssten, ist Kritik unpassend?

Das war die Eingangsvoraussetzung laut TE.

Die Anforderung des TS war, dass der Code möglichst simpel und kurz ist, nicht, dass er möglichst hingesaut wird. Vielleicht gehen unsere Interpretationen von den Anforderungen des TS in unterschiedliche Richtungen.

Moniert wurde später, dass in den vorigen Ansätzen das more-<span> wegen der Ansprache über nextSibling gezwungenermaßen direkt an den Trigger anschließen muss. Diese Behinderung habe ich mit meinem Ansatz gelöst. Dass ein more-Container nicht im Elternelement stehen müssen soll, lese ich beim OP nicht. Du?

Nein, aber es steht auch nirgends, dass diese Abhängigkeit gegeben sein muss. Wenn du deinen Wagen zur Werkstatt bringst, um die defekten Scheibenwischer reparieren zu lassen, dann akzeptierst du wohl auch nicht, wenn der dir die Frontscheibe zerschlägt. Die Lösung reicht nämlich ebenfalls aus, um das Problem mit den defekten Scheibenwischern zu lösen. In der Praxis muss so eine Lösung angemessen und verhältnismäßig sein. Man spricht da auch von "erwartungsgemäß".

genau diese Art von "Diskussonen" und genau diese Art von destruktivem und sinnlos-aggressivem Verhalten

Ich habe es in einem vorherigen Post bereits gesagt und wiederhole mich gerne noch mal:

Ich habe mehrere objektive Kritikpunkte genannt. Du könntest sie akzeptieren und versuchen deine persönlichen Fähigkeiten auszubauen. Du könntest natürlich auch dagegen argumentieren, wenn du überzeugt bist, dass die Kritik nicht gerechtfertigt ist. Alternativ kannst du dich natürlich auch von der Kritik persönlich angegriffen fühlen und rumweinen.

"destruktiv und sinnlos-aggressiv" hätte ich mich circa so ausgedrückt: Dein Code ist Scheiße und überhaupt bist du Scheiße, geh doch mit was giftigem Spielen.
Dich stattdessen auf die Schwächen deiner Implementierung aufmerksam zu machen und darauf hinzudeuten, was man hätte besser machen können, ist alles andere als destruktiv. Es ist die konstruktivste Form der Kritik, die man geben kann. :unknown:

dexter · 16 Dez. 2015

/me verteilt Kekse.

Und zurück zum (technischen) Thema. Mimositäten dürft ihr gerne woanders ausmachen. (technische) Lösungen oder Anregungen hier. Dazu zählt auch so Quark wie:

@F.L.X: Melde dich mal per PN,

Kurzfassung: technische Lösungen und Anregungen hier, mimimi per PN und nicht andersrum. Danke.

virtus · 17 Dez. 2015

Ich glaube ich kann ganz gut selbst entscheiden ob und welche Lösungen ich wem wie zur Verfügung stelle.
Faulheit unter "Programmierern" unterstütze ich nicht. Hinweise, wie eine saubere Lösung aussehen kann, habe ich hinreichend gegeben und wenn jemand Fragen hat, dann kann er diese stellen. Jeder mit ein wenig Interesse und Programmiererfahrung kann sich das selbst basteln. F.L.X. scheint mir kein Programmierer zu sein und sofern er Interesse hat, stelle ich ihm die Lösung zur Verfügung.

theSplit · 17 Dez. 2015

@virtus

- da ist jemand aber jetzt etwas sehr sensibel.

Dexter hat doch nur gesagt, persönliches Heckmeck außerhalb des Threads - obwohl das unnötige Energieverschwendung ist und nervig dazu - und die technischen Pros und Cons gern hier mit rein. Ganz normal.

[KLUGSCHEISS-MODUS-AN]
Als Programmierer sollte man in der Lage sein mit "Code"-Kritik (was nichts persönliches ist) umzugehen, ohne gleich an die Decke zu gehen.

[KLUGSCHEISS-MODUS-AUS]

onclick unhide <span>blabla</span>

F.L.X

Neu angemeldet

KcDaRookie

Temporär Suspendiert :D

theSplit

1998

virtus

Gehasst

Jester

★★★★☆ (Kasparski)

F.L.X

Neu angemeldet

virtus

Gehasst

Jester

★★★★☆ (Kasparski)

dexter

Cloogshicer®

virtus

Gehasst

Jester

★★★★☆ (Kasparski)

dexter

Cloogshicer®

Jester

★★★★☆ (Kasparski)

virtus

Gehasst

dexter

Cloogshicer®

virtus

Gehasst

theSplit

1998