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?