On Donnerstag, 15. März 2018 14:02:41 CET Daniel Gultsch wrote: > What intrigues me on something markdown ish (albeit probably something > more than Styling currently has to offer) are its limitations. > Particularity no color (that will never work in a federated > environment where you don't know the design language and color scheme > of the receiving application) and the lack of tables and such (tables > will never work if you don't know the size of the displaying device) > If we want to go with something more xml~ish I would prefer to > annotate meaning (headline, importance, et al) instead of the > availibilty of color and absolute font sizes and font family was > something that annoyed me the most in XHTML-IM (despite the security > flaws in the implementations)
Okay, so since I’m not going to get around to updating '394 this month and there’s considerable interest, I’ll write down what I have in mind: * Emphasis, Strong emphasis, inline-preformatted (code) * Enumerations * Itemized lists * Headings (two or three levels) * Paragraphs * XEP-0392-based colors (i.e. you only give a hue and the remainder is handled by the recipient) * Code blocks with annotation of the language for optional receiver-side highlighting * Maybe inline images Now there has been a lot of discussion around how to make this degrade gracefully. I’m thinking of the following: Each markup annotation has a mandatory pre- and postfix in the body which is stripped once the markup is applied. That works like this (just a rough outline, don’t take the syntax for literal): <body>This is the *new* markup.</body> <markup> <emphasis start="12" end="17"/> </markup> Now <emphasis/> would be defined so that the selected range of <body/> MUST start with "*" and MUST end with "*". If-and-only-if (iff) that is the case, the prefix and postfix is removed and the text is displayed with emphasis applied on the word "new". This is complex, and will not get less complex with more complex constructs like enumerations. The reason for this complexity is that it allows a '393-compatible <body/> message, and also in general a good human-readable representation in clients which do not support it (if we chose the requirements well), while at the same time not allowing to "delete" arbitrary characters for some readers (it has been pointed out that this type of discrepancy can lead to problems). So as a timeline, before updating '394, I want to: - Draft an actual implementation of this scheme in JabberCat - Figure out ways to represent the more complex elements Unfortunately and as I mentioned, I have other priorities currently which is why this won’t happen this month. Sorry. However, I’d be interested in feedback to this approach and in general. 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] _______________________________________________
