Cool. Yeah, that all sounds good to me.

Yeah that was my plan; relative links on non-Phriction pages just won't get marked up.

(If the current page isn't a Phriction page, I guess just don't mark the thing up?)

That seems reasonable to me. I like using ./ to opt in to this and not making it the default.

@epriestley Can I write and submit a patch for this?

T8407 holds a small piece of UI for this.

✂✂✂✂✂
✄✄✄✄✄

needs a haircut

yea i noticed that.

See also T5701 for bonus complexity.

@jshirley, here's the issue we spoke about earlier.

D15535 should completely fix this in all cases

Evidence for the trial (when the fix goes live the description will render correctly)

It was another cspeckmim

u wot m8? havin' a go? havin' a little laff?

I don't particularly love ASIDE as the trigger, maybe MEMO is a little better? But it doesn't really capture the intent particularly well, I think.

oh, I'm just braindead: I skipped over the nav portion entirely since it wasn't the obvious thing I wanted.

This is already documented, do you have any suggestions for improving the existing documentation?

I wanted to use it for de-emphasis (like you're aside) and for inside of tables for various things. I was also trying to use it for a small "edit this panel" link like the other task but the href on the button is cooler.

oh, cool. That should be documented, but is exactly what I wanted.

Yeah, I think changing text size inline often tends to look pretty bad since line heights get all messed up, too.

I'd prefer to not support this. Would like to know real use cases instead, maybe just have lighter text or other means. But generally prefer to keep accessibility issues to a minimum.

Note that you can do this today:

We're planning to do this at some point:

Do you have some examples of things you'd like to use this for?

this task might more generally: support inline remarkup in link names. I havn't tried to make image, bold, or other interesting links.

for anyone else that runs into this in the future: http://www.gossamer-threads.com/lists/wiki/mediawiki-cvs/626638

I think the most natural syntax (and the one I tried before discovering it didn't work!) would be to allow one to basically copy-paste the existing path at the top of file pages (the one inside the phui-header-header element), so that for example, a link to Diffusion's readme file on here would be: rP/README.md
And to link to, say, a specific line of a specific revision: rPbe0e84a81abc/README.md$17
And likewise for ranges: rPbe0e84a81abc/README.md$5-13

We use a custom field release description of type remarkup. We then export tasks via conduit API to our HTML release notes. In this release description we use some of the remarkup feature set.

For easier onboarding of new users and better discoverability of anchor links in general, how about adding an extra character like "¶" at the end of a heading when hovering over it? This would make it very easy to copy an anchor. An example from the issue tracker Trac:

@ProfFan My pleasure! :-) Thank you for the link - will take a look.

In T6609#160639, @ablekh wrote:

@ProfFan Great job! Thank you for your efforts. BTW, what is Celerity?

@ProfFan Great job! Thank you for your efforts. BTW, what is Celerity?

Just changed the code to utilize celerity and now the extension works on all pages and comments :)

In T6609#160552, @johnny-bit wrote:

This looks awesome @ProfFan !

This looks awesome @ProfFan !

Now updated the parsing mechanism to make it able to handle multiline inline LaTeX.

Ah cool, good to know. Thanks for the quick fix!

Yeah, I came to approximately the same conclusion. Save + restore on the scroll position appears to be a complete fix as far as I can tell.

Invalidating the cache is trivial, but I think <code> is used to style code blocks and has a bunch of different rules (e.g., block formatting) already associated with it.

So I looked into this and it is the call to area.focus() in the setSelectionRange method in https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/core/TextAreaUtils.js (unsure what line, my view of this file is plaintext here) that causes the scrolling. I removed this line and it seemed to have the expected behavior but who knows what other problems removing it may cause.

Presuming resolved, but yell if I missed anything.

Caches should be purged, let me know if you're still seeing issues? D15311 will fix the underlying problem, and should promote and deploy in the next 24 hours.

@hyOzd No, this utilizes KaTeX and renders LaTeX using HTML and CSS. It is completely combined into the normal rendering workflow and is cached properly.

@ProfFan does this create images on the server side?

I did a rough implementation of this functionality (full of dirty hacks) here at GitHub.

In general, we can't possibly create buttons for everything -- there are way too many rules, and some of the rules don't lend themselves easily to clicking a button. The icon already links to the full documentation, which explains everything (and this document is huge, because there are ton of rules).

(That's admittedly not communicated very clearly by my screenshot.)

Old behavior was this:

what did it look like before?

Currently, no block elements (lists, tables, code blocks, interpreter blocks, etc) work inside table cells. They interpret their content as inline only. So this is the expected behavior.

In general this falls under "feedback" or "design feedback" (see T10208). We don't have any decent mechanic for taking and holding these opinions in Phabricator. For "design feedback" we currently limit it to what is on the current Roadmap. This helps our small team (2 people) remain focused on building and thinking about the current product.

I'm going to merge this over this since it's not a bug report nor a valid feature request (since a per user option already exists).