On Wed, Mar 27, 2019, at 16:03, Ненахов Андрей wrote: > I'm firmly against imposing limitations such as these on users. They > can always check what website was opened by a browser.
At that point, it's too late. > Also, named hyperlinks are a done deal, it works everywhere. Where's "everywhere"? I'm not aware of many IM clients that allow you to do this. My feelings on this aren't that strong, so a good argument for why it's needed could convince me, but I can't imagine why a user would want to do this over just copy/pasting a URL into the client and letting it be auto linked. Clicking a button, adding a title, etc. just doesn't seem necessary except maybe in very niche use cases. > > For lists I don't really see a point in including markdown. The > > client can still add a lists button and just add "1." or a center > > dot before each item. No need for extra markup. > > Likewise we can use CAPS instead of bold. Who needs those weitghted > fonts? :) That's not the same thing though. The list will presumably look exactly the same (and possibly be seen by the renderer as exactly the same thing) though whether you encode the fact that it's a list in the XML or not. Why bother adding more XML when it's not going to change anything and you can have a plain text version that works everywhere, whether your client supports lists or not? Do you think it's a correct assumption that as a user I won't care whether it was sent with some fancy XML formatting, or whether a bullet character was included in my actual message? If not I'd love to know what benefit it provides to the user. If you do agree with that, what benefit does it provide to client devs to encode the list in the XML? Or does it provide a benefit to someone else? > Not really difficult. We've already made it, and it works great. I'm > not talking, of course, about inserting media in <img> style html > images in random areas of the text. This appears to be what the "begin"/"end" attributes in the references examples you provide do. If you're not talking about this, why bother including it in a markup XEP instead of just attaching it using OOB or similar? I'm not understanding the benefit of coming up with another way to do this (If the benefit you see is just having fewer XEPs, read on for why I disagree, if there's some other benefit I'm missing, I'd love to know what it is). > No,only like what any whatsapp is capable of. However, I don't think > it's beyond our capacity to make a decently looking text even if it > WILL contain images within. If articles on Medium.com can look > decently on both desktop and mobile, I see no reason to claim that it > can't be done. Oh it can be done (obviously, since the web does it), it's just more work and a lot of extra complexity to think about for very little benefit that I can see. I said it was complicated, not impossible :) > Then you obviously missed the point of my proposal: to have a uniform > approach to everything message. The needs of a modern messenger far > exceed the simple 'markup' problem. I'd even say that markup is the > least of modern messenger needs. Your suggestion is to basically stick > to the same disparate patchwork of XEPs that already exists. So far, > results of this approach are less than spectacular. I think it's time > to test a different approach. Yes, I'm disputing the fact that we need one uniform way of encoding all this very different information into XML. Having OOB and styling doesn't seem like a patchwork of XEPs to me, they just seem like two fundamentally different problems, which means they have fundamentally different solutions. I do think we should settle on one way to include media, one way to include styling, and one way to do mentions though. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
