I've posted before how to change the look of the new and cool areas (avoiding the group by category) "feature".

Some notes about what is where in which files

nph-build.cgi is not the only place that writes out embedded HTML tags around links.html or subcategory.html results.

search.cgi outputs a linked title surrounded by P tags. If you put table formatting in your search-results.html file, you need to make sure that you take that into account, since it can cause crazy formatting errors if the bare P tags are inserted into tables between anything but TD tags.

nph-build.cgi has the print-cat routine, which also outputs formatting HTML. Same for the new page and top-10

page.cgi has the same routines for dynamic builds.

The easiest way to avoid this is to make sure your link.html and subcategory.html files are a stand-alone html block, either inside P or TABLE tags. Sometimes, for advanced formatting, this isn't always the best, and you are tempted to make the entry a ROW (TR tags) or ELEMENT (TD tags) in a larger puzzle. If you do, you need to be aware of all the places extra html is written out.
-- ESPECIALLY where the category names are inserted between link entries!!

What happens, is the P block is inserted between the /TR and TR tags, and MSIE tries to interpret it as floating-blocks of CSS, netscape often dies, and sometimes MSIE will simply ignore the blocks!

It's very strange behaviour for die-hard HTML coders, since it's a quirk in the .css rendering engines and not the HTML so it's not really obvious what is broken or even going on. It's like two element blocks are fighting for the same space, and the P blocks are floated to the top, and the TABLE and TR blocks are kept in order.







------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

Not being an HTML guru, do you have any suggestions for this? Is it worth taking the <p> tags out of things like nph-build.cgi, search.cgi, etc? Almost all of it is used for grouping, so we would need somewhere to define how you want the grouping to work. Maybe an option in the config that could enable/disable it.

Any thoughts?

Cheers,

Alex

<G> I'm not a fan of embedded, hard coded, anything. And the more I play with perl and the use of Hashes to pass dynamic tag=>data structures on the fly, the less I like it

I would really try to pull all the output code out of the source, and into template files, or even a variable array or hash.

That way, using the current layout, there'd be a heading.html that would define the formatting of that section (line). By pulling it out of the code, people won't lose track of the formatting -- and more importantly wouldn't have to edit source code.

So, a call to &load_template (heading.html...)
followed by the calls to &load_template (link.html....)

New, Cool, and Search are the areas that call this form of grouping.

I still vote for an option to group by category or not on each of those pages:


And, of course, a way to return the searches in an order other than score

I guess what I like is the APACHE and ANLOG type of config file, where everything is set in a sometimes massive config file, and the only time you really ever need to go to the source is to do something really, really weird <G>

There's no reason for Links to get _that_ extreme, and it might not even be completely desirable since some flexibility to (easily) change the output is very desireable -- BUT -- anything that can be answered in a YES/NO or override type of situation should be in a config file. It even makes program development easier. Many options are never changed... but if they need to be, it's only in one file, in an easy to find place, and not in the source code.