Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Sam Whited]

On Tue, Nov 1, 2016 at 9:25 PM, XMPP Extensions Editor  wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Spoiler messages
>
> Abstract:
>   This specification defines an XMPP protocol extension that provides a
>   method for indicating a message is a spoiler and should be displayed as
>   such.
>
>
> URL: http://xmpp.org/extensions/inbox/spoiler.html

The author has submitted Version 0.0.2 of this protoxep which
addresses some of the concerns raised on this list and it has now been
published. Please use the newest version for future reviews.

Thanks,
Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[SouL]

Thank you very much for the feedback we are receiving about Spoilers.

*Regarding 'xml:lang' values for hints
It is indeed a good idea. We didn't think about and it.

*About RFC 2119 keywords use:
Using as an example «Users SHOULD be able to uncover or hide a spoiler message 
at will, anytime.», when writing this,
we thought about this line as a recommendation for a better UX.
We know everyone would expect this behaviour in a client, but we didn't want 
to «make harder» the implementation (or rather, to not meddle in).
The basic idea was to know there is a message that has to be covered.
The hint attribute or those UX recommendations, are there [more] for a better 
implementation rather than anything else.

Of course, we are very pleased to make any necessary changes to this proposed 
XEP to improve it as much as it can be.


*Nomenclature
We were not sure to use or not «spoiler» as the main word here, because we 
don't know if it is used in formal contexts or how this word is perceived 
outside the "Internet culture".

We didn't want to use «hide» because the message is not a hidden thing, it is 
more like a covered message. 

At the end, we used «spoiler» because it makes easy and fast to understand 
what is the XEP about.

We understand sending big chunks of text is not desirable in an IM context, 
but we also understand not everyone knows or is willing to use services that 
allow you to host big chunks of messages.

As an example, let's say Romeo is subscribed to a digital newspaper and he 
usually sends subscriber's comments from the news to Juliet, which is not 
subscribed, and this way, they create a topic to be discussed.

They could benefit from this XEP having a more visually appealing conversation, 
although those comments are not spoilers at all.

In such cases, it is true it is wrong to call them spoilers, but at the end, 
the behaviour is the same. 

We would be very happy either using «spoiler» (because it is easy to 
understand, etc) or any other word that could describe better this feature.


*Regarding multiple  elements
We are not aware how clients handle multiple  elements, unfortunately, 
but with the current specification, we thought the client would display as 
spoiler the content of the message the user would see.
So, if the user would see a formated text using , the client would put 
inside the spoiler, that content.

If not, the specification will need to be improved in that aspect, definitely.




Thank you very much again for your comments, we are happy to hear and learn 
from them.


Cheers!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Stefan Strigler]

Like



and then



etc...

Greets, Stefan

On Wed, Nov 2, 2016 at 8:40 AM Stefan Strigler 
wrote:

> Couldn't we also support trigger warnings within this context in the same
> way?
>
> On Wed, Nov 2, 2016 at 3:33 AM Lance Stout  wrote:
>
> The  element can be used to display human readable text via
> the `hint` attribute, so it should be noted that multiple 
> elements could be present with different `xml:lang` values.
>
> It might be worth making the hint text the character data of the
>  element instead of an attribute.
>
>
>
> /Lance
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Brian Cully]

> On 1-Nov-2016, at 22:25, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Spoiler messages
> 
> Abstract: 
>  This specification defines an XMPP protocol extension that provides a
>  method for indicating a message is a spoiler and should be displayed as
>  such.
> 
> 
> URL: http://xmpp.org/extensions/inbox/spoiler.html

Useful!

Minor nit I’ll pick: The examples in §2 have incorrect addressing, from 
what I can tell: Example 1 should have ‘to’ set to “jul...@capulet.com 
/balcony”, likewise the ‘from’ in Example 2.

I don’t want to derail this, since I think it’s a useful feature as 
presented, but it occurs to me that the  element is often used in 
various Internet fora as a way to hide images as well. Would it be reasonable 
to, instead of simply containing the text to display, instead embed a separate 
element, a la  and/or ? On a related note, as messages can 
contain multiple  elements, each qualified by a language, it seems to me 
the  tag should support multi-language use as well.

-bjc___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Dave Cridland]

On 2 Nov 2016 02:25, "XMPP Extensions Editor"  wrote:
>
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Spoiler messages
>
> Abstract:
>   This specification defines an XMPP protocol extension that provides
a
>   method for indicating a message is a spoiler and should be
displayed as
>   such.
>
>
> URL: http://xmpp.org/extensions/inbox/spoiler.html
>
> The council will decide in the next two weeks whether to accept this
proposal as an official XEP.
>

I have to say this is very well written. I'm fine with accepting this.

Three comments (very minor):

* There's some uses of RFC 2119 keywords which are not correct, for example
"Users SHOULD be able to [...]", which implies there may be valid reasons
not to let them. There's a few cases where the keywords look like they've
caused serious torture to the phrasing to get in. I accept this latter is
personal taste, but it's usually fine to express absolute requirements as
statements of fact, and reserve the RFC 2119 words for when it might
otherwise be unclear.

* Example 3 should be a complete Shakespeare soliloquy. Perhaps Act 2 Scene
2, "What light through yonder window breaks?" etc. (I'm not *totally*
serious about this.)

* I suspect there are a number of cases where a lengthy message is useful
to keep in context, but would disrupt the flow is sent in full. These are
not spoilers, as such, but ... folded? I'm not sure. You can see examples
of what I'm thinking of by pasting something reasonably large into
Prosody's chatroom. Not that I'm suggesting everyone joins and pastes Act 2
Scene 2's "What light through yonder window breaks" soliloquy in there to
find out. Honest. But if anyone happens to think of a more generic name,
I'd be open to that.

Dave.

> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Stefan Strigler]

Couldn't we also support trigger warnings within this context in the same
way?

On Wed, Nov 2, 2016 at 3:33 AM Lance Stout  wrote:

> The  element can be used to display human readable text via
> the `hint` attribute, so it should be noted that multiple 
> elements could be present with different `xml:lang` values.
>
> It might be worth making the hint text the character data of the
>  element instead of an attribute.
>
>
>
> /Lance
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Lance Stout]

The  element can be used to display human readable text via
the `hint` attribute, so it should be noted that multiple 
elements could be present with different `xml:lang` values.

It might be worth making the hint text the character data of the 
 element instead of an attribute.



/Lance

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___