Posts by Donner

    :/ Es ist wie so oft im Leben... Vorführeffekt


    Bei mir habe ich gerade im ersten Anlauf das Problem reproduzieren können: Sie ersten Beitrag hier:

    Test zu verschwundenen Dateianhängen - Thunderbird Mail DE
    kasdjeAchtung Rutschgefahr.png
    www.thunderbird-mail.de


    In den weiteren Versuchen klappte es dann wieder nicht. Bei den Versuchen ist mir noch etwas anderes aufgefallen:

    Wenn man einen Reload im Editor vor dem finalen Absenden macht, bleiben manchmal die Dateianhänge bzw. Grafiken im Editor zu sehen, aber manchmal sind diese nach dem Reload einfach sofort weg. In letzterem Fall würde man eh neu hochladen und hätte das "Nirvana"-Problem gar nicht.

    Es muss irgendwas beim Erstellen des Beitrags schief gehen. Ich habe Beiträge in Verdacht, die über eine sehr lange Zeit (mehrere Stunden) geschrieben werden. Merkwürdigerweise scheinen die Bilder zuerst im Beitrag zu sehen sein, sonst würden es die Autoren ja merken, dass ihr Beitrag keine Bilder hat.

    Wenn ich nicht irre, passiert dies, wenn zwischen Einfügen oder vermeintlichem Hochladen der Grafiken ein Reload im Browser ausgeführt wird. Die Grafiken werden dann letztlich nicht korrekt beim finalen Absenden des Beitrags mit hochgeladen oder verschwinden sonst wo im Nirvana. Das lässt sich reproduzieren. Ruft den Beitrag nach solch einem Versuch einfach mal mit einem anderen Browser auf - die Grafik wird nicht da sein. Sie ist nur im ursprünglichen Browser (dank Cache) zu sehen.


    Alexander Ebert

    Dies ist es durchaus wert, um zu den Fehlern des Core verschoben zu werden und es anzugehen, denke ich.

    Ich wurde von einem Foren-Benutzer über folgendes informiert:


    1.) Benutzer eines Screenreaders benötigen bei der Auswahl der Labels mehr Information. Es genügt nicht die kurze Bezeichnung des Labels (bspw: "Version"). Hier müsste ein beschreibender Text in der Art "Bitte wählen Sie eine Version aus der Liste" zusätzlich möglich bzw. vorhanden sein. Der Text könnte vom WSC bzw. WSF natürlich auch allgemein gehalten sein: "Bitte wählen Sie eine der Optionen aus dem Auswahlmenü." oder bei erzwungener Auswahl: "Sie müssen eine der Optionen aus dem Auswahlmenü wählen.". Andernfalls hören/lesen die blinden Menschen einfach nur den Namen des Labels "Version" und müssen selbst auf die Idee kommen, dass hier überhaupt eine Auswahl möglich wäre - es könnte ja einfach auch irgendein Text sein.


    2.) Das Auswahlmenü der Labels ist für den Screenreader scheinbar nicht zugänglich:


    Wie schaut es denn generell mit der Barrierefreiheit des WSC / WSF aus? Wird dies bei der Entwicklung des Systems berücksichtigt?

    von was für einem Overhead die Rede ist

    Damit meinte ich den Teil des CSS, den man mit Optimierung einsparen könnte - also nichts, was Dir widersprechen würde.


    Ich denke man müsste hier im Thema differenzieren, in ein Profi die Optimierung macht bzw sich mit dem Ergebnis auseinander setzt oder ein Amateur. Und niemand stellt in Frage, dass Optimierung prinzipiell gut ist. Die Frage ist aber, ob es sich für "unsere" zusätzlichen Codezeilen lohnt.

    Das es komplex ist dachte ich mir, mein Problem ist, das ich 1400 Zeilen CSS habe, da dachte ich das es da vllt. was gibt das dass Reduziert.

    Wie soll ein Amateur nach solchen Tools noch erkennen können, wo neue Probleme im CSS entstanden sind, weil das Tool "falsch gehandelt" hat? Man kann doch überhaupt nicht alles auf der Website überblicken, um dann selbst die Fehler zu finden - jedenfalls nicht, wenn das Tool tatsächlich entscheidend viel Overhead reduzieren könnte. Wenn das Tool fast nichts findet/verändert, dann hat es auch nichts relevantes gespart.

    Anscheinend ist der HTML-Generator empfindlich für bestimmte Tags oder vermeintliche Fehler im HTML, was dann zu den übermäßigen <p></p> im Code führt. Wenn ich das Beispiel von oben nehme und etwas abspecke, dann kann ich durch wiederholtes Wechseln zwischen HTML und WYSIWYG jeweils 2 zusätzliche <p></p> Zeilen an jeder Leerzeile provozieren. Auch das <p></p> vor dem <center><img.... kann ich provozieren.


    Wenn ich andererseits scheinbar sauberen Code habe, der pur aus einem ursprünglich leeren WYSIWYG Text erzeugt wurde, dann tritt das Verhalten gar nicht auf.

    Das hast du falsch verstanden. Denn Imagick (PHP) hat mit den Bildformaten nichts zu tun. Formate, die von ImageMagick unterstützt werden, werden automatisch von Imagick unterstützt.

    Dann ist es bei mir vermutlich an der zusätzlichen Hürde von Plesk und dessen PHP-Versionen auf dem Server gescheitert. Jedenfalls hat das manuelle Installieren der aktuellen ImageMagick-Version unter Ubuntu 18.04 nicht ausgereicht, um dann WebP für Imagick in "meinem" PHP verfügbar zu haben.

    Du meinst also die Darstellung, wenn nur noch eine Spalte für die Boxen übrig bleibt (auf Smartphones).


    Ändere folgende Regel:

    CSS
    @media (max-width: 1024px){
        .boxesSidebarLeft>.boxContainer>.box, .boxesSidebarRight>.boxContainer>.box {
            border: 0;
            border-radius: 10px;
            margin: 0 0 30px 0 !important;
        }
    }

    so ab:

    CSS
    @media (max-width: 1024px){
        .boxesSidebarLeft>.boxContainer>.box:not(:last-child), .boxesSidebarRight>.boxContainer>.box:not(:last-child) {
            border: 0;
            border-radius: 10px;
            margin: 0 !important;
    }


    Zusätzlich könntest Du noch folgende Regel:

    Code
    .content:first-child+.boxesSidebarRight {
        margin-bottom: 20px;
        margin-top: 0;
    }

    so ändern:

    Code
    @media (max-width: 544px){
        .content:first-child+.boxesSidebarRight {
            margin-bottom: 0;
            margin-top: 0;
        }
    }