Cards im Wiki

[Rolf B]

Hallo Wiki-Autoren,

das Thema Cards, das wir neulich im Discord besprochen hatten, ist jetzt soweit umgesetzt und im Hauptwiki verfügbar.

Auf der Vorlage:Card Seite ist die Dokumentation und ein paar Beispiele. Auf der "Wie fange ich an?" Seite sind die ersten 6 Cards umgestellt.

Ich bitte die, die es interessiert, um einen Review. Haben wir damit das, was wir besprochen hatten?

Rolf

[Matthias Scharwies]

Servus!

Hallo Wiki-Autoren,

das Thema Cards, das wir neulich im Discord besprochen hatten, ist jetzt soweit umgesetzt und im Hauptwiki verfügbar.

Auf der Vorlage:Card Seite ist die Dokumentation und ein paar Beispiele. Auf der "Wie fange ich an?" Seite sind die ersten 6 Cards umgestellt.

Ich bitte die, die es interessiert, um einen Review. Haben wir damit das, was wir besprochen hatten?

Ja,

eine einfache übersichtliche Struktur! Vielen Dank!

eine Verständnisfrage:

link gibt an, auf welche Wiki-Seite die Card verlinken soll. Der Link überdeckt die ganze Karte! Links im Karteninhalt sind unzulässig.

Damit sollte der Link bei :Hover irgendwie gekennzeichnet werden, vorzugsweise in einer „Linkfarbe“.

Das ist jetzt ein schwarzer Rand - evtl. wieder ein blauer Schatten?

Was mich stört ist das img:hover bei den ersten beiden Cards, wo ich gar nicht weiß, wo es herkommt, wenn oben drüber der Link ist?

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

wenn ein Kindelement der Card die Klasse can-glow hat, wird dafür, sobald der Link aktiv wird (Fokus oder Hover), die Farbe Orange und der Box-Shadow gesetzt.

Dammich, das wollte ich aufgeschrieben haben.

Die Vorlage setzt can-glow für das Icon bzw. das Logo sowie für das Inhaltsbild

Das geht in etwa so:

.card:has(a:hover, a:focus) .can-glow {
   color:orange;
   box-shadow: ...;
}

Ich kann für den Titeltext bei aktivem Link auch noch eine Unterstreichung setzen.

Rolf

[Rolf B]

Hallo Matthias,

so, die Unterstreichung ist drin und die "Wie fange ich an" Seite ist auf die Vorlage umgestellt.

Ich muss gestehen, dass das mehr Arbeit war als gedacht. Kann aber auch daran liegen, dass das Feintuning der Card-vorlage und der Einbau auf die Seite sich gegenseitig gestört hat 😉

Ich habe noch einen Parameter vollbild= hinzugefügt. Der wird alternativ zu "bild" verwendet und führt dazu, dass der Titelbereich auf position:absolute gesetzt wird, so dass er über dem Bild schwebt. Die Card "der richtige Code-Editor" gewinnt dadurch. Und ich habe das Idee-Bild für "Vom der Idee zum Projekt" etwas niedriger gemacht, sonst war da zu viel Abstand drüber. Hätte ich auch lassen können, als "vollbild" wäre das viel einfacher gewesen. Aber das habe ich erst danach gebaut 🙄.

Was mir jetzt noch fehlt, ist eine Idee, wie ich ein Bild bündig an die Unterkante der Card setze, wenn Nachbarcards die Höhe der Card-Zeile erhöhen. Das müsste man bei "Bilder im Internet" tun. Aber wie man das korrekt in den Rest des Card-Layouts integriert, das ist mir noch unklar. Eigentlich müsste der Card-Inhalt mit display:flex erstellt werden und der Inhaltsbereich mit flex:1 0 auto erstellt werden. Aber das hat andere Störeffekte, Flexitems haben ihren eigenen Blockformatierungskontext und das gefloatete Icon kann dann nicht mehr aus dem Titel hinausragen. Vermutlich gibt's da keine Universallösung 😟. Bild als Hintergrundbild erstellen und der Card eine Mindesthöhe geben ist auch nicht drin, weil die Bildhöhe ja mit der Card-Breite wechseln kann. Sollte man die Cards zu Containern machen?

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

so, die Unterstreichung ist drin und die "Wie fange ich an" Seite ist auf die Vorlage umgestellt.

Danke! Ich hab mir die Cards angeschaut und versucht die einzelnen Parameter nachzuvollziehen.

wenn ein Kindelement der Card die Klasse can-glow hat, wird dafür, sobald der Link aktiv wird (Fokus oder Hover), die Farbe Orange und der Box-Shadow gesetzt.

Dammich, das wollte ich aufgeschrieben haben.

Die Vorlage setzt can-glow für das Icon bzw. das Logo sowie für das Inhaltsbild

Das geht in etwa so:

.card:has(a:hover, a:focus) .can-glow {
   color:orange;
   box-shadow: ...;
}

Die orange Linkfarbe ist ja ein Relikt aus dem braunen Theme des Jahres 2010^[1]

Mir geht es drum:

Eine Card ist ein Link .

Dann erwarte ich auch eine Umrandung um eben diesen und nicht um die Bilder, die nur einen Teil der Card ausmachen.

So wie bei der zweiten Card "Der richtige Code-Editor". Das würde ich nächste Woche auch bei den anderen Cards so einführen - nur eben in blau!

.card a:hover, 
.card a:focus {
  color: blue;
  box-shadow: ...;
}

Die dritte Card für den Seiteninspektor wird bei :hover schwarz! Da hätte ich den gleichen blauen glow erwartet, auch bei Card 4-6, aber eben ohne, dass die Icons dann extra gekennzeichnet werden.

Ich kann für den Titeltext bei aktivem Link auch noch eine Unterstreichung setzen.

Ja, wobei man eigentlich die Unterstreichung im Normaltext haben müsste. Das fände ich aber nicht so schön.

Ich habe noch einen Parameter vollbild= hinzugefügt. Der wird alternativ zu "bild" verwendet und führt dazu, dass der Titelbereich auf position:absolute gesetzt wird, so dass er über dem Bild schwebt. Die Card "der richtige Code-Editor" gewinnt dadurch. Und ich habe das Idee-Bild für "Vom der Idee zum Projekt" etwas niedriger gemacht, sonst war da zu viel Abstand drüber. Hätte ich auch lassen können, als "vollbild" wäre das viel einfacher gewesen. Aber das habe ich erst danach gebaut 🙄.

Sollte man, jetzt - bevor wir die div-Cards umbauen, die beiden Parameter zusammenfassen?

vollbild ist ja gut; Beim Erstellen des Bilds schaut man, wo sich der Titel befindet, für den Einsatz des normalen bild könnte man den Inhalt-Parameter nehmen.

Was mir jetzt noch fehlt, ist eine Idee, wie ich ein Bild bündig an die Unterkante der Card setze, wenn Nachbarcards die Höhe der Card-Zeile erhöhen. Das müsste man bei "Bilder im Internet" tun. Aber wie man das korrekt in den Rest des Card-Layouts integriert, das ist mir noch unklar. Eigentlich müsste der Card-Inhalt mit display:flex erstellt werden und der Inhaltsbereich mit flex:1 0 auto erstellt werden. Aber das hat andere Störeffekte, Flexitems haben ihren eigenen Blockformatierungskontext und das gefloatete Icon kann dann nicht mehr aus dem Titel hinausragen. Vermutlich gibt's da keine Universallösung 😟. Bild als Hintergrundbild erstellen und der Card eine Mindesthöhe geben ist auch nicht drin, weil die Bildhöhe ja mit der Card-Breite wechseln kann. Sollte man die Cards zu Containern machen?

Evtl. einfach die Konvention, dass alle SVG-Icons der Kategorie:Icon das gleiche Seitenverhälntis haben sollten? Dann wäre das - besonders beim Vollbild-Parameter - ohne magic numbers gelöst.

  {{Card|
    link...|                <<- Pflicht, Wikiseite auf die die Card verweist
    titel=...|              <<- Sollte genutzt werden, kann bei Vollbild-Card entfallen
    titelfarbe=...|         <<- Optional, Farbe für Titel
    hintergrund=...|        <<- background-Eigenschaft für Card
    farbe=...|              <<- color-Eigenschaft für Card
    icon=...|logo=...|      <<- Optional, nur eins von beiden verwenden
    neu=jjjjmmtt|           <<- Optional, jjjjmmtt=Tag an dem die Card hinzugefügt wurde
    inhalt=...|             <<- Wikitext
    bild=...|               <<- Wird unter Inhalt in Card-Breite angezeigt
    vollbild=...|           <<- Für Bilder, die die Card ganz ausfüllen. Inhalt und Teaser NICHT verwenden! 
                                Titel, Icon und Logo können verwendet werden und werden dem Bild überlagert.
    teaser=...|             <<- Nur Text, wird unter Inhalt und Bild angezeigt
    zeilen=...|spalten=...  <<- Optional, für Cards die größer als ein Rasterfeld sein sollen
  }}

titel find ich sehr wichtig, ich weiß nicht, ob man den Text durch ein SVG ersetzen könnte. Gut und flexibel, wenn es keine Pflicht ist

titelfarbe sollte wegfallen, Links sind immer blau!

iconund logo sind Synonyme, wäre es nicht ok, wenn man das unter Icon zusammenfasst?

inhalt und teaser sind imho Synonyme, da könnte man nur den Parameter inhalt verwenden.

Dann hätte man die Parameter titel, icon, vollbild und inhalt - damit könnte man alles abbilden.

Herzliche Grüße

Matthias Scharwies

---

1. Oranger Text auf weißem Grund? SELF-Blog 01.10.2022 ↩︎

[Rolf B]

Hallo Matthias,

die Titelfarbe ist drin damit man ggf. eine Card-Wüste visuell etwas auflockern kann. Gerade wenn eine Hintergrundfarbe ins Spiel kommt, muss man was für den Kontrast tun können. Gut, dann müsste das Ding eher "farbe" heißen und für alle Texte auf der Card gelten. Aber wenn man mit den Hintergrundfarben Disziplin hält, kann man darauf schon verzichten.

Die orange Linkfarbe ist ja ein Relikt aus dem braunen Theme des Jahres 2010

Okay. Also weg mit can-glow und als Markierung für eine aktive Card (hover/focus) nur noch ein Outline und ein Box-Shadow für die Card? Und den Titel unterstreichen? Das macht die Cards formaler. Und langweiliger…

Die dritte Card für den Seiteninspektor wird bei :hover schwarz!

Whut? Bei mir wird der Titel unterstrichen und die Card bekommt die schwarze Outline. Ein Cache-Problem? Am Fuchs liegt's nicht, gerade probiert.

icon und logo sind Synonyme

Njein. Der Unterschied zwischen icon und logo ist, dass icon IMMER ein Bild einbindet und eine Breite vorgibt. Erstellt wird ein linkfreies img-Element mit den Klassen can-glow und icon. Die Breite ist 35% der Card, maximal 4em. Mit logo wird hingegen ein leeres div mit float:right und der can-glow Klasse gesetzt. Der Inhalt ist frei. D.h. icon ist die für Bilder optimierte Version von logo, mit logo musst Du mehr selbst tun und hast damit mehr Freiheiten. Deine "CSS-Nesting" Card wäre ohne logo nicht machbar gewesen bzw. ich hätte dann ein SVG erstellen müssen und als icon einbinden.

Das gilt auch für "bild". Es erzeugt ein linkloses Image mit der Klasse teaser (die ist historisch aus deinen div-Cards entstanden) und img.teaser wird im CSS auf 100% Breite gesetzt. "vollbild" erstellt den gleichen Inhalt, ist aber zusätzlich ein Schalter, der den Titel auf position:absolute setzt. Meine erste Idee war, diesen Schalter eigenständig zu haben (titel-absolut=1 oder so), aber dieser Modus ergibt keinen Sinn, wenn man Inhaltstext auf der Karte hat, darum bin ich davon wieder ab.

Evtl. einfach die Konvention, dass alle SVG-Icons der Kategorie:Icon das gleiche Seitenverhälntis haben sollten?

Es gibt ja zwei Bildtypen auf Cards: Icons (oben rechts, Teil des Titel) und Bilder (unten, volle Breite). Icons sind eher quadratisch oder im Hochformat, während Bilder bei "Normalcards" Querformat haben. Ein Bildformat für die Card-Bilder löst es auch nicht unbedingt, denk an "Bilder im Internet", da ist bewusst ein flaches Bild drin.

Der teaser-Parameter ist historisch gewachsen. Der Inhalt ist freier Wikitext und wird über dem Card-Bild dargestellt (sofern eins da ist). Er kann auch etwas länger sein und eine Liste bilden. Der Teaser ist auf etlichen deiner Cards vorhanden. Er wird automatisch in ein <p class="teaser"> gesetzt, ist als Einzeiler gedacht und wird unter dem Card-Bild dargestellt.

Ich möchte eigentlich vermeiden, dass man die Klassen, die das Cardverhalten steuern, im Wikitext kennen und zuordnen muss. Wer die Card-Vorlage verwendet, sollte von der Konstruktion der Cards möglichst nichts mitbekommen und schon gar nicht die verwendeten Klassen kennen.

Ich könnte "bild" und "teaser" entfernen und alle Inhalte über inhalt= zuordnen (oder dann sogar wieder auf {{{1}}} zurückgehen). Dann müsste ich aber mindestens eine Subvorlage {{Card/Bild|Foo.svg}} machen, die das img-Element korrekt erzeugt und beklasst. Ist das so viel hilfreicher?

Eine Card/Vollbild-Vorlage als Inhaltsvorlage könnte man auch machen. Im CSS würde man dann mit

.card:has(.vollbild) .titel {
   position:absolute;
}

arbeiten.

Ich könnte auch "icon" entfernen und eine Vorlage Card/Icon erstellen. Dann würde man

  logo={{Card/Icon|Foo.svg}}|

schreiben. Aber ist das alles bequemer für den Nutzer? Die Vorlage soll bequem zu verwenden sein, nicht bequem zu erstellen.

Das Erstellen von mehreren Card-Vorlagen oder Subvorlagen wollte ich ja eigentlich vermeiden. Eine einzige Vorlage gibt einen stringenteren Rahmen vor. Ist es so wichtig, möglichst wenige Parameter zu haben?

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

die Titelfarbe ist drin damit man ggf. eine Card-Wüste visuell etwas auflockern kann.

Ja, schon. Aber Stylesheets wurden doch erfunden, um Elemente mit einer Funktion durchgängig einheitlich und damit gut erkennbar zu gestalten.

Am einfachsten wäre es, die normale Link-, bzw. Textfarbe zu nehmen, damit wir beim Dark Mode dann eben umschalten können. Bunte Cards sollten die Ausnahme bleiben, die einen Akzent setzen, aber eben nicht 3x4 Cards mit 12 verschiedenen Farben. Nur .neu soll eben einen grünen Hintergrund bekommen, bei dem aber auch die Standardfarbe passt.

Gerade wenn eine Hintergrundfarbe ins Spiel kommt, muss man was für den Kontrast tun können. Gut, dann müsste das Ding eher "farbe" heißen und für alle Texte auf der Card gelten. Aber wenn man mit den Hintergrundfarben Disziplin hält, kann man darauf schon verzichten.

Das wäre eine Idee. Aber ich glaube, dass mit dem „Disziplin halten“ ist gut!

Die orange Linkfarbe ist ja ein Relikt aus dem braunen Theme des Jahres 2010

Okay. Also weg mit can-glow und als Markierung für eine aktive Card (hover/focus) nur noch ein Outline und ein Box-Shadow für die Card? Und den Titel unterstreichen? Das macht die Cards formaler. Und langweiliger…

Das macht ja das SVG, oder nicht?

Die dritte Card für den Seiteninspektor wird bei :hover schwarz!

Whut? Bei mir wird der Titel unterstrichen und die Card bekommt die schwarze Outline. Ein Cache-Problem? Am Fuchs liegt's nicht, gerade probiert.

Mist - ich kann kein Deutsch mehr - die Umrandung ist schwarz, aber eben nicht blau.

icon und logo sind Synonyme

Njein. Der Unterschied zwischen icon und logo ist, dass icon IMMER ein Bild einbindet und eine Breite vorgibt. Erstellt wird ein linkfreies img-Element mit den Klassen can-glow und icon. Die Breite ist 35% der Card, maximal 4em. Mit logo wird hingegen ein leeres div mit float:right und der can-glow Klasse gesetzt. Der Inhalt ist frei. D.h. icon ist die für Bilder optimierte Version von logo, mit logo musst Du mehr selbst tun und hast damit mehr Freiheiten. Deine "CSS-Nesting" Card wäre ohne logo nicht machbar gewesen bzw. ich hätte dann ein SVG erstellen müssen und als icon einbinden.

OK! Verstanden! (Das gleiche Problem habe ich grad mit einer Card „SEO“, die ich wsl. nie wieder brauche. Anstelle eines SVG setze ich da:

inhalt=<span style="font-size:8em;font-weight:bold;color:green">SEO</span>

Das gilt auch für "bild". Es erzeugt ein linkloses Image mit der Klasse teaser (die ist historisch aus deinen div-Cards entstanden) und img.teaser wird im CSS auf 100% Breite gesetzt.

Ah! Mist, das mit den 100% Breite kriegen wir ohne Klasse und damit Parameter nicht hin.

Trotzdem würde ich gerne überlegen, ob wir uns deshalb nicht auf

• Icon oben rechts oder
• Vollbild absolut positioniert

einigen sollten.

@JürgenB @Felix Riesterer Was denkt ihr?

"vollbild" erstellt den gleichen Inhalt, ist aber zusätzlich ein Schalter, der den Titel auf position:absolute setzt. Meine erste Idee war, diesen Schalter eigenständig zu haben (titel-absolut=1 oder so), aber dieser Modus ergibt keinen Sinn, wenn man Inhaltstext auf der Karte hat, darum bin ich davon wieder ab.

Evtl. einfach die Konvention, dass alle SVG-Icons der Kategorie:Icon das gleiche Seitenverhälntis haben sollten?

Es gibt ja zwei Bildtypen auf Cards: Icons (oben rechts, Teil des Titel) und Bilder (unten, volle Breite). Icons sind eher quadratisch oder im Hochformat, während Bilder bei "Normalcards" Querformat haben. Ein Bildformat für die Card-Bilder löst es auch nicht unbedingt, denk an "Bilder im Internet", da ist bewusst ein flaches Bild drin.

Der teaser-Parameter ist historisch gewachsen. Der Inhalt ist freier Wikitext und wird über dem Card-Bild dargestellt (sofern eins da ist). Er kann auch etwas länger sein und eine Liste bilden. Der Teaser ist auf etlichen deiner Cards vorhanden. Er wird automatisch in ein <p class="teaser"> gesetzt, ist als Einzeiler gedacht und wird unter dem Card-Bild dargestellt.

Ja, aber eigentlich geht's auch ohne die Klasse, oder?

Ich möchte eigentlich vermeiden, dass man die Klassen, die das Cardverhalten steuern, im Wikitext kennen und zuordnen muss. Wer die Card-Vorlage verwendet, sollte von der Konstruktion der Cards möglichst nichts mitbekommen und schon gar nicht die verwendeten Klassen kennen.

Ich könnte "bild" und "teaser" entfernen und alle Inhalte über inhalt= zuordnen (oder dann sogar wieder auf {{{1}}} zurückgehen). Dann müsste ich aber mindestens eine Subvorlage {{Card/Bild|Foo.svg}} machen, die das img-Element korrekt erzeugt und beklasst. Ist das so viel hilfreicher?

Nein, einfach nur:

inhalt=irgendein Inhalt in Wikisyntax - siehe oben der span

Eine Card/Vollbild-Vorlage als Inhaltsvorlage könnte man auch machen. Im CSS würde man dann mit

.card:has(.vollbild) .titel {
   position:absolute;
}

arbeiten.

Ich könnte auch "icon" entfernen und eine Vorlage Card/Icon erstellen. Dann würde man

  logo={{Card/Icon|Foo.svg}}|

schreiben. Aber ist das alles bequemer für den Nutzer? Die Vorlage soll bequem zu verwenden sein, nicht bequem zu erstellen.

Das Erstellen von mehreren Card-Vorlagen oder Subvorlagen wollte ich ja eigentlich vermeiden. Eine einzige Vorlage gibt einen stringenteren Rahmen vor. Ist es so wichtig, möglichst wenige Parameter zu haben?

Genau!

Nur eine Card-Vorlage!

Nur diese Parameter

link

titel

icon / logo /das sehe ich ein

vollbild / falls wir das mit dem bild sein lassen

inhalt

background

color

Spalte

Zeile

Herzliche Grüße

Matthias Scharwies

[MudGuard]

Hi,

Aber Stylesheets wurden doch dafür erfunden, um Elemente mit einer Funktion durchgängig einheitlich und damit gut erkennbar zu gestalten.

Ne, die wurden doch erfunden, daß man für die abgerundeten Ecken nicht mehr siebenunddrölfzig div-Elemente ineinander schachteln muß …

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo Matthias,

damit sind wir dann eigentlich bei meinem Parametersatz 😂

Bis auf background/color, da hatte ich hintergrund/farbe. Bisher hatten wir die Vorlagen deutsch parametriert, oder?

Und bis auf die Teaserzeile, die unter das Card-Bild gesetzt werden könnte.

Ich denke noch mal darüber nach, inhalt/bild/vollbild/teaser wegzulassen und statt dessen {{{1}}} als Inhalt einzusteuern. Dann hat man alles selbst in der Hand.

Ein Bild sollte aber als {{Card/Bild|Dateixyz.svg}} eingebunden werden und darüber so beklasst werden, dass es die Card-Breite ausfüllt. Ob ich dann noch {{Card/Vollbild|...}} mache?

Echt doof, dass ich Wiki-SVGs nicht als background-image setzen kann, das wäre am elegantesten. Aber das geht (derzeit) nur mit Extension oder JS, weil ich Datei:Foo.svg in den Pfad zum eigentlichen SVG umsteuern muss, sonst hab ich das Vorschau-PNG als Hintergrundbild.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

damit sind wir dann eigentlich bei meinem Parametersatz 😂

Bis auf background/color, da hatte ich hintergrund/farbe. Bisher hatten wir die Vorlagen deutsch parametriert, oder?

War aus dem Gedächtnis.

Und bis auf die Teaserzeile, die unter das Card-Bild gesetzt werden könnte.

Ich glaube, dass mindestens die weg kann!

Und evtl. der Parameter Bild, wenn man die vorhandenen - dafür in Frage kommenden - SVGs so anpasst, dass sie als vollbild angezeigt werden.

Ich denke noch mal darüber nach, inhalt/bild/vollbild/teaser wegzulassen und statt dessen {{{1}}} als Inhalt einzusteuern. Dann hat man alles selbst in der Hand.

Das finde ich gut!

Ein Bild sollte aber als {{Card/Bild|Dateixyz.svg}} eingebunden werden und darüber so beklasst werden, dass es die Card-Breite ausfüllt. Ob ich dann noch {{Card/Vollbild|...}} mache?

Lass uns da mal drüber reden - entweder per Discord oder über Handy.

Und abwarten, was Jürgen und Felix sagen.

Echt doof, dass ich Wiki-SVGs nicht als background-image setzen kann, das wäre am elegantesten. Aber das geht (derzeit) nur mit Extension oder JS, weil ich Datei:Foo.svg in den Pfad zum eigentlichen SVG umsteuern muss, sonst hab ich das Vorschau-PNG als Hintergrundbild.

Ja!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

ich habe im Testwiki nochmal experimentiert.

https://wiki-test.selfhtml.org/wiki/Vorlage:Card/Dokumentation

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

ich habe im Testwiki nochmal experimentiert.

https://wiki-test.selfhtml.org/wiki/Vorlage:Card/Dokumentation

Danke,

schau ich mir morgen an!

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

ich befürchte, wir reden aneinander vorbei.

Ausgangslage:

Wir haben Cards / wollen Cards haben, die einerseits einheitlich aussehen sollen, andererseits möglichst flexibel eingesetzt werden können.

Das (und die Cards auf den anderen Seiten) waren alles Tests, nach denen man jetzt sortieren sollte, was man braucht und wie man das einheitlich gestalten kann.

Die Unterteilung in Bild und Vollbild hast du am 11.02. eingeführt. Ich sehe da eher 2 Vollbild-Cards, die die gleichen Parameter erhalten sollten.^[1]:

Die dritte Card enthält (noch) kein Bild ^[2]

Cards 4-6 enthalten

• eine Grafik, die als Icon rechts oben positioniert ist und
• unten HTML enthält.

Ich traue mir zu, die unteren 9 Cards nach diesen Typen zu formatieren:

BTW: Die sehen doch auch mit blauem Titel bunt aus - müsste man für den Titel noch weitere Farben haben?

Jetzt müssen wir diese 2 Typen in eine Form gießen:

Vorlage: Card

Eine Vorlage sollte uns HTML ersparen und eben ein einheitliches Aussehen, das der Benutzer wiedererkennt, haben. Dies erleichtert ihm das Erfassen von Inhalten.

Ich möchte eigentlich vermeiden, dass man die Klassen, die das Cardverhalten steuern, im Wikitext kennen und zuordnen muss. Wer die Card-Vorlage verwendet, sollte von der Konstruktion der Cards möglichst nichts mitbekommen und schon gar nicht die verwendeten Klassen kennen.

Full Ack. Genau - und deshalb sollten wir eine einfache Struktur mit so wenig Parametern wie möglich finden!

Das ist imho keine Kopiervorlage, sondern eine Auflistung aller Möglichkeiten.

  {{Card|
    link...|                <<- Pflicht, Wikiseite auf die die Card verweist
    titel=...|              <<- Sollte genutzt werden, kann bei Vollbild-Card entfallen
    titelfarbe=...|         <<- Optional, Farbe für Titel
    hintergrund=...|        <<- background-Eigenschaft für Card
    farbe=...|              <<- color-Eigenschaft für Card
    icon=...|logo=...|      <<- Optional, nur eins von beiden verwenden
    neu=jjjjmmtt|           <<- Optional, jjjjmmtt=Tag an dem die Card hinzugefügt wurde
    inhalt=...|             <<- Wikitext
    bild=...|               <<- Wird unter Inhalt in Card-Breite angezeigt
    vollbild=...|           <<- Für Bilder, die die Card ganz ausfüllen. Inhalt und Teaser NICHT verwenden! 
                                Titel, Icon und Logo können verwendet werden und werden dem Bild überlagert.
    teaser=...|             <<- Nur Text, wird unter Inhalt und Bild angezeigt
    zeilen=...|spalten=...  <<- Optional, für Cards die größer als ein Rasterfeld sein sollen
  }}

Meine Vorschläge für Kopiervorlagen

Vollbild

  {{Card|
    link= ...|     <<- URL, auf die die Card verweist
    titel=...|     <<- Seitenname sollte genutzt werden, kann entfallen
    vollbild=...|  <<- Für Bilder, die die Card ganz ausfüllen. 
                       Inhalt NICHT verwenden! 
                       Titel, Icon und Logo können verwendet werden und werden 
                       dem Bild überlagert.
  }}

„normal“

  {{Card|
    link= ...|         <<- URL, auf die die Card verweist
    titel=...|         <<- Seitenname
    icon=...|logo=...| <<- Optional, nur eins von beiden verwenden
    inhalt=...|        <<- Wikitext mit näherer Beschreibung
  }}

HTML, das in "inhalt" notiert wird, nimmt die verfügbare Breite ein, eine class="teaser" ist nicht mehr notwendig

Bilder, die wir auf 100% Breite haben wollen, werden als vollbild notiert -

ein <p class="teaser"><img src... ></p> ist nicht mehr nötig.

Ich könnte "bild" und "teaser" entfernen und alle Inhalte über inhalt= zuordnen (oder dann sogar wieder auf {{{1}}} zurückgehen).

Ja. Würde ich machen!

Dann müsste ich aber mindestens eine Subvorlage {{Card/Bild|Foo.svg}} machen, die das img-Element korrekt erzeugt und beklasst. Ist das so viel hilfreicher?

Nein, siehe oben!

Ich würde bei Bildern 2 Regelsätze verwenden:

.card img {
  width: 100%
  height: auto;
}

.card img.icon {
  width: 110px;
  float: right;
  margin-left: 0.3em;
}

Im oberen Regelsatz wären die Vollbilder und auch Bilder in inhaltdrin;

im unteren die Bilder, die mit dem Icon/Logo-Parameter einbunden werden.

Ich muss nur durch die SVG-Bilder durchgehen und sie auf viewBox="0 0 0 600 400" anpassen. Zusätzlich schaue ich, dass Bild-Inhalte nicht durch einen Titel verdeckt werden.

Ausnahme, wenn man Cards anders formatieren will

{{Card|
  link=...|          <<- URL, auf die die Card verweist
  titel=...|         <<- Seitenname
  icon=...|logo=...| <<- Optional, nur eins von beiden verwenden
  inhalt=...|        <<- Wikitext mit näherer Beschreibung
  hintergrund=...|   <<- Optional, background-Eigenschaft für Card
  farbe=...|         <<- Optional, color-Eigenschaft für Card
  neu=jjjjmmtt|      <<- Optional, jjjjmmtt=Datum
  zeilen=...|spalten=...  <<- Optional, für Cards die größer als ein Rasterfeld sein sollen
  }}

Herzliche Grüße

Matthias Scharwies

---

1. Du schrubst: Und ich habe das Idee-Bild für "Vom der Idee zum Projekt" etwas niedriger gemacht, sonst war da zu viel Abstand drüber. Hätte ich auch lassen können, als "vollbild" wäre das viel einfacher gewesen. Aber das habe ich erst danach gebaut 🙄.
   Ebent! Das geht alles mit dem vollbild-Parameter einfacher! Also weg mit bild! ↩︎

2. Dort werde ich ja den Screenshot des Seiteninspektors einfügen und sie dann auch zum Vollbild machen. ↩︎

[Matthias Scharwies]

Webprojekte planen und Bilder im Internet sind jetzt beide Vollbild, sieht doch gut aus, oder?

Falls der Cache mitspielt 😀

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

dafür hast Du jetzt die SVG Grafik ändern müssen und ohne Not ein Vollbild erstellt. Das kannst Du bei SVGs problemlos tun, bei PNGs ("Arbeiten mit dem Seiteninspektor") wird es schon schwieriger. Transparenz und so.

Ich muss nur durch die SVG-Bilder durchgehen und sie auf viewBox="0 0 0 600 400" anpassen.

Nein, bitte nicht. Zumindest jetzt noch nicht, während wir diskutieren. Zum einen ist das eine Heidenarbeit, zum anderen passt das nicht für jedes Bild. Beispiel: Landscape.svg - das hast Du im Hauptwiki einfach mal höher gemacht. Im Moment steht es alleine auf der Card, aber ursprünglich gab es noch drei Infopunkte dazu. Die sind auf der Doku-Seite von Card vorhanden und ich finde, das sieht da besser aus. Das höher gezogene Bild macht die Card jetzt viel zu hoch.

Der Diskussionsstand war, dass die Parameter bild/vollbild/inhalt/teaser weg solten. Statt dessen gibt's nur Card-Inhalt (als {{{1}}}). Und dann braucht man die Vorlage für Card-Bilder, denn andernfalls musst Du explizit jedesmal [[Datei:Bild123.svg|link=]] oder [[Datei:Bild123.svg|link=|class=vollbild]] schreiben.

Die Card/Bild-Vorlage kapselt das. Und sie schafft neue Möglichkeiten: Auf der Vorlage:Card Seite im Testwiki hat die "Bilder im Internet"-Card noch Text, und ich habe mit dem "schiebe" Parameter eine leichte Überlappung zwischen Text und Bild hergestellt (das Bild liegt dafür mit z-index im Hintergrund).

Mit das Card/Bild Vorlage kann man sicherlich auch erreichen, dass ein Bild bündig nach unten gesetzt wird und nicht abhängig von seinen Nachbarn im Raum schwebt. Das ist bei einigen Bildcards so. Für die Vollbilder habe ich bereits eine Lösung mit Flexbox und align-items:end, hier ist sicher noch Potenzial.

Solange wir noch kontrovers diskutieren, ist das, was ich gerade habe, immer noch ein Proof Of Concent und kann sich ändern. Für eine breite Umsetzung mit großen Umbauarbeiten an Grafiken ist es definitiv zu früh. @JürgenB, @Felix Riesterer, @Camping_RIDER - habt ihr keine Meinung zum Thema?

Die Kopiervorlage kann man sicher abspecken, ja. Bzw. zwei machen. Im Hauptwiki ist sie schon verkleinert, im Testwiki ziehe ich das nach, wenn wir einen finalen Stand haben.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

dafür hast Du jetzt die SVG Grafik ändern müssen und ohne Not ein Vollbild erstellt.

Ja, bzw. Nein - du hattest die Grafik geändert, ich habe sie wiederhergestellt!!! ^[1]

Das kannst Du bei SVGs problemlos tun, bei PNGs ("Arbeiten mit dem Seiteninspektor") wird es schon schwieriger. Transparenz und so.

Sollten die Vollbilder nicht unten liegen und der Titel absolut positioniert oben drauf?

Ich muss nur durch die SVG-Bilder durchgehen und sie auf viewBox="0 0 0 600 400" anpassen.

Nein, bitte nicht. Zumindest jetzt noch nicht, während wir diskutieren. Zum einen ist das eine Heidenarbeit, zum anderen passt das nicht für jedes Bild. Beispiel: Landscape.svg - das hast Du im Hauptwiki einfach mal höher gemacht. Im Moment steht es alleine auf der Card, aber ursprünglich gab es noch drei Infopunkte dazu. Die sind auf der Doku-Seite von Card vorhanden und ich finde, das sieht da besser aus. Das höher gezogene Bild macht die Card jetzt viel zu hoch.

Der Diskussionsstand war, dass die Parameter bild/vollbild/inhalt/teaser weg solten.

Eher bild/vollbild zusammengefasst und inhalt oder {{{{1}}}} anstelle von teaser.

Statt dessen gibt's nur Card-Inhalt (als {{{1}}}). Und dann braucht man die Vorlage für Card-Bilder, denn andernfalls musst Du explizit jedesmal [[Datei:Bild123.svg|link=]] oder [[Datei:Bild123.svg|link=|class=vollbild]] schreiben.

Die Card/Bild-Vorlage kapselt das. Und sie schafft neue Möglichkeiten: Auf der Vorlage:Card Seite im Testwiki hat die "Bilder im Internet"-Card noch Text, und ich habe mit dem "schiebe" Parameter eine leichte Überlappung zwischen Text und Bild hergestellt (das Bild liegt dafür mit z-index im Hintergrund).

Eine Vorlage soll vereinfachen und nicht unzählig neue Möglichkeiten schaffen. Dann nimmt nämlich jeder wieder HTML, weil die Vorlage zu kompliziert ist.

Mit das Card/Bild Vorlage kann man sicherlich auch erreichen, dass ein Bild bündig nach unten gesetzt wird und nicht abhängig von seinen Nachbarn im Raum schwebt. Das ist bei einigen Bildcards so. Für die Vollbilder habe ich bereits eine Lösung mit Flexbox und align-items:end, hier ist sicher noch Potenzial.

Solange wir noch kontrovers diskutieren, ist das, was ich gerade habe, immer noch ein Proof Of Concent und kann sich ändern. Für eine breite Umsetzung mit großen Umbauarbeiten an Grafiken ist es definitiv zu früh. @JürgenB, @Felix Riesterer, @Camping_RIDER - habt ihr keine Meinung zum Thema?

Die Kopiervorlage kann man sicher abspecken, ja. Bzw. zwei machen. Im Hauptwiki ist sie schon verkleinert, im Testwiki ziehe ich das nach, wenn wir einen finalen Stand haben.

Irgendwie haben wir uns da verzettelt. Wir hätten als Arbeitsgruppe im Test-Wiki ein Ergebnis vorstellen und beschließen sollen, anstatt jetzt im Haupt-Wiki probieren und es dann „im Test-Wiki nachzuziehen“. 😟

Herzliche Grüße

Matthias Scharwies

---

1. Du schrubst: Und ich habe das Idee-Bild für "Vom der Idee zum Projekt" etwas niedriger gemacht, sonst war da zu viel Abstand drüber. Hätte ich auch lassen können, als "vollbild" wäre das viel einfacher gewesen. Aber das habe ich erst danach gebaut 🙄. ↩︎

[Rolf B]

Hallo Matthias Scharwies,

Ja, bzw. Nein - du hattest die Grafik geändert, ich habe sie wiederhergestellt!!! [1]

Ups. Ja. 😳

Sollten die Vollbilder nicht unten liegen und der Titel absolut positioniert oben drauf?

Ja. Aber die Vollbilder müssen da, wo der Titel drüberliegt, transparent sein, damit die Card durchscheint. Sonst kann es schwer lesbar werden, vor allem bei der light/dark Umschaltung, die wir ja auch noch können möchten.

Der Diskussionsstand war, dass die Parameter bild/vollbild/inhalt/teaser weg solten.

Eher bild/vollbild zusammengefasst und inhalt oder {{{{1}}}} anstelle von teaser.
(...)
Eine Vorlage soll vereinfachen und nicht unzählig neue Möglichkeiten schaffen. Dann nimmt nämlich jeder wieder HTML, weil die Vorlage zu kompliziert ist.

Dann haben wir uns missverstanden. Aber findest Du das, was jetzt im Testwiki steht, so schlecht? Der Inhalt ist Wikitext, und nur Bilder bekommen eine Sonderbehandlung: Sie werden mit Card/Bild eingebunden statt mit [[Datei:...]]. Wenn jemand Cards mit handgemachtem HTML erstellt, müssen wir eingreifen. Solange wir 2 das nicht tun… Handgemachtes HTML ist nur für die freien Logos relevant. Aber da könnte man tatsächlich sagen: Male ein SVG! und die logo= Variante entfernen. Im Moment ist das ja nur für CSS Nesting verwendet.

anstatt jetzt im Haupt-Wiki probieren und es dann „im Test-Wiki nachzuziehen“. 😟

Beim "Nachziehen" sprach ich nur von der Card-Doku. Im Hauptwiki ist jetzt der Stand mit bild/vollbild/inhalt/teaser, der aber experimentell ist. Verwendet wird er auf der Card-Doku und versuchsweise auf "Wie fange ich an". Die nächste Iteration ist nur im Testwiki (ja gut, Card/Bild steht auch im Hauptwiki, wird aber nicht verwendet) und das würde ich gerne so lassen, bis wir den finalen Stand haben.

Rolf

[Matthias Scharwies]

Guten Morgen!

Dann haben wir uns missverstanden.

Ich glaube auch - ein kurzes Gespräch hätte so etwas ausräumen können.

Aber findest Du das, was jetzt im Testwiki steht, so schlecht?

Du meinst: https://wiki-test.selfhtml.org/wiki/Wie_fange_ich_an%3F

Nein! Das sieht gut aus und auch der Vorlagen-Code ist kurz und knapp.

Den Parameter schiebe würde ich persönlich nicht nutzen; habe mit --offsetY: 2em; herumgespielt und sehe irgendwie keinen Nutzen.

Der Inhalt ist Wikitext, und nur Bilder bekommen eine Sonderbehandlung: Sie werden mit Card/Bild eingebunden statt mit [[Datei:...]]. Wenn jemand Cards mit handgemachtem HTML erstellt, müssen wir eingreifen. Solange wir 2 das nicht tun… Handgemachtes HTML ist nur für die freien Logos relevant. Aber da könnte man tatsächlich sagen: Male ein SVG! und die logo= Variante entfernen. Im Moment ist das ja nur für CSS Nesting verwendet.

Das würde ich am Wochenende zu Hause machen und dann hätten wir es einheitlich!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias Scharwies,

ein kurzes Gespräch hätte so etwas ausräumen können.

Ja, sorry. Aber das hat bei mir einfach nicht gepasst.

Der Nutzen von "schiebe" ist halt, dass man damit Überlappungen Text/Bild hinbekommt, wenn ein Vollbild nicht passt. Je nach Card-Layout kann das helfen.

Rolf

[Rolf B]

Hallo Matthias,

ich habe im Testwiki jetzt die Vorlagen Card, Card/Bild und Card/Dokumentation so weit, dass man sie ins Hauptwiki übernehmen könnte. Im CSS sind noch ein paar Altlasten drin. Bevor ich das CSS aufräume und die Vorlage übertrage, sollten wir alle Seiten, die im Testwiki experimentell {{Card}} verwenden, konsolidieren und mögliche Schwachpunkte finden.

Einen hab ich schon: Cards mit externen Links, auf der Seite JavaScript und CSS. Da unterscheide ich in der Vorlage nicht und der Link wird falsch formatiert, wenn ich link=https://.. schreibe. Was tun?

• "Geht nicht" - Redirect-Seite dafür anlegen (wenn das funktioniert)
• In der Vorlage prüfen, ob der link mit http beginnt
• Zwei Parameter machen: link und external, einer davon muss verwendet werden.

Auf der Content is King Seite hab ich dann noch eine blöde Abhängigkeit zur globalen Line-Height gefunden (die Du mit br br br gelöst hattest...)

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

ich habe im Testwiki jetzt die Vorlagen Card, Card/Bild und Card/Dokumentation so weit, dass man sie ins Hauptwiki übernehmen könnte.

Vielen Dank!!

Im CSS sind noch ein paar Altlasten drin.

Bevor ich das CSS aufräume und die Vorlage übertrage, sollten wir alle Seiten, die im Testwiki experimentell {{Card}} verwenden, konsolidieren und mögliche Schwachpunkte finden.

Ja!

Einen hab ich schon: Cards mit externen Links, auf der Seite JavaScript und CSS. Da unterscheide ich in der Vorlage nicht und der Link wird falsch formatiert, wenn ich link=https://.. schreibe. Was tun?

• "Geht nicht" - Redirect-Seite dafür anlegen (wenn das funktioniert)
• In der Vorlage prüfen, ob der link mit http beginnt
• Zwei Parameter machen: link und external, einer davon muss verwendet werden.

Ja, mir wären die zwei Parameter am Liebsten!

Eigentlich gibt es bis jetzt nur 2 Cards, die auf den Blog verlinken, aber dein „@when das W3C aufSASSig wird“-Artikel hätte ich ebenfalls gerne im Wiki verlinkt.

Bloß wie? Evtl. als neue Reihe über den „normalen“ Tutorials?

Ein Blog-Artikel ist ja immer ein Augenblickszustand, da hatte ich schon überlegt, ob man z.B. bei Houdini die Inhalte ins Wiki ziehen könnte, aber zumindest bei den Leaflet-Artikeln sind viele iFrames drin.

Auf der Content is King Seite hab ich dann noch eine blöde Abhängigkeit zur globalen Line-Height gefunden (die Du mit br br br gelöst hattest...)

Es ist die Frage, ob man solche suboptimalen Artikel wie SEO mit einer Card beehren sollte. Und wenn ja, ob man dafür extra ein SVG (hier mit nur drei Buchstaben) erstellen sollte. Normalerweise sollte da ein Text-Link reichen.

Lass uns das mal am Mittwoch diskutieren.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias Scharwies,

@when das W3C aufSASSig wird

meine Meinung wäre: warte damit noch ab, das ist noch nirgends implementiert. Das Wiki ist kein Newsticker, der Blog schon eher.

Sobald die ersten Browser es anbieten, kann man das unter @ Rules als Artikel einbauen. Der Blogartikel soll ja nur einen Ausblick auf die kommende Änderung bieten.

Rolf

[JürgenB]

Hallo,

… zumindest bei den Leaflet-Artikeln sind viele iFrames drin.

also bei diesem sind die Vorschauen verlinkte Bilder, und bei diesem gibt es nur einen Link zum Beispiel.

Gruß
Jürgen

[Rolf B]

Hallo Matthias,

Update:

• Im Testwiki war zeilen/spalten nicht richtig implementiert → fixed
• Ich habe ein Pen-Icon.svg erzeugt, das nur den Stift zeigt. Statt mit gefüllten Konturen habe ich den Stift einfach mit dicken Strichen gezeichnet, damit ist es nur noch ein Path statt drölf.
• Auf der https://wiki-test.selfhtml.org/wiki/JavaScript_und_CSS Seite habe ich Pen-Icon.svg für die Custom Properties Card verwendet. Der Pen ist jetzt das Card-Icon, und var(--♥️) ist normaler Text, ohne ein SVG Herz. Dieses Herz ist je nach Fontsize nämlich nicht sauber positioniert gewesen.
• Die Houdini-Card ist doppelt hoch, damit dein Häschen besser zur Geltung kommt. Wenn man das Häschen nur als Icon setzt, reicht einfache Höhe.

iframes im Wiki, das ist ein anderes Thema. Das ließe sich hypothetisch mit JS analog zum Livebeispiel lösen. Aber ich habe Bedenken, dass das jemand missbraucht, um beliebige iframes ins Wiki zu crashen. Livebeispiel macht das nur mit Wiki-Beispielen. Im Blog muss man Blog-Schreibrecht haben. Im Wiki bekommen wir das über die kontrollierten Änderungen zwar mit, aber dieser Kontrollblick muss dann auch geworfen werden. Dafür bräuchten wir eine Security-Idee, z.B. ein SHA Hash der URL, den man dem iframe hinzufügen muss, den nur Admins vergeben können und der von einer Wiki-Extension validiert wird. Inwieweit das sicher ist, weiß ich nicht. Man müsste vermutlich einen sehr langen Key verwenden, um zu verhindern, dass jemand dank bekanntem Plaintext den Private Key herausbekommt. Oder man braucht eine Liste von iframe-URLs, die nur Admins pflegen können, und wer einen iframe einbinden will, muss die URL in dieser Liste hinterlegen. Das ist aber ein anderes Thema und sollte separat diskutiert werden!

Rolf

[Matthias Scharwies]

Servus!

@when das W3C aufSASSig wird

meine Meinung wäre: warte damit noch ab, das ist noch nirgends implementiert. Das Wiki ist kein Newsticker, der Blog schon eher.

Es geht mir nicht um die eine Card, sondern eine Strategie, wie wir Blog-Artikel über CSS im Wiki auf der Tutorial-Seite bewerben - oder sollte man das gar nicht tun?

Update:

• Ich habe ein Pen-Icon.svg erzeugt, das nur den Stift zeigt. Statt mit gefüllten Konturen habe ich den Stift einfach mit dicken Strichen gezeichnet, damit ist es nur noch ein Path statt drölf.

Sehr gut, evtl. mehrfach verwendbar

• Die Houdini-Card ist doppelt hoch, damit dein Häschen besser zur Geltung kommt. Wenn man das Häschen nur als Icon setzt, reicht einfache Höhe.

Problem: eine Card und zwei Links. Da müssen wir aber sowieso noch drüber reden, wie man diese "JavaScript und CSS"-Inhalte gliedert. Evtl. schreibst du irgendwann noch einen Teil 3?! 😀

iframes im Wiki, das ist ein anderes Thema. Das ließe sich hypothetisch mit JS analog zum Livebeispiel lösen. Aber ich habe Bedenken,

Ja!

Wenn in Jürgens Leaflet-Artikel gar keine iframes drin sind, könnte man sie auch ins Wiki migrieren, wo sie von der Wiki-Suche gefunden würden. Wichtig ist mir da eine Verlinkung aller unserer Inhalte - auch derjenigen im Blog.

Wir haben nämlich einiges! - leider verstreut und nicht verlinkt!

Das ist aber ein anderes Thema und sollte separat diskutiert werden!

Ja, in Hannover!?

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Hallo @Rolf B,

ich finde die https://wiki.selfhtml.org/wiki/Vorlage:Card sehr gelungen, vielen Dank dafür! Mir fällt nichts ein, was man vom UX-Aspekt oder Layout her noch ändern müsste.

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

ich finde die https://wiki.selfhtml.org/wiki/Vorlage:Card sehr gelungen, vielen Dank dafür! Mir fällt nichts ein, was man vom UX-Aspekt oder Layout her noch ändern müsste.

Danke, uns fehlt manchmal das Feedback, was uns befürchten lässt, dass wir irgendetwas übersehen.

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

@Rolf B hat gestern Abend die Cards-Vorlage in HTML/Tutorials eingebaut. Vielen Dank dafür!

Bei JavaScript/Tutorials habe ich angefangen, glaube aber, dass wir vorher diskutieren müssen, welche Tutorials …

• überhaupt eine Card verdienen,
• „für Anfänger“ bzw. „für Fortgeschrittene“ sind.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

Die Cards einzubauen ist einfach. Wenn man dabei dann auch noch Strukturüberlegungen für's Wiki anstellt, wird es natürlich umfangreicher.

Ich habe mich auf der HTML/Tutorials-Seite deswegen etwas schwer getan, weil mich mal wieder die "Bilder" Card genervt hatte. Bis ich dein vertikal verlängertes Landscape.svg revertet hatte, dann ging's besser. Ich bin aber immer noch nicht zufrieden. Es gibt bei schmaleren Viewports Breitenbereiche, da werden die Cards relativ breit. minmax(17em, 1fr) bei gap:1em kann bedeuten, dass eine Card 34.9em breit wird, bevor die zweite Spalte kommt. Ein Bild, das einen 3:2 Aspekt hat, wird dann 23em hoch, und das macht die Card echt riesig. Deshalb hatte ich eine max-height 10em drin, was auch nicht schön ist, weil das Bild dann die Card nicht füllt. Beim Landscape.svg kommt dann noch hinzu, dass die visuelle Verlängerung mit dem Hintergrundgradienten nicht passt. Ich glaube, ich muss im CSS noch eine Medienabfrage einbauen, die bei einer Breite des Inhalts von unter 35em die Card-Liste auf 25em Breite limitiert. Damit das gut funktioniert, muss der Content-Bereich des Wiki wohl zu einem inline-size Container werden; ich hoffe, das gibt keine negativen Wechselwirkungen.

Inhaltlich: sortieren muss man ggf. auch.

JavaScript/Tutorials

Da frage ich mich gerade, warum die Infoboxen, bei denen die Card "OHNE PROGRAMMIEREN" bewirbt, im Advanced-Bereich von JavaScript gelandet sind...

Die können bei JS zwar verlinkt werden, aber als "Siehe auch" in den HTML Bereich. Oder?

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Die Cards einzubauen ist einfach. Wenn man dabei dann auch noch Strukturüberlegungen für's Wiki anstellt, wird es natürlich umfangreicher.

Ich habe mich auf der HTML/Tutorials-Seite deswegen etwas schwer getan, weil mich mal wieder die "Bilder" Card genervt hatte. Bis ich dein vertikal verlängertes Landscape.svg revertet hatte, dann ging's besser.

Evtl. muss man dann eben ein Vollbild aka illustration im Format 2:3 erstellen und verwenden.

Solche Fragen habe ich z.B. auch bei JavaScript und CSS (Alternative zu animated gif; Icon für CSSOM, etc …)

Inhaltlich: sortieren muss man ggf. auch.

JavaScript/Tutorials

Da frage ich mich gerade, warum die Infoboxen, bei denen die Card "OHNE PROGRAMMIEREN" bewirbt, im Advanced-Bereich von JavaScript gelandet sind...

Weil die die Tutorials über „zugängliche Dialogboxen“ und ähnliches ersetzt haben.

Die können bei JS zwar verlinkt werden, aber als "Siehe auch" in den HTML Bereich. Oder?

Ja, und deshalb osllten wir uns an einem Abend mal ein Portal nach dem anderen vornehmen und einfach so drüber idksutieren, was uns so auffällt.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

Evtl. muss man dann eben ein Vollbild aka illustration im Format 2:3 erstellen und verwenden.

Landscape.svg wird aber auch zusammen mit Text verwendet, das geht dann nicht. Und wenn die Cards breiter werden, wird ein verlängertes Landscape.svg einfach zu hoch, die Card ist dann riesig, und leer. Das ist MIST.

Dann muss ich aber evtl doch hingehen und ein background-image dadurch simulieren, dass ich ein "Vollbild" in ein separates DIV im Hintergrund der Karte setze. Mit {{filepath:Landscape.svg}} komme ich zwar an den Wikipfad des SVG heran, aber Mediawiki verhindert, dass Wikitext eine url(...) Angabe in ein style-Attribut einbaut, es ersetzt dann den ganzen Attributinhalt durch /* insecure input */.

data-bgimg="url(...)" geht, aber dann muss ich mit JS nachhelfen, denn attr(data-bgimg) wird als Hintergrund generell noch nicht unterstützt.

Also entweder das Hintergrundbild in der Vorlage als HTML Ebene simulieren, oder die Selfhtml-Extensions erweitern. Zum Kotzen es ist!

Der einzige Lichtblick ist, dass die Vorlage das alles kapselt. D.h. wenn man irgendwann eine bessere Lösung findet, ändert man die Vorlage und gut ist.

Rolf

[Matthias Scharwies]

Guten Morgen,

heute haben Rolf und ich die letzten Cards in die neue Cards-Vorlage umgezogen.

Jetzt geht es um das FineTuning. @Camping_RIDER bemängelte den Hintergund mit einem Verlauf. Welche Vorschläge habt ihr?

Auf der Seite Typografie ist bei der ersten Card der Titel zu lang, bzw (noch) nicht trennbar. Wie würdet ihr das auflösen?

Schriftformatierung

Schrift formatieren

Das zweite würde funktionieren und der Titel würde nach oben rutschen, dann entspräche der Titel aber nicht dem Seitennamen. Schlimm?

Interessant finde ich weiter unten, dass man auch den Titel mit HTML + Inline-CSS gestalten kann - siehe die „Rahmen“-Card.

Rolf fand das Icon für Formulare etwas schlicht, Vorschläge, anyone?

Herzliche Grüße

Matthias Scharwies

[Auge]

Hallo

Sorry, dass ich den Thread kapere, aber deswegen einen neuen zu eröffnen, halte ich für übertrieben.

Auf der Einstiegsseite des Wikis gibt es den Block zum Mastodon-Account von SelfHTML. Ist es gewollt, dass der Link zur Einladungsseite des Servers (bildung.social) führt? Ich war verwirrt, da mich der Linktext vermuten ließ, dass ich über den Link im SelfHTML-Account lande.

Entweder das Ziel ist schlecht gewählt, oder der Linktext ist irreführend. MMn trifft ersteres zu.

Tschö, Auge

[Matthias Scharwies]

Servus!

Hallo

Sorry, dass ich den Thread kapere, aber deswegen einen neuen zu eröffnen, halte ich für übertrieben.

Auf der Einstiegsseite des Wikis gibt es den Block zum Mastodon-Account von SelfHTML. Ist es gewollt, dass der Link zur Einladungsseite des Servers (bildung.social) führt? Ich war verwirrt, da mich der Linktext vermuten ließ, dass ich über den Link im SelfHTML-Account lande.

Entweder das Ziel ist schlecht gewählt, oder der Linktext ist irreführend. MMn trifft ersteres zu.

Danke, ist mir unangemeldet auch schon mal aufgefallen, hab's dann aber wieder vergessen!

Ist geändert! (Ein Klick auf das Logo hätte die richtige Seite erwischt 😀)

Herzliche Grüße

Matthias Scharwies