earlier replies
Replying to @LeaVerou
First is Chrome, right? If so, yeah, that's wrong, and it's a known bug. Our bullet handling is *fucked up*.
1
1
Yeah, Chrome, FF, Safari. Any workaround ideas? It's breaking <li> editing in @mavoweb… :/
1
No workaround besides reimplementing markers yourself, until we fix it. (Previously we matched Safari, hiding it entirely.)
2
1
Safari (and our previous behavior) transplants the marker box to the first, deepest box child of the <li> *for no discernible reason*.
1
So if the child is overflow:hidden/scroll/etc (or replaced, like here), it just hides the bullet, as it's "overflowing".
1
Whoa. That sounds pretty major!
1
Yup, it's bonkers as hell. No clue how/why it was originally implemented that way.
1
Perhaps because it was easier to hook into existing tree handling than special case markers?
1
Nah, correct would just make it a child of the <li>. Making it a child of a block descendant doesn't make anything simpler, I'd think.
2
There must be some special handling, because look: dabblet.com/gist/2abfc8f1ec1… The marker stays behind.
2
Replying to @LeaVerou @tabatkins
FWIW, bullet vertical positioning is hard. There are a bunch of cases Firefox gets wrong. Should break down into 3 basic cases:

Aug 1, 2017 · 12:57 PM UTC

1
Replying to @davidbaron @LeaVerou @tabatkins
1. bullet positioned next to a line box, if the first inline descendant (non-replaced or replaced) of the block is in a line box
1
2. bullet positioned next to a non-inline replaced descendant, if the first inline or replaced descendant (1^ wrong) is non-inline replaced
1
more replies