nicht angemeldet
Rolf B
Camping_RIDER
Felix Riesterer
Matthias Scharwies
Matthias Scharwies
Rolf B
Matthias Scharwies
Rolf B
Rolf B
Hallo alle,
ich habe mal wieder ein Problem mit den Wiki-Cards. Auf der SVG/Tutorials Seite ist eine Card, die auf die CSS-Transforms verlinkt. Diese Card habe ich zweizeilig gemacht. Ich möchte nun die Transform-Raute vertikal in der Card zentrieren. Das ist natürlich ein nice-to-have und wenn's nicht geht, dann geht's nicht. Aber das will ich natürlich genau wissen.
Falls jemand denkt: Wieso, ist doch zentriert? - derzeit habe ich mir mit einem Füll-Div beholfen
Die Card ist natürlich nur eine von vielen, d.h. das, was ich mache, muss für alle Cards passen.
Die Idee ist, dass alle Cards über die Card-Vorlage erzeugt werden. Die erzeugt diesen HTML-Rahmen für die Cards:
<div class="card">
<div class="card-titel">
<div class="logo"><img ...></div>
TITELTEXT
<div>
<div class="card-inhalt">
...
</div>
</div>
Das Logo ist rechts gefloatet, kann also aus dem Titel hinaus und in den Inhalt hinragen und in beiden Text verdrängen. Das möchte ich auch so haben. Das .card-Element ist ein inline-size Container, was mir den Zugriff auf die cqh-Einheit verwehrt. Die hätte ich in einem size-Container, aber dann bekomme ich keine dynamische Anpassung der Höhe an den Inhalt.
Um die Transform-Raute vertikal zentrieren zu können, müsste .card-inhalt die volle Card-Höhe bekommen. Dann hätte ich diverse Möglichkeiten. Auf der Transform-Card wäre das mit height:100% möglich, aber nur, weil auf dieser Card das Titel-div nicht erzeugt wird. Wenn ich das auf anderen Cards mache, würde mir das Inhalt-div damit aus der Card hinaushängen. Ich kann daher nicht im Stylesheet grundsätzlich 100% Höhe auf den .card-inhalt geben. Ich muss es so machen, dass .card-inhalt so hoch ist, dass es in der Card den Platz unter dem Titel füllt. Es muss aber auch mindestens so hoch sein wie sein Inhalt, und die Card muss automatisch mindestens so hoch sein, dass Titel und Inhalt hineinpassen.
Wenn für den Card-Inhalt Flexbox oder Grid hinzunehme, bekomme ich einen Blockformatierungskontext auf den Titel. Das ist auch wieder Mist, weil dann das Logo im Titel eingesperrt bleibt.
Kann ich unter diesen Rahmenbedingungen nur mit CSS den .card-inhalt überhaupt die Card auffüllen lassen?
Rolf
Kaum hilfreich, aber … SCNR:
Wieso nur denke ich da jetzt (nicht nur) an meine „gedrehten Überschriften“? Transformierte Objekte sind mit position: absolute quasi verwandt: sie befinden sich nicht mehr im Element, liegen irgendwie darüber (werden aber von einem clip o. ä. gelegentlich dann doch noch beeindruckt) — und haben damit jeden Kontakt zu ihren Wurzeln verloren. Alles was sie mitbekommen können, ist ihr „Erbe“. Ob das nun mit inherit eingefordert wird oder einfach so mit in der Tüte ist.
Sie wandern damit alo aus. So weit, daß man in beiden Richtungen voneinander nur noch wenig mitbekommt: selbst wenn so ein „Auswanderer“ einen Brief heimschicken könnte, „Maße, Gewichte und sogar Währungen“ haben in dieser Welt nur lokal relative Bedeutungen.
Ach ja: bei grid und flex ist das nicht grundlegend anders.
Was bleibt? Wenigstens vorerst nur eine Idee. Über einen „absoluten Raum“, der alle da relevanten Werte von außen diktiert. Zahlen (usw.), an denen sich die (v. a. „kritischen“) Inhalte aufhängen lassen. IMHO eine art Hyper-Pixel-Layout, das beispielsweise an der einen Stelle „x breit, y hoch“, an der anderen als „y breit, 3 x hoch“ diktiert. (Ja, genau: so ein Flex- oder Grid-Item hat da – auch – keine Ahnung …)
Es soll jetzt nur niemand behaupten, daß mir das gefallen würde.
Aloha ;)
Auf der SVG/Tutorials Seite ist eine Card, die auf die CSS-Transforms verlinkt. Diese Card habe ich zweizeilig gemacht. Ich möchte nun die Transform-Raute vertikal in der Card zentrieren.
Ich mach mich jetzt mal unbeliebt und spiegle die Sichtweise von außen, aus Anwendersicht...
Wenn ich mir die verlinkte Seite anschaue, dann springt mir die eine zweizeilige Card extrem ins Auge - einerseits, weil sie größer ist als die anderen, andererseits, weil der Text - im Gegensatz zu allen anderen Cards - in die Card direkt mit eingebunden ist und dadurch extrem hervorgehoben wirkt.
Die Card ist so wie sie ist also ein richtiger Eyecatcher - und das ist in dem Fall nichts Gutes. Die Cards stellen gleichberechtigte Verweise auf Unterthemen dar. Eine einzelne Card derart durch auffallend andere Gestaltung hervorzuheben ist schlechte Nutzerführung.
Du solltest dein Problem daher meiner Meinung nach gar nicht lösen. Du solltest stattdessen den Text, der jetzt aktuell innerhalb der Grafik steht, wie in allen anderen Cards daneben schreiben, als kleineres seitliches Bild nur noch die gedrehten Kästen stehen lassen und dann eine einzeilige Card verwenden - wie alle anderen Cards auch, damit die Card ihren Zweck einer gleichberechtigten Verlinkung erfüllt.
Schon klar, nett dass man das machen kann mit dem gedrehten Text in der gedrehten Box - aber es bleibt letztlich eine Spielerei und beschädigt an dieser Stelle dann ggf. sogar den eigentlichen Zweck dieser Illustration, wenn dadurch diese Illustration gegenüber anderen gleichberechtigten extrem hervorsticht.
Grüße,
RIDER
P.S.: Auch wenn das nichts direkt mit dem Thema zu tun hat (ggf. gehört dieser Teil abgetrennt und extra diskutiert): Vielleicht sollte man insgesamt auch über die Gestaltung der Cards nochmal nachdenken. Der eine fehlende Rand auf der linken Seite geht visuell, vor allem in Verbindung mit den abgerundeten Ecken, überhaupt nicht, und die dotted-Linie... mei, wems gefällt, ich finds mehr schräg, habe da so Comic-Sans-Vibes. Gegen den Farbverlauf im Hintergrund habe ich nicht so viel wie gegen die Ränder, aber auch da ist halt die Frage, warum im Wiki-Gesamtdesign überall einfarbig hinterlegte Flächen vorkommen und nur in den Cards Farbverläufe. Wie gesagt, damit kann ich gut leben (mit den Rändern eher nicht so), aber mir ist nicht klar, warum man nicht einfach wie für alle farbig hinterlegten Flächen einfarbige Grautöne für die Cards her nimmt. Die Boxen links und oben haben ja auch nur ein einfaches #d5d5d5 bzw. #f1f3f4 und das Forum verwendet für interaktive Elemente auch grundsätzlich einfarbige Flächen...
Hallo Janosch,
wenn Dir das Gesamtdesign der Cards (Eckenrundung, Farbgebung, Randgestaltung) nicht gefällt, könntest Du einen Alternativvorschlag machen, der dein Konzept zeigt. Das existierende CSS ist in mediawiki:common.css zu finden (im Testwiki selfhtml.css), das HTML in Vorlage:Card.
Dass wir sonst nirgends Farbverläufe haben, ist fast richtig. Guck in die blaue Titelzeile 😉.
Matthias hat die Transform-Card bewusst so gestaltet, dass sie Transforms verwendet. Man hätte auch ein SVG-Bild erstellen können. Diesen selbstbezüglichen Ansatz kann man diskutieren, aber das ist ein anderes Thema.
Man könnte in Frage stellen, ob die Card in dieser Prominenz etwas auf der SVG Seite verloren hat. Ich habe sie auf 2 Reihen vergrößert, weil sie sonst ihre Nachbarcards zu sehr vergrößert. Aber das ist ein Thema, das Matthias schon ansprach: Man müsste diese Portalseiten gemeinsam durchgehen und tunen. Das ist im Forum schlecht, das sollte eine Discord-Session sein oder live passieren.
Der Anlass mag damit wegdiskutierbar sein, mein Anliegen aber nicht: Kann ich .card-inhalt unter den genannten Rahmenbedingungen auf volle .card-Höhe bringen?
Rolf
Servus!
Hallo Janosch,
wenn Dir das Gesamtdesign der Cards (Eckenrundung, Farbgebung, Randgestaltung) nicht gefällt, könntest Du einen Alternativvorschlag machen, der dein Konzept zeigt. Das existierende CSS ist in mediawiki:common.css zu finden (im Testwiki selfhtml.css), das HTML in Vorlage:Card.
nur mal als Idee, weil Janosch das Forum ansprach:
JavaScript_und_CSS (Test-Wiki)
Da habe ich mal die Farben der Kategorie-Tags im Forum genommen. (Evtl. [Strg] [F5] drücken)
Dass wir sonst nirgends Farbverläufe haben, ist fast richtig. Guck in die blaue Titelzeile 😉.
Matthias hat die Transform-Card bewusst so gestaltet, dass sie Transforms verwendet. Man hätte auch ein SVG-Bild erstellen können. Diesen selbstbezüglichen Ansatz kann man diskutieren, aber das ist ein anderes Thema.
Genau, das mit den Cards war ja eine Entwicklung mit Experimenten, die wir jetzt vereinheitlichen wollen.
Und ja, ich hatte teilweise eben noch diese Linklisten vor Augen. Da sollten wir drauf schauen, dass die Cards ungefähr eine aspect-ratio: 2/3 haben.
Man könnte in Frage stellen, ob die Card in dieser Prominenz etwas auf der SVG Seite verloren hat. Ich habe sie auf 2 Reihen vergrößert, weil sie sonst ihre Nachbarcards zu sehr vergrößert. Aber das ist ein Thema, das Matthias schon ansprach: Man müsste diese Portalseiten gemeinsam durchgehen und tunen. Das ist im Forum schlecht, das sollte eine Discord-Session sein oder live passieren.
Genau! In Hannover? Vorher?
Der Anlass mag damit wegdiskutierbar sein, mein Anliegen aber nicht: Kann ich .card-inhalt unter den genannten Rahmenbedingungen auf volle .card-Höhe bringen?
Ich komme auch nur auf die 100% des Eltern-Containers.
Herzliche Grüße
Matthias Scharwies
Guten Morgen,
ich habe lange überlegt, ob ich noch etwas zum Thema beitragen kann.
Es geht um die Cards.
Siehe hier: Hilfe:Verbesserungsvorschläge/2023
Matthias hat die Transform-Card bewusst so gestaltet, dass sie Transforms verwendet. Man hätte auch ein SVG-Bild erstellen können. Diesen selbstbezüglichen Ansatz kann man diskutieren, aber das ist ein anderes Thema.
Ich hatte das ganze letzte Jahr experimentiert: Rastergafiken, a-Elemente mit vielen spans (so auch das transform-Beispiel) und den SVG-Infografiken als Cards; aber eben auch Tiles in denen in einem div mehrere Links präsentiert werden können.
Wir haben beschlossen, diesen Wildwuchs zu vereinheitlichen und eine Vorlage:Card zu erstellen.
Und dabei haben wir jetzt folgendes Problem:
Normalerweise sollte das 1. Kind einer Card als Titel oben kleben. Bei der Transform-Card sucht Rolf eine Möglichkeit, dies aufzuheben und den Inhalt mittig zu zentrieren.
Rolf hat ja schon die technische Lösung gefunden:
Auf der Transform-Card wäre das mit height:100% möglich,
Dies kann man entweder mit einem Parameter in der Vorlage oder mit einem weiteren Div-Container erreichen. Wollen wir das?
Alternativ könnte man eben überlegen, wie eine Card aussehen soll, die in unser Schema passt.
Das würde ich gerne morgen ab 20:15 am Stammtisch mit euch gemeinsam tun.
@Camping_RIDER Wie gefällt dir die blaue Färbung im Test-Wiki: JavaScript_und_CSS
Auch für diese Seite müsste man über Aufbau und Inhalt der Cards diskutieren.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Alternativ könnte man eben überlegen, wie eine Card aussehen soll, die in unser Schema passt.
Das können wir tun, aber damit behandeln wir das Symptom, nicht die Ursache.
Das Grundproblem bleibt: wie bringe ich es zu Stande, dass das .card-inhalt div den Teil unter dem Titel vollständig ausfüllt und dabei die Eigenschaften des gefloateten Logos erhalten bleiben.
Wenn ich keinen Titel habe (bzw. dieser mit position:absolute aus dem Flow ist), dann kann ich den .card-inhalt auf 100% bringen. Das tue ich bereits (im Wiki mache ich es ohne Nesting):
.cards-list .card:has(.vollbild)
{
.card-titel {
position: absolute;
width: 100cqw;
}
.card-inhalt {
display: flex;
flex-flow: column;
justify-content: end;
height: 100%;
}
}
Aber das klappt aus den genannten Gründen nicht, wenn .card-titel und .card-inhalt beide im Flow sind. Bisher kam kein Vorschlag, das könnte bedeuten, dass es tatsächlich nicht geht. @Gunnar Bittersmann - hast Du schonmal drei Hirnzellen daran verwenden können?
Eine Lösung, die ich vermeiden will, besteht in einer statischen Zauberei mit einer festen Höhe für den Titel und einem calc(100% - var(--titel-höhe)) für den Inhalt. Oder wenn, dann nur mit einem Resize-Observer auf dem Titel, der die Titelhöhe ermittelt.
Ich werde mal eine Frage auf Stack Overflow stellen.
Rolf
Lieber Rolf,
auf Deine konkrete Frage weiß ich keine Antwort, weil ich mit den Layoutkonzepten noch nicht vertraut bin, die Du da ansprichst. Aber mir fällt etwas anderes auf:
<div class="card"> <div class="card-titel"> <div class="logo"><img ...></div> TITELTEXT <div> <div class="card-inhalt"> ... </div> </div>
Div-Suppe ist wieder im Kommen! Aber mal ernsthaft: Braucht es neben der Klasse card weitere Unterklassen? Ist nicht das erste Kind-Div zwingend dasjenige mit dem Titel? Dann kann man sich die Klasse card-titel ganz sparen und verwendet einen passenden Selektor mit nth-child(n). Oder siehst Du da gravierende Nachteile? Auch card-inhalt lässt sich einsparen, wenn klar ist, dass das zweite Kind-Div von .card zwingend dasjenige mit dem Inhalt ist.
Wenn ich unsere letzte Discord-Runde richtig in Erinnerung habe, wolltest Du zweierlei Konzepte umsetzen, wobei eines ein gefloatetes img-Element verwendet, ein anderes aber ein Hintergrundbild. In diesem Fall kann man ja noch eine zweite Klasse an das .card-Div anbringen, die dafür sorgt, dass wiederum andere Selektoren greifen, ohne dass man die Div-Divs mit eigenen Klassen belegen muss.
Noch lieber wäre mir ein semantisches Markup. Was spricht gegen diese Struktur?
<div class="card">
<h6><!-- Titel -->
<img src="" alt="Logo mit gekippten Quadraten">
TITELTEXT
</h6>
<p><!-- Inhalt -->
...
</p>
</div>
Dann schreiben sich auch die Selektoren besser, wenn man kein .card > div:nth-child(1) schreiben muss, sondern stattdessen .card h6 nehmen kann. Liest sich in meinen Augen auch besser.
Liebe Grüße
Felix Riesterer
Servus!
Div-Suppe ist wieder im Kommen!
Noch lieber wäre mir ein semantisches Markup. Was spricht gegen diese Struktur?
<div class="card"> <h6><!-- Titel --> <img src="" alt="Logo mit gekippten Quadraten"> TITELTEXT </h6> <p><!-- Inhalt --> ... </p> </div>
Leider wird jede Überschrift in das TOC -Inhaltsverzeichnis übernommen. Das könnte man auf Portalseiten aussschalten, am Ende eines Artikels auf == Siehe auch == aber nicht.
Ein Teil der Div-Suppe ist Wiki-bedingt, jedes Bild sieht im Wiki so aus:
<div>
<a href="link auf Bildseite">
<img >
</a>
</div>
Ich hatte - z.B. bei der angesprochenen transform-Raute mit einem a-Element mit Kindelementen experimentiert. Dann gehen aber nur span-Elemente und keine Bilder.
ODer man müsste doch das ideale HTML-Markup mit JS erzeugen:
<a class="card" href="link auf Seite">
<p class="titel">Titel</p>
<img class="logo">
<div> Platz für Inhalt</div>
</a>
Da hatte ich aber immer Bammel davor, denn wenn wir da mal anfangen…
Andererseits könnte man dann die „Vollbilder“ als Hintergrundbild im a festlegen.
Mein Vorschlag: Erstmal so lassen und hoffen, dass man dermaleinst HTML5, bzw. flexibleres Markup im Wiki verwenden kann.
Herzliche Grüße
Matthias Scharwies
… Ist nicht das erste Kind-Div zwingend dasjenige mit dem Titel? …
Nennt man so etwas „heute“ nicht header? (Hier dann vielleicht .card > header?)
Servus!
… Ist nicht das erste Kind-Div zwingend dasjenige mit dem Titel? …
Nennt man so etwas „heute“ nicht
header? (Hier dann vielleicht.card > header?)
Ja, aber im Wiki können wir nur gewisse HTML-Elemente verwenden, daher die eigentlich verpönte div-Suppe.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
zur Erklärung: Das liegt erstmal am Mediawiki-Parser. Dem muss man jedes HTML Element freischalten, das in Wikitext zulässig ist.
Die semantischen Elemente könnte man zulassen. In einer Card setzt ein header Element aber voraus, dass die card eine Section erzeugt (article, section, aside, nav, main), sonst passt das semantisch nicht. Die Cards Abfrage sind aber li in einer ul.
Ob es richtiger wäre, sie zu sections in einem nav zu machen? Ich glaube nicht, für eine section sind sie zu klein. Also kein header pro card. Glaube ich.
Rolf
Sehen wir es mal etwas distanzierter, abstrakter: auf die Größe soll es ankommen? Was macht man dann, wenn der Inhalt sich dynamisch ändert? Mal einem Roman gleicht, dann aber gerade mal nur ein eher dümmliches „Hä?“ hergibt?
Bildlich gesprochen: Nirgends im Duden steht drin, wie umfangreich ein Text sein muß, um in (in seinem Sinne) regelkonformer Weise verfaßt zu werden. Und wann der dann, im Umkehrschluß, vielleicht gar Zinken erzwingt?
Ein, zwei nicht groß durchdachte Gedanken „in der Nähe“:
Außerdem, so nebenher, gibt es ja auch keine Pflichten, die besagen würden, daß einem h1 ein h2folgen muß. Wo wäre festgeschrieben, daß eine Überschrift nicht schlicht von einem simplen Absatz ihre Existenzberechtigung erhält? Ja wenn die Absäzte sich wie Flöhe zu verhalten anfangen …
Noch so eine irritierende Überlegung: ist <summary>nicht auch eine Art <header>? Hmm… also die Browser sehen das, „in der Außendarstellung“, nicht so. Denen sind mehrere davon an fast beliebiger Position der <details> durchaus recht. Nur das Abzählen (:first-child etc.) will da nicht mitspielen.
Servus!
Sehen wir es mal etwas distanzierter, abstrakter: auf die Größe soll es ankommen? Was macht man dann, wenn der Inhalt sich dynamisch ändert? Mal einem Roman gleicht, dann aber …
Es geht um die Cards.
Siehe hier: Hilfe:Verbesserungsvorschläge/2023
Herzliche Grüße
Matthias Scharwies
Ja, Cards waren und sind das eigentliche Thema. Aber „In einer Card setzt ein header Element aber voraus, dass die card eine Section erzeugt (article, section, aside, nav, main)“ liest sich (fast) so, als ob alles, was von
<article>
<section> … </section>
<aside> … </aside>
</article>
abweicht, verboten oder gar unmöglich wäre. Wobei, da fehlt doch was! Wenn, dann doch:
<article>
<header> … </header>
<section> … </section>
<aside> … </aside>
<footer> … </footer>
</article>
Na ja, dieser MediaWiki-Parser scheint das ja dann doch zu tun. Und … hmmm… bei der Formulierung wäre das erste Exemplar aber dann ja doch wieder erlaubt? Ist ja kein <header> drin … 🥳
Hallo nix,
der Mediawikiparser lässt einfach diese Elemente nicht zu. Und wenn Du keine Idee zu meiner CSS Frage hast, solltest Du den Thread jetzt bitte nicht weiter kapern.
Rolf
Hallo nix,
Hä?
Rolf
Na, wir haben „heute“ ein paar neue Elemente. Die sind, im Gegensatz zu den alten, vor allem diesen „historisch gewachsenen“, grundsätzlich erst mal frei von gestalterischen Aufgaben „grafischer Art“.
Das einzige Problem dabei und mit ihnen ist (bis auf weiteres), daß sie in den anderen gefangen sind — oder diese ebenso fangen. Sprich: so etwas geht nicht:
<neuling>
<div>Bla …</neuling> …bla…
</div>
Gut, man kommt meist drum herum, kann den Effekt (z. B. „Text, der sich vom 1. bis 3. Grid-Item über das 8. bis 10. und danach ab dem 15. bis zu seinem Ende ergießt“) mit floathinkriegen. Aber wenn man „HTML&Co“ schon so aufbläst, daß man damit (wenigstens theoretisch) ganze Lexika (womöglich auch noch als Einseiter!) abbilden kann …
Sei’s drum: ungefähr die Stelle, an der run-in bisher (soweit ich das bei meinen Streifzügen bisher verstanden habe) gescheitert ist: z. B. der Inhalt eines Artikels, der sich über verschiedene Bereiche in da angelegte „ich wäre bereit für den Artikel“ Elemente verteilt. (An der Stelle scheint ja z. Zt. auch gekocht zu werden, irgendwo hab’ ich da was gelesen.)
Damit ist dann aber, finde ich, eine Forderung nach Mindest- und Maximal-Inhalten einigermaßen sinnfrei. Ein <header> ist ein <header>, egal, ob der nun diesen im Artikel oder in einem anderen Element, mal eher inhalts- (header in einem article, aber auch in da drin zu findenden sections …), mal aber mehr gestaltungsbezogen (wie eben bislang schon summary in details; bei figure/figcaption … ist figcaption nicht mehr „Unter-“ denn eine „Überschrift“? Also ein header/footer-Zwitter?) eingesetzt wird.
Jedenfalls wird ja auch einigermaßen deutlich zwischen h1…6 und header unterschieden: sectioning content ➔ headings and sections
Und: ein Beispiel gibt’s auch noch:
Here the attribution is given in a footer after the quoted text, and metadata about the reference has been added using the Microdata syntax (note it could have equally been marked up using RDFA Lite).
<blockquote>
<p>… she said she would not sign any deposition containing the word “amorous”
instead of “advances”. …</p>
<footer itemscope itemtype="http://schema.org/Book">
<span itemprop="author">Heinrich Böll</span>,
<span itemprop="name">The Lost Honor of Katharina Blum</span>,
<span itemprop="datePublished">January 1, 1974</span>
</footer>
</blockquote>
Was noch „richtig interessant“ wird: wird man “legacy”, diese historisch gewachsenen Elemente, meucheln (müssen)? Damit die nicht selten sinnverwirrende Frage, ob es denn nun ein inhaltlich strukturierendes oder ein designendes Element wäre … hmmm… kann man die überhaupt wirklich „klären“?
BTW: wenn man „bei denen unter die Motorhaube schaut“, findet man im CSS manch hübsche Stelle. Beispielsweise die ids der Links in der Tabelle “Abstract-to-Physical Mappings”. 2:0? 🤓