Sean M. Burke wrote: > At 12:20 2002-04-07 +0800, Stas Bekman wrote: > >>> I'm worried that the non-hypertext renderings of such Pod would be >>> even worse. >> >> Please explain how would it be worse? > > > Well, one way is by not showing the URL at all. > And if we go the other way and plaintext-render it as "linktext > (<scheme:...>)", then I worry that people writing Pod and seeing just > its HTML renderings may not sufficiently appreciate the visual "cost" of > a hyperlink in different media, whereas this is always quite apparent > with L<scheme:...> links -- since they basically come out the same > length in all media.
I doubt that rendering 'text (uri)' will be a problem. Also notice that human brain will most likely learn fast to skip the '(uri)' part and it'll be still there when you need it. >> Huh? Various resources have various URL lengths. You want another >> shorter example? >> http://example.com/news.html?item_32894_43ER_54&where_4358asdf08 >> This example comes to show that lots of URLs are very meaningless and >> shouldn't be displayed as is even if they short. > > > Except in plaintext renderings? > > I don't doubt that such long links exist. I'm curious whether they're a > common problem tho. (Note the two parts: common, and problem.) > Recall that Pod is not everything for everyone -- it's the 80/20 rule as > applied to markup. And moreover, no-one will go blind from seeing long > URLs. (Not that blindness-prevention is my /only/ criterion in > considering what is good for Pod.) I think the main argument is that URIs are not designed for human consumption, even if it's a good idea to make them so. Thefore if you are into a publishing for human consumption, it's unacceptable to use URIs as titles, even if for certain nice URIs it is acceptable. I use POD to write a book. I had to extend POD to accoplish this simple requirement that we discuss. I use POD for writing a lot of other documents, using extended POD tools, so unless users use the generated by me HTML/PDFs, they cannot use source pods using standard tools, which sucks. So may be we stop wasting people's time developing their own solutions unusable outside of their projects and provide a solution to this well defined and understood problem. Currently perlpodspec (and therefore the tools derived from it) doesn't provide a solution for this problem. Since this discussion always had the same end: NO to L<text|uri>, I came with a new sequence, to circumvent the broken record experience. Unless you have a technical argument against adding this new sequence lets put it in, adjust the parsers, converters and move on spending our time on other productive things. __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
