Fixed characterHeight calculation, which could cause overflowing

[mikesir87]

The previous calculation was simply using the height of the letter
W, but wasn't taking into account that each row has a lineHeight,
which might be greater. If the lineHeight is .4px off, after many
rows, it will cause the proposedGeometry to have an extra row,
potentially causing hidden rows (based on layout).

[Tyriar]

Deferring to @parisk since I don't use the fit addon.

[coveralls]

Coverage increased (+7.3%) to 67.75% when pulling 3c3a646 on mikesir87:fix-fit-calculation into ff29fd6 on sourcelair:master.

[parisk]

Thanks for your contribution @mikesir87!

It seems that the offsetHeight attribute takes into account the actual height, padding and border of an element, so it does not ignore the parent element's lineHeight.

My objection with this implementation is that it uses the style attribute, while it would be better if we could somehow extract the calculated height of the line.

The best would be to either utilize CharMeasure.ts (which is kind of difficult) or at least simulate this behavior here.

[mikesir87]

It seems that the offsetHeight attribute takes into account the actual height, padding and border of an element, so it does not ignore the parent element's lineHeight.

You're absolutely correct here. The problem is that offsetHeight and clientHeight return the value as an integer. But, what if the value was non-integer? Chrome seems to truncate the decimal completely, while Safari and FF behave differently by using the decimal value. The Codepen below demonstrates this. You'll see in FF/Safari that if you adjust the line-height to another decimal value, the overall height of the container changes, while in Chrome, it stays constant.

http://codepen.io/anon/pen/LWzEYj

My objection with this implementation is that it uses the style attribute, while it would be better if we could somehow extract the calculated height of the line.

Haha... no objections about that here! Does seem like a "hack" of a solution. Looking at how the CharMeasure works and is being used, I think a better approach is to use get the boundingClientRect's height. I tested in FF/Safari/Chrome and they all return the expected value (supporting non-integer values). New commit reflects this change.

[coveralls]

Coverage increased (+7.3%) to 67.75% when pulling 6cbf0b1 on mikesir87:fix-fit-calculation into ff29fd6 on sourcelair:master.

[mofux]

term is the terminal instance, not the subject row that you will want to measure the height on. I'm afraid this line will crash... 🤔

[mikesir87]

Good catch and sorry about that... yes, it would crash. Just pushed the fix.

[coveralls]

Coverage increased (+7.3%) to 67.75% when pulling 0cb8ecc on mikesir87:fix-fit-calculation into ff29fd6 on sourcelair:master.

[parisk]

Looks great now. Thanks a lot @mikesir87!