Howdy I've been following this thread with some interest. For what it's worth, I too think third party URL shorteners are evil, but folks will use them.
On Tue, 29 Sep 2009 14:06:50 -0700 Brion Vibber <[email protected]> wrote: > On Tue, Sep 29, 2009 at 12:55 PM, Craig Andrews > <[email protected]>wrote: > > > > Might this be better to do client-side in the web UI, like for the > > > attachment preview popups? > > > > > That would be easy to do. Would the short url have a tooltip with > > the long url when the user hovers over it? Or should the short url > > be automatically transformed to the long url, in line, on page > > load? Or something else? > > > > Tooltip on hover should be fine for desktop usage; mainly I find I > want to check the target URL before clicking so I've got some idea > what I'm getting into. ;) > > Hover tooltips might not work too well on mobile browsers, though... > of course then you've got the problem that the long URL probably > won't fit on screen, so we can live with that! > It's not just you, Brion, but I think a browser-centric approach will always cause you frustration. Start with the standard and see what it offers. You are talking about the title attribute which happens to render as a tooltip in most graphical browsers. The purpose of the attribute is to provide additional information about a link over and above what the link text does. Its rendering can vary: "Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource:" [1] So when user agents will not support the attribute, that's them not implementing the standard fully. You've done your job by picking the right attribute. The browser is giving users the diminished experience, not you. > > Some browsers like Safari default to not showing a status > bar, so you can't necessarily rely on just sticking the long-form URL > in the <a href> either. > No you can't, or even that the browser has such a thing as a status bar. See above. So I think if the long URL goes anywhere, it's in a title attribute on the link. Now I'll say what I think we really should do. I believe revealing the true endpoint of a link in these cases is actually the job of the user agent or a plug-in. If, as the producer of the content (in a sense), we want to help protect users, we should be helping them in their environments, not in the site. Help connect users with functionality that will help them with other sites, too. Teach them to find their own fish. Explain to users about short URLs and what they might do to minimise risk. That's my idealistic view :) There are one or two Firefox plug-ins alluding to this functionality. I didn't like the look of any enough to try (I'm very discerning). Perhaps someone looking for a project could make a decent one? _If_ we had influence, I would say use it to push browser producers to improve trust around short URLs. I feel sure that one day they will realise that this is valuable, anyway. I hope that made some sense to someone. Cheers [1] http://www.w3.org/TR/html401/struct/global.html#adef-title _______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
