Unexpected height of a paragraph around floated before element

[rnbutler87]

Hi, I’m checking the height of the first paragraphs within list tags. With the exception of single paragraph line or a triple line paragraph, I intend for the text to float around the bullet point. I’m checking this in javascript. See my codepen here:

https://codepen.io/rnbutler87/pen/qzOwjB

All works perfectly EXCEPT, for an exceptionally narrow band of screen widths.

For example, in the codepen (in chrome I guess) using the Device toolbar in the development menu, scale the browser window down to just before the first paragraph of each list item breaks from 3 lines to 4. There is about a 2 or 3 pixel window where the height of the paragraph still seems to register as only 3 lines (and hence the javascript doesn’t work) yet there is clearly 4 lines of text…

For clarity, here is a video demonstrating what I mean:

https://www.loom.com/share/55cf59730e574a63ba47be5f17eda657

It’s a tiny thing, but it’s driving me mental. I’ve spent ages trying to get to the bottom of it and I’m sure it’s got something to do with the float of the bullet point affecting the breaking of the paragraph line and thus it’s height…

If anyone can shed any light on it or how I fix it, any help would be massively appreciated.

Many thanks,

Richard

[Shikkediel]

This was nonsense…

[Shikkediel]

By the way, it doesn’t work on Firefox. The exact line-height is 27.2 pixels which Mozilla rounds to 82 where Chrome does 81. They rejected relatively recent subpixel precision against the specification.

Edit number 27 – above is the only valid thing I added…

Far as I can tell it has to do with the containing block changing width when using overflow: hidden – and thus not calculating the available space correctly.

[rnbutler87]

Hi thank you for taking the time to help.

I’ve changed the calculation to account for line height fractionally more than 27px (i.e. as 27.2) However, it still doesn’t seem to work. No matter how many pixels I account for, it still doesn’t seem to work as expected…

[Shikkediel]

With all the edits I made, it might have not been clear that that was somewhat of a side issue and not a proper solution…

Having looked at it for quite while, I actually don’t think there is one unfortunately. The problem is that the width that is calculated without the class, is based on 100% – but when adding overflow: hidden the containing block gets a width of 100% - 56px (the size of the pseudo with padding subtracted). This means that any words that are shorter than 56 pixels will be wrapped to the next line when adding the class. So it fits on three lines when checking but not anymore when subsequently reducing the available space by that amount.

The only approach I can think of would require to know the length of the last word(s) and force it to always wrap when it’s shorter than those 56 pixels. But that seems overly complicated.

[Shikkediel]

You’ll notice it works correctly when the last word is longer than the pseudo’s width…

codepen.io/BgzNQw

As an unsatisfying middle ground solution (which I added but commented out), I would probably do a double check on the three-liner and remove the class when it turns out the last line was wrapped. Anything else would require a bunch of JS I think.

[rnbutler87]

Hi, thank you! The javascript check you added would indeed seem like the most elegant option with everything weighed up.

Really appreciate your help on this.

Thank you.

[Monro]

Device toolbar in the development menu.

[Author]

Posts