On 18.10.2017 18:47, Goffi wrote:
> Le mercredi 18 octobre 2017, 18:12:54 CEST Florian Schmaus a écrit :
>> On 18.10.2017 17:52, Goffi wrote:
>>> 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?
>
> Finally some discussion :).
>
>> I think 2 and 4, 7 don't apply to CommonMark,
>
> CommonMark is specified, but how can you garantee that the dev will use
> libraries compliant with CommonMark?No one can, but that applies to all approaches, even to <body/> text. > The initial issue was that XHTML-IM was > put as is without filtering while the spec says not to do it, so I expect > something far worse with a markup with dozen of syntaxes and different > libraries. I think the security situation is, while not perfect, far better compared to XHTML-IM. >> 1 only partly and is not >> relevant to the situation BMH wants to improve. > > It would be used a a rich syntax, so it is definitely relevant I really don't think so. >> Regarding 3: Nobody >> talks about supporting all flavours. > > The ProtoXEP says "This list is not comprehensive and not meant to be.", so > it > clearly means that any flavour can be used. Good point. I didn't notice that this could be misinterpreted. What I tried to express is that the list does not include every existing markup language. But only the "Markup Language Identifier" defined in the XEP can be used with BMH. And I plan to specify some requirements for markup languages to be included in that list. Like the already mentioned requirement that the language must be reasonably readable when treated as plain text. >> 5. is also not an issue when you >> look at the situation BMH wants to improve. > > Again allowing a protoXEP like this would mean using it as a rich syntax > vectore, so the issue is relevant. No, it is totally irrelevant. Please recall the situation BMH tries to improve: You already have the data formatted using e.g. CommonMark. Whether or not CommonMark supports feature X does not matter. >> 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. > > And what do you do when you have HTML tags? You put them raw? What if > Markdown > syntaxes are inside? Tou remove? how can I send HTML then? Similar as above: You usually wont have custom HTML in those situations. And if you want to send CommonMark+HTML formated data, then you should not use BMH. >> 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. > > So what's wrong with a CommonMark to XHTML(-IM) then? Not all IM clients support XHTML-IM(-NEXT), but all support <body/>. That is why you will end up with stuffing CommonMark into the <body/> in such situations anyways. Even if you additionally do XHTML-IM. I think the last point is very important: If you want to send data that is already in CommonMark *and* even if you convert it to XHTML-IM(-NEXT), you are going to stuff it into a <body/> for interoperability anyway. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
