Responsive Backend

[MarkusR]

Da ich in meiner Entwicklungsumgebung die Frames schon länger beseitigt habe, die Seiten also immer komplett mit Titelleiste und Navigation ausgeliefert werden und die Navigation in ConPressoPlus ja schon seit Jahren dynamisch geladen wird, war es nun mal Zeit die Seiten responsive, also für "small screens" zugänglich zu machen.
Dafür habe ich das aus mod_mobile bekannte "Hamburger"-Menü zum Ein- und Ausblenden der Navigation (mit erweiterten Abständen) herangezogen. Das funktioniert recht gut und ist auf einem Tablet schon sehr gut nutzbar, auf einem Smartphone purzeln aber noch Schriftgrößen durcheinander.
Aber es wird sowieso Zeit die quer im Code verstreuten Hunderte style-Tags durch Klassen und ein entsprechendes CSS zu ersetzen.
Das ist eben eine fiese Fleißarbeit, die dann in aktuell 4 Styles durchdekliniert werden muss...

[hscha]

Das ist natürlich sehr cool!
Die Umstellung auf ein responsives Design ist eine üble Fummelei, gerade wenn es sich um so kleinteilige Sites wie das Backend handelt. Trotzdem lohnt es sich - ich kann das aber gut nachvollziehen

[MarkusR]

Ja, überrascht wurde ich zuletzt von Safari auf iOS, der partout nicht auf Klick-Ereignisse reagieren wollte, so dass ich nun "touchstart" benutzen muss. Außerdem wollten absolut positionierte Elemente einfach nicht dort erscheinen, wo sie ihr Werk tun sollten...
Im Firefox auf iOS alles gar kein Problem...

Es wird auch nicht responsive wie "mobile first", sondern es werden unwesentliche Informationen ausgeblendet. Hauptarbeitsmittel soll der PC oder ein Tablet bleiben, aber für mal schnell was korrigieren oder administrative Tätigkeiten sollte es reichen. Will ja wohl keiner komplexe Templates am Smartphone bearbeiten...

[hscha]

Ja, darum gehts: Schnell mal was ergänzen oder korrigieren mit dem Smartphone...
Eigentlich sollten die Zeiten vorbei sein, wo jeder Browser was anderes im Code braucht... seit CSS 3 jedenfalls - aber Safari ist doch speziell. Da ich mit IOS und macOS lebe, fällt mir das schon gar nicht mehr auf. Ich teste aber auch alles mit Firefox.

[MarkusR]

Ziemlich entnervend war auch, dass plötzlich Schriften, die eindeutig in der Größe festgelegt waren, nach Belieben skaliert wurden.

Erst mit viel Recherche brachte das CSS

Code: Alles auswählen

    /* fix for small screens, prevents font scaling */
    -webkit-text-size-adjust: 100%;
    text-size-adjust: 100%;

im body-Tag eine einheitliche Schriftgröße.

[hscha]

Hallo Markus,
wird man das responsive Backend irgendwann auch nutzen können und/oder wird es Bestandteil eines neuen ConPresso-Versionszweiges werden?

Grüße von Horst

[MarkusR]

Hallo Horst,

da das responsive Backend und das Entfernen der Framesets umfangreiche Code- und Strukturänderungen erfordert, wird es nicht Einzug in eine 4.1.x halten.

Ziel ist ein - wie Du schon bemerkst - neuer Versionszweig mit vielen anderen umfangreichen Änderungen und neuen Möglichkeiten (die hier ja schon geteasert wurden) mit kompletter Überarbeitung des Codes.
Aktuell mache ich da eine Zwangspause, weil ich von der ConPresso GmbH noch kein verbindliches o.k. dafür bekommen habe...

[hscha]

Na dann drücke ich mal die Daumen für uns alle!

[hscha]

Ja, überrascht wurde ich zuletzt von Safari auf iOS, der partout nicht auf Klick-Ereignisse reagieren wollte, so dass ich nun "touchstart" benutzen muss. ...

Damit gehts:

Code: Alles auswählen

<button class="navbutton" aria-expanded="false" aria-controls="navi-liste" title="Klick: Men&uuml; aufklappen">
&#x2630
</button>

Dann das Javaskript dazu:

Code: Alles auswählen

<script>
    	const hamburger = document.querySelector('button[aria-expanded]');
    	function klappNav({
      	target
    	}) {
      	const expanded = target.getAttribute('aria-expanded') === 'true' || false;
      	hamburger.setAttribute('aria-expanded', !expanded);
    	}
    	hamburger.addEventListener('click', klappNav); 
</script>

Grüße von Horst

[MarkusR]

Danke Horst,

meine Lösung sieht so aus:

Code: Alles auswählen

const isTouchDevice = 'ontouchstart' in window || navigator.maxTouchPoints > 0; // true auf Touch-Geräten
const event = (isTouchDevice) ? 'touchstart' : 'click';

addEventListener(event, (evt) => {
  var navPane = document.getElementById('navigation_pane');
  var toggler = document.getElementById('menuToggler');
  
  if (!evt.target.closest("#navigation_pane") && !evt.target.closest("#menuHamburger")) { // irgendwo klicken -> close
	  navPane.classList.remove("mobileNavigation");
	  toggler.innerHTML = '≡';
  } else if (evt.target.closest("#menuHamburger") && !navPane.classList.contains('mobileNavigation')) { // hamburger klicken -> open
	  navPane.classList.add("mobileNavigation");
	  toggler.innerHTML = '×';
	  navPane.scrollIntoView({ behavior: "smooth" });
  } else if (evt.target.closest("#menuHamburger") && navPane.classList.contains('mobileNavigation')) { // x klicken -> close
	  navPane.classList.remove("mobileNavigation");
	  toggler.innerHTML = '≡';
  }
});

So kann ich ganz normal Events definieren, nur ist der Trigger mal cLick (normale Geröte) und mal touchstart (mobile Geräte). Und ich nutze Events, weil es meist keine Buttons sondern Objekte und Regionen sind

[hscha]

Coole Lösung!
Mein aufgeklapptes Menü schließt sich nämlich nur mit erneutem Klick auf den Hamburger-Button. Vllt. übernehme ich deine Lösung, wenn das in Ordnung ist...

Grüße von Horst

[MarkusR]

Das ist natürlich in Ordnung.

Da das CPO-Backend-Menü recht lang werden kann und das X (wechselt mit dem Hamburger-Button) weit entfernt ist, war es mir wichtig, dass sich das Menu schließt, wenn man woanders hinklickt.
Übernommen habe ich das vom (zukünftigen) Frontend-Editing.

Das schloss dann auch reine CSS-Lösungen aus, auch wenn mir sowas viel lieber wäre.