Martijn Wargers (dead) Reporter
	Description • 17 years ago

See testcase, when clicking on the button, it shrinks.
Although the end result looks more correct to me, the button should not change size when clicking on it.

	nemo
	Comment 1 • 16 years ago

Another testcase, on a div this time.  Button sets then removes a padding.

	nemo
	Comment 2 • 16 years ago

removed invalid styling "none" and added a setTimeout since otherwise it didn't apply the styling.

	nemo
	Comment 3 • 16 years ago

Also odd, is that in the (fixed) attachment after triggering recalc, there is still some white space to the right inside the div.

	RNicoletto
	Comment 8 • 13 years ago

Possible workaround: https://addons.mozilla.org/firefox/addon/bug385615/

	Roman Komarov
	Comment 11 • 13 years ago

Attached some more test-cases.

What I can see: with larger font-size the bigger extra width would be, the more letters after the first, again the bigger the extra width would be.

Adding float to first-letter invert this behavior, but the extra would depend only on the font-size of the first letter.

And if the font-size of the first-letter is lesser than the inline-block's, then the width of this inline-block “shrinks”.

	Elijah Lynn
	Comment 13 • 12 years ago

Want to cross link two in the wild bug reports to this issue.

http://stackoverflow.com/questions/13160161/firefox-whitespace-oddity-bug-on-a-element/

http://stackoverflow.com/questions/7548255/is-there-a-css-workaround-for-firefox-bug-inline-block-first-letter-with-cha

	jan dvorak
	Comment 15 • 12 years ago

Crosslinking another Stack overflow question: http://stackoverflow.com/questions/14130653/firefox-calculating-blocks-larger/14131771#14131771

A block-level link shrinks (recalculates its width) to the correct size when focused. All (left, right, middle) clicks trigger the fix. Tabbing onto the link triggers the fix if not prevented by Javascript. Some hover effects also fix the bug.

Manifests as an unwanted gap between floating elements.

	Michał Gołębiowski-Owczarek [:mgol]
	Comment 18 • 11 years ago

Any chance of getting it fixed soon? This bug has been open for 6 years and the styling errors caused by this bug are very visible and workarounds are so ugly... This bug is a huge PITA.

	m93a.cz
	Comment 20 • 9 years ago

Still present in FF 38. Not only "font-size" but also "text-transform" triggers the bug. I'm not sure why but in my case "uppercase" makes a way bigger bug-padding than "capitalize", although the result should be (and is in standard-compliant browsers) the same.

	Jonathan Kew [:jfkthame]
	Comment 23 • 8 years ago

This applies to any aspect of the style of ::first-letter that may affect measurement (not only font-size). E.g. it can be reproduced with text-transform, font-family, font-stretch, font-weight, letter-spacing, etc. Updating the summary to make it more general.

	David Baron :dbaron:
	Comment 28 • 7 years ago

Note that bug 362880 comment 2 has some thoughts on how to fix this.