Truncate component breaks JSX conventions

[bradenmacdonald]

Feedback summary

The <Truncate> component documentation says:

Note: Truncate supports only plain HTML children and not jsx.

And a supposed example of this can be seen in the "HTML markdown support" section.

However, this is not true. A more accurate statement would be "Truncate supports only a buggy, idiosyncratic version of JSX."

It is JSX, not HTML

First of all, if it was truly HTML instead of JSX, it would have to be passed into the Truncate component as a string; it is in fact being parsed by React's JSX parser. You can clearly see this if you use other JSX syntax like {"string interpolation"}:

Bugs

Second, of all, it throws errors on things that are perfectly valid HTML or JSX:

Incompatibility

Finally, because this is actually JSX but it's not implemented correctly, TypeScript is always going to throw errors like this (which is how I discovered all this):

Type '{ children: Element; class: string; }' is not assignable to type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
  Property 'class' does not exist on type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'. Did you mean 'className'?

I don't think it is possible to tell TypeScript that some portion of the JSX is using our own special version of JSX and should be using class instead of className.

Suggestion

At the very least, I suggest fixing the bugs and implementing support for className instead of class, htmlFor instead of for, etc. so that we can use this with TypeScript.

But now might be the time to replace the current complex JS implementation with a simple CSS implementation, given that all major browsers have supported -webkit-line-clamp for a while (click "Usage Relative").

[brian-smith-tcril]

After discussing in today's Paragon WG meeting, a reasonable path forward would be to deprecate the current Truncate component (move it to Truncate.Deprecated) and build a new Truncate component that supports our use cases (including a11y concerns around aria-label/title etc.) in as modern a way as possible.

[bradenmacdonald]

supports our use cases (including a11y concerns around aria-label/title etc.)

@brian-smith-tcril Are those requirements documented anywhere? I don't see them in the README nor the code.

[kblemel]

@brian-smith-tcril We discussed a few top level a11y concerns (e.g., using proper HTML/ARIA semantics and providing equivalent access for keyboard and touchscreen to the full title display on mouseover).

After reviewing WCAG Success Criteria, I realized that I'll need more information on expected use cases to understand possible additional issues with both SC 1.4.10 Reflow (added in 2.1) and 1.4.4 Resize Text.