nicht angemeldet
tabs und body aktualisieren
Rolf B
Orlok
Matthias Apsel
Matthias ScharwiesHallo
Ich habe eine Seite mit Tabs, die per CSS gesteuert werden. Wenn ich nun auf einen Tab drücke, wird per JavaScript eine PHP Seite in den Body geladen. Mit dieser PHP Seite möchte ich das ein User sein Kennwort ändern kann. Die Meldungen, die von der PHP Seite kommen, z.B. Kennwort erfolgreich geändert, möchte ich wieder in dem Tab zur Verfügung stellen, ohne das sich die ganze Seite erneut lädt. Ich hoffe das war verständlich, hier der Code.
Test.html
<!doctype html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=yes">
<script src="jquery.js" type="text/javascript"></script>
<script type="text/javascript">
function kb_source_2_target(tabseite) {
//alert(tabseite);
$.get(tabseite, function(data) {
$('#div_body').html(data);
})
}
</script>
</head>
<style>
.menueleiste {
border-bottom: 2px solid #CE1719;
width: 90%;
margin-left: auto;
margin-right: auto;
display: flex;
}
.tab [type=radio] {
display: none;
}
/* normler Tab */
.tab label {
border : 2px solid #CE1719;
width: 100px;
height:auto;
border-radius: 5px 5px 0px 0px;
}
/* Tab beim �berfahren */
.tab:hover + label {
border : 0px solid white;
width: 100px;
height:auto;
border-radius: 5px 5px 0px 0px;
}
/* Aktiver Tab */
[type=radio]:checked + label {
border : 2px solid #CE1719;
width: 100px;
height:auto;
border-bottom-color: aqua;
background-color: aqua;
border-radius: 5px 5px 0px 0px;
}
.body {
border : 2px solid #CE1719;
background-color: aqua;
margin-top: -2px;
width: 90%;
margin-left: auto;
margin-right: auto;
height: 500px;
}
</style>
<body>
<div class="menueleiste">
<div class="tab">
<input type="radio" id="tab-1" name="tab-group-1" onclick="kb_source_2_target('passwortwechsel.php')">
<label for="tab-1">Kennwort aendern</label>
</div>
<div class="tab">
<input type="radio" id="tab-2" name="tab-group-1" onclick="kb_source_2_target('leer.php')">
<label for="tab-2">Benutzer</label>
</div>
</div>
<div class="body" id="div_body">
</div>
</body>
</html>
passwortwechsel.php
<?php
if ($_POST['pwweg'] == 'Abschicken') {
// sql abfragen und �berpr�fung des kennworts wenn alles ok geht es mit header('') weiter
header('location: test.html');
}
?>
<form method="POST" action="passwortwechsel.php">
<div id="div_changepass"><h1>Kennwort �ndern</h1></div>
<div class="">
<input type="text" name="altespasswort" placeholder="altes Kennwort" required>
</div>
<div class="">
<input type="text" name="nneuespasswort1" placeholder="neues Kennwort" required>
</div>
<div class="">
<input type="text" name="neuespasswort2" placeholder="neues kennwort" required>
</div>
<div class="">
<input type="Submit" name="pwweg" value="Abschicken">
</div>
</form>
kann mir da jemand helfen.
Danke
-
Hallo sascha321,
ENTWEDER Tabs mit partiellen Reload ODER ein Tab-artiges Erscheinungsbild mit klassischen Full-Reload.
Wenn Du möchtest, dass das Passwort-Tab kein Neuladen der ganzen Seite auslöst, musst du Ajax-Techniken verwenden. Das Spektrum ist breit. Auf jeden Fall darfst Du das Form für die Passwortänderung nicht einfach abschicken, sondern musst das Submit-Event des Form abfangen, den Server-Request als XMLHttpRequest selbst schicken und die Antwort ins Tab einbauen.
jQuery.post() oder jQuery.load() können dir dabei helfen.
Wenn Du am Server einen location Header setzt, ist das ein Status Code 302, dem folgt der XMLHttpRequest automatisch. Du solltest also auf eine PHP Seite umleiten, die als Tab-Inhalt geeignet ist. Oder du machst keinen Redirect, sondern sendest gleich den neuen Tab-Inhalt.
Rolf
--
sumpsi - posui - clusi -
Hallo Sascha
Ich habe eine Seite mit Tabs, die per CSS gesteuert werden.
Nein, hast du nicht.
Jedenfalls nicht, wenn du damit die Seite meinst, deren Code du hier gepostet hast. Zwei Radiobuttons und ein paar
div-Elemente ohne besondere Bedeutung sind noch keine Tabs. Es sind nur zwei Radiobuttons und ein paardiv-Elemente ohne besondere Bedeutung. Wenn du Tabs willst, dann musst du das im Markup entsprechend kenntlich machen. Außerdem musst du mit JavaScript dafür sorgen, dass die Tabs den Erwartungen der Benutzer gemäß bedient werden können. Eine Implementierung von Tabs nur mit CSS kannst du vergessen.Die Umsetzung eines Tabbed Interface ist keine ganz triviale Aufgabe. Damit ein solches Widget von allen Benutzern erkannt und bedient werden kann, müssen viele Aspekte beachtet werden. Es genügt nicht, etwas bloß wie Tabs aussehen zu lassen. Der Zweck der Elemente muss auch für diejenigen Benutzer erkennbar sein, die sich die Inhalte der Seite vorlesen lassen, statt sie selbst in Augenschein zu nehmen. Zusätzlich gibt es Konventionen in Bezug auf die Tastaturbedienbarkeit von Tabs, die zu berücksichtigen sind, um den Benutzern die Bedienung nicht unnötig zu erschweren.
Was ist bei der Implementierung von Tabs zu beachten?
Fallback
Bevor man sich überlegt, wie Tabs implementiert werden könnten, sollte man sich erst einmal Gedanken darüber machen, wie die Inhalte strukturiert sein sollen, wenn JavaScript nicht zur Verfügung steht. Eine korrekte Implementierung von Tabs ist ohne die Verwendung von JavaScript nicht möglich, aber es gibt tausend Gründe, aus denen ein Programm nicht geladen oder ausgeführt werden kann. Wenn du nicht mehr oder weniger willkürlich Benutzer von der Bedienung deiner Seite ausschließen willst, brauchst du also eine Alternative, welche nicht von der Ausführung eines Skripts abhängig ist.
Die übliche Vorgehensweise in diesem Fall ist, die Inhalte der Tabs grundsätzlich anzuzeigen und sie über eine seiteninterne Navigation zu verlinken. Steht JavaScript zur Verfügung, werden programmatisch alle Inhalte ausgeblendet, außer denjenigen, die zum anfänglich ausgewählten Tab gehören. Die seiteninterne Navigation wird durch das Skript entweder in eine Liste von Tabs umgebaut, oder durch eine solche Liste ersetzt.
Die Navigation zu ersetzen ist meiner Meinung nach dem Umbau vorzuziehen. Es ist mit weniger Aufwand verbunden und verbessert die Les- und Wartbarkeit des Codes. Das Markup für die Liste mit den Tabs kann in einem
template-Element notiert werden. Der Inhalt dieses Elements wird zusammen mit dem Rest der Seite geparst, aber nicht gerendert. Ein Programm kann über diecontent-Eigenschaft dieses Elements auf dessen Inhalt zugreifen und ihn an der gewünschten Stelle in die Seite einfügen. Die dort bereits vorhandene Navigation wird im gleichen Schritt entfernt.Erkennbarkeit
Mit den Komponenten eines Tabbed Interface sind bestimmte Rollen verknüpft. Damit alle Benutzer die Chance haben, die Bedeutung eines solchen Widgets zu erkennen, müssen diese Rollen den Elementen, welche die jeweiligen Komponenten repräsentieren, unter Verwendung des
role-Attributs ausdrücklich zugewiesen werden. Durch das Hinzufügen des Attributs wird die ursprüngliche Semantik der Elemente überschrieben. Zur Verbesserung der Bedienbarkeit ist darüber hinaus dafür zu sorgen, dass alle verwendeten Elemente einen passenden Accessible Name besitzen, also einen Namen, der eine nützliche Beschreibung des jeweiligen Elements ermöglicht. Schließlich ist es auch erforderlich, dass der aktuelle Zustand des Widgets in einer allgemein verständlichen Weise kenntlich gemacht wird.Tabliste
Dem Element, das die Tabs gruppiert, wird die Rolle
tablistzugewiesen. Dabei kann es sich im Prinzip um irgendein Element handeln. Das heißt, es wäre nicht falsch, an dieser Stelle eindivzu verwenden. Gemäß dem Fall, dass eine bereits existierende Navigation umgebaut werden soll, wäre die Liste mit den Links das Ziel dieser Rollenzuweisung. Wird eine geordnete oder ungeordnete Liste wiederverwendet, sollte außerdem den Kindern der Liste, also denli-Elementen, die Rollenonezugewiesen werden. Die Kindelemente einer Tabliste sind Tabs und sonst nichts. Die List Items sind überflüssig.Das Hinzufügen der Rolle
noneveranlasst den Browser, die Existenz derli-Elemente gegenüber anderen Anwendungen zu verbergen. Elemente mit dieser Rolle werden nicht in die Repräsentation der Seite aufgenommen, die über die Accessibility API des jeweiligen Betriebssystems anderen Programmen zugänglich gemacht wird. Aus Sicht von assistiver Software wie zum Beispiel Screen Readern, die über diese Schnittstellen auf den Browser und die darin angezeigte Webseite zugreifen, sind die Tabs dann Kinder der Tabliste.Zu beachten ist in diesem Zusammenhang aber, dass gegenwärtig, als Fallback oder Ersatz für die Rolle
none, die Rollepresentationangegeben werden sollte. Die Bedeutung der beiden Rollen ist zwar identisch und die Verwendung der Rollenonewird grundsätzlich empfohlen, aber die Rollepresentationgenießt noch die breitere Unterstützung.Neben der entsprechenden Rolle, sollte für die Tabliste auch ein aussagekräftiger Name angegeben werden. Sehende Benutzer können sich hier schnell einen Überblick verschaffen, aber Benutzer, die sich die Seite vorlesen lassen, müssten ohne zusätzliche Informationen erst durch die ganze Liste navigieren, um zu verstehen, welche Inhalte in dem Widget zusammengefasst sind. Mit dem Attribut
aria-labelkann ein passender Name hinzugefügt werden. Der Name muss nicht zwingend ein einzelner Bezeichner sein. Es kann auch eine kurze, aus wenigen Worten bestehende Beschreibung sein. Dabei sollte allerdings vermieden werden, von einer „Liste“ oder „Tabliste“ zu sprechen, da diese Information bereits aus der Rolle des Elements hervorgeht. Von Screen Readern werden die Rolle und der Name üblicherweise nacheinander vorgelesen.Tabs
Den Elementen, die Tabs repräsentieren, wird die Rolle
tabzugewiesen. Als Basis für diese Komponenten würde ich Buttons verwenden. Hast du dich hingegen entschieden, eine bestehende Navigation umzubauen, erhalten die Links die Rolletab. Außerdem sollten die Tabs über eineidverfügen, damit über die Elemente, die mit den Tabs verknüpft sind, auf den jeweils dazugehörigen Tab Bezug genommen werden kann. Ein Name für die Tabs muss nicht über ein Attribut angegeben werden. Der Name ist in diesem Fall einfach der textuelle Inhalt der Elemente.Was auf den Tabs allerdings vermerkt werden sollte, ist die Information, ob der einzelne Tab gerade ausgewählt ist oder nicht. Das heißt, über die Tabs wird der aktuelle Zustand des Widgets kommuniziert. Zu diesem Zweck wird das Attribut
aria-selectedhinzugefügt, mit dem Werttruefür den gerade ausgewählten Tab. Hierbei ist zu beachten, dass es sich bei diesem Attribut nicht um ein boolesches Attribut im engeren Sinne handelt, sprich, es gibt neben den Zuständentrueundfalsenoch den Zustandundefined, der soviel bedeutet wie: „Dieses Element kann nicht ausgewählt werden.“ Dabei handelt es sich außerdem um den Standardzustand. Für die Tabs, die gerade nicht ausgewählt sind, ist das Attribut also anzugeben und explizit auf den Wertfalsezu setzen.Es könnte zudem auf den Tabs das Attribut
aria-controlsdefiniert werden. Das halte ich beim derzeitigen Stand der Dinge aber nicht für sinnvoll, weshalb ich von dessen Gebrauch abraten würde. In diesem Beitrag findest du etwas mehr Informationen dazu.Tabpanels
Den Elementen, die den Inhalt eines Tabs repräsentieren, wird die Rolle
tabpanelzugewiesen. Als Basiselement wird hier regelmäßigsectioneine gute Wahl sein. Der Name eines Tabpanels sollte dem Namen des dazugehörigen Tabs entsprechen. Dieser muss jedoch nicht ausdrücklich angegeben werden. Mit dem Attributaria-labelledbykann auf den Namen des zu dem Panel gehörenden Tabs verwiesen werden, indem als Attributwert eine Referenz auf dieiddes Tabs notiert wird. Das ist insgesamt die robustere Lösung, da es hiermit nur noch eine "Quelle der Wahrheit" gibt. Wird der textuelle Inhalt eines Tabs verändert, dann wird der Name des assoziierten Tabpanels automatisch angepasst. Inkonsistente Beschriftungen sind damit ausgeschlossen.Dass der Inhalt eines nicht ausgewählten Tabs verborgen ist, sollte ebenfalls im Markup notiert werden. Hierfür wird das Attribut
hiddenverwendet. Zu beachten ist hier, dass beimhidden-Attribut die Präsenz des Attributs den Zustandtruerepräsentiert und die Abwesenheit denfalse-Zustand. Wird das Attribut gesetzt, kann der Wert weggelassen werden. Oder es wird der leere String oder der Name des Attributs angegeben.Bedienbarkeit
Durch eine Tabliste wird bemerkenswerterweise nicht mit der Tabulatortaste navigiert, sondern mit den Pfeiltasten. Ist die Tabliste horizontal orientiert, wird mit den Tasten "Pfeil nach rechts" und "Pfeil nach links" von einem Tab zum nächsten gesprungen. Ist die Tabliste hingegen vertikal orientiert, werden die Tasten "Pfeil nach unten" und "Pfeil nach oben" verwendet. Dabei wird standardmäßig davon ausgegangen, dass die Liste der Tabs horizontal orientiert ist. Ist sie das nicht oder nicht mehr, sollte man das angeben, was mit Hilfe des
aria-orientation-Attributs bewerkstelligt werden kann. Das Attribut wird der Tabliste hinzugefügt und bei einer vertikalen Ausrichtung aufverticalgesetzt.Hier ist zu beachten, dass eine vertikale Ausrichtung der Tabliste nicht bereits dann vorliegt, wenn die Tabliste automatisch umgebrochen wurde und infolgedessen ein paar der Tabs untereinander dargestellt werden. Der Sinn einer Angabe zur Ausrichtung der Tabliste und der Anpassung der Navigationstasten an die Ausrichtung besteht darin, Bedienung und optisches Erscheinungsbild konsistent zu halten. Nicht alle Benutzer, die ein solches Widget mit der Tastatur bedienen, sind in ihrer Sehfähigkeit eingeschränkt. Es wäre aus Benutzersicht ein unerwartetes Verhalten, wenn die Tabs auf dem Bildschirm untereinander angeordnet sind, die Bedienung aber mit den horizontalen Pfeiltasten erfolgen soll.
Anzumerken wäre an dieser Stelle vielleicht noch, dass die Verwendung von Tabs bei schmalen Viewports nicht die beste Idee ist. Die Methode
matchMediakann dazu verwendet werden, programmatisch zu überprüfen, ob die Zusammenfassung von Inhalten in Tabs auf der Seite überhaupt sinnvoll ist. Ist der Viewport zu schmal, kann man sich die Ausführung sparen und es bei der als Fallback vorgesehenen Darstellung belassen.
Mit diesem Beitrag geht’s weiter.
-
Fortsetzung dieses Beitrags.
Die Navigation mit Pfeiltasten hat den großen Vorteil, dass die Liste der mittels Tabulatortaste fokussierbaren Elemente weniger umfangreich ist. Das führt dazu, dass mit der Tastatur schneller zwischen verschiedenen Bereichen der Seite navigiert werden kann. Es kann auch als eine Form von Progressive Disclosure betrachtet werden: Benutzer entscheiden anhand des Labels der Tabliste selbst, ob sie diesen Bereich der Seite weiter erkunden möchten oder nicht, und werden nicht genötigt, erst durch alle Tabs hindurch zu navigieren, bevor sie eventuell interessantere Inhalte erreichen.
Eine weitere sinnvolle Anforderung ist, dass die Navigation mit den Pfeiltasten abgeschlossen sein sollte. Das heißt, bei einer horizontal orientierten Tabliste sollte das Drücken der "Pfeil nach links"-Taste, wenn der Fokus auf dem ersten Tab in der Liste liegt, dazu führen, dass zum letzten Tab gesprungen wird. Das Drücken der "Pfeil nach rechts"-Taste, bei Fokus auf dem letzten Tab, soll den Fokus entsprechend zum ersten Tab der Liste verschieben. Bei einer vertikal orientierten Tabliste erfolgt die Navigation analog. Darüber hinaus kann die Usability verbessert werden, indem man erlaubt, mit der "Ende"-Taste zum letzten Tab zu springen, und mit der "Pos 1"-Taste zum ersten. Das erleichtert die Bedienung, besonders bei Tablisten mit vielen Einträgen.
Fokus
Es wird also innerhalb der Tabliste nicht mit der Tabulatortaste, sondern mit den Pfeiltasten navigiert. Das bedeutet, dass zu jedem Zeitpunkt nur ein Tab durch das Drücken der Tabulatortaste den Fokus bekommen kann. Tabt der Benutzer von außerhalb des Widgets in die Tabliste hinein, darf nur der aktuell ausgewählte Tab den Fokus erhalten. Ausgehend von diesem Tab wird beim Drücken der entsprechenden Pfeiltasten – programmatisch durch den Aufruf der Methode
focus– der Fokus von einem Tab zum nächsten verschoben. Besitzt einer der Tabs den Fokus und der Benutzer drückt die Tabulatortaste, wird entweder das erste interaktive Element innerhalb des ausgewählten Tabpanels, oder das Tabpanel selbst fokussiert.Es sollte grundsätzlich vermieden werden, Elemente, die nicht interaktiv sind, per Tastatur fokussierbar zu machen, da die Benutzer mit der Fokussierbarkeit die Erwartung verbinden, irgendeine Aktion auslösen zu können. In diesem speziellen Fall kann es aber dennoch angebracht sein, dem Tabpanel Fokus zu geben, damit keine Inhalte übersprungen werden. Besteht diese Gefahr im konkreten Fall nicht, sollte man den Dingen ihren Lauf lassen. Wird dem Benutzer erlaubt, den Fokus auf das Tabpanel zu setzen, oder entscheidet man sich, den Fokus auf das Panel programmatisch zu setzen, gilt wie immer, dass dies auch visuell erkennbar sein muss. Mit Hilfe der Pseudoklasse
:focuskann ein entsprechender Stil auch für ein gegenwärtig fokussiertes Tabpanel definiert werden.Damit ein Element durch das Drücken der Tabulatortaste den Fokus erhalten kann, muss es entweder wie im Fall von Buttons oder Links interaktiver Inhalt sein, oder aber über ein gesetztes
tabindex-Attribut mit einem nicht-negativen Wert verfügen. Positive Werte für dieses Attribut sollten allerdings prinzipiell vermieden werden: Manuelle Eingriffe in die Tab Order führen in aller Regel nur dazu, dass die Benutzbarkeit der Seite eingeschränkt wird. Die Reihenfolge, in der interaktive Elemente squenziell fokussiert werden, sollte danach bestimmt werden, in welcher Reihenfolge diese Elemente im Markup stehen.Die Elemente, die auch mit der Tabulatortaste fokussierbar sein sollen, bekommen das Attribut
tabindexmit dem Wert0verpasst. Das betrifft den aktuell ausgewählten Tab, sowie unter Umständen die zu den Tabs gehörenden Panels. Elemente, die ausschließlich programmatisch den Fokus erhalten sollen, etwa als Reaktion auf das Drücken der linken oder rechten Pfeiltaste, bekommen hingegen eintabindex-Attribut mit dem Wert-1. Das betrifft diejenigen Tabs, die gegenwärtig nicht ausgewählt sind. Navigiert der Benutzer durch die Tabliste, sind entsprechend nicht nur diearia-selected-Attribute der Tabs, sondern auch dietabindex-Attribute an die aktuelle Auswahl anzupassen.Auswahl
Es bleibt die Frage, wann ein Tab ausgewählt und dessen Inhalt angezeigt werden soll. Bereits dann, wenn der Tab den Fokus erhält oder erst, wenn der Tab durch das Drücken der Leer- oder Entertaste aktiviert wird? Im Allgemeinen ist das wohl Geschmackssache. Welche der beiden Varianten die Nutzer deiner Seite erwarten, hängt von ihren Erfahrungen mit dieser Art Widgets ab, die wesentlich durch die entsprechenden Implementierungen der von ihren Betriebssystemen genutzten GUIs geprägt werden. Diese Implementierungen sind aber nicht einheitlich, weshalb man es diesbezüglich nicht allen Nutzern gleichermaßen recht machen kann.
Es gibt allerdings Bestrebungen, für Webseiten und Webanwendungen einen einheitlichen Standard zu etablieren. Danach sollte ein Tabpanel bereits eingeblendet werden, wenn der Nutzer zum zugehörigen Tab navigiert. Das heißt, die Auswahl folgt dem Fokus. Das gilt allerdings nur unter der Vorraussetzung, dass der anzuzeigende Inhalt bereits geladen und geparst wurde. Ist das nicht der Fall, sollte definitiv auf eine Aktivierung durch den Benutzer gewartet werden. Das könnte sonst zu einem Usability-Desaster führen, wenn die Navigation der Tabliste durch das Laden der Inhalte merklich verzögert wird. Wenn die Inhalte der Tabpanels dynamisch geladen werden, sollte man sich gegebenenfalls eine Preloading-Strategie überlegen, um Wartezeiten bei der Navigation zu vermeiden.
Erreichbarkeit
Was bei diesem Thema oft übersehen wird, ist die Frage der Erreichbarkeit von Inhalten, die in einem Tabbed Interface zusammengefasst sind. Enthält ein Tab Linkziele, entweder das Tabpanel selbst oder ein Element darin, und ist dieser Tab nicht der Tab, der gerade ausgewählt ist, dann sind diese Ziele über die entsprechende URL nicht erreichbar. Aus Benutzersicht ist das alles andere als optimal. Angenommen eine Nutzerin besucht die Seite zuerst mit ihrem Smartphone, wo alle Inhalte angezeigt werden, und setzt ein Lesezeichen auf ein Linkziel innerhalb der Seite. Später ruft sie das Lesezeichen auf dem Laptop ab, wo die Inhalte in Tabs verpackt sind, und findet nicht wonach sie sucht. Das ist keine gute Nutzungserfahrung.
Es sollte also beim Programmstart geprüft werden, ob die URL einen Fragmentbezeichner enthält, der entweder einen nicht ausgewählten Tab oder ein Element darin adressiert. Ist das der Fall, sollte dieser Tab der anfänglich ausgewählte Tab werden. Die Prüfung der URL kann mit der Eigenschaft
window.location.hasherfolgen. Es sollte aber auch auf Eingaben des Benutzers reagiert werden, die zu einem späteren Zeitpunkt erfolgen. Zu diesem Zweck kann aufwindowein Eventhandler für daspopstate-Ereignis registriert werden. Dieses Ereignis wird bei Eingaben in die Adressleiste des Browsers ausgelöst, ebenso wie bei der Navigation der History des Browsers mit dessen "Vor"- und "Zurück"-Buttons.Schließlich wird es in den meisten Fällen auch sinnvoll sein, die URL an den gerade ausgewählten Tab anzupassen. Dazu können die Methoden
pushStateundreplaceStatedes Objekteswindow.historyverwendet werden. Wann immer der ausgewählte Tab wechselt, wird ein neuer Eintrag auf den History Stack gelegt. Wird zudem wie empfohlen auf den Eintritt des Ereignissespopstatereagiert, können die Benutzer über die History des Browsers durch die schon besuchten Tabs navigieren. Außerdem macht es eine solche Implementierung sehr viel einfacher, Lesezeichen auf die einzelnen Tabs zu setzen, so, wie es bei einer als Fallback verwendeten Navigation auch möglich ist.
Du siehst also, eine richtige™ Umsetzung von Tabs bedeutet eine Menge Aufwand. Sehr wahrscheinlich habe ich sogar noch das ein oder andere Detail vergessen und bei einigen Sachen bin ich nicht hundertprozentig sicher, was aktuell die Best Practices sind. Die gute Nachricht für dich ist, dass du dir den Aufwand vermutlich sparen kannst.
Wenn ich mir deinen Code so ansehe, drängt sich mir der Gedanke auf, dass du eigentlich gar keine Tabs willst. Das sieht mir eher danach aus, dass du beim Klick auf "Benutzer" oder "Passwort ändern" im Sinne einer SPA eine komplett neue Ansicht laden willst. Falls dem so wäre, solltest du nicht versuchen den Eindruck zu erwecken, es würde sich um Tabs handeln, weder dir selbst, noch den Benutzern deiner Seite gegenüber. Verwende stattdessen Links auf externe Ressourcen als Fallback und wenn JavaScript verfügbar ist, registrierst du für diese Links Eventhandler, in denen du mit
preventDefaultden Sprung zu einem anderen Dokument unterbindest.Im Anschluss kannst du die Fetch API dazu verwenden die gewünschten Inhalte zu laden. Wenn sie da sind, baust du sie in die Seite ein, aktualisierst den Inhalt des
title-Elements und setzt den Fokus entweder auf die geladene Überschrift oder den Container. Zum Thema Fokussierbarkeit siehe die Absätze oben. Für den Fall, dass du den Fokus auf das Element setzt, dass die neuen Inhalte gruppiert, solltest du dieses Element mit dem Attributaria-labeloder dem Attributaria-labelledbyentsprechend beschriften.Viele Grüße,
Orlok
--
„Dance like it hurts.
Make love like you need money.
Work when people are watching.“ — Dogbert-
Hallo Orlok,
wenn der @Matthias Scharwies wieder da ist, sollte das unbedingt ins Wiki.
Bis demnächst
Matthias--
Rosen sind rot.-
Servus!
Hallo Orlok,
wenn der @Matthias Scharwies wieder da ist, sollte das unbedingt ins Wiki.
Warum machen wir es nicht wie bei der Wikipedia? Dort können auch unangemeldete Benutzer Beiträge ändern und verbessern. Diese werden dann gesichtet und ggfalls verschoben oder weiter ausgebaut.
<ironie> Ach so, haben wir ja schon</ironie>
Wir sollten imho darauf achten, dass das Wiki von der Community und nicht nur von einzelnen weiterentwicklet wird. Herzliche Grüße
Matthias Scharwies
--
"Survive or die trying!"
-
-
Danke für den Beitrag, verstehe das zwar nicht ganz und kann es deswegen nicht umsetzten. Habe es aber mit Ajax geschafft, die Seite ohne kompletten reload neu mit Daten zu füttern.
-
-