Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

HTML logic/format bug

Quote Reply
HTML logic/format bug
On the COOL page, and I'm sure other pages, I haven't looked, there is a problem with the HTML.

It has to do with the way links are formatted, but the categories are inserted between them.

In order to get even columns, you have to open a <TABLE> before the <%link_results> and your link.html has within it <TR>...</TR> , and then a closing </TABLE> after the <%link_results%>

Because the category names do not follow the rules, they are inserted with a <P>Category... and no closing </P> --- which 2 years ago, was the _preferred_ way, until style sheets, which require a closing tag.

This puts the category name BETWEEN a </TR> and <TR> tag.

But, also the open container <P> with no close container </P>

Any thoughts?

Quote Reply
Re: HTML logic/format bug In reply to
Hi,

I'm not sure I understand? Are you just looking to have the <P> closed properly? If so, it shouldn't be too hard, but I think it is embeded in nph-build.cgi. Is it messing up the style sheets? I think it's the same in Links 2.0 which does pass HTML validation ok.

Cheers,

Alex
Quote Reply
Re: HTML logic/format bug In reply to
Two issues ---

1) Because of the way category names are inserted into the link-list, they are not treated as 'links' and thus fall outside the formatting for the 'links'. In my case, each link is put inside a set of <TR> tags, the category name is put BETWEEN a </TR> and a <TR> tag -- between two _links_ -- and is thus in-valid HTML.

2) the open <P> may pass some HTML validations now, only because prior to CSS, there was a big movement afloat to eliminate the </P> tag as redundant. It's a _CONTAINER_ tag, that was always used as a non-container tag like <BR>. In regular HTML it didn't cause a problem, since all it did was force a larger "break" in the opening formatting. This causes a _lot_ of problems with style sheets which don't like open container tags without closing tags, because they don't know when to stop -- and/or if a <P> is nested, or separate. For CSS this becomes _VERY_ important, and they have no way to figure it out -- parts of the page following may eventually not be displayed, or displayed incorrectly.

If you look at HTML formatted with <P> only, and with <P></P> the formatting is _VERY_ different. The browser knows how to put groups of <P></P> together, but not groups of text separated with just <P>.

Because of this, there is a move afloat to require the </P> as part of the next HTML specification -- ie. enforce this 'laxity' in the previous specification.

In order to remain compatible, all <P> must have a closing </P>

Might as well do it now... rather than try to track down elusive format errors later.