On Sun, Jun 07, 2020 at 09:38:04PM +0300, Frank LENORMAND wrote: > This amendment that prevents conflicts between list items and > *emphasised text* indirectly acknowledges that clients may not > render *emphasised text* verbatim. > > Writers are no longer ensured by the standard that their text surrounded with > asterisks will not be decorated by the client, by extension. Writers were *never* assured by the standard that text surrounded with asterisks would not be decorated by the client! Clients that want to do that can, but it's strictly an optional extra out-of-spec nicety. If anybody wants to do this, the onus is on them to do is smartly enough that it doesn't interfere with the specced use of asterisks for line items. If they mess that up, presumably their users will move to an either less ambitious or better written client which doesn't mangle things. > Are there any plans to mention inline text decoration explicitly in the > specification? If yes, it follows that there should be a way for writers > to escape asterisks around words, in non pre-formatted blocks. There aren't. Even if there were, it wouldn't follow that there would need to be a way to escape them. The spec says "authors should not expect to exercise any control over the precise rendering of their text lines, only of their actual textual content". This extends to not being able to opt out of various optional niceties that clients may choose to implement above and beyond the spec. Authors of text/gemini should never expect to influence the size, weight, colour, font, alignment etc. of any of their text. That's in the client's hands, and that's a good thing. The advanced line types that exist may have common and semi-predictable consequences for stylisastion in extant clients, but the reason they are in there is primarily to give some way to convey important *semantic* information. It's true that the list item type doesn't *quite* live up to that ideal. But I like pretty lists, so... Cheers, Solderpunk
---
Previous in thread (4 of 35): 🗣️ Frank LENORMAND (lenormfml (a) gmail.com)
Next in thread (6 of 35): 🗣️ Luke Emmet (luke.emmet (a) gmail.com)