Don’ts für ein neues Stilsystem

  • App
    WoltLab Suite Core

    Ich weiß, Sammelthemen sind nicht gewünscht. Das hier aber in einzelne Tasks aufzuteilen, finde ich wenig sinnvoll. Viel mehr soll es auch als Checkliste dienen und kann vielleicht nach GitHub hin übernommen werden, wenn es irgendwann mal darum geht, ein neues Stilsystem zu entwerfen bzw. das aktuelle zu überarbeiten.

    Bei meiner letzten Stilerstellung habe ich einfach mal gesammelt, was nicht optimal ist:

    Nicht-Standard-Schriftdicke, die man nicht konfigurieren kann

    font-weight: 300 bzw. font-weight: 600 hat nicht jede Schriftart.

    Negatives margin für den Inhalt

    Beispiel .content > .section

    Beispiel Footer-Boxen

    Farben des Stileditors teilweise erst ab einem gewissen Breakpoint verwenden

    Beispiel pageNavigation, das ist jedes Mal wieder mobil eine unnötige Anpassung.

    Mobile Breadcrumbs verbessern

    Negatives margin-top verändert die Positionierung von pageNavigation drastisch

    Grobe Layout-Bereiche global verfügbar machen

    Beispiel .wbbStats etc. => muss sonst von jedem Entwickler mit eigenem Präfix hinzugefügt werden, mehr Aufwand für Stilersteller.

    Icons innerhalb von Links mit eigener Farbe

    currentColor wäre hier sinnvoll, um die Link-Farbe zu erben.

    Überschriften standardmäßig ohne abstufende Höhe
    Verwendet man selbst irgendwo im HTML eine Überschrift, muss man diese dann erst selbst anpassen, dass sie eine ordentliche Größe bekommt.

    !important vermeiden

    Warum, sollte klar sein.

    Mobil die Schrift eigenmächtig fix und nicht einstellbar für alle verkleinern

    Alles manuell anzupassen ist mühselig.

    Lange Verkettungen von Selektoren vermeiden
    Beispiel: .containerList > li .buttonGroupNavigation > ul > li > a > .icon
    Besser: den Listenelementen und Links eindeutige Klassen geben (bsp. buttonGroupNavigationItem bzw. buttonGroupNavigationLink) und dann damit arbeiten.

    Icons innerhalb von Links andere Farben geben

    Beispielsweise .menuOverlayItemLinkIcon.active>.icon::before statt .menuOverlayItemLinkIcon.active und sämtlichen Icons ein color: currentColor;.

    Falls jemandem noch weitere Dinge auffallen, gerne ergänzen. :)

  • Black Rider 29. März 2021 um 11:46

    Hat den Titel des Themas von „Don’t für ein neues Stilsystem“ zu „Don’ts für ein neues Stilsystem“ geändert.
  • Könnte man denn nicht jedem einen einzelnen dl container geben?

    Beispiel

    Code
    <div class="dataList">
        <dl class="dataList__container">
            <dt></dt>
            <dd></dd>
        </dl>
        <dl class="dataList__container">
            <dt></dt>
            <dd></dd>
        </dl>
    </div>
  • Das würde halt die Semantik verändern. Wenn man das nur macht, um es "einfacher gestalten zu können", kann man gleich für alles <div> verwenden. Vielleicht lässt sich das Problem, welches du gerne mit einem solchen Container lösen würdest, auch anders lösen, CSS ist ja recht mächtig geworden, aber das sollten wir an einer anderen Stelle fortführen, weil das mit dem Vorschlag nichts mehr zu tun hat. ;)

  • auf die Schnelle würde mir einfallen:

    • standardmäßig auf Schriftgrößen in px verzichten (sollte nur noch eine Option im Editor sein) - die Standardgröße sollte dabei 16px entsprechen
    • auf Iconfonts verzichten und stattdessen auf SVG(-Sprites) setzen
  • auf Iconfonts verzichten und stattdessen auf SVG(-Sprites) setzen

    Bei der Menge an Icons, die verwendet werden, glaube ich nicht, dass das sinnvoll ist. Font Awesome ist zwar groß, aber als Sprite sind es 1,2 – 1,6 MB in der aktuellen Version 5, was durchaus wesentlich größer ist als sie per Font zu laden.

    Ich verstehe den Punkt von LoStisWorld durchaus, habe da selbst schon Dinge mit kaum oder nicht sauber umsetzen können. Data-Listen gehören für mich verboten. :D

  • Mich würde ja mal ein Beispiel interessieren, was genau Probleme mit dem Markup dieser Listen bereitet. Mir ist schon klar, dass es auf "klassischen Wegen" etwas schwierig sein kann, wenn man kein zusätzliches Markup einfügen darf, aber man kann doch echt viel mehr machen, als man zunächst meinen möchte, wenn man Gebrauch von modernen Standards wie Grids macht. Aber das ist halt alles nur Theorie, ohne den realen Anwendungsfall zu kennen. Vielleicht ist ja genau das, was ihr im Sinn habt, tatsächlich schwierig bis unmöglich umzusetzen. Das interessiert mich jetzt einfach mal. ;)

  • Mir würde es schon reichen wenn WoltLab vielleicht mal solche Geschichten in Zukunft in Angriff nimmt. So das man als Drittanbieter die Software-Farben auch mit nutzen kann ohne dafür eigene Variablen anzulegen. Zumal es dutzende Fälle gibt bei denen WoltLab extra Variablen dafür hat, sie aber nicht nutzt.

    Würde man ein $white definieren statt rgba(255...) dann könnte man das White im Falle eines Dark/Light-Modes auch wesentlich einfacher bearbeiten.

  • Bitte zerlegt das Thema nicht mit Diskussionen über nutzen oder geht ja eh nicht.

    Ich finde das Thema gut, so kann man als Entwickler einfach sagen was man vermisst oder geändert haben möchte.

    Wenn ihr einer Idee oder Wunsch zustimmt gibt es Reaktionen.

    Nutzt diese.

    Falls ihr eigene Ideen oder Wünsche habt immer her damit.

    Ich werde hier garantiert auch ein wenig meine Wünsche reinschreiben aber erst zu Ostern.

    Arbeit geht nun mal vor ^^

  • Ich hätte gerne eine Klasse mit der ich Vorschaubilder stylen kann (Abstände, Rahmen usw.) , wenn der Nutzer kein Recht hat, diese groß zu klicken (herunterzuladen). Das sind bei mir Gäste.

    Außerdem hätte ich in der Threadansicht gerne eine Klasse, damit ich einen Abstand zwischen die Post bekommen kann, wenn ich nicht die jetzt vorhandene Linie haben möchte, sondern jeweils Rahmen um das Posting. So wie es früher auch beim 4.1 war.

    Liebe Grüße
    Susi

  • Außerdem hätte ich in der Threadansicht gerne eine Klasse, damit ich einen Abstand zwischen die Post bekommen kann, wenn ich nicht die jetzt vorhandene Linie haben möchte, sondern jeweils Rahmen um das Posting. So wie es früher auch beim 4.1 war.

    Wozu brauchst Du da eine weitere Klasse? Das geht auch mit der vorhandenen Struktur.


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

  • Zum Thema Stilsystem: Ich finde es sehr unglücklich, dass für den Header in den E-Mails die gleiche Hintergrund-Farbe verwendet wird für den Header der Website. Ich würde mir hier unterschiedliche Felder wünschen. Ich halte es generell für keine gute Idee, Website- und E-Mail-Gestaltung zu vermischen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!