Ingo Schwarze <schwa...@usta.de> wrote: > Yes, i do strongly object.
You make good points, Ingo. Let me see if I can answer your concerns. > I think it is very bad practice to omit the protocol from an URI. > For one thing, it results in invalid URI syntax. I am only talking about the display. When hovering over the link the full URL would be shown. And, of course, the underlying link address would include "https://" as that is necessary for it to even work. Also, I am not suggesting changing the URL in a way that would break the link. In particular, to address the concern someone else had, I don't think groff should ever remove a "www." hostname. For hardcopy, typing what is printed would still go to the same page. For ASCII output, cut-and-paste into a browser also still works. > On top of that, the fact that this week, the web is a monoculture of > https:// neither means that other protocols don't exist nor that > other protocols cannot become used. Like you, I would prefer if writing, especially printed, would be valid decades from now. If someday all URLs begin with ACK!THBBFT!://, the default presumption may change and it would take a historian to know to try https:// instead. So, why doesn't that convince publishers of today to always leave in the protocol? I think the answer is that most URLs are ephemeral and aren't expected to be around ten years from now. > Oh wait, i think i have occasionally seen URIs like rsync:// and > git:// and imaps:// even amid the prevalent monoculture. Existing protocols, like man://, mailto:, and gopher:// are not a problem as I'm not talking about eliding all protocols, just the ones that web browsers default to when a protocol isn't specified. > Besides, the distinction between http:// and https:// can > occasionally be meaningful. Yes, and an author would surely specify the link text on those occasions instead of letting groff come up with a good default. It is simply a matter of specifying both the URL (the underlying link) and the link text (which is what is to be displayed). .URL https://foo.bar.com/fred/juki/ https://foo.bar.com/fred/juki/ > And finally, the omission of the protocol can - depending on the > context - cause confusion because it removes an obvious indicator > that the thing printed is a URI in the first place, an indicator > that the document author may have relied on. I also wondered whether people might get confused, particularly if a document tells them to go to an unusual domain like "jit.si". However, the WWW package (or, at least, my version), does distinguish URLs from plain text by color (PDF) or underlining (nroff). For documents processed with groff -c, italics are used. > I hate the malpractice of omitting the protocol even in browser > software (e.g. in the address bar and in similar places). It treats > the users as stupid animals who cannot understand proper URI syntax. > It is insulting. I'm sorry, but I don't see the same problems you do, Ingo. But, even if I am wrong — as I often am — is solving those problems in groff's domain as a typesetting program? Shouldn't groff follow common conventions in the industry? > You propose to break the rendering of existing documents for > absolutely no benefit: authors who want to join the malpractice > of omitting the protocol are already perfectly free to do so by > writing: > > .URL foo.bar.com/fred/juki Actually, no. The first argument is the URL and so it must be specified with the protocol in order for the link to function. You might be correct if you said that they could do this: .URL https://foo.bar.com/fred/juki/ foo.bar.com/fred/juki/ However, since shortening a URL as much as possible may be a common case in publishing, it is worth considering whether it should be the default. Personally, it'd save me time as an author if groff did the work for me instead of me having to shorten each URL by hand. Unlike some of the people on this list, though, I am no expert on publishing standards. That is why I am asking what everyone thinks. As for breaking existing documents... that's one of the things I was hoping people would be able to show me. Are there actually any existing documents where the author's intent requires the protocol be shown *and* they didn't specify exactly what they wanted displayed using a second argument? > Consequently, we have to assume that those who provided syntactically > correct URIs in their documents did so... on purpose. I think my biggest mistake was giving the impression that I was suggesting changing what an author has requested be printed. That is not the case. My question was only about what default makes the most sense if the author omits the link text and leaves it up to groff to "do the right thing" with a bare URL. Some publishers are making URLs shorter by removing the protocol and, personally, I find it more readable. If that is the typical desire of authors and publishers, then perhaps it should also be what is most simple and convenient in groff. I hope I addressed all of your concerns, Ingo. What do other people think? How often do you want URLs to display as www.website.tld and how often, https://www.website.tld? My bias is strongly towards the former, but I'm asking out of ignorance, not because I want a specific answer. —b9 P.S. I just realized that T. Kurt Bond may have thought that Steve was talking about lopping off the "www". I believe what Steve was saying was, https://www.website.tld → www.website.tld not www.website.tld → website.tld P.P.S. Nate: Good tip. I think MANWIDTH=66 may be even more readable. I wish 'groff -mandoc -Tpdf' used two columns (whenever it wouldn't cause bad hyphenation or interword spacing.) ____ Addendum: "+1 (212) PEnnsylvania Six-Five Thousand!" Hmmm.... somehow not as catchy. ;-)