May show only mail and phone number without mailto: or tel: prefixes?

Markdown:

<tel:+375255318270>

Gives:

<a href="tel:+375255318270">tel:+375255318270</a>

But can we have more human?

<a href="tel:+375255318270">+375255318270</a>

Demo of issue.

I am writing my resume in markdown, and want human resources not being afraid of it.

1 Like

This is how it worked in the original spec; the “mailto:” part is not visually displayed.

Automatic links for email addresses work similarly, except that Markdown will also perform a bit of randomized decimal and hex entity-encoding to help obscure your address from address-harvesting spambots. For example, Markdown will turn this:

<address@example.com>

into something like this:

<a href="&#x6D;&#x61;i&#x6C;&#x74;&#x6F;:&#x61;&#x64;&#x64;&#x72;&#x65; &#115;&#115;&#64;&#101;&#120;&#x61;&#109;&#x70;&#x6C;e&#x2E;&#99;&#111; &#109;">&#x61;&#x64;&#x64;&#x72;&#x65;&#115;&#115;&#64;&#101;&#120;&#x61; &#109;&#x70;&#x6C;e&#x2E;&#99;&#111;&#109;</a>

which will render in a browser as a clickable link to “address@example.com”.

1 Like

I don’t think such naive spam bot avoidance techniques – maybe that made sense in 2004 with the original spec and (still the latest) perl code release – are remotely worth canonizing in the spec today.

Does anyone actually use the tel: link style? I guess that’d be useful on mobile phone browsers?

1 Like

Scrambling the email address offers little advantage while complicating the spec. I’m also in favour of leaving this feature out.

In CommonMark 0.10, it looks like “mailto:” isn’t displayed if an autolink is used (consistent with the Daring Fireball spec). There is an email autolinks section which explains this in detail. However example 434 contradicts the email autolinks specification.

1 Like

An email autolink consists of <, followed by an email address, followed by >

Note that there’s no mailto: in there, so:

<FOO@BAR.BAZ>
<MAILTO:FOO@BAR.BAZ>

renders to:

<a href="mailto:FOO@BAR.BAZ">FOO@BAR.BAZ</a>
<a href="MAILTO:FOO@BAR.BAZ">MAILTO:FOO@BAR.BAZ</a>
3 Likes

+++ Chris Alley [Nov 09 14 07:53 ]:

Scrambling the email address offers little advantage while complicating the spec. I’m also in favour of leaving this feature out.

Yes. Someone could always implement a renderer that did this.

In CommonMark 0.10, it looks like “mailto:” isn’t displayed if an autolink is used (consistent with the Daring Fireball spec). There is an email autolinks section which explains this in detail. However example 434 contradicts the email autolinks specification.

No, it doesn’t. There’s a difference between

<mailto:foo@bar.baz>

and

<foo@bar.baz>

Ther former is a URI autolink, and the latter is a special email
autolink.

1 Like

Good point @mb21 (and @jgm), my mistake.

This leaves the question of how telephone numbers should be handled. In the pre-iPhone era of 2004 it would have been less common for a phone number to also be a link. Perhaps the parser could autodetect phone numbers within angle brackets, similar to email addresses? What would be the requirements of a valid phone number?

1 Like

Well, Safari on iPhone detects some numbers as phone numbers, no special markup needed (unless you want to turn the feature OFF).

I’m not sure that people use phone numbers in markdown that often to warrant a tel-nr-detection-algorithm in the markdown spec. You can always write:

[+375255318270](tel:+375255318270)

Or maybe another use case for directives?

::tel[+375255318270]
1 Like

It might make a good extension. I have not looked at how Safari detects phone numbers, but what happens if there is similar formatted number that is not intended to be a phone number? Or a phone number does not start with a plus sign? There may be some value in explicitly defining a phone number – for familiarity, using a similar syntax to email autolinks.

2 Likes

For reference, here is a link to the IETF proposed standard for the tel URI scheme: http://tools.ietf.org/html/rfc3966

1 Like

I will follow for now:

[+55555555](tel:55555555)

But it misses readability of .md files as first goal. Importance of telephone numbers is increasing over time (phone number first IM like Viber, global oriented SIM providers, cheap smart phones for developing countries, SIM based authorization and payment methods, and I click rel: link in Chrome installed on Windows and it launches Skype), but this can lead to invention of simplified (1 full number = 1 globally identifiable person) version of string which can be number, leading to simpler parser and other tag rather then tel:.

Right now PHP Markdown gives results I want out of tel:.

I think to follow “implement a renderer” because I need more divergence of rendering (my resume for web and for print), but “renderers” seems should be declarative like XSLT rather then imperative. Even multi language render hooks seems to hard for me.

Email and tel: could be first tests for such declarative render configuration, first will lead to email obfuscation(like in version mentioned earlier) and second to pretty print of phone number (like in PHP Markdown)

If it does not conflict with existing features we could go even simpler and drop the explict use of tel:. Instead of:

<tel:+55555555>

use:

<+55555555>

which would output:

<a href="tel:+55555555">+55555555</a>

The parser could check that the content inside the angle brackets begins with a + and contains only numbers and hyphens (beyond the initial +). This is just an example; there might be more conditions to check for.

1 Like

Quick look at mentioned RFC suggests that I want global-number to be identified:

<+55555555>

local-number seems can be more complex to parse.

global-number actually is very like mail

<dzmitry.lahoda@gmail.com>

by tendency to be unique and simple to parse.

May there be conflict with other numbers, which are like phone numbers, but not?
I do not recall such, additionally made quick check of some. Non of these starts with +.