I believe this has been fixed by D20327 / D20393 -- at least, the examples above no longer seem to reproduce any bad behavior.

It's disappointing that this isn't supported.

PhabricatorObjectRemarkupRule->renderObjectEmbedForAnyMedia() currently calls renderObjectTagForMail() unconditionally when we're in HTML mail mode. This always renders a (F123: Xyz) element.

@mydeveloperday Thanks! That'll work

@dwilches I needed the same ,just wrote up my solution here

Is there a workaround for including a newline in a table's cells? I've tried with both pipe and HTML syntax, and with %%%, triple back-tick and <br> with no success.

I think https://secure.phabricator.com/book/phabricator/article/remarkup/ needs update to include this.

Maybe vertical-align: top? Or display: inline-flex?

yikes

FYI Chrome/Windows after the change (extra whitespace added?)

In Safari we get this marvel:

I don't currently plan to pursue this.

We now support emoji; we might support stickers at some point. If we did, I'd expect them to use the autocomplete element (which I think is in a relatively good place for emoji), not actually be invoked with :P, ^-^, etc.

Since there's no known actual problem with this today, I don't plan to fix it.

This is well-suited to a third-party extension, particularly after T5055.

I don't currently plan to pursue this.

I don't currently plan to pursue this.

I don't currently plan to pursue this.

I don't currently plan to support this.

I don't currently plan to support this. You may be able to add a rule to support something like <br /> with a Remarkup extension.

I don't currently plan to change the remaining edge case behaviors since I'm not sure they ever occur in the wild.

This seems largely resolved.

This request seems very niche, so I don't currently plan to pursue this. It may be possible to implement it as an extension.

I don't currently plan to pursue this.

This is unlikely to ever happen without stronger use cases for nested block-level elements.

See followup in T13105.

See followup in T13105.

very good memes

hmmm

Actually, HTML mail has an issue now.

This is technically fixed now but the meme stuff is real old and rough so I'm going to maybe make some kind of effort to get through more of T5258, etc.

This is conceptually easy but no trigger character really makes a ton of sense. I'm going to decline this until it's more clear what the desired behavior actually is.

I've removed the requirement that prototypes be enabled and marked this as fixed in D19195. The behavior could probably be refined, but I think it should fail in an obvious way when it fails, now.

D19111 doesn't fix this in the general case, but should produce the desired behavior for most inputs such that the input is in the form [x](y) and y is the URI of a Wikipedia article.

The intent isn't unambiguous in the general case, consider: Blah blah (see also [x](y)).

Ah thanks!

The non-bold ones also open in a new tab.

Oh! Yes. Sort of.

Just curious, but is the bold effect intentional in the "No Encoding Relative" scenario?

D19032 now renders D123 in text contexts (plaintext email) as D123 <https://dev.tyrellcorp.com/D123> instead of https://dev.tyrellcorp.com/D123.

As it turns out, I wrote a bit of {icon ... size=72} yesterday but ran into a related issue: it's hard for us to tell if the X in {icon X} is a single character or not.

Would you want to include the use case of making specific letters/words of inline text larger/smaller/bouncier? I like the idea of {style ...} though it is awfully similar to {icon ...}

Some other possibilities:

It's a real tragedy. The biggest header is definitely unacceptable for huge emoji.

Currently there's no way to make an increasingly larger parade of dogs

=====:dog2:=====
====:dog2:====
===:dog2:===
==:dog2:== 
=:dog2:=

Yeah, the only reason I pursued this was for giant emoji. I was just going to do {huge 🐱} or something first, but then I figured {drop-cap 🐱} was a little more defensible as a general feature while still solving the huge emoji problem.

I've been wanting to make a "giant emoji" task since emoji were added but was too afraid...

This is at least fixed in theory. To verify it, I waved my cursor over a revision's table of contents and didn't see any periods.