Frage zum Wiki-Artikel „rotate“

[nix]

Endlich mal eine richtige Frage — in der so manches drin steckt, was mich in der letzten Zeit so „an HTML“ geärgert hat. Zunächst:

body {
  display: grid;
  grid-template: "Ga Gb Gc" 1fr "Gd Ge Gf" 1fr "Gg Gh Gi" 1fr / repeat(3, 1fr);
}
header {
  grid-area: d;
}
…
  <header>Rand-Überschrift</header>

So weit, so gut. Nur: jetzt hätte ich header gerne um,mathematisch, 90 Grad (also -90deg) gedreht. Und passend in ihre Zelle (hier: grid-area: Gd;) eingepaßt. So, daß der Text eben „von Rechts her“ gelesen werden kann. Klar: rotate: -90deg;. Aber: wie ich es auch drehe und wende, ich kriege nicht raus, wie ich header erzähle, wie breit und hoch es auszufallen hat, damit das Ergebnis wenigstens so aussieht, als ob der Text in seiner Zelle sitzt. Abgesehen natürlich von dem Fall, daß ich das Layout von diesem Element abhängig mache und ihm dafür feste Werte vorgebe — was dann auch, nach ein wenig (vom Browser durchgeführter) Umrechnerei, doch wieder ein Pixel-Layout, gut, CSS-Pixel-Layout, wäre.

Aber sonst, ob nun mit Prozenten oder auch Versuchen mit Container-reletiven Maßen, wird aus diesem Header immer nur etwas, das irgendwo in einer unbestimmten Nähe vom gewählten Grid-Area herumlungert, drüber schwebt.

[Rolf B]

Hallo nix,

alle Transformationen werden angewendet, nachdem das Element ins Layout eingepasst wurde. Der Bezugspunkt für die Transformation ist in HTML der Mittelpunkt des Elements.

Wenn Du die Grid-Zellen responsiv mit fr dimensionierst, wird die Sache schwierig. Ganz schwierig wird es, wenn Du grid-area:d schreibst und im Template "Gd" schreibst - aber das ist sicher beim Abschreiben ins Forum passiert...

repeat(3, 1fr) geht bei Namenstemplates auch nicht, das musst Du ausschreiben.

Für den senkrechten header ist der writing-mode Dein Freund - allerdings nicht unbedingt so ganz. Wenn Du etwas vertikal an den linken Rand setzt, zeigt die Unterkante der Buchstaben zum Rand. text-orientation oder direction zeigen bei mir einfach keine Wirkung - da bin ich zu blöd für oder Chrome mag nicht. Aber ein beherztes rotate:180deg hat es gebracht.

https://jsfiddle.net/Rolf_b/73w1tqoy/

Rolf

[Gunnar Bittersmann]

@@Rolf B

Aber ein beherztes rotate:180deg hat es gebracht.

Reicht nicht (wenn man auch andere Zeichen als Buchstaben, Ziffern und Satzzeichen verwendet).

Da sollte noch text-orientation: sideways mit dazu.

☞ TIL about text-orientation

🖖 Живіть довго і процвітайте

[nix]

alle Transformationen werden angewendet, nachdem das Element ins Layout eingepasst wurde

Darum ja auch „wengistens so aussieht“.

Wenn Du die Grid-Zellen responsiv mit fr dimensionierst, wird die Sache schwierig.

Ich hab’s gemerkt. Was fehlt: das Drehen der Box müßte auch zurück, „vom Grid gesehen werden“.

… ist der writing-mode Dein Freund …

Schon das Platzieren der Box an der Stelle, die das Grid für „Gd“ (ja, hab’ das G beim platzsparenden „Verstümmeln“ für hier übersehen) ist nicht ganz einfach. Was allemal bleibt: man versuche nur, diesem Bereich dann auch noch eine flächendeckende, „Gd“ füllende, Hintergrundfarbe zu verpassen (und dabei das Grid nicht zu, was die Absicht hier angeht, verzerren) …

Zusammen gefaßt: Elemente haben zu wenig Ahnung „von der Welt“. Selbst die eigenen Maße können sie nicht mal verwenden, um daraus etwas zu machen. — Von ihrer Position, ob nun relativ zum Container oder gar zum Vierwport – Stichwort Tooltips) ganz abgesehen. Und anders herum erzählt (hier) das Grid denen auch nichts, cq-Dingens beziehen sich auf die gesamte Größe, nicht auf den Track. Da bleibt als Ausweg anscheinend doch nur: <del>grid</del><ins>div div div</ins>.

Abgesehen davon: writing-mode macht zwar den Anschein, es könnte die richtige Richtung sein. Wäre IMHO aber von der Intention her falsch. Die damit verbundenen Drehungen sollen ja „nur“ die Schrifzeichen in eine zum jeweiligen Schriftsystem passende Anordnung bringen (und „von unten nach oben“ scheint die Welt da nicht zu kennen). Was irgendwie witzig ist: so gedrehte Inhalte findet sich im Print-Bereich (nicht zuletzt: in der Werbung) doch öfter. Was aber nicht mal „zu Zeiten des Pixel-genauen Layouts“ hier Spuren hinterlassen hat.

[nix]

BTW („bis OT“)

Gerade gemerkt. So von wegen „auf verschiedenen Browsern testen“: die Datei-Vorschau unter neueren OS X-Versionen scheint mir, was die dazu gehörende Intention angeht, auch interessant zu sein. Die hängt an Safari? Ja, schon. Aber schon das Verhalten beim Erstellen dieser „Voransicht“, vor allem die Dauer dafür, scheint mir irgendwie Hinweise zu geben.

Bei meinem aktuellen und noch reichlich groben Ansatz fürs CSS (also v. a. ohne viele der Effekte, die vorher drin waren; keine transition, kein animation, selbst die Info-Boxen sind nur Boxen; es ist fast nur der Versuch, den Header zu drehen, drin) dauert das ziemlich lange. Und bei manchen der (sich eigentlich nur vom Inhalt her unerscheidenden) Seiten dazu ist das Ergebnis auch noch merkbar anders: anstelle der da sonst üblichen „kleinen HTML-Seite“ erscheint mittendrin ein Dialog, der eigetnlich wie ein gewöhnlicher „das Format kenn’ ich nicht“ Datei-Info-Dialog. Allerdings mit einem Vorschau-Bild, das doch wieder dem „Mini-HTML“ entspricht.

Was man daraus ableiten kann? Ich weiß es nicht, vermute nur, daß man daraus „statistisch“ ablesen kann, daß die Gestaltung (für Safari) knifflig ist (obwohl eigentlich nichts Großartiges drin ist?). Und/oder Informationen, die ich zunächst mal eher im Browser (Safari: Inspektor → Timeline) suchen würde. — Wobei sich der Inspektor, gerade in diesen anscheinend kniffligen Fällen, auch nur recht langsam auf die Bühne bewegen mag.

Nebenläufig: ob ich mir jetzt doch noch die Entwickler-Dokumentation zu OS… äh, iOS(! sic) antue? Da nachsehe, ob mein Verdacht, man hätte da Display-PDF durch Display-HTML ersetzt, kein Verdacht ist? Indizien dafür gibt es einige! Und: das gerade geschilderte und doch irritierende Verhalten … ist das womöglich ein Indiz für Probleme, womöglich gewaltige Probleme an dieser Stelle?