Frage zum Wiki-Artikel „inset-block“

[Inset Where?]

Möglicherweise sinnvolle Ergänzungen? Nur ein, zwei Gedanken:

• Anscheinend bezieht sich die errechnete Position bei diesen inset-…-start/end Elementen immer auf die start-Position. Zumindest sehe ich hier beim Versuch, ein ::after mittels dieser Angaben absolut zu positionieren, das gleiche Ergebnis mit beispielsweise ìnset-inline-start: 100% und inset-inline-end: -100%;; der einzige Unterschied, den ich sehen kann, ist die jeweils entgegengesetzte Bewegungsrichtung („positiv ist: ins Eltern-Element rein“). Und: bei Prozent-Angaben in Blockrichtung weiß ich noch nicht so recht, worauf die sich beziehen: inline 50% = Mitte des Elter, aber 50% Block …?
  Soweit mein Eindruck stimmt, könnte das hier vlt. erwähnt werden.

• Soweit ich es gesehen habe, wird nirgends (nicht nur „hier“) erwähnt, woran die Dominanz hängt. Wahrscheinlich, weil dabei die „Graffiti-Spielregeln“ zum Tragen kommen. Wobei ich hier die Revier-Rivalitäten von ggf. aufeinander treffenden ìnsert-… und herkömlichen top, right, bottom und left, aber auch die „orientierungslosen“ inset (ohne inline/block; das hat doch Potential für Irritationen, wird aber ja „nebenan“ schon erwähnt): „wer zuletzt drüber malt …“, also „weiter ‚hinten‘ im CSS steht“ …
  Allerdings könnte durch das Drehen der Achsen-Richtungen auch das ganz schön verwirrend werden. — Je nach Kontext könnte da unset bei den „Altvorderen“ hilfreich sein?

Ach so: mit tatsächlich von unseren Gepflogenheiten abweichenden Orientierungen (rtl, vertikal …) habe ich (noch) nicht herumprobiert: gordische Knoten zeichnen sich ab, da muß erst noch das Schwert geschliffen werden …

[Inset Where?]

Dazu dann, als Ergänzung, eine „kleine Hausaufgabe“.

Vorgegeben: ein herkömmliches ::after, das absolut positioniert 0,5cm hinter dem rechten Rand und, von unten gemessen, ein Viertel der Höhe des Eltern-Elements entfernt, positioniert ist.

Aufgabe: dies in eine ´inset-…-…`-Form (also „die reine Lehre“, ganz ohne top/right/bottom/left) übertragen.

Knifflig? Mir ist bisher noch kein Ansatz eingefallen, mit dem man dies angehen könnte. Aber: da soll doch so eine CSS-Funktion vielleicht demnächst auftauchen? (Wie man wohl auf diese Idee kam?)

[Rolf B]

Hallo Inset Where?,

Wenn ich Gunnar richtig verstehe, soll die moderne Lösung dieser Aufgabe mit anchor-positioning gelingen.

Klassisch würde man

left: calc(100% + 0.5cm);
bottom: 25%;

verwenden, bzw. inset-inline-start und inset-block-end.

Natürlich mit Position ≠ static im Elternelement.

Die 0.5cm aber nur in Print-CSS, auf dem Bildschirm eher em/rem.

Rolf

[Inset Where?]

Ja, klassisch schon. Aber zumindest für bottom gibt es wohl kein Pendant. Denn man müßte, wenn der Abstand nicht in Prozenten angegeben wird, 100% der (bleiben wir, der Überichtlichkeit wegen, bei „klassischer Orientierung“) Höhe ± Offset berechnen. Und Prozente vertragen sich nicht so sehr mit Längeneinheiten. (Jedenfalls ohne etwas wie calc-size.)

Und das mit den Ankern? Ist Pilz-Saison? Jedenfalls hab’ ich schon mal davon gehört. Aber beim kurzen Antesten damals hat eigentlich noch nichts davon funktioniert. Und bis ich da mal wieder vorbeisehe, dafür Zeit habe, ist bestimmt schon wieder Pilz-Saison. Aber in welchem Jahr? So schnell wie in der letzten Zeit neue Features und ähnliche Dinge sprießen …

[MudGuard]

Hi,

Ist Pilz-Saison?

Definiere Pilz-Saison.

Ich hab vor ein paar Tagen Judasohren geerntet.

Vor 4 Wochen gab's Austernseitlinge.

Und zwischendrin Frostrüblinge (a/k/a Samtfußrüblinge)

Bis die ersten Stockschwämmchen rauskommen, ist erfahrungsgemäß auch nicht mehr lang hin (2 - 3 Wochen)

Also ja, es ist Pilz-Saison (wann ist eigentlich keine?).

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Ich hab vor ein paar Tagen Judasohren geerntet.

Vor 4 Wochen gab's Austernseitlinge.

Und zwischendrin Frostrüblinge (a/k/a Samtfußrüblinge)

Bis die ersten Stockschwämmchen rauskommen, ist erfahrungsgemäß auch nicht mehr lang hin (2 - 3 Wochen)

Wer solche Pilze kennt, der bohrt auch Löcher in Ostereier!

🖖 Live long and prosper

[MudGuard]

Hi,

Wer solche Pilze kennt, der bohrt auch Löcher in Ostereier!

Sowas soll's geben, ja 😉

Und ich hab noch viele von mir schon verspeiste Pilzsorten ungenannt gelassen (Saitenstieliger Knoblauchschwindling, Flockenstieliger Hexenröhrling, Ziegenlippe, Herkuleskeule, Habichtspilz, Semmelstoppelpilz, Nebelgrauer Trichterling, Porphyrröhrling, Scheidenstreifling, Perlpilz, Safranschirmling, Totentrompete … um nur ein paar zu nennen)

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo Inset Where?,

Und Prozente vertragen sich nicht so sehr mit Längeneinheiten

Aber natürlich.

inset-block-end: calc(50% + 2em);

würde das Element 2em über der horizontalen Mittellinie platzieren.

Guckst Du

Wichtig bei calc() ist nur, dass ein + und ein - von Leerstellen umgeben sein müssen. Einer der vielen CSS-Quirks.

Rolf

[Matthias Scharwies]

Servus!

Möglicherweise sinnvolle Ergänzungen? Nur ein, zwei Gedanken:

... bei Prozent-Angaben in Blockrichtung weiß ich noch nicht so recht, worauf die sich beziehen: inline 50% = Mitte des Elter, aber 50% Block …?\

Bei den herkömmlichen Eigenschaften top, left, etc steht's:

top, bottom

• eine Prozentangabe = bezieht sich auf die Höhe des umschließenden Blocks. Negative Werte sind erlaubt.

wird zu: eine Prozentangabe = bezieht sich auf die „Höhe“ des umschließenden Blocks; bei vertikalen Schreibsystemen die „Breite“. Negative Werte sind erlaubt.

left, right:

• eine Prozentangabe = bezieht sich auf die Breite des Bezugselements der Positionierung (also des nächsten Elternelements, das nicht position:static; ist. Negative Werte sind erlaubt.

Soweit mein Eindruck stimmt, könnte das hier vlt. erwähnt werden.

Ich trage das nach.

Ach so: mit tatsächlich von unseren Gepflogenheiten abweichenden Orientierungen (rtl, vertikal …) habe ich (noch) nicht herumprobiert: gordische Knoten zeichnen sich ab, da muß erst noch das Schwert geschliffen werden …

Ich würde immer vom use-case her ausgehen.

Hier mal ein Beispiel mit Bagdes und timestamps:

Absolute Positionierung mit inset-inline

Herzliche Grüße
Matthias Scharwies

[Inset Where?]

Ja, „klassisch“ ist das bekannt. Aber bei den „inset mit was dazu“ wird es schnell unübersichtich. Und, wie schon erwähnt, zumindest bottom paßt zu keinem inset-…. Außer zu inset-…-start + 100%. Aber da ist dann auch das Ende der Fahnenstange: 100% + 5cap …?

Und wegen des use-case: ein wenig Neugier, die gelegentliche Blicke „ins unbekannte Land“ mit sich bringt, sollte nicht schaden. Nicht so sehr, weil man da unbedingt hin will. Eher, weil man dann nicht ganz so sehr überrascht wird, sollte man damit überfallen werden. — Wobei dies, im Zusammenhang mit diesem Thema, natürlich im Wesentlichen jenen passieren könnte, die sich mit einem Gemisch aus Bereichen mit unterschielichen (Text-)Ausrichtungen beschäftigen müssen.

[Auge]

Hallo

Ja, „klassisch“ ist das bekannt. Aber bei den „inset mit was dazu“ wird es schnell unübersichtich. Und, wie schon erwähnt, zumindest bottom paßt zu keinem inset-….

Wie kommst du darauf? inset-block-end entspricht bottom, fertig ist der Lack.

Tschö, Auge

[Inset Where?]

Also bei dem kurzen Experiment, das ich damit angestellt habe, war inset-block-end: 25% oberhalb des block-start. Und zwar, wahrscheinlich, 25% der Höhe darüber. Sprich: mit einem Wechseln des Vorzeichens beim angegeben Wert entsprechen (entsprachen?) sich die start- und die end-Ergebnisse:

         ┍━ ⇽ Pos. `inset-block-start - x`
         ┆    *oder* `inset-block-end + x`
         ┆
┉ start ┉┳< Anker des inset
         ┃   « … content … »
  ⇡      ┠╴ ⇽ Pos. `inset-block-start + x`
         ┃    *oder* `inset-block-end - x`
 100 (?) ┃
         ┃   « … content … »
  ⇣      ┃   « … content … »
         ┃   « … content … »
         ┃
┉ end ┉┉┉┻━━

Zwar war das, während ich verucht habe, die Styles einer Seite mittels User-CSS zu „dressieren“, so daß Nebeneffekte nicht ganz auszuschließen sind (gesucht habe ich, erfolglos, danach). Allemal habe ich keine inset-block oder inset-inline außer den meinen entdecken können, während ich top … left wechselweise das eine oder andere unset, inherit oder auch mal 0 gegönnt habe.     —     Andererseits wird einem beim hin- und herdrehen „im unbekannten Land“ auch schnell mal schwindlig …

Wenn es dann doch Seiteneffekte waren? Dann wird es erst recht knifflig, spätestens wenn „viele Köche“ am Brei rühren und beide Varianten kollidieren.

[Auge]

Hallo

Ok, mir wird gerade schwindelig.

Mal grundsätzlich. In unserer Schreibrichtung (ltr) entspricht inset-inline-start dem klassischen left, inset-inline-end wird zu right, inset-block-start wird zu top und inset-block-end zu bottom.

Bei Schriftsystemen, die von rechts nach links geschrieben werden, tauschen die inline-Eigenschaften ihre Positionen. Auch wenn man einen Block um 90° dreht, spielen die logischen Eigenschaften ihre Stärken aus. Während die Angabe von top auch bei einer um 90° gedrehten Box für oben gültig bleibt, drehen sich die Werte der logischen Eigenschaften mit der Box. Das mag bei den inset-Eigenschaften nicht sofort nützlich erscheinen, aber mit den logischen Eigenschaften für padding und margin ergibt das quasi sofort Sinn.

Speziell die inset-Eigenschaften ergeben zudem nur mit position ungleich static Sinn. Und bei nicht gedrehten Boxen mit ltr-Content verhalten sich die Eigenschaften wie ihre physikalischen Pendants. Ob du nun bottom: -50%; notierst oder inset-block-end: -50%;, bleibt sich gleich; worauf sich die 50% beziehen, auch.

Deine Experimente sollten, ohne, dass ich das jetzt getestet hätte, bei Verwendung von top, bottom, left und right mit den selben Werten zu gleichen Ergebnissen führen. Worin dein Experiment konkret bestand, konnte ich allerdings deiner Beschriebung und dem Schaubild nicht wirklich entnehmen. Das kann aber an meiner abendlich beschränkten Aufnahmefähigkeit liegen. 😉

Tschö, Auge

[Inset Where?]

(Darf auch als Antwort für Rolf B angesehen werden)

Ist die Kreisfrequenz schon hoch genug? Ich hätte da nämglich gerade noch ein paar neue Kohlen für den Kessel gefunden (die „meinem“ Problem hier immerhin in die Schienen helfen könnten …)

Könnten! Schon von wegen “use case”: der Blick über den Gartenzaun reicht mir. Wenigstens vorerst.

[Rolf B]

Hallo Inset Where?,

du musst auch beachten, dass inset-inline-start, inline-size und inset-inline-end zusammenspielen (für westliche Schrift: left, width und right). Wenn Du alle 3 angibst, können maximal 2 davon Beachtung finden, und zwar wird die in Schreibrichtung letzte ignoriert (bei ltr wird right ignoriert, bei rtl wird left ignoriert)

Ähnliches gilt in Blockrichtung.

Und genaugenommen kommen für die Gesamtbetrachtung noch margin-inline, padding-inline und border-inline hinzu… Zum Restlosverwirren: Die Spec

Rolf

[Inset Where?]

Mir ist dazu gerade noch ganz was anderes(?) eingefallen:

Wenn man (ohne besondere Absicherung) beide Formen, also (ein Beispiel aus einem Flohsack:) margin-left/margin-right und margin-inline verwendet — dann vernagelt man sich damit doch einen Weg „ins Land wo man anders schreibt“. Schließlich wird aus „unserem“ left===inline-start ganz schnell ganz was anderes.

Das, so eine „Nutzungsänderung“, ist nur sehr selten gewünscht? Möglich. Wahrscheinlich. Aber machen das nicht die diversen Tools rund ums Thema „ich bau’ mir mein CSS-Häuschen“, von den Bauherr/inen meist und erst Mal unbemerkt? — Zumindest MDN mischt.

Ich weiß jetzt nur (noch?) nicht, ob sie da entsprechende Vorsorge getroffen haben. Denn zumindest mehrere Sprachversionen (incl. etwas … hmmm, chinesisches?) sind ja mit eingepackt.

BTW: ich sah da gearde ein margin-trim „am Horizont“.

[Rolf B]

Hallo Inset Where?,

nein, die gemeinsame Verwendung von left/right und inline/block kann durchaus einen Sinn ergeben. left/right richtet sich nach der Bildschirmausrichtung, inline/block nach der Schreibrichtung. Je nach Kontext kann das eine oder andere richtig sein.

Falsch ist lediglich, die physischen und logischen Richtungen auf Grund westlicher Kulturerfahrung gleichzusetzen.

Ich stelle mir es aber auch als sehr herausfordernd vor, für horizontale und vertikale Leserichtung ein gemeinsames Stylesheet entwerfen zu wollen. Ich kann mir gut vorstellen, dass die geänderte Leserichtung massive Auswirkungen auf das Grundlayout hat und es auch ohne Existenz der logischen inline/block-Eigenschaften noch das geringste Problem wäre, margin-left in margin-top zu ändern. Die inline/block-Eigenschaften erleichtern lediglich ein paar Details, indem sie den magischen Zusammenhang zwischen writing-mode/text-orientation, dir-Attribut und top/right/bottom/left einkapseln.

Rolf

[Auge]

Hallo

Hallo Inset Where?,

nein, die gemeinsame Verwendung von left/right und inline/block kann durchaus einen Sinn ergeben. left/right richtet sich nach der Bildschirmausrichtung, inline/block nach der Schreibrichtung.

Sollte nicht sowieso die letztnotierte Eigenschaft die zuvor notierte überschreiben, falls sie – bei geeigneter Schreibrichtung – selbe Seite betrifft?

element {
  margin-left: 1em;
  /**
   * margin-inline-start gewinnt,
   * nach margin-left notiert,
   * in ltr-Sprachen, wirkt aber separat
   * von margin-left in rtl-Sprachen?
   */
  margin-inline-start: 2em;
}

Ich stelle mir es aber auch als sehr herausfordernd vor, für horizontale und vertikale Leserichtung ein gemeinsames Stylesheet entwerfen zu wollen.

Mir hat es gereicht, die Umstellung für ein Projekt durchzuführen, für das eine arabische Übersetzung eingebracht wurde. Da ging es nur um von rechts nach links oder umgekehrt, nicht noch zusätzlich um von oben nach unten (oder umgekehrt). Die HTML- und CSS-Quellen sind über mittlerweile fast 20 Jahre gewachsen und gerade das CSS angereichert mit Speziallösungen und mehrfach für einzelne Element(e/gruppen) notierte, oftmals (fast) identische Eigenschaftsblöcke. Als ich mir das, vor jeglicher Anpassung, zum ersten Mal anschaute, dachte ich mir „Ach du Scheiße! Das wird nie und nimmer nich' auch nur irgend'was!“

Die Umstellung auf logische Eigenschaften bot mir allerdings die Möglichkeit und auch die Notwendigkeit, den ganzen Schmonz aufzuräumen. Die Größe der CSS-Datei schrumpfte dabei (bis jetzt) von etwa 40 auf 32 Kilobyte. Ich bin mit den Optimierungen aber noch nicht fertig.

Lange Rede, kurzer Sinn: Die logischen Eigenschaften konnten in diesem Projekt die Eigenschaften mit physikalischer Bindung komplett ersetzen und es war dabei auch keinerlei „Raketentechnik“ im Spiel. In neuen Projekten benutze ich nichts anderes mehr, selbst wenn in den allermeisten Fällen nicht mit Übersetzungen in Sprachen zu rechnen ist, die nicht von links nach rechts geschrieben werden. Wenn man den Aufwand des Erlernens der logischen Eigenschaften erstmal auf sich genommen hat, geht das völlig problemlos.

Ich kann mir gut vorstellen, dass die geänderte Leserichtung massive Auswirkungen auf das Grundlayout hat und es auch ohne Existenz der logischen inline/block-Eigenschaften noch das geringste Problem wäre, margin-left in margin-top zu ändern. Die inline/block-Eigenschaften erleichtern lediglich ein paar Details, indem sie den magischen Zusammenhang zwischen writing-mode/text-orientation, dir-Attribut und top/right/bottom/left einkapseln.

In vielen Fällen geht es auch um nicht mehr, als die Berücksichtigung der Schreibrichtung.

Tschö, Auge

[Rolf B]

Hallo Auge,

mit „gemeinsam“ meinte ich nicht „in einem Element“ sondern „in einem Dokument“.

In einem Element sollten sie sich gegenseitig überschreiben, ja, es sei denn, da hat sich jemand Sonderregeln ausgedacht, die Vorrang vor den Kaskaden- und Spezifitätsregeln haben.

Rolf

[Auge]

Hallo

mit „gemeinsam“ meinte ich nicht „in einem Element“ sondern „in einem Dokument“.

Das ist klar. Ich habe mir nur Gedanken zum Sonderfall „ein und das selbe Element“ gemacht. Dass „hier“ die eine und „dort“ die andere Eigenschaft eingesetzt werden könnte, versteht sich von selbst. 😉

Tschö, Auge

[Inset Where?]

Da fällt mir gerade ein … (Also vlt. ein FYI?)

Seit MacOS gemeuchtelt und durch iOS (ein Android-Fork? ich würde nicht dagegen wetten!) ersetzt wurde, gibt’s ein „Späßchen“ rund um die Tastatur:

„Früher einmal“ war es so, daß man, wenn der Cursor mittein in einem Absatz von mehreren stand, mit Shift-(?:Alt|Command)-CursorTaste) eine Markierung veranlaßt hat, bei der sich das Ende entsprechend der Richtung der Pfeil-Tasten bewegt hat. Also z.B. mit Shift+{Command-Rechts Links} bis zum vorletzten Zeichen in der Zeile. Und „heute“? Da hängt es davon ab, ob es eine “mobile first” Anwendung ist. Denn diese kennen nur noch eins: die Markierung wird ausschließlich erweitert. Beim Beispiel also bis zum Ende der Zeile, aber incls. ein Zeichen früher. Und warum? Weil man unter iOS mit der Bildschirm-Tastatur wie markiert?

Ja, es gibt Ausnahmen. Z.B. Bbedit. Obwohl da (IMO) ettliche „iOS-Anleihen“ erkennbar sind, da blieb man dem „alten“ Schema (den HIG‼︎ also dem Schriftwerkt, in dem diese „runden Ecken“ standen – gaaanz weit hinten!) treu — und man zwingt die Leute eben nicht dazu, ständig zwischen Tastatur und Maus zu wechseln. Und schon garnicht, so einen Versuch der Textauswahl mehrfach zu unternehmen, nur weil das Ende immer wieder daneben landet und die Auswahl sowieso zu groß aufällt.
Reklamation? Zwecklos! “mobile first!!!! …” (Ja, P’Terry, ich weiß, Ausrufezeichen …)

Waru ich das hier dran hänge? Weil ich den Verdacht habe, daß da ein ähnliches „der Bezugspunkt ist oben, basta!“ die Ursache ist.