amphtml: ITI: Support for text clamp/truncation that doesn't require display: -webkit-box;

This is now implemented as the <amp-truncate-text> component. It currently requires the amp-truncate-text experiment to be enabled. This can be done via the browser console:

AMP.toggleExperiment('amp-truncate-text', true);

/cc @cpapazian If you have time, can you try this out and see if it fits your use case?

@cpapazian @sparhami

Regarding different component, I sampled a few live usages of amp-fit-text, and to my surprise, using amp-fit-text to clamp text by setting min and max font to the same value seems more common than I expected and that’s not at all the main point of that component.

I am leaning toward the idea of a new <amp-clamp-text>. @cpapazian in your particular use-case, is scaling of the text needed at all?

This is definitely good discussion in the I2I. The new component could purely use the JS implementation and expand feature could be built in via a default (and overridable) UI. We may provide an opt-out for the expand feature.

Even if text scaling and clamping at the same time is a common need, composition may be a better approach:

<amp-fit-text min-font-size=30>
  <amp-clamp-text>
  stuff
    <button overflow> 
        See more
    </button>
 </amp-clamp-text>
</amp-fit-text>

(we can make the above work by stoping amp-fit-text from applying overflow when there is a amp-clamp-text present as child and let that handle the overflow)

Thanks @cpapazian.

Assigning the issue and PR to @sparhami to see it through merge. Sepand has done some thinking about this.

I’ll leave it to you and @sparhami to discuss the API and get it reviewed in of the design meetings if needed, below are some of my thoughts:

1- I am okay with JS truncation, it adds a few additional relayouts but fit-text already does 4 or 5 I believe. 2- I don’t fully understand the overflow="fit | truncate" proposal in #15448. Overflow is implicit (when min-font-size is specified) and is always has to truncate, I don’t see what “fit” means here. That being said, we would want to allow: A- developer can specify an element that is displayed when overflow happens, developer can decide what tapping on that does, it can expand or does something else (open modal, navigate) B- (maybe) we provide a default UI that expands the text on tap (overridable by 2A)

the JS vs CSS implementations of overflow seem orthogonal to the above. Some versions of UIs in 2 are doable without JS version and some are not.

The reason I figured a new attribute made sense was that I would only want it to be visible if the text was overflown, though we could do that with a CSS class.

Aside from that, a myFitText.expand action sounds good to me.

(don’t expect you guys to prioritize this … we can find resources if it ends up being a must-have for us).

(in all honestly, unlikely we can prioritize this. PRs welcomed and appreciated of course. We can move much faster on reviews than infinite list from back then as this is a much more contained feature)

@cpapazian Thanks. Too bad JS is not avoidable for this. For https://github.com/ampproject/amphtml/issues/15448, we could just add an new action like myFitText.expand and let pubs implement the overflow instead of a new attribute.

we’re hoping to do something like this:

in an amp-story page. I’d like the text to flow around the “More” button in the bottom right, rather than under. This is pretty easy to to do with float:right.