Closed evantishuk closed 9 years ago
So this is for px-based line/word-spacing?
Does setting these values in relative em
units solve this use case without adding it to the plugin?
Yes. It's intended as a convenience for px-based spacing settings, to make FitText that much more ecumenical. I should have clearly stated that -- 'twas a late night pull request.
The assumption is that people often prefer letter/word-spacing with px for it's convenience and finer-grained control. If you're working off of a designed mock up, it's more straightforward to approximate kerning using px units than ems (4px v. 0.946em).
jQuery converts em values set in the CSS to px regardless. As far as I've been able to tell, you can use ems in the same way. So, there's no apparent degradation to normal behavior.
Let me stew on this for a bit. I'm leaning towards not merging this in just for a few reasons:
em
unitsline-height
calculation modifications like this in the past for the same reason, a relative way of doing it is already available.That said, let me think about it becuase you've got a point that most people on Earth just code their letter-spacing values in px
.
Thanks for this commit but I'm going to decline this pull request in favor of just relying on plain ol' CSS. I realize it's a bit more of hassle to do some math in the CSS, but I think scoping FitText to just font-size
suits it well.
Thanks again.
Letter and word spacing using pixels causes FitText to behave badly. Setting those spacing values to scale along with the font-size is relatively trivial, so I added that in.
Contributed code appears to work consistently in the sample of desktop browsers I tested against:
Ubuntu (12.04):
XP:
Testing on mobile devices worked, but was dependent on native typefaces and required some manual adjustment of the compressor parameter. May be best to adjust example.html to use a Google font that renders somewhat more consistently?
EDIT1: Formatting. EDIT2: Clarified this is for pixel-based units.