[Standards] Council Minutes 2020-05-27

Sam Whited sam at samwhited.com
Mon Jun 1 17:27:02 UTC 2020


On Mon, Jun 1, 2020, at 12:51, Tedd Sterr wrote:
>  Your view is that some clients may default to not styling, and other
>  clients may default to doing styling, and so the same message viewed
>  on two different clients will render differently. This is also going
>  to happen where some clients support styling and others don't - you
>  can't really fix that.

That's correct, not all clients will implement this, and we can't fix
that. However we can fix problems among clients that choose to implement
this spec. By not allowing remote clients that may or may not support
styling to have an option that may default to different things on
different receiving clients, we at least ensure that on a specific
receiving client messages are displayed the same way regardless of
weather the remote client supports this spec or not.

>  What you're doing is implicitly demanding that all supporting clients
>  MUST default to adding styling, and thus if no hint is provided they
>  will render with styling; if an opt-out is provided then there is no
>  styling; and if an opt-in is provided then they also apply styling -
>  which obviously makes the opt-in somewhat redundant. The opt-in,
>  then, doesn't add complexity, doesn't make it harder to implement,
>  and doesn't make it less consistent, it's just unnecessary.

That's correct.

>  I suppose the only remaining question is whether you can make such
>  demands on all clients. (There is a related question of whether
>  there's any point implementing this if you're not even going to use
>  it by default, but I think that should be a user preference.)

Not on all clients, just on clients that choose to support this spec.
Everyone else can continue to do whatever they want with messages where
users wrote things like *this*. Of course, naturally I hope more
implement this spec so that the ecosystem becomes more consistent :)

—Sam

-- 
Sam Whited


More information about the Standards mailing list