Beiträge von Clemens-XS

    firstlady Bei YooTheme werden die Bilder nach dem Einfügen ins Layout automatisch in drei bis fünf Bildschirmbreiten neu berechnet und, falls noch nicht geschehen, im webm-format platzsparend und in guter Qualität gecached. Die Bilder passen sich ansonsten selbstverständlich responsive an.

    Bei den Schriften ist das anders. Zwar kann ich für h1 bis h3 die font-sizes in zwei Stufen (unterhalb 940 und oberhalb) abhängig vom Screenwidth anpassen, aber dies ist mir einfach zu wenig. Deshalb habe ich je h1...h6 jeweils vier @media-Regeln definiert, um damit sowohl font-size als auch font-weight anzupassen. Diese hohe Variabilität gibt es nur bei variablen Fonts.

    Im Chrome- oder Brave-Mobilbrowser funktioniert das auch auf Mobilgeräten prima, aber nicht bei Firefox und auch nicht bei Safari.

    Ich hatte früher auch schon mal versucht, die Fonts an die Containerbreite anzupassen, in der sie genutzt werden. Das ging noch gründlicher schief, als jetzt die Nutzung des variablen Fonts, einfach weil gerade wieder bei Mobilbrowsern vw-Einheiten oder calc-Prozeduren nicht zuverlässig funktionieren. Genau dies ist wieder jetzt bei meinem Signet zu beobachten, das ich zurzeit mit der Kombination von vw und min- / max-width versuchte, kontinuierlich an die Screenwidth anzupassen, also ohne media-query-Abstufungen.

    Im Ergebnis sehe ich es auch wie du: Wenn alle Bemühungen keine Verbesserung bei Mobilbrowsern wie Firefox oder Safari bringen, dann muss das einfach hingenommen werden. Man kann es nicht allen Recht machen.
    Ich hätte bisher nur nicht gedacht, dass sich hier die Geschichte wiederholt, die wir alle früher mit dem unsäglichen Internetexplorer erleben durften. Statt die Browser mit immer mehr Schnickschnack und Features auszustatten, wäre es erheblich konstruktiver, dass endlich solche Darstellungs-Basics wie gerade beschrieben oder Features wie Web-RTC endlich mal zuverlässig integriert würden.

    Mich würde es nicht wundern, wenn es bald wieder Websites mit dem Vermerk im Footer geben würde: Best viewed by Chrome- / Brave-Browser :(

    Crosslink??? Ich diesen Thread hier mit der unterschiedlichen Darstellung auf verschiedenen Desktop- und Mobilbrowsern begonnen, wobei ich als Beispiel die DropDown-Liste gewählt hatte.

    In dem von dir angeführten Thread ging es um die Frage, wie man die DropDownliste auf Mobilgeräten im Design erzwungen verändern kann. Ist ja wohl ein deutlicher Unterschied der Fragestellung, oder?

    Und jetzt zuletzt nehme ich als Beispiel die Fonts im Menü, um die unterschiedliche Darstellung zu klären. Wo ist da jetzt ein Crosspost?

    Undschließlich gebe ich sogar noch meine Erkenntnisse als Tipp an die Community hier, nämlich dass variable Fonts zumindest in Firefox und Safari Mobil Probleme bereiten, die anscheinend aktuell noch nicht lösbar sind. Auch Crossposting?

    Neuigkeiten gibt es betreffend der unterschiedlichen Darstellung der Fonts / font size und font weight:

    Firefox Mobil scheint sehr empfindlich zu reagieren, wenn das CSS zum Integrieren der Fonts auch nur einen geringfügigen Fehler beinhaltet.

    Nach Diskussion mit dem YooTheme-Support und eigener Webrecherche stand im Ergebnis, dass der Firefox-Mobil-Browser sowie Safari mobil bis heute eine integrierte Aversion gegen variable Fonts haben und weder per CSS vorgegebene Größen noch Gewichte einhalten. Nicht einmal die im Internet auffindbaren Tipps, die angeblich bei beiden Mobilbrowsern zu Verbesserungen führen sollten, haben in der Realität etwas bewirkt!

    Das ist natürlich fatal bei Überschriften (zu groß und dann Umbrüche) und bei Overlays (zu großer Text führt zum Abschneiden überlaufenden Textes) sowie bei Menüs (zu großer Text führt zu aufgeblähtem Menü, das gescrollt werden muss und daher bedienerunfreundlich ist). Beispiel die hier angehängten beiden Bilder mit selbsterklärendem Dateinamen.

    Meine Schwierigkeit mit dem Signet müsste sich aber doch noch lösen lassen. Aktuell nutze ich ein SVG, weil es beim Skalieren scharf bleibt. Es könnte sein, dass die von mir gewünschte Skalierung mit PNG oder JPG besser gelingt.

    Die von mir hier angesprochenen Schwierigkeiten haben sicher noch mehr Webdesigner und Hobby-User wie ich. Daher wundert es mich, dass sich bisher an diesem Thema noch niemand beteiligt hat.

    Ich danke dir! Aber leider hat auch diese CSS-Definitionen keine Wirkung, auch nicht mit "!important"

    In der Brwoder-Konsole finde ich auch keine Berücksichtigung dieser Definition, sie ist einfach nicht enthalten bei

    <h2 class="menutitle">Main Menu</h2>

    Alle meine bisherigen Versuche, hier Einfluss zu nehmen, hatten keinen Erfolg, daher ja meine Anfrage hier.

    firstlady Da ich meine Website DSGVO-konform halten will, ohne lästigen OptIn-Klimbim, reagiere ich empfindlich auf externe Links, die ich nicht selbst eingebettet und mit einem Icon vor dem Link als externe Links kenntlich gemacht habe.

    Jetzt sehe ich, dass "Powered by SchuWeb" doch automatisch dieses Icon bekommen hat. Bei manchen anderen Extensions funktioniert genau diese Icon-Einbettung nicht.

    Also bleibt der Link "Powered by SchuWeb" natürlich drin! – Ich weiß durchaus, was Dankbarkeit ist :)

    Inhalt dieser Website

    Wow, ich danke dir herzlich!

    Diese Sitemap bietet genau das, was ich mir gewünscht habe. So sollte eigentlich eine Sitemap wirklich funktionieren: alle items werden in der Reihenfolge angeordnet, wie sie auch im Menü zu finden sind. So wird das auch ein Besucher erwarten.

    Kleiner Nachteil: "Powered by SchuWeb" ist als Link unter der Sitemap zu sehen.

    Magst du mir noch einen kleinen Tip auf die Schnelle geben?
    Ich hab ja nur ein Menü und will die Überschrift "Main Menu" über der Sitemap ausblenden. Wirksam sind folgende IDs und Klassen:

    #Schuweb_Sitemap h2 .menutitle

    Wie muss die CSS-Anweisung (display: none) für diese Kombination formuliert werden? Braucht es Leerzeichen zwischen h2 und der Klasse? Und was ist zwischen der ID und h2?

    Ich entwickle gerade eine Website, bei der eine Reihe von Artikeln, aber nicht alle, im Menü direkt verlinkt ist. Es gibt also keinen Kategorie-Blog. Mit OS-Map möchte ich auch ein Inhaltsverzeichnis anbieten.

    Da die Artikel nicht in der Reihenfolge angelegt worden sind, wie ich sie gerne in OS-Map gelistet sehen möchte, habe ich nun ein Problem, denn die in OS-Map angezeigte Reihenfolge entspricht derjenigen der Artikel-ID. Aber diese kann ich ja nicht so einfach ändern.

    Vielleicht hat jemand dafür eine Lösung? Oder gibt es Sitemaps, bei denen ich die Reihenfolge einfach neu definieren kann? Im JED wird so etwas nicht im Detail bei den Sitemaps beschrieben.

    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?

    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?

    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?)

    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?

    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.

    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.

    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.

    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?

    Hi! Triumph! – Alles funktioniert immer noch, wie gestern spät nachts.

    Ich habe aber heute Morgen zusätzlich in Matomo die Ziel-Website in CORS eingetragen, weil manche Browser aufgrund von Standard-Einstellungen einfach Matomo verweigern. Ebenfalls habe ich die Ziel-Website eingetragen als CORS auf der Quell-Website.

    Hat man uBlockOrigin laufen, so funzt das OptOut jedenfalls nicht. Und wenn in Brave der "Brave Schutz" aktiviert ist, geht Matomo OptOut auch nicht. Aber der "Brave-Schutz" blockiert erstaunlicher Weise nicht den Buchungskalender, obwohl bei dessen Benutzung ca. 30 Scripte von der Quell-Website benutzt werden.

    Erstaunlich finde ich auch, dass der Buchungskalender auf der Zielwebsite läuft, aber das zum Testen eingebundene Bild von der Quell-Website weiterhin nicht abrufbar ist. Das ist aber OK, weil es nur zum Test gewesen ist.

    Dass der Matomo-OptOut nicht funktioniert bei aktiviertem uBlockOrigin oder mit "Brave Schutz" hat IMHO rechtlich keine Auswirkungen, da der Besucher ja selbst die Nutzung verhindert hat – egal ob wissentlich oder unbewusst.

    Huhhhh langer Thread. Aber ich hoffe, damit auch anderen weiter geholfen zu haben.

    Mehrfach in Brave und Firefox getestet und es scheint zu funktionieren mit folgenden Einstellungen:

    uMatrix: alle Scripte usw. zulassen

    uBlockOrigin: deaktivieren

    im Brave-Browser den "Brave-Schutz" deaktivieren

    in der htaccess der Quellwebsite:

    In der Ziel-Website werden die gleichen Regeln verwendet ausgenommen die dritte Regel:

    Code
        Header always set Content-Security-Policy "frame-ancestors 'self' https://matomo.lebenslust-jetzt.de"

    Der Test mit den Browsern, egal ob mit dem Browser-AddOn "CacheCleaner" oder mit öffnen der Site in einem neuen Tab oder in einem neu gestarteten Browser ist nicht zuverlässig. Änderungen in der htaccess im HTTP-Header werden anscheinend erst nach mehreren Minuten wirksam.

    Bin gespannt, ob es morgen auch noch funktioniert! :)