On 12.05.20 21:35, Jonas Schäfer (XSF Editor) wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
This XEP tries to fill the gap of lack of formatting instructions introduced by deprecating XHTML-IM (XEP-0071). > 2. Does the specification solve the problem stated in the introduction > and requirements? The XEP does not allow to have a message that is rendered the same as the HTML "I am <b>bold</b>". This is because styling directives are done inline and are supposed to be displayed, thus to make a word bold, it is required to change the text as it is displayed. §7 outlines accessibility considerations which I don't believe have been thought through carefully: > When displaying text with formatting, developers should take care to ensure sufficient contrast exists between styled and unstyled text so that users with vision deficiencies are able to distinguish between the two. Some clients reduce contrast of characters they believe to be meant as styling directive. The accessibility considerations don't mention this at all. Given that through the way styling directives work there are false positives, it's more important to properly display styling directives than to ensure contrast between different styles of text. Also depending on the type of application and device, it may be impossible to ensure high contrast between styled and unstyled text. Also this section ask to ensure high contrast between styled and unstyled. However good readability of *all* text should be preferred over high contrast. If styling directives are displayed properly, users with vision deficiencies can also "just" read the styling directives instead of the styling itself. > Formatted text may also be rendered poorly by screen readers. When applying formatting it may be desirable to include directives to exclude formatting characters from being read. As mentioned above there are false positives in styling directive detection. If those would not be read, users with screen readers would no longer be able to correctly read the message. Also screen readers often lack support for reading styling, thus it also makes sense to read styling directives if it's not a false positive. I'd turn this statement around and change it as such: > it may be desirable to include directives to exclude styling from being read but to ensure that styling directives are read, i.e. "This is *bold*" thus should be read as "This is asterisk bold asterisk". > 3. Do you plan to implement this specification in your code? If not, > why not? Dino currently does not implement quotations (as specified in §5.1.3). Various clients already have different ways in displaying quotations, some are *not* following the recommendation layed out in §6 to display formatting characters. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? Nitpick: In §4 the term "styling directive" is introduced, which is used in §5. In §6 and §7 the term "formatting characters" is used which remains undefined. I believe it's meant to be the same, thus "formatting characters" should be changed to "styling directives" in §6 and §7. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
