phone link with href tel: attribute - bad render

[tatsmaki]

Minimal HTML example

Cell <a href="tel:+12125550132">+1-212-555-0132</a>
<br />
Work <a href="tel:(310)5550123">(310) 555-0123</a>

Observed output

1. href tel: attribute is displayed
2. it displays invalid content

Cell +1-212-555-0132 tel:+1-212-555-0132
Work (310) 555-0123 tel:(310) 555-0123

Expected output
Do not display href tel: attribute (same as mailto: works currently)

Cell +1-212-555-0132
Work (310) 555-0123

Version information

• html-to-text: v9.0.5
• node: v20.19.6

[KillyMXI]

Why mailto: can work as expected - because:

• mailto: prefix is (the only one that is currently) stripped
• the email address itself has strict format that is likely to be equal in href and text content, and therefore can be hidden by hideLinkHrefIfSameAsText option
  • Note that this is not the case with the provided phone example

Given input Cell <a href="tel:+12125550132">+1-212-555-0132</a>

• the exact output Cell +1-212-555-0132 tel:+1-212-555-0132 is not actually observed (unless there is a custom formatter in the client code that does this). Notice the phone format
• the output Cell +1-212-555-0132 can only be achieved by ignoring href or by a custom formatter that will normalize phone numbers for comparison

I can do some adjustments. This issue adds to a small heap of input on anchor tag formatter rework.
I can potentially provide separate formatters for emails and phones instead of growing the generic anchor formatter in complexity.

It can also be addressed in client code already - by matching a[href^="tel:"] with necessary options.
But I can't tell how much custom logic a library like react-email would be willing to maintain.

[tatsmaki]

@KillyMXI we found few options to do it on consumer side:

• using selector
• using regex

however I expect html-to-text can handle all href attributes the same way (mailto, tel, geo).

provide separate formatters for emails and phones instead of growing the generic anchor formatter in complexity.

from my point of view this might be the most reasonable approach

[KillyMXI]

Selector is the intended way to customize html-to-text, the member of that library is correct.

They also confirmed that they are not interested to do any detailed customization on their side.
Instead, they expose html-to-text options for their clients, which is a great way to handle it!
I'm usually not aware when downstream libraries do this. Reading documentation should help.

Thanks for bringing it up. This helps to shape the next version.

For any brought-up issues, my goals are:

1. make configuration possible
2. make sensible defaults if possible

Reading documentation and doing custom configuration might still be necessary, because there are limits of what I'm aware of and what level of details I see fit for the standard library of formatters.