| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Welp, turns out I was overthinking it. CSS does not support inline
position: absolute at all, it just blockifies.
That does leave us with the question of "why does inline-block behave
differently than block?" Especially because both in Gecko and Blink,
getComputedStyle for absolute inline-blocks gives me "block", not
"inline-block", and yet there is the same difference in rendering when I
change the CSS.
I first thought it's a quirks mode issue, but standards mode doesn't
affect it. Wat.
|
|
|
This fixes a) resolution of `position: absolute' percentage sizes with
an indefinite containing block size (wait what?), and b) positioning of
`position: absolute' inner block boxes inside inline boxes.
a) is possible because `position: absolute' does not affect its
parent's layout. I would love to have a long talk with whoever
thought that specifying it like this is a good idea. You know, just
because you can... anyways, shockingly enough, this was still the more
straightforward part.
b) forced me to change the box tree to allow blocks inside inlines,
which is ugly, but no big deal. Two questions then remained:
1. *where* to put such boxes, and
2. *how large* these boxes should be; this is hardly obvious since
an inline box does not have an unambiguous width or height.
Of course the CSS standard, never too eager to fulfill my basic
expectations, says nothing about this (other than "it's not defined").
So I first tried to reverse engineer what Gecko does, and after hours of
pain and suffering I realized... that it's broken LOL
https://bugzilla.mozilla.org/show_bug.cgi?id=489100
Therefore I ended up (partially) copying Blink behavior, which, while
equally nonsensical as Gecko (and of course divergent), at least does
not change after a partial layout. Thank you LayoutNG for saving my
sanity.
As for the practical benefits: this fixes the bug where Invidious
[video] tags wouldn't show up. Hey, it's something!
Still left to-do: `position: absolute' for `display: inline' boxes.
|