Lieber Matthias,

Damit kann :focus irgendwann™️ durch :focus-inner ersetzt werden.

hoffentlich nie. Worin soll denn der funktionale Unterschied bestehen? Mir ist im Zweifel die kürzere Form deutlich lieber (und abwärtskompatibel zu älteren UA), wenn sie denn exakt das selbe meint.

Liebe Grüße,

Felix Riesterer.

Hej Matthias,

Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

Für aktuelle Browser mit focus-within

Vielen Dank!

Hat Matthias Apsel am 31.10. vorgeschlagen:

Ja, sorry. Hatte ich zu spät gesehen.

Marc

Hallo Felix Riesterer,

das klingt mir verdächtig nach Würgaround.

ist nicht mal das. Was nutzt es mir, wenn ich weiß, wie meine Seite zu bedienen ist, wenn es die Besucher meiner Seite nicht wissen.

Ich wollte damit nur aufzeigen, dass ich und einige wenige andere das Menu dennoch bedienen können.

Bis demnächst
Matthias

Aloha ;)

Ich sprach da in der Vergangenheit schon mehrfach von einer „verlorengegangenen Interaktionsebene“, die uns Touch-Geräte-/Browser-Hersteller nach wie vor schuldig bleiben und die wir jetzt irgendwie emulieren müssen

Andersrum wird ein Schuh draus: Designer/Entwickler sollten aufhören, spezielle Interaktionsformen von Desktop-Anwendungen allgemein aufs Web übertragen.

Nein. Einfach nein. Die Interaktionsform via hover ist schon sehr viel länger „im Web“ (zum Beispiel in den Standards) als Touch-Geräte das Web darstellen.

Sorry, aber das geht mir schon wieder zu sehr in Richtung spiritistischer Verklärung und Rechtfertigungslehre. Meine Aussage war eigentlich recht simpel: Vor der Verbreitung von Touchgeräten gab es eine Interaktionsebene, die jetzt nicht mehr ohne weiteres zur Verfügung steht.

Ich glaube nicht, dass man daran viel diskutieren muss.

Genauso wie man nicht drüber diskutieren muss, dass man die armen Touch-User, die kein hover können, nicht im Regen stehen lassen darf.

Ich glaube nicht, dass dem viel hinzuzufügen ist?!

Ein Tooltip erscheint und erläutert die Steuerung in einem Satz

Spätestens hier hätte dir dein Fehler auffallen sollen. UI-Elemente hinzufügen, um das UI zu erklären – funktioniert immer. Nicht.

Auf deine konstruktive Erklärung, wie man ein solches Menü auch den nicht-hover-fähigen zugänglich machen kann, bin ich gespannt. Der Schuh, da eine intuitive Behandlung von hover zu erreichen, liegt eigentlich bei den Browserherstellern - die sich aber bis heute diesen Schuh nicht anziehen. Deshalb gibt es da keinen einheitlichen Bedienungsmechanismus, und deshalb brauchts eine Erklärung. Die im Übrigen mehr dazu da ist zu zeigen "da geht noch mehr als nur das Untermenü anzuzeigen"; die Bedienung ist ja bis auf den Doppelklick intuitiv.

Wenn du mir jetzt sagst: „geht nicht, mach ein anderes Menü“, dann sage ich dir, dass du damit einerseits Recht hast und andererseits das Thema damit um Elefantenbreite verfehlst; ich hatte sehr deutlich beschrieben, dass es mir darum ging, das Dilemma „bestehendes Hover-Menü für Touch-User bedienbar machen“ zu behandeln und nicht die Frage, ob man das Dilemma nicht auch irgendwie durch Refactoring umgehen kann.

Zum Anschauen: https://eja-aalen.de/angebote/freizeiten[^1]

Zickt rum beim Laden.

Das ist keine sehr hilfreiche Fehlerbeschreibung.

Auf dem iPhone erscheint das Menü in Gänze – ohne dass eine Hierarchie erkennbar wäre, was Unterpunkte und was Unterunterpunkte sind.

Die nur improvisierte Darstellung auf sehr schmalen Bildschirmen ist einer der Gründe, warum da dringend eine Komplett-Überarbeitung her muss. Das war aber hier nicht der Punkt. Wenn du dein iPhone drehst kannst du im Querformat das sehen, was ich hier zeigen wollte. Falls du daran überhaupt interessiert bist.

Beim Scrollen flackern wie wild Farben auf.

Kannst du das genauer beschreiben? Mir ist nicht klar, auf was du mich hinweisen möchtest.

Ordentliche Tastatursteuerung gibt mein Menü im Moment leider nicht her, da war ich damals schlampig. […] das hätte ich noch zusätzlich sicherstellen müssen.

Die Vergangenheitsform ist unangebracht.

Ist sie nicht. Dass eine Neugestaltung ansteht (nicht-Vergangenheitsform) habe ich deutlich geschrieben.

Solange das Menü nicht benutzbar ist, solltest du es nicht als Beispiel präsentieren. Es sei denn, als Negativbeispiel.

Ach, hab ich das denn? Ich habe absichtlich dazugeschrieben, dass die verlinkte Seite eben nicht beispielreif ist.

Ich hätte natürlich auch hergehen können und einfach nur den Quellcode ohne was zum Anschauen hinknallen können. Oder mir noch mehr Zeit um die Ohren schlagen und das auf Codepen nachbauen können. Stattdessen habe ich darauf vertraut, dass Leser meines Beitrages versuchen zu verstehen, was ich Ihnen sagen möchte, ohne selbst jede Eventualität eines Missverständnisses auszumerzen.

Oder anders formuliert: Ich hatte auf Anwendung des Prinzips der wohlwollenden Interpretation gehofft, um sachlich voranzukommen, und bin auf Strohmann-Argumente gestoßen. Na was das bloß aussagt...

Grüße,

RIDER

Aloha ;)

Warum gibt's eigentlich keine Maus für's Mobilgerät? USB-Anschluß ist doch üblicherweise vorhanden (zum Aufladen ...)

USB-Sticks kann man am Mobilgerät anschließen (und drauf zugreifen). Maus hab ich noch nie getestet 😂

Grüße,

RIDER

@@Matthias Scharwies

Danke, ich hab's kopiert und versuch's mal in das JS-Tutorial einzubauen.

Da besteht noch einiges Verbesserungspotential. this anstatt event.target hatte ich ja schon erwähnt, aber auch damit wäre

event.target.parentNode.classList.toggle("open");

const open = event.target.parentNode.classList.contains("open");

noch unsinnig. Element.classList.toggle() gibt ja schon genau das zurück, was man haben möchte. Die Abfrage mit Element.classList.contains() ist Quatsch.

const open = this.parentNode.classList.toggle("open");

und gut ist.

LLAP 🖖

@@Felix Riesterer

Wenn ich mir allerdings diesen Schreibaufwand anschaue, als Beispiel sei nur der Setter $element.attr("name", "value") im Vergleich zu element.setAttribute("name", "value"), und der Getter $element.attr("name") im Vergleich zu element.getAttribute("name") genannt.

setAttribute/getAttribute sind eben sprechende Namen; attr ist kryptisch.

Und 8 Zeichen mehr machen für dich Schreibaufwand? Stattdessen willst du lieber dem Nutzer aufbürden, zusätzlich eine 87 kB große Bibliothek zu laden? Ernsthaft?

Das Mantra von jQuery war (neben dem Ausbügeln von Browserunterschieden) "write less do more". Das sehe ich hier ganz deutlich: Mit jQuery schreibt man weniger Code-Fülle,

Man schreibt vielleicht weniger, aber …

die im Endeffekt zu lesbarerem weil weniger geblähtem Code führt.

… zur Lesbarkeit s.o.

Weniger aufgebläht? Eben nicht. Die 87 kB musst du in deine Rechnung schon mit einbeziehen.

Aber falls dir attr heilig sein sollte, kannst sowas in der Art machen:

Element.prototype.attr = function(name, value)
{
	if (arguments.length > 1)
	{
		return this.setAttribute(name, value);
	}
	else
	{
		return this.getAttribute(name);
	}
}



document.body.attr('foo', 'bar');

console.log(document.body.attr('foo')); // bar

Dazu brauchst du kein jQuery.

LLAP 🖖

@@Felix Riesterer

Das title-Attribut macht keinen Sinn, auch wenn da etwas anderes drinstünde.

Mit Verlaub: doch! Wenn jemand mit der Maus über dem Button hovert, dann will der vielleicht wissen, was der bewirkt. Das kann ein Tooltip mit dem Inhalt des title-Attributs vermitteln. In diesem Kontext ist nämlich die Beschriftung des Buttons ausgeblendet. Man "sieht" nur noch ein Plus- oder Minus-Zeichen.

Bei Anwendungen wie bspw. Photoshop, Illustrator, InDesign usw. weiß ich solche Tooltips durchaus zu schätzen, wenn sie mir die hinter den Icons liegende Funktion erzählen. Nur sind das Desktop-Anwendungen, bei denen man davon ausgehen kann, dass die Nutzer eine Maus schubsen – wenn nicht einen Stift auf dem Grafiktablett.

Davon ist bei Webanwendungen nicht auszugehen.

Entweder das UI ist selbsterklärend (yay!)– dann brauchen auch Mausschubser keine Tooltips. Oder das UI ist nicht selbsterklärend (meh!) – dann brauchen auch Nicht-Mausschubser eine Erklärung, und zwar in einer anderen Form, nicht als Tooltips.

LLAP 🖖

Aloha ;)

Nur das mittlerweile populär werdende jQuery-Bashing zugunsten von VanillaJS hat wie jede Religion so seine Konzeptlücken.

Ich würde sogar so weit gehen zu sagen, dass die Konzeptlücken-Eigenschaft dem Wort Bashing bereits inhärent ist 😂

Grüße,

RIDER