On Samstag, 14. Oktober 2017 14:25:59 CEST Goffi wrote: > and thanks for this message. I generally agree (as previously said, I'm not > firmly opposed to a new syntax, but it needs to be specified, with a strict > syntax (rejected if invalid) and extensible, and if possible XML based. > > And I also agree that XHTML-IM should be kept until this syntax is draft > (with possibly a mention at the top that it will be obsoleted in the > future). We also have to check every XEP where XHTML-IM is used (to see if > replacement is fine).
I would be in favour of something XML-based. I’m not sure if the fact that one
definitely has to traverse the tree to map local-names and attributes to their
XHTML equivalents is sufficient to prevent people from letting maliciously
injected XHTML leak into the web view. For example, if we had a paragraph
thing called <para/> and emphasis called <emph/>:
<para>This new markup is <emph>amazing</emph><script xmlns="<xhtml ns>"
type="text/javascript">alert('or is it?');</script></para>
I *think* that it should be sufficient that clients will have to traverse the
tree to make them reject XHTML and other unknown elements and attributes.
(Again, a reference implementation for this might help with that.)
> I just have two remarks:
> > - Pre-formatted text (code), including a way to specify the language (this
> > may make the colorisation of things obsolete, the only use-case I’ve heard
> > so far is syntax-highlighting)
>
> It's not the only one. First a language may not be known by receiving
> client,
I don’t think clients should include color codes by default, but this is
bikeshedding :)
> second color can be used outside of code (for instance sending the
> colorized output of SHELL command). This maybe a niche use case, but still
> I think the ability to use colors is needed.
Right, that makes sense. So in any case, color support is reasonable, but I
agree with Georg that it should be restricted to hues (so that clients can
choose saturation and lightness according to their theme for ideal
readability).
> > - Embedding multimedia content, like images, audio, video (a SIMS-message
> > may be better suited for that)
>
> SIMS is useful to attach media, but for pictures (and maybe video), it is
> useful to specify where in the text it should be rendered.
I tend to agree.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
