Vanessa, Schepp und Peter ließen das Glückrad kreiseln. Aber es ist ein neues Glücksrad! Die offizielle Workingdraft-Glücksrad-Webapp, die auf MDN-Daten basiert, setzt uns nicht mehr nur HTML-Elemente vor, sondern spuckt auch DOM-APIs, JS-Features und CSS-Gedöns aus.
[00:01:02] Glücksrad
- pre-Element
- Wer hätte das gedacht? Das
pre
-Element hat einwidth
-Attribut (das wir nicht benutzen sollten)! Sonstige Erkenntnisse zum Element: es kann kein Shadow-Host sein (das können nur ausgewählte Elemente sein) und xmp-Elemente sind unter der Haube auch nur pre-Elemente (zumindest näherungsweise). - Icons im Web Manifest
- Wir sinnieren über Manifest-Icons,
apple-touch-icon
,theme-color
, die allgemeine Meta-Tag-Inflation, Icon- und Webfont-Generatoren sowie die bulletproof @font-face syntax. - text-orientation
- Wir setzen die CSS-Eigenschaft
text-orientation
in den Kontext zu z.B. Ruby-Annotationen und schaffen es am Ende auf wundersame Weise, bei Pi-hole zu landen. - blend-mode
- Wir versuchen zu erahnen, wie viel
blend-mode
(nicht zu verwechseln mit background-blend-mode, mix-blend-mode und color-mix()) tatsächlich verwendet wird und landen bei der einzigen Quelle, die dererlei Fragen zu beantworten vermag: dem State of the Web Report. - DOMPointReadOnly
- Brauchen wir einen Constructor für ein einfaches Objekt mit vier Feldern? Wir suchen nach Pro-Argumenten.
- CSS-Typ ratio
- Der
ratio
-Typ (nicht zu verwechseln mit aspect-ratio oder aspect-ratio) führt uns in eine Diskussion höherer CSS-Mathematik. - scroll-margin-block-end
- Eine der Logical CSS Properties lässt uns mental zu Scroll-Snapping, der Anwendung von Scroll-Snapping und den Kollegen von WWSIV scrollen.
- i-Element
- Wir grenzen
i
gegenem
ab und sinnieren über Boostrap und Accessibility
Kommentare
Tom #
Geschrieben am 29.07.2021 um 12:45
Danke, das war wieder mal eine sehr unterhaltsame Begleitung auf der #tagesLichtRunde eben.
Das DomPointReadOnly Ding wird _der_ Partyschreck. Haha.
@schepp, wie meintest Du das mit der „Sortierung“ bzw was ist größer/kleiner bei den Aspect-Ratios?
Ich finde das eine spannende Sache, gerade im RWD context, bzw in unserem Web-Boxen-In-Boxen Ding.
Wenn man sich die Beispielkistchen auf der Ratio MDM Seite ankuckt, dann ist klar, das flächenmässig das 4:3 kleiner ist, als das 16:9.
Aber nur, weil die Beispiele die gleiche Höhe haben.
Im Web ist aber doch fast immer so, dass wir die Breite als Richtwert haben – und schwubbs, dreht sich das um, da ist dann ein 4:3 raumgreifender als ein 16:9.
Ich hatte irgendwann mal 100(%breite)/w*h als Formel – 16:9 => 100/16*9=56.25 – 4:3 => 100/4*3=75 (ups, das sind ja die Werte aus dem height 0 padding-top hack :-))
Bei der Höhe als Referenzwert wäre das dann 100(%höhe)/h*w – 16:9 => 100/9*16=177,77 4:3 => 100/3*4=133,33 usw.
Zu den Logical Props frage ich mich, was passiert denn bei der shorthand `margin: 1em 2em 3em 4em;` mittlerweile im Hintergrund, macht der Browser daraus weiterhin margin-top|right|bottom|left oder wird das margin-block-start|margin-inline-end|margin-block-end|margin-inline-start ?
oder gibt es halt eine explizite `margin-block` und `margin-inline` shorthand mit nur zwei Werten jeweils?
Da muss ich mal die Specs zu lesen, glaube ich. :-)
Schepp #
Geschrieben am 2.08.2021 um 12:33
Obwohl es mathematisch einfach zu berechnen ist, finde ich es dennoch schwierig im Kopf auszumodellieren, ob nun 4/3 oder 16/9 der größere oder kleinere Wert ist. Und das macht es intuitiv. Dabei steht einem nicht nur im Weg, dass 16:9 sich im Kopf nicht so eben errechnen lässt, sondern auch die räumlichen Kontexte, die Du oben auflistest, die aber in Wirklichkeit keine Rolle spielen.
Richtig ist am Ende:
* 16/9 = 1.778
* 4/3 = 1.333
Ergo ist 4/3 kleiner als 16/9.
Ich vermute, ganz am Ende wird der Browser sowohl für
margin-left
als auch fürmargin-inline-start
auf einer klassischen Left-to-Right-Top-to-Bottom-Seite denselben Rendercodepfad nutzen. Allerdings werden die Eigenschaften nicht schon beim CSS-Parser-Durchgang ge-aliased, weil das nicht geht. Denn bei einer RTL-Seite sindmargin-left
undmargin-inline-start
nicht mehr dasselbe. Dass dem so ist, kannst Du in der Blink-Source (Stichwort „alias_for“) nachlesen. Was wir dort aber lernen ist, dass WebKit schon lange Zeit logische Eigenschaften kannte, nur hießen die damals-webkit-margin-before
(Block Start),-webkit-margin-after
(Block End),-webkit-margin-start
(Inline Start) und-webkit-margin-end
(Inline End). Denn die wurden zu den neuen Namen ge-aliased.Ja, die gibt es! margin-block und margin-inline bei MDN.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.