On Thu, Dec 6, 2018, 20:54 Dave Cridland <d...@cridland.net> wrote: > Looks like a problem worth solving, but note below. > > I'd prefer - non blockingly - the following: > > * A click element. I feel that having an id and a click is superior given > the ambiguity of a text string.
An earlier draft had a <click> element, however it was dropped. Not entirely sure who convinced me but here's Matthew Wild: > reason for <body> is simply that the buttons are meant to be > optionally-rendered convenience things > > i.e. they would always have a text equivalent for non-button clients or > people who like typing > > at which point having two ways on the wire to perform the same action is > pretty pointless Anyways, if clicking a button sends an exact string given on the button then there should be no ambiguity? > * The examples should be changed to include a Big Red Button. I think the > worthwhile gag would be funnier this way. Yes! > Blocking: > > * How does this relate, if at all, to Forms? Not. This simple ProtoXEP grew out of an Informat ProtoXEP draft I started on about doing this with dataforms, for which there exists precedent already, eg: https://xmpp.org/extensions/xep-0045.html#requestvoice The general feedback I got about this was that it was ugly complicated overkill. On Thu, Dec 06, 2018 at 09:18:43PM +0000, Ivan Vučica wrote: > Some things: > > - other clients (chatbots) cannot discover capability to show buttons, nor > provide alternate text in case buttons are supported. You provide the alternate text in the `<body>` element. > - how does this interact with XHTML-IM or its replacement(s)? Not. -- Regards, Kim "Zash" Alvefur
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
