Technische Fragen zu einer Seite, die nur aus einer Seite besteht

[Rüdi]

Hi, es gibt ja diese Seiten, die quasi nur aus einer einzigen bestehen und oben im Menü Anker gesetzt werden, die dann mittels <a href="#seite> auf den Bereich scrollen. Leider finde ich gerade keine Beispielseite, dennoch habe ich dazu einige Fragen:

I) Teile ich die einzelnen Seitenbereiche auch in <section> bzw. <article> ein? Also quasi mehrere <section> untereinander, alles "umzäunt" von einer <main>? Oder löse ich das mit <div>-Bereichen?

II) Wie erreiche ich, dass immer genau eine Bildschirmseite gefüllt wird? Mit width und height 100%?

III) Ich würde gerne jeweils ein anderes Hintergrundbild pro <section> machen, das dann ebenfalls in voller Breite und Höhe angezeigt wird. Welcher CSS-Befehl wird dafür benötigt?

IV) Die besagten Menüs oben am Rand, die immer da bleiben ("sticky"): Gibt es die auch aus purem CSS? Ich finde nur Lösungen, die JS beinhalten.

V) Haben diese "einseitigen Seiten" einen Namen?

Vielen Dank für die Antworten und Hilfestellungen!

[MrMurphy1]

Hallo,

deine Vorstellungen haben mit aktuellen Webseiten leider wenig zu tun.

Das Hauptproblem bei einer Antwort sind deine fehlenden Informationen zum Inhalt der Webseite. Von daher können wir dir nur sagen was unsinnig ist, aber nicht so richtig erklären warum.

I.) Das kommt auf den Inhalt an. Da auf einseitigen Webseiten aber keine zusätzlichen Informationen auf anderen Seiten vorliegen können wird das article-Element am sinnvollsten sein.

II.) Dazu muss erst mal geklärt werden, wieviel Inhalt die Seite hat und wie sie sich auf Smartphones und Tablets verhalten soll.

III.) Das gleiche wie bei II.). Zusätzlich: Wie soll sich das Bild bei Hoch- und Querformat verhalten?

IV.) Ja. Allerdings muss geklärt werden wie wichtig dir Spielereien sind, die nur mit JS eingebaut werden können.

V.) One-Pager oder One-Page-Design.

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

I.) Das kommt auf den Inhalt an.

Unbedingt.

Da auf einseitigen Webseiten aber keine zusätzlichen Informationen auf anderen Seiten vorliegen können wird das article-Element am sinnvollsten sein.

Die Begründung verstehe ich nicht. Ich würde denken, dass i.d.R. section am sinnvollsten wäre. Aber siehe I.

LLAP 🖖

[Friderike Feldsalat]

es gibt ja diese Seiten, die quasi nur aus einer einzigen bestehen und oben im Menü Anker gesetzt werden, die dann mittels <a href="#seite> auf den Bereich scrollen. Leider finde ich gerade keine Beispielseite, dennoch habe ich dazu einige Fragen:

I) Teile ich die einzelnen Seitenbereiche auch in <section> bzw. <article> ein? Also quasi mehrere <section> untereinander, alles "umzäunt" von einer <main>? Oder löse ich das mit <div>-Bereichen?

Der Anker hinter der Raute wird seit der HTML-Steinzeit über ein passendes <a name="anker"> angesteuert. Statt des name-Attributs sollte allerdings das id-Attribut benutzt werden, und das funktioniert dann bei beliebigen Elementen, <h1 id="anker"> kannst du also ebenfalls über seite.html#anker ansteuern.

II) Wie erreiche ich, dass immer genau eine Bildschirmseite gefüllt wird? Mit width und height 100%?

Mit den Maßen vw und vh (http://www.w3.org/TR/css3-values/#viewport-relative-lengths). Ob das sinnvoll ist, insbesondere, wenn der Inhalt größer ist als das Browserfenster, lasse ich mal dahingestellt.

III) Ich würde gerne jeweils ein anderes Hintergrundbild pro <section> machen, das dann ebenfalls in voller Breite und Höhe angezeigt wird. Welcher CSS-Befehl wird dafür benötigt?

Befasse dich mit, Überraschung!, der background-Attributfamilie. Seite darfst du selbst raussuchen, denn auf die Idee, bei Fragen zum Hintergrund im Bereich CSS nach irgendwas mit "background" im Namen zu suchen, solltest du eigentlich eigenständig kommen.

IV) Die besagten Menüs oben am Rand, die immer da bleiben ("sticky"): Gibt es die auch aus purem CSS? Ich finde nur Lösungen, die JS beinhalten.

position:fixed (siehe http://www.w3.org/TR/CSS21/visuren.html#fixed-positioning). Javascript ist nötig, um den sehr ähnlichen Effekt von position:sticky (https://drafts.csswg.org/css-position/#fixed-pos) zu erreichen, da dies derzeit nur von Firefox und Webkit unterstützt wird.

V) Haben diese "einseitigen Seiten" einen Namen?

Spielkram?

[MrMurphy1]

Hallo

Spielkram?

Das sehe ich anders. Grade wenn eine Webseite relativ wenig Inhalt hat ist es benutzerfreundlicher, diesen auf einer Seite zu präsentieren als zwanghaft mehrere Seiten zusätzlich mit hohlen Floskeln zu füllen. Deshalb haben One-Pager durchaus ihre Berechtigung.

Die Besucher kommen so auch viel schneller an die Informationen die sie suchen.

Nachtrag: Siehe zum Beispiel

http://t3n.de/news/one-page-design-webdesign-trend-471366/

Gruss

MrMurphy

[Leander]

Ja, ist wahr, wenn ich eine Dokumentation scrape und die aus Hunderten Seiten besteht und keine Druckansicht all-in-one-page bietet, ist das einfach nur lästig.

[Gunnar Bittersmann]

@@Friderike Feldsalat

Der Anker hinter der Raute wird seit der HTML-Steinzeit über ein passendes <a name="anker"> angesteuert.

Die Steinzeit ist vorbei. In der Neuzeit (HTML5) gibt es <a name="anker"> nicht mehr.

<h1 id="anker"> kannst du also ebenfalls über seite.html#anker ansteuern.

Sinvoller ist es, das Containerelement (bspw. <section id="anker">) als Anker zu verwenden.

II) Wie erreiche ich, dass immer genau eine Bildschirmseite gefüllt wird? Mit width und height 100%?

Mit den Maßen vw und vh (http://www.w3.org/TR/css3-values/#viewport-relative-lengths).

vh ja, vw eher nein. Viewport vs Percentage Units

LLAP 🖖

[Gunnar Bittersmann]

@@Rüdi

I) Teile ich die einzelnen Seitenbereiche auch in <section> bzw. <article> ein? Also quasi mehrere <section> untereinander, alles "umzäunt" von einer <main>? Oder löse ich das mit <div>-Bereichen?

Ob section, article oder gar div das passende Element ist, hängt vom Inhalt ab.

II) Wie erreiche ich, dass immer genau eine Bildschirmseite gefüllt wird? Mit width und height 100%?

Mit der Viewport-Einheit vh.

Interessant dürften auch scroll snap points sein. Can I use?

III) Ich würde gerne jeweils ein anderes Hintergrundbild pro <section> machen, das dann ebenfalls in voller Breite und Höhe angezeigt wird. Welcher CSS-Befehl wird dafür benötigt?

Für die Größe des Hintergrundbildes? Ähm, background-size vielleicht? Und ehm, kein Befehl.

IV) Die besagten Menüs oben am Rand, die immer da bleiben ("sticky"): Gibt es die auch aus purem CSS? Ich finde nur Lösungen, die JS beinhalten.

Das wird schwierig. Wenn das Menü durch position: fixed am oberen Viewportrand fixiert wird, müssen alle Bereiche padding-top entsprechend der Höhe des Menüs bekommen. Dumm nur, dass man diese nicht kennt.

LLAP 🖖

[Sara]

Hallo,

Interessant dürften auch scroll snap points sein. Can I use?

95% rot, würde ich auf einer produktiven Seite niemals einsetzten. Selbst der Google Chrome der eigentlich immer ganz vorne mit dabei ist, kann es noch nicht.

[Gunnar Bittersmann]

@@Sara

Hallo,

Interessant dürften auch scroll snap points sein. Can I use?

95% rot, würde ich auf einer produktiven Seite niemals einsetzten. Selbst der Google Chrome der eigentlich immer ganz vorne mit dabei ist, kann es noch nicht.

Ja und?

Warum sollte man das in Browsern, die das schon unterstützen, nicht schon einsetzen? Dann haben deren Nutzer ein noch besseres Nutzungserlebnis als Nutzer anderer Browser (für die die Seite natürlich trotzdem voll funktionstüchtig ist) – progressive enhancement.

LLAP 🖖

[Sara]

Hallo,

Warum sollte man das in Browsern, die das schon unterstützen, nicht schon einsetzen? Dann haben deren Nutzer ein noch besseres Nutzungserlebnis als Nutzer anderer Browser (für die die Seite natürlich trotzdem voll funktionstüchtig ist) – progressive enhancement.

weil man ständig irgendwelche Fallbacks für ältere Browser einbauen muss, was die Wartung nicht gerade besser / einfacher macht. Außerdem wie rechtfertigst du gegenüber deinem Kunden der Mehraufwand und dadurch die höheren Kosten?

[Gunnar Bittersmann]

@@Sara

Warum sollte man das in Browsern, die das schon unterstützen, nicht schon einsetzen? Dann haben deren Nutzer ein noch besseres Nutzungserlebnis als Nutzer anderer Browser (für die die Seite natürlich trotzdem voll funktionstüchtig ist) – progressive enhancement.

weil man ständig irgendwelche Fallbacks für ältere Browser einbauen muss,

Ich dachte, ich hätte progressive enhancement verständlich beschrieben. Man muss eben nicht irgendwelche Fallbacks für ältere Browser einbauen.

Die Seite funktioniert grundlegend in allen Browsern. In Browsern, die ein gewisses Feature unterstützen, wird die Seite um dieses Feature angereichert (englisch: enhanced). Womöglich sieht eine Seite in verschiedenen Browsern je nach deren Fähigkeiten unterschiedlich aus. Warum denn auch nicht?

Außerdem wie rechtfertigst du gegenüber deinem Kunden der Mehraufwand und dadurch die höheren Kosten?

Da der Mehraufwand gleich null ist, sollte das kein Problem sein.

LLAP 🖖

[Sara]

Hallo,

Womöglich sieht eine Seite in verschiedenen Browsern je nach deren Fähigkeiten unterschiedlich aus. Warum denn auch nicht?

Wenn dieses deine Meinung ist, ok! Wenn deine Kunden dieses auch noch akzeptieren umso besser. Wir haben mit Kunden in der Agentur zu tun wo sehr großen Wert drauf legen, dass ihre neue Webseite / Grafiken in allen relevanten Browsern gleich aussehen.

[Gunnar Bittersmann]

@@Sara

Wenn dieses deine Meinung ist, ok!

Es ist nicht nur meine Meinung. Jeremy Keith bspw. ist es immer wert, gehört und gelesen zu werden.

Wir haben mit Kunden in der Agentur zu tun wo sehr großen Wert drauf legen, dass ihre neue Webseite / Grafiken in allen relevanten Browsern gleich aussehen.

1. Kein Nutzer legt großen Wert darauf, dass eine Webseite in verschiedenen Browsern (auf demselben System) gleich aussieht. Nutzer vergleichen das überhaupt nicht; sie verwenden auf einem System einen bestimmten Browser.
    
   Auf verschiedenen Geräten muss eine Webseite zwangsläufig unterschiedlich aussehen – jeweils ans Gerät angepasst.

2. Womöglich liegt das nicht an euren Kunden, sondern an euch. Wenn man einen Kunden fragt „Möchten Sie, dass Ihre Seite in allen Browsern gleich aussieht?“, dann wird der wohl mit Ja antworten. Das ist aber die falsche Frage, um sie einem Kunden zu stellen.
    
   Wenn man den Kunden fragt „Möchten Sie, dass Ihre Seite in allen Browsern bestmöglich aussieht?“, dann wird der wohl mit Ja antworten. Bestmöglich in einem Browser heißt: je nach Fähigkeiten dieses Browsers. Also in verschiedenen Browsern unterschiedlich.
    
   Stellt die richtigen Fragen, dann bekommt ihr auch die richtigen Antworten.

LLAP 🖖

[Sara]

Hallo,

2. Womöglich liegt das nicht an euren Kunden, sondern an euch. Wenn man einen Kunden fragt „Möchten Sie, dass Ihre Seite in allen Browsern gleich aussieht?“, dann wird der wohl mit Ja antworten. Das ist aber die falsche Frage, um sie einem Kunden zu stellen.
   Wenn man den Kunden fragt „Möchten Sie, dass Ihre Seite in allen Browsern bestmöglich aussieht?“, dann wird der wohl mit Ja antworten. Bestmöglich in einem Browser heißt: je nach Fähigkeiten dieses Browsers. Also in verschiedenen Browsern unterschiedlich.

das ist eine sehr gute Idee, diese werde ich beim nächsten Kundengespräch 100% berücksichtigen. Danke für den Tipp. Bis jetzt stellten wir wirklich immer die Frage, soll / muss ihre Seite in allen relevanten Browsern gleich aussehen. Natürlich lautete die Antwort "ja". Also letzten wir uns hin und haben diverse Browser auf und schauen, dass alles ja am gleichen Platz ist. Arbeit ohne ende, aber das muss ich dir bestimmt nicht sagen :)

[Gunnar Bittersmann]

@@Sara

… Also letzten wir uns hin und haben diverse Browser auf und schauen, dass alles ja am gleichen Platz ist. Arbeit ohne ende, aber das muss ich dir bestimmt nicht sagen :)

Schade um die Zeit, oder? Was hätte man in der Zeit alles Nützliches machen können!

Genau wie Jeremy Keith sagt (Übersetzung von mir):

„Es ist ein verbreiteter Irrglaube, dass progressive enhancement heißt, seine Zeit in alte Browser zu stecken – das Gegenteil ist der Fall. Die Grundfunktionalität zu erstellen dauert nicht allzu lange. Wenn man das getan hat, kann man seine Zeit damit verbringen, mit den neusten und großartigsten Browsertechnologien zu experimentieren; sicher in dem Wissen, dass selbst wenn diese noch nicht weitgehend unterstützt werden, man den Fallback ja bereits hat.

Der Schlüssel zu diesem Ansatz der Webentwicklung ist die Erkenntnis, dass es nicht ein einziges Nutzerinterface gibt – es kann viele leicht verschiedene Interfaces geben, abhängig von den Eigenschaften und Fähigkeiten des jeweiligen Browsers und Gerätes zum jeweiligen Zeitpunkt. Und das ist auch völlig in Ordnung. Webseiten müssen nicht in jedem Browser gleich aussehen.

Wenn man das so akzeptiert, ist das ein wahrhaft befreiender Gedanke. Anstatt seine Zeit mit dem Versuch zu verbringen, Webseiten in den verschiedensten Browsern gleich aussehen zu lassen, kann man seine Zeit darin investieren sicherzustellen, dass die Kernfunktion dessen, was man baut, überall funktioniert, und gleichzeitig in fähigeren Browsern die bestmögliche Nutzungserfahrung zu bieten.“

Ende der Predigt. ;-)

LLAP 🖖

[Sara]

Hallo,

soll es in diese Richtung gehen?

http://stanhub.com/tutorials/change-active-state-in-sticky-navigation-on-scroll/

[Rüdi]

Vielen Dank für all die Antworten!

Die letzte Variante kommt meinem Vorhaben sehr nahe, vielen Dank dafür!

Ich habe mir über das "Spielkram"-Argument auch Gedanken gemacht. Ich denke das nicht und sehe es wie Mr Murphy: Wenn es nicht so viel Inhalt gibt, ist das durchaus sinnig.

[Friderike Feldsalat]

Ich habe mir über das "Spielkram"-Argument auch Gedanken gemacht.

Ein Wort mit Fragezeichen dahinter täte ich nicht als Argument bezeichnen, aber wenn nun schon zwei darauf so anspringen, scheint's ja getroffen zu haben :>

[Rüdi]

Ich habe mir über das "Spielkram"-Argument auch Gedanken gemacht.

Ein Wort mit Fragezeichen dahinter täte ich nicht als Argument bezeichnen, aber wenn nun schon zwei darauf so anspringen, scheint's ja getroffen zu haben :>

Das war auch keine Kritik meinerseits.

Das Beispiel von Sara hat den Haken, dass das Menü nicht mitmacht. Ich kann das gerade nicht testen, aber im Quellcode steht 960px für nav. Macht man einfach 100% draus und dann klappt das?

[Sara]

Hallo,

Das Beispiel von Sara hat den Haken, dass das Menü nicht mitmacht. Ich kann das gerade nicht testen, aber im Quellcode steht 960px für nav. Macht man einfach 100% draus und dann klappt das?

was soll das Menü denn machen? Wenn du aus den 960px 100% machst, nimmt das Menü die ganze Breit ein und wird links oben angedockt. Mit den 960px begrenzt du dieses etwas. Allerdings sollte man auf PX wenn möglich verzichten und lieber zu % em uswm. zurückgreifen.

[encoder]

V) Haben diese "einseitigen Seiten" einen Namen?

Ich nenne sie: Immer öfter anzutreffender, langweilig aussehender Einheitsbrei, der leider für mobile Geräte nötig ist um ein paar Byte Datenvolumen zu sparen und auch auf kleinen Displays Inhalt zwar nicht ansprechend aber immerhin erkennbar darzustellen :-)

Peppe die Seite wenigstens ein bisschen auf damit sie etwas aus dem sich verbreitenden Windows 8 - Look ausbricht: eine Hintergrundfarbe und eine Textfarbe. Es ist gruslig zu sehen was aus manchem Webseiten wurde seit sie mobil erreichbar sein sollen.

Ja ich weiß dieser Beitrag ist keine Antwort. Vielleicht hilft er dem Threadersteller trotzdem was schöneres zu entwerfen als er vor hat.

[Gunnar Bittersmann]

@@encoder

V) Haben diese "einseitigen Seiten" einen Namen? Ich nenne sie: Immer öfter anzutreffender, langweilig aussehender Einheitsbrei, der leider für mobile Geräte nötig ist um ein paar Byte Datenvolumen zu sparen und auch auf kleinen Displays Inhalt zwar nicht ansprechend aber immerhin erkennbar darzustellen :-)

So eine „einseitige Seite[sic!]“ kann bei Storytelling schon sinnvoll sein. Da scrollen Nutzer dann auch, um den Inhalt zu lesen.

Was man aber nicht tun sollte: viele verschiedenartige Inhalte untereinander auf eine Seite zu packen. Woher soll der Nutzer erkennen, was ihn weiter unten noch so alles erwartet?

Luke Wroblewski: “Somebody will take their desktop site and they're like, OK, we squeezed it into a single column. Mobile website. Right. I love the responsive design methodology for adapting to lots of different devices, but many responsive sites you look at are like, you know how we're going to solve mobile? One big long list. Great.

And you may say, well, what's wrong that Luke? Well let's take a look at one of the premiere examples of responsive web design, the Boston Globe. […]

So when I hit this page, it looks like there is a game going on and Obama is mad about something. That's like it. That's all I get. And then I scroll. And I scroll. And it turns out, oh what was that? Was it like some opinion? Oh they have sports things here too. What? Metro? Nation, and the world, politics, who knew politics was here? Business, hey. Going, going, going. I removed the ad. Going, going, going. Still going. Phew. They managed to fit it all in. Good. […]

And you may look at this and say, but Luke, Luke, Luke, people will scroll. Yeah, people will scroll. I'm not saying scrolling is bad. […]

So scrolling is not bad. Josh Porter actually says this nicely, scrolling is a continuation, an example that highlights it. Like am I interested in this? Let me read a little bit more. Oh OK. Whereas a click is a decision. So people understand this context. They know the modality they're in. They will continue to scroll, and it's not an issue.

Long pages and these things become an issue, if you don't understand the context. So when you just take a web page, and you fold it into one big scrolling list, there is this flat hierarchy, and that everything's equal. You got no idea what down here. […]”

LLAP 🖖

[encoder]

So eine „einseitige Seite[sic!]“ kann bei Storytelling schon sinnvoll sein.

Wenn mans richtig macht, ja. Ich sehe nur immer wieder den Trend, alles auf eine Seite zu packen, was man vorher in sinnvolle Unterseiten gepackt hat. Selbst wenn es thematisch zusammengehört, hatten verschiedene Seiten eine bessere Unterteilung. Nachdem man bei mobil optimierten Seiten die Navigation gerne schmälert, findet man auf der großen Seite erst recht nichts mehr. Der Autor nimmt währenddessen an er hätte alles richtig gemacht. Da möchte ich zum nachdenken anregen.

[Leander]

Hallo,

I) Teile ich die einzelnen Seitenbereiche auch in <section> bzw. <article> ein? Also quasi mehrere <section> untereinander, alles "umzäunt" von einer <main>? Oder löse ich das mit <div>-Bereichen?

Das kannst Du selbst entscheiden, Ein Artikel kann mehrere Sektionen haben. Und eine Sektion kann mehrere Artikel haben. Wenn alles der gleiche Inhalt ist, sollte das äußerste Element article sein, wenn es eine Kollektion von Artikeln ist, wie zum Beispiel auf der Frontseite einer Nachrichtenseite, dann sollte das äußerste eine section sein. Wenn Du article verwendest, tue bitte die Überschriften, Autor, Erstelldatum, weiterführende Links mit rein, sonst macht mir das nachher beim Scrapen nur wieder Arbeit. Die Kommantare kannste draußen lassen, die guten sollten eh in den Artikel eingearbeitet werden.

II) Wie erreiche ich, dass immer genau eine Bildschirmseite gefüllt wird? Mit width und height 100%?

Das würde ich lassen. Lass es frei fließen.

III) Ich würde gerne jeweils ein anderes Hintergrundbild pro <section> machen, das dann ebenfalls in voller Breite und Höhe angezeigt wird. Welcher CSS-Befehl wird dafür benötigt?

Das würde ich auch lassen. Stört beim lesen, ist das erste was ich beim scrapen entferne.

IV) Die besagten Menüs oben am Rand, die immer da bleiben ("sticky"): Gibt es die auch aus purem CSS? Ich finde nur Lösungen, die JS beinhalten.

CSS position static aber auch das gefällt nicht jedem, zum Beispiel nicht mir. Mitscrollen rechts und links geht gerade so, weil da mehr Platz ist. Aber ich hab für sauber verschachtelte Überschriften sowieso ein Firefox Addon am Start, das mir alles schön übersichtlich und ein-/ausklappbar in meiner Seitenleiste anzeigt.

Oben oder unten mitscrollende Leisten ist für mich ein rotes Tuch. Bewirkt sofortiges wegklicken der Seite oder tweaken mit Yarip. Praktischerweise machst Du das mit Javascript, dann muß ich nur Javascript deaktivieren.

V) Haben diese "einseitigen Seiten" einen Namen?

ich würde hier eher von Webdokument sprechen, während mehrere Seiten eine Website (ohne "e") bilden. Wobei z.B. die Selfhtml Doku sicherlich keine Website ist, sondern eine Dokumentation.

Gruß, Leander

[Hecke]

...wenn man das gepostete Beispiel nimmt...

Hier isses:

Ist es dann möglich, dass das "Sticky" Menü bei mobilen Geräten "klappbar" wird, also wie ein Drop-Down? Das ist doch bei mobilen Seiten gängig.

[Camping_RIDER]

Aloha ;)

...wenn man das gepostete Beispiel nimmt...

Hier isses:

Ist es dann möglich, dass das "Sticky" Menü bei mobilen Geräten "klappbar" wird, also wie ein Drop-Down? Das ist doch bei mobilen Seiten gängig.

Selbstverständlich. Das kann man sogar mit reinem CSS umsetzen; du benötigst dazu ein media-query, das bei entsprechender Bildschirmbreite (bzw. Mangel davon) geeignete CSS-Regeln in Kraft setzt. Das Aufklappen kann dann zum Beispiel über die Pseudoklassen focus und active oder mit Hilfe des CSS Checkbox Hack geschehen (letztere Möglichkeit präferiere ich; einen Artikel auf deutsch in unserem Wiki dazu gibts leider erst, wenn ich dazu komme).

Jedenfalls kann die Schaltfläche zum Aufklappen bei größeren Bildschirmbreiten mit display:none ausgeblendet werden und bei kleineren Bildschirmbreiten eingeblendet, während die Links ausgeblendet werden - die Einblendung geschieht dann im :active-/:hover-Teil bzw. im input[type=checkbox]:checked-Teil und kann sogar mit einer Änderung der Schaltfläche (per content: oder background-image:) einhergehen.

Schau dir die verlinkten Sachen an und frag nach, wenn du etwas nochmal erklärt haben möchtest, mir fehlt gerade die Muse zur Fleißarbeit und vorauseilenden ausführlichen Erklärung ;)

Grüße,

RIDER