Höhe der Vorschau im Wiki vergrößern

[JürgenB]

Hallo,

kann man die Höhe der Vorschau im Wiki vergrößern? Sie ist auf 25em eingestellt, und das ist für das Beispiel, an dem ich gerade bastle, zu wenig.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

das ist eine Funktionalität des Frickl-Overlay; es setzt das live-view Element in HTML ein.

Die Höhe ist im common.css des Mediawiki eingestellt; man müsste das mit einem style-Attribut überschreiben. In der Beispiel-Vorlage müsste man einen data-Parameter an das .note-box-example div hängen, der die gewünschte Höhe angibt und der vom Frickl-Setup in common.js ausgelesen wird.

Das könnte man als Teilbereich des Frickl-Makeover sehen.

Frage ist nur, ob das wirklich nötig ist oder feature creep. Du könntest auch deine Größenformel so anpassen, dass sie die Boxen sicher in den Viewport rendert. Was dann möglicherweise allein mit CSS nicht mehr geht, aber zumindest sollte eine max-Klausel hinein, die verhindert, dass auch bei einer Höhe von 45em die Boxen unten raushängen. Wäre das möglich, zumindest interimsmäßig?

Rolf

[JürgenB]

Hallo Rolf,

ich hatte die Hoffnung, dass es da einen Parameter gibt, den ich nicht gefunden habe. Dass es den nicht gibt, ist aber kein Problem.

Bei mir hing die Größe von Quadraten vom Minimum aus Seitenhöhe und -breite ab. Daher wurden Sie in der Vorschau recht klein. Ich habe ihnen jetzt einfach eine Mindestgröße gegeben, da Scrollbalken kein Problem sind.

Gruß
Jürgen

[Felix Riesterer]

Lieber Rolf,

das ist eine Funktionalität des Frickl-Overlay; es setzt das live-view Element in HTML ein.

sehr richtig.

man müsste das mit einem style-Attribut überschreiben.

Oder man verwendet ein data-Attribut, welches von der common.css berücksichtigt wird. Oder man löst das mit einer custom property...

Das könnte man als Teilbereich des Frickl-Makeover sehen.

Fände ich gut!

Frage ist nur, ob das wirklich nötig ist oder feature creep.

Damals hatte ich keine zündende Idee, wie man die Höhe dynamisch machen kann. Auch fehlt mir die Expertise das für alle (gängigen) Browser und vor allem Viewports zufriedenstellend zu lösen.

Liebe Grüße

Felix Riesterer

[JürgenB]

Hallo Felix,

… das für alle (gängigen) Browser und vor allem Viewports zufriedenstellend zu lösen.

das ist mMn auch nicht nötig. Mir hätte es gereicht, wenn ich die Höhe im Wiki-Quelltext hätte einstellen können. Aber ich habe das „Problem“ jetzt anders gelöst. Als aus meiner Sicht (erst mal) kein Bedarf.

Gruß
Jürgen

[Rolf B]

Hallo Felix,

Oder man verwendet ein data-Attribut, welches von der common.css berücksichtigt wird.

Wenn du denkst, was ich denke, das Du denkst, dann denke ich, dass das noch nicht geht.

Aktuell kann man mit attr() nur Strings auslesen und in eine content-Eigenschaft übertragen. Und man kann nur data-Attribute des gestylten Elements auslesen, nicht der Elternelemente.

Die Krücke, den Wert von data-hoehe erstmal in ein custom property zu übertragen, würde das Vererbungsproblem lösen. Aber auch das geht noch nicht. Das Typ-Problem bleibt ebenso, weil der Wert des custom property "30em" ist und nicht 30em - String statt Length - und das lässt sich an height: nicht zuweisen. Eine Typkonvertierung in CSS, geht das? Mit attr() soll es mal gehen, aber noch nicht.

Da das Frickl-Overlay ohnehin JavaScript braucht, muss man da auch keine CSS-Kunstwerke für zurechtmeißeln. Denke ich 😉

Rolf

[Matthias Scharwies]

Servus!

Hallo Felix,

Oder man verwendet ein data-Attribut, welches von der common.css berücksichtigt wird.

Wenn du denkst, was ich denke, das Du denkst, dann denke ich, dass das noch nicht geht.

Aktuell kann man mit attr() nur Strings auslesen und in eine content-Eigenschaft übertragen. Und man kann nur data-Attribute des gestylten Elements auslesen, nicht der Elternelemente.

Die Krücke, den Wert von data-hoehe erstmal in ein custom property zu übertragen, würde das Vererbungsproblem lösen. Aber auch das geht noch nicht. Das Typ-Problem bleibt ebenso, weil der Wert des custom property "30em" ist und nicht 30em - String statt Length - und das lässt sich an height: nicht zuweisen. Eine Typkonvertierung in CSS, geht das? Mit attr() soll es mal gehen, aber noch nicht.

• (CSS-Variablen)#Längeneinheiten_und_custom_properties

.icon {
  --scale: 1;

  /* this works */
  font-size: calc(var(--scale) * 1rem);
}

Da das Frickl-Overlay ohnehin JavaScript braucht, muss man da auch keine CSS-Kunstwerke für zurechtmeißeln. Denke ich 😉

Ja, aber ich würde nicht zu viele Features realiseren.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

sorry, nein. Ich weiß nicht, ob die Spezifikatoren mal sowas im Sinn hatten, aber die aktuelle CSS Values Level 3 Spec sagt es anders. Sie sagt vor allem, dass attr() außerhalb der content-Eigenschaft "at risk" sei, d.h. es kommt so schnell noch nicht oder kann sich noch ändern.

.icon {
  /* this works NOT, it's contrary to the Spec! */
  --scale: attr(data-foo);

  font-size: calc(var(--scale) * 1rem);
}

Problem ist, dass attr(data-foo) per Default einen String liefert, keine Zahl, und var(--scale) den String nicht in eine Zahl konvertiert. Problem ist weiter, dass attr in einer custom property Zuweisung noch nicht funktioniert.

Statt dessen dieser Blick in die Zukunft:

<style>
.icon {
  /* this IS SPECCED TO work, but doesn't (yet) */
  --scale: attr(data-foo number, 10);

  font-size: calc(var(--scale) * 1rem);
}
</style>
...
<div class="icon" data-foo="42">😀</div>

und auch dies

<style>
.icon {
  /* this IS SPECCED TO work, but doesn't (yet) */
  --scale: attr(data-foo length, 10em);

  font-size: calc(var(--scale));
}
</style>
...
<div class="icon" data-foo="4em">😀</div>

Wenn die Implementierung von attr() absehbar wäre, würd ich dazu ja was bloggen. Aber bei "at risk" - hm, könnte vergeblich oder viel zu früh sein.

Rolf