Desktop vs. Mobil: Darstellung der DropDown-Liste eines Formulars

Im Footer meiner Website befindet sich der Link zu einem Buchungskalender, mit dem meine Klienten bei mir Termine buchen können. Der Kalender läuft inzwischen einwandfrei. Ich habe aber ein Problem bei der Darstellung auf Mobilgeräten, speziell Smartphones im Portrait-mode / schmalem Bildschirm:

Wenn man die Liste der Leistungen anklickt, erhält man in der Desktop-Ansicht eine übliche DropDown-Liste angezeigt, deren FontSize ich sogar unterhalb 480px Breite reduziert habe, denn manche Texte in der Liste sind etwas lang. Hierfür habe ich folgende CSS-Definition eingefügt:

.input-large.form-select.form-control option {
    @media screen and (max-width: 480px){
       font-size: 14px !important;}
    }

Wenn man diese Liste auf einem Smartphone angezeigt bekommt, ist es plötzlich keine normale DropDown-Liste mehr, sondern eine Liste mit Radio-Buttons. Vermutlich ist der Wechsel der Darstellung durch eine Bootstrap-CSS-Definition verursacht. (Der Kalender nutzt Bootstrap.) Ferner ist die Schriftgröße bei dieser Darstellung viel zu groß, wenn ich sie im Chrome- / Brave-Browser anzeigen lasse. Im Firefox Mobil ist die Schrift deutlich kleiner, aber immer noch zu groß.

Ich habe schon viel versucht, die CSS-Definition zu finden und durch eigenes CSS zu ändern. Problem dabei ist, dass ich zwar im Desktop-Firefox den Useragent auf z.B. Firefox Mobil wechseln kann und die Fensterbreite des Firefox recht schmal stelle. Aber dennoch bleibt die Darstellung der Auswahlliste im "Desktop-Modus". Ich kann also die CSS-Anweisungen nicht finden, die im Mobilbetrieb die Radiobuttons verursachen und die Schriftgröße vermutlich der Willkür des Browsers überlässt.

Ich habe ja nichts gegen die Radio-Buttons, möchte aber die Schriftgröße und den Zeilenabstand zwischen den Options verändern.

Wie sollte ich vorgehen, um dieses Ziel zu erreichen?

Ich komme grad vom verspäteten Mittagessen, sodass ich nur den Vorschlag von Sieger66 ausprobiert habe. Leider sind die Ergebnisse sowohl in Firefox Mobil als auch Chrome / Brave Mobil unverändert. Die CSS-Definitionen scheinen hier nicht zu greifen.

christine2 Dein Screenshot ist sicher von einem Desktop-Browser.

Ich vermute ja, dass irgendwo im Bootstrap-CSS eine @media-Abfrage existiert, die prüft, ob es sich um ein Touch-Screen-Gerät handelt. Wenn ja, wird die DropDown-Liste eben nicht mehr als Auswahlliste gezeigt, sondern als Liste mit Radiobuttons.

Unerwünschter Weise ändert sich mit dem vorgeschlagenen CSS die Feld-Beschriftung der Liste wie z.B. "Status auswählen" und "Leistung auswählen" auf Desktop-Browsern. Mit meiner bereits benutzten CSS-Anweisung (jetzt korrigiert – DANKE !):

@media screen and (max-width: 540px){
    .input-large.form-select.form-control option {
                 font-size: 14px !important;
         margin-bottom: 5px !important;}
    }

Hatte ich für Desktop-Browser bereits eine funktionierende Anpassung der Schriftgröße erreicht. Leider wirkt diese eben nicht auf die Darstellung in Mobil-Browsern – vermutlich aus eben dem o.g. Grund betr. Bootstrap-CSS. Leider habe ich keine Smartphone-Browser-Simulation, mit der ich die CSS-Definitionen aus der Bootstrap-CSS effizient auffinden könnte.

Auf dem Smartphone war es nicht möglich, einen Sceenshot von der geöffneten DropDown-Liste mit den Radio-Buttons anzufertigen. Ich hab's mit ner Webcam hinbekommen und hänge die beiden Bilder mal hier dran.

firstlady Der Buchungskalender ist von Joomdonation.com und JED-gelistet. Es ist nach meiner bisherigen Erfahrung aufgrund der vielfältigen Einstellungsmöglichkeiten der einzige Kalender, der für die Anforderungen einer Gesundheitspraxis in Frage kommt.

Für die Auswahl mit den DropDown-Listen wird ein Modul benutzt. Dieses Modul habe ich in einem Joomla-Artikel platziert und mit dem zusätzlichen Text ergänzt. Die Modul-Platzierung bzw. überhaupt die ganze Gestaltung meiner Site habe ich mit YooTheme Pagebuilder vorgenommen, welches auf dem Ui-Kit beruht.

Der Joomla-Artikel mit dem Modul wird dann in einen iFrame geladen, der in einer Lightbox gezeigt wird. Das hat zwei Vorteile: Der Benutzer wird beim Buchungsvorgang nicht durch andere sichtbare Ui-Elemente abgelenkt und ferner zwinge ich das Layout in die schmale Begrenzung des iFrame, wodurch ich mir erspare, den Code der weiteren Seiten im Buchungskalender anpassen zu müssen.

Danke an Sieger66 für die Links. Ich werde mir die im Laufe des Tages genauer anschauen und hoffe, doch noch eine Lösung zu finden.
Die grundsätzliche Frage ist jedoch, ob es überhaupt möglich ist, Mobilbrowser zu einer bestimmten Darstellung dieser Standard-Elemente zu zwingen.

Am hilfreichsten scheint mir die zweite Verlinkung zu https://www.mediaevent.de/html/select.html

Ich habe auch mit "appearance" experimentiert:

.input-large.form-select.form-control option {
    appearance: none;}

Leider hatte es keine Wirkung – weder auf Desktop-Browser, noch auf Mobil-Browser. In der Browser-Konsole konnte ich sehen, dass die "appearance-Definition" auch tatsächlich beachtet wurde.

Dabei sind die von mir verwendeten CSS-Klassen ja bei Desktop-Browsern an der richtigen Stelle – der Gestaltung der DropDown-Liste – wirksam. Das kann also nicht sooo falsch sein.

Heute morgen mein vorerst letzter Versuch:

Überlegung: Vielleicht sind bestimmte Klassen, die ich im vorigen Code eingeschlossen hatte, bei Touchscreen-Geräten gar nicht aktiv? Dann kann "appearance" ja nicht wirksam werden.

Deshalb versuchte ich es heute morgen neu mit:

@media screen and (pointer:coarse) {
#osbsearchmodule .form-control option {
   appearance: none;} 
   } 

Die ID beschränkt die Wirksamkeit auf das Modul mit den Auswahl-Listen. "form-control" gehört anscheinend immer zu den Listen dazu. "option" beschränkt die Wirkung auf die DropDown-Liste, sodass das "select"-Feld unbeeinflusst bleibt.

Resultat: Es wirkt nicht!
Ich habe dann auch noch die Klasse "form-control" entfernt, sodass jegliche "option" im Bereich des Moduls beeinflusst werden müsste – aber auch hier zeigt sich keine Wirkung.

Durch meine beiden Bilder weiter oben im Thread dürfte klar sein, dass hier ein Problem vorliegt, dass gewiss nicht nur mich, sondern viele andere Anwender betrifft, die z.B. längere Texte als Options verwenden müssen.

Nu habe ich keine Idee mehr, was ich noch versuchen könnte. – Habt Ihr noch welche?

Ich habe gerade dies hier gefunden:

Effortless Custom Form Input Styling With Webkit Appearance None

Ben Nadel explores the use of "Webkit-Appearance" as a means to add custom CSS styling to form input controls. This CSS property removes the native styling of…

www.bennadel.com

Da werde ich wohl einige Zeit benötigen, um das zu erproben. Ich melde mich dann wieder hier. (Aber vielleicht sind inzwischen andere schneller?)

Das ließ mir jetzt doch keine Ruhe:

Ich habe den Code aus o.g. Quelle in meine neue in Entwicklung befindliche Website eingebaut. Unter dieser URL ist der Test mitsamt von mir eingefügten Kurzkommentaren zu finden:
Form-Test appearance = none

Resultat:
Auf den mir verfügbaren Desktop-Browsern wird apperance: none beachtet und die Gestaltung der Formular-Elemente wird wie gewünscht beeinflusst.

Auf den mir verfügbaren Mobil-Browsern bleibt die Gestaltung völlig unbeeinflusst!
apperance: none hat keine Wirkung! – obwohl auch in der Mozilla-Dokumentation das Gegenteil beschrieben wird.

Was jetzt? Aufgeben?

Moment! Ich hatte ja geschrieben, dass ich auf dieser separaten Webseite den Code von hier https://www.bennadel.com/blog/3776-effo…arance-none.htm eingefügt habe.

Deshalb ist da kein JS wirksam. Bei meinem Modul des Buchungskalenders könnte das natürlich anders aussehen. Hier geht es erst mal darum zu prüfen, ob "appearance: none überhaupt einen Einfluss auf Mobil-Browser hat.

Sieger66 Den von dir verlinkten Artikel bei MDN hatte ich auch gelesen. Aber schon am Anfang steht:

Zitat

Note: We'll focus on building the control, not on how to make the code generic and reusable; that would involve some non-trivial JavaScript code and DOM manipulation in an unknown context, and that is out of the scope of this article.

Konkret: Sie zeigen hier sozusagen ein Funktionsprinzip, ein Proof of Concept, dass es möglich ist, die gewünschten Änderungen zu verwirklichen, aber dass im jeweiligen Anwendungsfall "nicht-triviale" JS-code Entwicklungen erforderlich sind.

Nach der Besprechung der neuen CSS-Definitionen geht es in dem Artikel an das JS. Gleich zu Beginn steht aus gutem Grund der nächste Warnhinweis:

Zitat

Warning: The following is educational code, not production code, and should not be used as-is. It is neither future-proof nor will work on legacy browsers. It also has redundant parts that should be optimized in production code.

Damit würde ich nicht nur meine KnowHow-Grenze überschreiten, sondern auch in den Code des Moduls eingreifen müssen. Und das wird vermutlich zu Konflikten führen mit dem bereits im Modul vorhandenen JS-Code. Zudem müsste ich den PHP-Code anfassen, damit neue Definitionen in CSS und JS "eingebaut" werden können. Auch davon habe ich keine Ahnung.

Den Programmierer von Joomdonation kann ich für solche npssungen sicher ebenfalls nicht begeistern. Die bisher nötigen Anpassungen, die er für mich (kostenpflichtig) realisiert hat, erforderten eine sagen wir mal "sehr aufwendige Korrespondenz", die auf Arbeitsüberlastung oder auf Unwillen schließen lassen könnte.

Zu Beginn dieses Threds hatte ich angenommen, es sei möglich, die bereits vorhandenen CSS-Klassen des Moduls durch eigene Definitionen so abzuändern, dass die gewünschte Gestaltung dabei heraus käme. Die Verwendung von "appearance: none" bestätigte scheinbar zunächst, dass meine Absicht realisierbar wäre.

Bis auf Weiteres gebe ich an dieser Stelle auf. Vielleicht wird es ja im Rahmen der CSS-4-Normung eine Verbesserung von "appearance: none" geben?

Ich freue mich, dass du mir hier dein JoomBook vorstellst und ich habe mir die Feature-List auf JED angesehen. Das ist beeindruckend und könnte tatsächlich für mich geeignet sein. Aaaaber:

Du wirst sicher schon bei der Entwicklung festgestellt haben, wie komplex solch ein Buchungskalender mit allen Funktionen, Abhängigkeiten usw. ist, bis hin zum Datenschutz, nach dem die Kunden automatisch nach einer einstellbaren Zeit vom System gelöscht werden.

Ich stecke gerade in der Umsetzung meines neuen Marketing- und Werbekonzepts und habe daher keine Zeit, dein Projekt auf einer meiner Testseiten zu installieren und auszuprobieren. Ich habe z.B. zwei Praxen, die eine bei mir im Wohnbereich, die andere ca. 45 Autominuten entfernt. Wenn jemand einen Termin in der entfernt liegenden Praxis bucht, muss der Buchungskalender die Fahrtzeit vor und nach diesem Termin berücksichtigen und z.B. eine nächste Buchung an meinem Wohnort verhindern. Bei zwei aufeinander folgenden Terminen in der entfernt liegenden Praxis entfällt natürlich diese Zwangspause, sodass dort eine Uhrzeit noch gebucht werden kann, während diese Uhrzeit an meinem Wohnort bereits nicht mehr buchbar sein darf.
Mein aktueller Buchungskalender lässt hier keine Einstellungen oder Funkionen zu.

Und falls mal wenig Buchungen vorliegen, muss ich ohne großen Aufwand "Schein-Buchungen" einfügen, weil sonst spitzfindige Zeitgenossen schlussfolgern könnten, dass ich nicht ausgebucht bin und das einen ungünstigen Grund haben müsste.

Ich hatte den Entwickler von OS-Services Booking schon auf mehrere Unstimmigkeiten aufmerksam gemacht. Dann tut er regelmäßig so, als würde er meine Frage aufgrund von Sprachschwierigkeiten oder aufgrund einer angeblich unverständlichen Beschreibung meinerseits nicht verstehen und könne mir daher nicht weiter helfen. Zuletzt hatte ich ihm die offensichtlichen Fehler / Mängel sogar per Video / Screenrecording gezeigt und in Englisch erklärt. Ich fühle mich da nicht mehr ernst genommen. Das war noch direkt nach dem Erwerb der Lizenz ganz anders. Ich habe die Lizenz seit Dezember 2025 auslaufen gelassen.

Per PN / eMail kann ich dir mal meinen Buchungskalender in der Version 5 (veraltet) "zeigen". Die derzeitigen Funktionen reichen mir noch aus. Falls aber intensiv gebucht wird, muss ich manuell eingreifen; und das ist aufwendig und für Klienten wegen evtl. nötiger Umbuchungen ärgerlich. Spätestens dann komme ich gern auf deine Extension zurück.

Hi Martin!
Die Schwierigkeit liegt in der enormen Komplexität der Aufgabenstellung und darin, diese präzise und möglichst unmissverständlich beschreiben zu können. Dafür fehlt mir leider die Zeit.

Es gab damals (vor ca. 3 Jahren) nur zwei Lösungen bei JED, die aufgrund der Beschreibung der Features für mich in Frage kamen. Prompt habe ich zunächst die ungünstigere der beiden gewählt! :–) Bei OS Services Booking hatte ich ebenfalls erst mal einige Korrespondenz mit dem Entwickler, weil es teils Fehler in der Extension gab und teils weil ich zusätzliche Features benötigte, die dann auch tatsächlich integriert worden sind. Allerdings musste ich die Aufgabe: "ein Dienstleister an zwei Standorten mit dem Ausschluss sich zeitlich überlappender Buchungen" durch einen Trick lösen, weil das Programm das nicht hergab. Und die benötigte Fahrtzeit usw., was ich oben gerade skizziert hatte, ist aktuell gar nicht gelöst. Falls derzeit solche Buchungen erfolgen, muss ich eine der beiden verschieben und dies per Korrespondenz mit dem Klienten klären.

Beide Extensions haben einen großen Nachteil gegenüber deinem Angebot: Beide bieten keine kostenfreie Version zum Ausprobieren an oder zumindest eine 4-Wochen-Testphase vor Kauf der Lizenz. Von daher ist dein Angebot wirklich verlockend.

Frage: Wie kann ich dir, wie du schriebst, "die Funktionen meiner jetzigen Version zeigen"? – Selbst wenn ich dir Admin-Zugang geben würde, wäre die Komplexität so groß, dass du dich erst mal in die Struktur einarbeiten müsstest.

Vielleicht schaffe ich es doch zeitlich irgendwie, eine grobe Beschreibung der für mich wichtigsten Features zu erstellen.