border-width - kann sie Nachkommastellen haben?

[Rolf B]

Hallo alle,

ich bin auf einigen Umwegen zu dieser Frage gekommen - eigentlich ging es mir um eine Bemerkung in MDN, wonach clientLeft/clientTop die Position der linken oberen Ecke der Padding Box^[1] eines Elements liefern (es sei denn, es ist inline), und zwar relativ zur linken oberen Ecke der vollständigen Box des Elements. Oder mit anderen Worten und den Worten der Spec: clientLeft = border-left-width und clientTop = border-top-width.

Aber mit einer Einschränkung: clientLeft und clientTop liefern nur ganzzahlige Werte. Und man solle element.getBoundingClientRect() verwenden, wenn man die Werte inclusive der Nachkommastellen haben wolle.

Ah. Oh. Hä?

getBoundingClientRect liefert mir doch das Rechteck, das die Elementbox einnimmt, relativ zum Viewport. Okay, das tut es mit Nachkommastellen, aber was hilft mir das bei clientLeft/clientTop? Bevor ich ein MDN Issue einstelle, wollte ich mir anschauen, welche SINNVOLLEN Wege es gibt, an clientLeft/clientTop mit Nachkommastellen heranzukommen.

Und es macht den Anschein, als gebe es keinen sinnvollen Weg. Weil es nämlich den Usecase gar nicht gibt. Weil ich es nämlich zum Verrecken nicht hinbekomme, Ränder mit einer non-integer Breite zu setzen.

Die Spec sagt dazu nichts. Nur: <length> oder thin/medium/thick. Ich habe es mit Chrome und Firefox probiert. Methode:

<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>

.box {
  width: 200px; height: 50px;
  box-sizing: content-box;   /* Bevor mir einer hiermit ankommt */
  border: 1px solid red;
}

und die border-Angabe von 1px auf 1.5px geändert. Und? Es rührt sich nichts. Erwartetes Ergebnis: Der Stapel wird 5px höher.

Kontrollversuch mit der Höhe: height:50px vs height:20.5px - jau. Da tut sich dann was.

Also sprach das Gretchen: Lieber Heinrich Browser - wie hältst Du's mit den Nachkommastellen bei Rändern?! Kann mir das jemand verbindlich bequellen?

Rolf

---

1. Paddingbox = Client Box plus Paddingbereich. Oder Außenrand der Box minus Rand ↩︎

[Felix Riesterer]

Lieber Rolf,

nur mal auf die Schnelle: border-width: 0.1em; - Hilft Dir das weiter?

Liebe Grüße

Felix Riesterer

[Raketenwilli]

nur mal auf die Schnelle: border-width: 0.1em; - Hilft Dir das weiter?

Naja. Ich habe auch überlegt, inwiefern Nachkommastellen bei den von Rolf erwähnten Pixeln denn eine Rolle spielen. Dann habe ich [STRG] und [+] gleichzeitig gedrückt.

[Rolf B]

Hallo Felix Riesterer,

mit emmchen hab ich natürlich auch gespielt, aber de facto arbeitet der Browser ja bei allen internen Abläufen mit Pixeln. Die diversen x,y,left,top,width,height-Eigenschaften liefern alle Pixel, und alle ganzzahlig.

Ich hab mein Beispiel von oben mit font-size:10px und dann border-width:0.1em und 0,19em wiederholt. Gleicher Effekt - bei 0.2em ist ein Sprung.

Rolf

[Raketenwilli]

Hallo Felix Riesterer,

Entschuldige die unhöfliche Einmischung in das wohl angestrebte Privatgespräch … Aber

bei 0.2em ist ein Sprung

Bei einer Schriftgöße von 10px ist das der logisch zwingend eintretende Effekt, weil dann bei der Umrechnung in Pixel jeweils die x,5 erreicht (unter- oder überschritten) wird und sich aus der Rundung auf einen ganzzahligen Wert ergo der „Sprung“ ergibt.

[Rolf B]

Hallo Raketenwilli,

wieso Privatgespräch?

Genau dieses Runden ist ja der Punkt, auf den es mir ankommt. Der Browser rechnet ja oft auch mit Nachkommastellen bei Pixeln und rundet erst beim Rendern - siehe den "Kontrollversuch" mit der Höhe, den ich im Eröffnungsbeitrag beschrieben habe.

Bei den Rändern scheint er es nicht zu tun - und da frag ich halt: ist das spezifiziert oder eine Freiheit des Browsers?

Rolf

[Raketenwilli]

Genau dieses Runden ist ja der Punkt, auf den es mir ankommt. Der Browser rechnet ja oft auch mit Nachkommastellen bei Pixeln und rundet erst beim Rendern - siehe den "Kontrollversuch" mit der Höhe, den ich im Eröffnungsbeitrag beschrieben habe.

Hm. Ja. Hab mich oft geärgert. Gerade auch über das Verhalten beim Vergrößern/Verkleinern der Seiten. Gab Zeiten und Browser, da wurde alles vergrößert/verkleinert, soweit es nicht mit px „begrößt“ war. Mit hässlichen Ergebnissen.

Bei den Rändern scheint er es nicht zu tun - und da frag ich halt: ist das spezifiziert oder eine Freiheit des Browsers?

Naja. Zumindest das MDN spricht von „serializieren“. Kann man schon so verstehen:

• analog: dezimale Zahlen
• serialisiert: ganze Zahlen, also gerundet

In der CSS-Spec selbst habe ich nicht nachgesehen und leider keine Zeit mehr - ich muss nach Hannover. Arbeiten. (ab morgen früh)

Und: „Danke, für das, was Du eben (20:01) getan hast.“ War richtig und vor allem rechtzeitig.

[Raketenwilli]

Hm. Quelle?

https://w3c.github.io/csswg-drafts/css-backgrounds/#propdef-border-width

These properties set the thickness of the border. Where

<line-width> = <length [0,∞]> | thin | medium | thick

linkt zu: https://www.w3.org/TR/css-values-4/#length-value

There are two types of length units: relative and absolute. The specified value of a length (specified length) is represented by its quantity and its unit. The computed value of a length (computed length) is the specified length resolved to an absolute length, and its unit is not distinguished: it can be represented by any absolute length unit (but will be serialized using its canonical unit, px).

Das „serialized using its canonical unit“ kann man schon so verstehen, als dürfe der Browser das auf ganze Pixel runden.