On 18.10.2017 17:52, Goffi wrote:
> 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?I think 2 and 4, 7 don't apply to CommonMark, 1 only partly and is not relevant to the situation BMH wants to improve. Regarding 3: Nobody talks about supporting all flavours. 5. is also not an issue when you look at the situation BMH wants to improve. 6. is also a non-issue: While CommonMark specifies HTML pass through, it is not performed when it's sensible, e.g. no Stackexchange site or discourse installation allows HTML pass through. The situation BMH tries to improve is the following: I do have a bunch of data formatted using a markup language, say CommonMark, that I want to send over XMPP to an XMPP client. Because there is no converter from CommonMark to XHTML-IM(-NEXT) and since I don't want to write one (for various reasons), I'm just going to stuff CommonMark into <body/>. The good thing about markup languages which are reasonably well readable in plain is: Even if the receiving client doesn't know CommonMark exists, it will display the textual content just fine (thanks to the nature of CommonMark). But if the client knows about the existence of CommonMark, and if there is an BMH, then it could display the content in a more sophisticated way. Uh, and there are tons of CommonMark to X converters available. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
