launchpad-users team mailing list archive

[William Grant <william.grant@xxxxxxxxxxxxx>]

On 28/01/15 14:52, Pierre Equoy wrote:
> On Wed, Jan 28, 2015 at 11:20 AM, William Grant <william.grant@xxxxxxxxxxxxx wrote:
>> On 28/01/15 13:45, Pierre Equoy wrote:
>>> On Wed, Jan 28, 2015 at 10:38 AM, William Grant <william.grant@xxxxxxxxxxxxx> wrote:
>>> On 28/01/15 13:01, Pierre Equoy wrote:
>>>> Hello everyone,
>>>>
>>>> I wanted to add a feature request about adding Markdown to the different
>>>> Launchpad text fields (description, comments), but I realized there was
>>>> already an open bug about this [1].
>>>>
>>>> It looks like Martin Pool did all the work in a separate branch back in
>>>> 2011, and therefore this feature is (almost) ready for the users,but...
>>>> no progress since then, and in 2012 the bug was unassigned and its
>>>> priority reduced to "Low".
>>>>
>>>> Could someone pick up this branch and review it? I think it would be a
>>>> valuable addition to Launchpad, especially for links and code blocks.
>>>>
>>>> Thanks in advance!
>>>
>>>     As detailed in the bug you linked, Martin's branch was merged in 2011,
>>>     but nobody has picked up where he left off. Markdown support is not
>>>     currently a priority for Canonical's Launchpad team, but we'd happily
>>>     help with and accept a patch that got the feature closer to
>>>     production-ready.
>>>
>>> Thanks for your quick answer!
>>>
>>> I indeed didn't see his proposal had been merged to the lp:launchpad branch.
>>>
>>> So what work is remaining to have this feature ready exactly?
>>
>>  - Some kind of caching is required, as Markdown rendering performance
>>    is insufficient for widespread realtime use.
>>
>>  - Links must be rendered with rel="nofollow" to dissuade spammers.
>>
>>  - URLs and other text must be linkified (see
>>    <https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
>>    /view/head:/lib/lp/app/browser/stringformatter.py#L499> for the
>>    existing implementation).
>>
>>  - Elements rendered from Markdown need to be styled appropriately.
>>
> Are there already rules about the styling? Existing CSS or something like
> that...

Styling user content the same as the rest of Launchpad is confusing,
opens the door to various social engineering attacks, and wouldn't fit
well in comment boxes. User content needs dedicated CSS.

>>
>>  - Non-editable content (eg. comments) needs previews to avoid
>>    formatting mistakes.
>>
> Sidenote question: what is the rationale in not being able to edit comments?

We're not fundamentally opposed to it, but pretending that comments can
be edited once they've already been emailed out to thousands of people
and a dozen mailing lists is a little misleading. It's also a feature
that is very open to abuse unless designed carefully.

>>  - Thought needs to be given to not corrupt the rendering of existing
>>    plaintext comments, and to minimise misinterpretation of email
>>    content as Markdown.
>>
> Do you have a sample "e-mail content" that could be a problem?
> I suppose when people use e-mail to answer a comment in Launchpad, it is
> stripped out of any formatting and used in plaintext mode... but maybe I'm
> wrong.

We don't strip out formatting: we treat email as one should, by
pretending that any text/html part doesn't exist.

But an issue arises when someone composes a plaintext email that happens
to accidentally contain valid Markdown, just as there would be odd
renderings of our millions of existing comments if we started treating
the last decade of existing plaintext content as Markdown.

I don't know if this will be a big practical problem, but it's something
that we need to consider before we turn it on everywhere.

William.

Attachment: signature.asc
Description: OpenPGP digital signature