Le mercredi 18 octobre 2017, 17:28:31 CEST Jonas Wielicki a écrit :
> On Montag, 16. Oktober 2017 18:38:46 CEST Jonas Wielicki wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Body Markup Hints
> > Abstract:
> > This document specifies hints about the markup language used in
> > elements.
> >
> > URL: https://xmpp.org/extensions/inbox/bmh.html
>
> So, I don’t like this. The reason is that it will require trickery to make
> it usefully interoperable. For example, there are different flavours of
> Markdown (let’s call them Vanilla, Chocolate and Strawberry). Now a message
> is sent which happens to be compatible Vanilla and Strawberry, but not
> Chocolate.
>
> Here’s the first issue: does the client *know* that? Or will it only tag it
> as one of the flavours? If it tags only as Vanilla, a client which may
> support Strawberry would not correctly display the markup.
>
> The second issue is if a client which supports Strawberry and Chocolate sees
> a message in Vanilla flavour. It could try to parse it as either Strawberry
> or Chocolate (which would probably work in *most* cases, but not in all),
> or not show proper markup.
>
>
> This generalises to other markup languages and different versions of them
> and is not a problem specific to Markdown.
>
>
> This could lead to islands of clients only supporting whatever markup
> language is hip in the language they’re implemented in (python clients for
> example supporting reStructuredText, many others one or another flavour of
> Markdown) etc., leading to a very inconsistent user experience, which I
> don’t like about this.
>
>
> (Even if it isn’t meant as a replacement for XHTML-IM, I fear that it would
> be used as such.)
>
>
> kind regards,
> Jonas
I fully agree with Jonas + what I've already said on Markdown (and nobody
disagreed on those points so far), that I'll repeat below for reference +
putting it in <body> is even worse (<body> is for plain text, and markup
language will not be nice outside of client displaying rich text, also it may
make the task more difficult for bots trying to parse human languages) + no
comprehensive list of syntaxes is the best path to no interoperability.
Here is the list of points I have against Markdown, some of them also apply to
other textish syntaxes, and 6) is particularly bad (you'll see people putting
unfiltered markdown with <script>[bad things]</script> inside):
1) as its name state it's a writting syntax and not a publishing one. There is
not such thing as invalid Markdown (every text is valid Markdown), but the
result will differ according to rendering library used.
Even original author says that it's not a publishing format ("HTML is a
publishing format; Markdown is a writing format." cf. https://
daringfireball.net/projects/markdown/syntax)
2) it's not specified and it's unlikely that it will be (and yes I know about
common Markdown and RFCs about the MIME type and the guidance on Mardown).
3) there are dozen of flavours, more or less (in)compatibles
4) as stated by Jonas, it's really hard to extend without side results (should
I interpret ~bla bla~ as strikethrough? Yes my librarie is doing it! Oh wait
no, it's not an official syntax, there is not strikethrough in Markdown…
https://daringfireball.net/linked/2015/11/05/markdown-strikethrough-slack ).
5) it's limited (no color, no strikethourgh in classic syntax)
6) official syntax allow embedding HTML, so libraries may or may not interpret
<script> as HTML, ruining the whole purpose of "changing syntax because it's
better for security".
7) my_long_variable will emphasis "long" in some implementation, not in others
(example taken from Wikipedia)
So can you point what is wrong/false in those points, and if you can't how
could it be sensible to use those syntaxes as publishing format?
Goffi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
