On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote: > Le mercredi 8 novembre 2017, 10:39:49 CET Daniel Gultsch a écrit : > > Reading this the first time I wasn't sure what you mean by opt-in. > > > > But essentially you want each 'styled' message annotated by an <styled > > xmlns="styling..."/> tag or something like that. And you want clients > > to render those messages styled only if a message contains that tag. > > > > I can get on board with this. > > I mild annoyance is that the sending client needs to support this. So > > if i'm using mcabber which doesn't support styling I can never trigger > > styling on the receiving side even if I, as a knowing user, know about > > the syntax and the consequences of styling. > > > > But if this is required to get everyone happy I can accept this as a > > compromise. > > Hi Daniel, > > regarding the new "Message Markup" proposal from Jonas I think there is > little sense to keep pushing this styling one, the use case is covered and > in a far better way (no markup in the body).
We’re having a nice, civil discussion in xsf@ right now about this, let me summarize my current viewpoint on this (as author of the Message Markup proposal): - Styling fills a gap in the sense that it documents currently used input formats *and* provides a nice fallback for plain-text clients at the same time. - It should be viewed as a docmuentation of the current status instead of a new markup format everyone is supposed to use from now on. - Daniel agreed to an opt-in mechanism so that clients which did not intend to send Styling-ed messages don’t get their messages interpreted that way inadvertently. - People pointed out rightfully so that Message Markup indeed contains something like markup in the body -- this is contradictory to the mission statement that it should not. I have a hard time to resolve this contradiction, but it boils down to "we need a plaintext fallback" and "plaintext fallback is hard to distinguish from markup language in many cases". - I think that there’s merit in having something like the rejected Body Markup Hints as a more general mechanism and have Styling define the current use of intuitive ascii-based markup. This provides us with an opt-in mechanism and a common switch. - I think we have to acknowledge that there are sources which emit a markup of a certain class (like what is documented in Styling, or even Markdown like the sources Florian quoted when proposing Body Markup Hints) which falls back to plaintext gracefully. We can make use of this property (which Message Markup does not necessarily have, and which XHTML-IM certainly does not) by leaving the markup in the <body/> as plain-text fallback and at the same time conveying a hint how it can be formatted nicely. Examples of markup which falls back to plaintext gracefully: Markdown, CommonMark, Styling. Counter-examples: XHTML, reStructuredText (sometimes), Markdown containing HTML. - I think we at the same time also have to acknowldege that there are sources which emit text which is really just plaintext (automated systems), and their messages must not be interpreted incorrectly as marked up. - I think we also have to acknowledge that there are use-cases for much richer text, for example within the Social Network and Blog Federation interest groups (sorry if that name doesn’t quite fit). Those use-cases were covered by XHTML-IM before, and fail to be covered by BMH and Styling. Message Markup can cover those use-cases, if it gets extended into that direction, while helping to prevent the security issues of XHTML-IM. Please see the other thread for considerations about plaintext fallback. I think that this discussion has helped me to better understand where I want to go with Message Markup, and I also think that both specifications plus possibly BMH should co-exist. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
