good <ulink> practice

Karsten Wade kwade at redhat.com
Fri Sep 16 20:48:02 UTC 2005


On Fri, 2005-09-16 at 13:16 -0400, Tammy Fox wrote:

> Lost in what sense? When it is printed? If so, the way we work around
> this for the magazine is to have a print CSS that prints the URL in
> parentheses after the link. Thus, you get the best of both worlds--nice
> readable links in web format and printed URLs for printouts.

We're not (yet) using a print CSS for Fedora docs, but that is
regardless.  For most of the world, print = PS/PDF.  I'm not interested
in telling them that HTML + CSS is good enough, partially because I
don't necessarily agree with that. :)

The recursive <ulink> style[1] came about because of broken tools in
making PS/PDF output.  If this is no longer broken, that is one argument
against the recursive usage.

Sometimes I think it's cleaner to use a direct URL inline.  It's
becoming a way we speak and write, that links are visible and have
semantic meaning.  This is what a Wiki does.  I think it is a mistake to
hide the WikiName behind "some Wiki thing" link text.

For example, it has meaning to think of Docs/Beats/DevelTools/GCC and
that full path.  It teaches the reader how to find information.  Hiding
the path behind a link takes that how-to find information away from the
reader and in the control of the author.

To convert this into a rule around ulink, how does this sound?

A. Until you can _prove_ that your PDF output is working, you must use
the recursive <ulink url="foo"/> style.

B. You may use that style whenever it brings more semantic meaning to
the discussion.

C. You may use a hiding-URL style <ulink url="foo">like this</ulink>
whenever you want, as long as PDF output is working.

The problem here is the FOP, if any at all, right?

I don't think I have anything that builds I can test with. :)

- Karsten
[1] <ulink url="http://foo"/>
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20050916/75b2fb49/attachment.bin 


More information about the docs mailing list