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? 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.

> 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

> 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.

> 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.


> 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?

Can you garantee that developers will use a Markdown library with raw HTML 
disabled? 

> 
> 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 do convert Markdown to XHTML-IM without issue.

> 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).

And make bot task and accessibility more difficult, 

> 
> 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?


Goffi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to