Re: [csswg-drafts] [css-fonts-4] Feature for making text always fit the width of its parent

@tobireif I'm responding in length, out of respect for the lengths to which you have commented. So, I'd encourage you to read through [css-values-3](https://drafts.csswg.org/css-values-3/), [css-text-3](https://drafts.csswg.org/css-text-3/), [css-display-3](https://drafts.csswg.org/css-display-3/), [css-align-3](https://drafts.csswg.org/css-align-3/), [css-contain-1](https://drafts.csswg.org/css-contain-1/), [css-inline](https://drafts.csswg.org/css-inline/), etc... at least.

Then take a stab at providing a normative way to specify how this feature could work in the "wild west" of layout land. This is why in my previous https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-380627833 I'd shared my questioning stream of consciousness. And addressing those questions could be what would compel authors to see the merit you are trying to communicate. Have you used the fittext.js plugin on an element with an em based width? An element displayed inline? Text-indent? Initial-letter? How would it fit alongside the font-size property or font shorthand? With descendant that's displayed as block but floated? With generated content added to its box tree with possibly display values? I just quickly tried the plugin against a few of these cases, with most causing it to implode. If you want to persuade more support, provide rationale for how this feature *could be worth the effort of specification, let alone browser implementation.

As for your own site, the type inside your headers is simple enough that you'd have performance gains in just using vw inside a breakpoint, reducing 50 lines of runtime js to possible 4 lines of css.

-- 
GitHub Notification of comment by jonjohnjohnson
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-381327575 using your GitHub account

Received on Saturday, 14 April 2018 13:00:46 UTC