On Mon, 2005-09-12 at 14:53 -0700, Karsten Wade 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. Tammy

On Fri, 2005-09-16 at 13:16 -0400, Tammy Fox wrote: 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/

Uttered Mark Johnson <mjohnson(a)redhat.com&gt;, spake thus: I have tested both <ulink> forms using HTML and FOP. Both forms render correctly. So the choice is ours. I'd recommend using the null content form of <ulink url="http://www.example.com"/> because it is more prone to correct usage. Cheers

Great! So we have consensus: The null content form shall be the recommended practice in the markup guide. Short-term Timeline: -------------------- I'll look over the threads on this list, Brad's post, & the existing guide over next few days and summarize the status on or by October 11th. If I don't identify any outstanding/undiscussed issues, Karsten & I will then proceed to draft a markup policy guide. If I identify any issues that have yet to be raised, I will certainly bring them to the table for discussion. A cursory glance at the Fedora Docs Guide didn't yield any mention of conditionalization (tho I could've missed it). In my summary, then, I'll also make some suggestions for handling conditionalization (for different arches, say), via attribute-based profiling. Have a weekend! Cheers, Mark -- ---------------------------------------------------------- Mark Johnson <mjohnson(a)redhat.com&gt; Engineering Content Services Red Hat, Inc. <http://www.redhat.com> Tel: 919.754.4151 Fax: 919.754.3708 GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242