Frage zum Wiki-Artikel „border-radius“

[nix]

Wie eigentlich verrundet man, beispielsweise, die Ecke block-end / inline-start?

Nicth gleich hauen, ich weiß schon, daß das nicht hier übersehen wurde. (Und von outline ignorieren wir gleich ganz.) Aber: border ist wohl nur was für komplette Projekte ge(d|m)macht.

[Matthias Scharwies]

Servus!

Wie eigentlich verrundet man, beispielsweise, die Ecke block-end / inline-start?

Nicth gleich hauen,

Das ist ne gute Frage! Könntest Du einen Codepen anlegen und eine Box (div mit border) in mehreren Schreibrichtungen mit einer linken, oberen Ecke versehen? Hatte eigentlich vermutet, dass es mittlerweile was wie border-inline-start-radiusgeben würde.

Ich finde die Logischen_Eigenschaften interessant, bleibe aber weiterhin bei den klassischen Angaben, da ich keine asiatischen / arabischen Texte veröffentliche.

ich weiß schon, daß das nicht hier übersehen wurde. (Und von outline ignorieren wir gleich ganz.) Aber: border ist wohl nur was für komplette Projekte ge(d|m)macht.

Achtung: Ich überarbeite grad: CSS/Tutorials/Boxmodell/Rahmen

Das besteht im Augenblick aus lauter Dopplungen zur Referenz.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias

die Eigenschaften gibt's. Wer ihre Namen erfunden hat, gehört dazu verdammt, sie ohne Handbuch benutzen zu müssen 🤮

Ich habe das Aside-CSS-Eigenschaften-Rahmen schonmal vorbereitet. Für die Artikelarbeit würde ich mir heute abend die Zeit nehmen wollen.

Rolf

[nix]

die Eigenschaften gibt's. Wer ihre Namen erfunden hat, gehört dazu verdammt, sie ohne Handbuch benutzen zu müssen

Es gibt ein border-margin-inline-start-block-end usw. (oder wie sie jetzt heißen sollen)? Ja, das ist oder wäre „etwas aufwändig“.
Ansonsten denke ich jetzt aber (auch) an gelegentliche Ausflüge in die „text-basierte Unix-Welt“: was machen diese zwei oder drei Buchstaben jetzt schon wieder? Wenn einem da nicht „einfach so“ einfällt, wie dieses Tool heißt, das „dingens“ macht („ich hab’s doch schon tausendmal benutzt!“), hat man viel Spaß beim Suchen danach. Klar, die kurzen Naben wie z. B. „ls“ sind für den geübten Shell-Scripter kein Problem und (v.a. auch für die damaligen™ Rechner) angenehm. Aber … wofür hat man denn ein „alias“? Das man ja durchaus auch in seine Shell automatisch eintragen lassen kann. (Und wenn CSS OOP könnte … s. u.)

[Rolf B]

Hallo nix,

Sie heißen border-X-Y-radius. Für X und Y kann start oder end stehen. X ist für die Block-Achse, Y für die Inline-Achse.

Ich schreibe dazu noch was im Wiki, wird nur heute abend nichts mehr.

Du kannst ja derweil in der Spec schmökern.

Rolf

[nix]

Ah, doch nicht ganz so schlimm. Eigentlich sogar eingängig.

Die Spec?

Also so lange ich damit nichts in die Luft jagen kann … 😈

[Gunnar Bittersmann]

@@Matthias Scharwies

Ich finde die Logischen_Eigenschaften interessant, bleibe aber weiterhin bei den klassischen Angaben, da ich keine asiatischen / arabischen Texte veröffentliche.

Wie schon bei HTML verschenkst du auch bei CSS viele Möglichkeiten‽

Angenommen, du hast

.box { margin: 2em 3em 2em 1em }

Jetzt willst du für .special.box den vertikalen Abstand von 2em auf 4em erhöhen. Wie machst du das?

.special.box { margin: 4em 3em 4em 1em }

Meh. Verstoß gegen DRY (don’t repeat yourself). Wenn dann der Abstand nach links geändert werden soll, müsstest du das an zwei Stellen tun. Sowas sollte man vermeiden.

.special.box { margin-top: 4em; margin-bottom: 4em }

Wieder nicht DRY. Wenn der Abstand nach oben/unten von 4em auf 5em geändert werden soll, musst du das an zwei Stellen tun. Sowas sollte man vermeiden.

Die Lösung ist

.special.box { margin-block: 4em }

Dass die logischen Eigenschaften nur für von rechts nach links oder von oben nach unten Geschriebenes gut wären, ist (d)ein Irrglaube.

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

[nix]

Angenommen, du hast

.box { margin: 2em 3em 2em 1em }

Jetzt willst du für .special.box den vertikalen Abstand von 2em auf 4em erhöhen. Wie machst du das?

margin-top? Und weil CSS nicht objektorientiert arbeitet, inherit hin, revert her:

.box { margin: 2em 3em 2em 1em }
.special-box { margin-top: 4em }
…
<div class="box special-box"> …

?

Daß es nichts wie ein

.dingens { … }
.dongens inherits dingens { … }

gibt, war mir schon öfter lästig. Nicht wegen der Tipperei, sondern a) wegen der Übersicht (das CSS wird so nur umfangreicher) und b) den so oft weit verteilten Stellen, an denen dann, „irgendwann nach einigem Bearbeiten“, eigentlich zusammengehörige Werte verteilt stehen. Was so ein CSS mit lauter kleinen Tretmienen versieht. “Mit OOP drin” könnte ich mir dagegen ein Tool vorstellen, das einem den CSS-„Stammbaum“ präsentiert — und den dann womöglich auch noch bearbeitbar macht.

[Gunnar Bittersmann]

@@nix

Jetzt willst du für .special.box den vertikalen Abstand von 2em auf 4em erhöhen. Wie machst du das? margin-top?

Nein. „Vertikaler Abstand“ meint Abstand darüber und darunter.

Daß es nichts wie ein

.dingens { … }
.dongens inherits dingens { … }

gibt, war mir schon öfter lästig.

In CSS-Präprozessoren gibt es das. ☞ ebony & ivory

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

[Matthias Scharwies]

Guten Morgen!

Achtung: Ich überarbeite grad: CSS/Tutorials/Boxmodell/Rahmen

Das besteht im Augenblick aus lauter Dopplungen zur Referenz.

So das ist jetzt vorerst fertig: Rahmen und Ribbons

Fun fact: Schon bei der Typografie-Reihe bin ich auf ein Tutorial zu Ribbons gestoßen, das nur an wenigen Stellen im Wiki gelistet war.

Ich habe es hier integriert und die magic numbers aus 2015 durch custom properties ersetzt.

Das 4. Beispiel zu box-shadow muss noch vollendet werden; das mach ich im September.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo nix, hallo alle

analog zu border-top-left-radius kann ich auch bei border-start-start-radius zwei Werte angeben, für den Fall, dass ich eine elliptische Abrundung möchte.

Mir scheint aber, dass Chrome hier merkwürdig reagiert (habe gerade kein Füchslein zur Hand): Der erste Wert wird immer für die horizontale Richtung verwendet und der zweite Wert für die vertikale Richtung. Die Spec scheint aber zu sagen, dass der erste Wert die Block-Richtung und der zweite Wert die Inline-Richtung definiert.

https://jsfiddle.net/Rolf_b/r7mc4jt3/

Ist das ein Chrome-Bug? Ein Spec-Bug? Oder ein Rolf-Bug?

Bei mir sieht die elliptische Ecke der roten Boxen nicht wie eine gedrehte Version der blauen Box aus - ich finde aber, sie sollten es tun, so wie in den grünen Boxen.

Rolf

[Raketenwilli]

Mir scheint aber, dass Chrome hier merkwürdig reagiert (habe gerade kein Füchslein zur Hand):

102.14.0esr (Debian 12):

116.0.3 (Direkt von Mozilla, unter Debian 12):

[nix]

… kann ich auch bei border-start-start-radius …

Mir scheint, da sollen die Eck-Kurven in sich, jeweils das eine Kurvensegment, „gebogen“ werden. So viel hatte ich da ja nicht mal erwartet. Eher ein border-block-start-radius als Pendant für border-top-radius. — Allerdings merke ich gerade: da würde das Formulieren von Bezeichnern wohl wirklich …

Aber: nur ein kleines Stück darunter … logical?

These properties correspond to the height and width properties. The mapping depends on the element’s writing-mode.

[nix]

Räusper … natürlich border-block-start-radius als Pendant für border-top-left-radius …

[Gunnar Bittersmann]

@@Rolf B

Der erste Wert wird immer für die horizontale Richtung verwendet und der zweite Wert für die vertikale Richtung. Die Spec scheint aber zu sagen, dass der erste Wert die Block-Richtung und der zweite Wert die Inline-Richtung definiert.

Wo liest du das raus?

Die Spec sagt: Value: <'border-top-left-radius'> und dort steht: “The first value is the horizontal radius, the second the vertical radius.”

“The mapping depends on the element’s writing-mode, direction, and text-orientation, with the first start/end giving the block axis side, and the second the inline-axis side (i.e. patterned as 'border-block-inline-radius')” bezieht sich wohl nur darauf, welche physische Ecke nun mit der jeweiligen logischen Eigenschaft gesetzt wird.

Ist das ein Chrome-Bug? Ein Spec-Bug?

Die Browser verhalten sich so, wie es in der aktuellen Spec steht.

Mein erster Gedanke wäre auch, dass der erste Wert den Radius in Block-Richtung und der zweite Wert den Radius in Inline-Richtung angeben sollte. Dann wäre das ein Spec-Bug.

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

[Rolf B]

Hallo Gunnar Bittersmann,

Mein erster Gedanke wäre auch, dass der erste Wert den Radius in Block-Richtung und der zweite Wert den Radius in Inline-Richtung angeben sollte.

Ja. Hab ich auch gedacht. Aber es wäre falsch.

Weil es so ist, dass die physischen Eigenschaften erst den horizontalen und dann den vertikalen Wert haben wollen, sollten die logischen Eigenschaften erst den Inline- und dann den Block-Wert erwarten.

Ich weiß, es widerspricht anderen Eigenschaften, die zuerst Block und dann Inline sehen wollen. Aber dieses Problem ist anderswo und früher entstanden, border-top-left-radius & Co hätten von Anfang an erst vertikal, dann horizontal erwarten müssen, damit es analog zu margin: 1em 2em; oder ähnlichem ist. Allein schon aus Konsistenzgründen - die Eigenschaft ist ja bereits als border-Y-X-radius benannt und sollte dann auch die Werte in Reihenfolge Y X erwarten. Das tut sie nicht, die Backgrounds and Borders Level 3 Spec ist verabschiedet, damit müssen wir jetzt leben 😟

Rolf

[Auge]

Hallo

analog zu border-top-left-radius kann ich auch bei border-start-start-radius zwei Werte angeben, für den Fall, dass ich eine elliptische Abrundung möchte.

Mir scheint aber, dass Chrome hier merkwürdig reagiert (habe gerade kein Füchslein zur Hand): Der erste Wert wird immer für die horizontale Richtung verwendet und der zweite Wert für die vertikale Richtung. Die Spec scheint aber zu sagen, dass der erste Wert die Block-Richtung und der zweite Wert die Inline-Richtung definiert.

https://jsfiddle.net/Rolf_b/r7mc4jt3/

Ist das ein Chrome-Bug? Ein Spec-Bug? Oder ein Rolf-Bug?

Ich würde eher davon ausgehen, dass das eine Missinterpretation deinerseits ist.

Du gibst Radien für die Ränder des div selbst an und drehst die innerhalb der divs befindlichen Texte/Inhalte „zurecht“. Also einmal Formatierung des Elements selbst und einmal Formatierung dessen Inhalts.

Bei mir sieht die elliptische Ecke der roten Boxen nicht wie eine gedrehte Version der blauen Box aus - ich finde aber, sie sollten es tun, so wie in den grünen Boxen.

Ohne es ausprobiert zu haben, würde ich behaupten wollen, dass Transformationen der gesamten Blöcke (mit rotate) die von dir gewünschten Ergebnisse zeitigte.

Tschö, Auge

[Rolf B]

Hallo Auge,

rotate

Das ist nicht das Thema. Das Thema ist writing-mode. Ein Chinese soll sich nicht mit rotate behelfen.

Du gibst Radien für die Ränder des div selbst an und drehst die innerhalb der divs befindlichen Texte/Inhalte „zurecht“.

Ich gebe einen Writing-Mode für's Div an und würde erwarten, dass der für das Element gilt - also auch für dessen Ränder - für das der Writing-Mode notiert ist. Ich verstehe die Spec so, dass sich die Block/Inline-Definitionen daran orientieren sollen.

Aber zur Kontrolle habe ich den Inhalt jetzt nochmal in ein div gepackt. Wenn der writing-mode nur für den Inhalt gilt, müsste er dort ja ziehen. Tut er aber nicht. Auch dort ist der erste Wert der in horizontaler Richtung, nicht der in Inline-Richtung.

Nachdem ich die Spec jetzt nochmal gelesen habe, denke ich, dass ich etwas falsch verstanden habe. Sie meinen, dass in border-X-Y-radius das X für die Blockrichtung und das Y für die Inlinerichtung steht. Aus writing-mode & Co ergibt sich lediglich, auf welchen border-top/bottom-left/right-radius der jeweilige border-start/end-start/end-radius abgebildet wird. Mehr aber auch nicht, d.h. wenn ich zwei Werte angebe, dann werden beide Werte 1:1 von der logischen auf die physische Radiusangabe übertragen, und es bleibt dabei, dass der erste Wert die horizontale Richtung beschreibt.

Und DAS kommt mir jetzt wie eine Auslassung in der Spec vor; wenn ich logische Angaben mache, die sich auf eine senkrecht gestellte Inline-Achse beziehen, dann muss ich Dinge, die vorher horizontal waren, ebenfalls senkrecht stellen. Find ich.

Ich weiß aber auch nicht, ob und wo die Autoren das diskutiert haben könnten. Und vermutlich ist es schon zu lange im Freiland, um das noch ändern zu können. Sind elliptische Abrundungen so exotisch, dass das keinem aufgefallen ist?! Ich hab jetzt ein Issue zur Spec aufgemacht, mal schauen, was draus wird.

Rolf

[Auge]

Hallo

rotate

Das ist nicht das Thema. Das Thema ist writing-mode. Ein Chinese soll sich nicht mit rotate behelfen.

Doch, vielleicht ist es genau das. Vielleicht erwartest du von dem Werkzeug einfach etwas, was es nicht zu leisten vermag. Nur, weil du einen Hammer in der Hand hast, ist das Problem nicht unbedingt ein Nagel. Vielleicht solltest du einfach zum Schraubendreher greifen.

Tschö, Auge

[Rolf B]

Hallo Auge,

wenn man mir aber einen Schraubendreher verkauft, der sich automatisch an Philips, Pozidriv und Torx-Schrauben anpasst, dies aber nur tut, wenn er waagerecht gehalten wird, dann wäre es albern, bei einer senkrecht eingedrehten Schraube das Haus auf die Seite zu kippen.

Statt dessen sollte man klären, warum die Automatik nicht tut, was man erwartet.

Die Antworten, die ich auf mein Ticket bekommen habe, sind auch nicht: du willst etwas unsinnigen, sondern eher: ja, hm, es war einfacher so.

It's like that because logical and physical properties share a computed value

Damit ist eingestanden, dass es unlogisch ist. Es schien aber nicht anders machbar gewesen zu sein.

Rolf