> I'll look further at your example. I don't understand what the color
> code is doing (it seems to be causing some odd effects in my docs,
> too), and I'm currently debugging it.
So here's the bug -- and it isn't just about color. It's about HTML
elements, and their semantics. In particular, see section 3.2.1 of
the HTML 4 spec: ``rules governing elements (e.g., they must be
properly nested, an end tag closes, back to the matching start tag,
all unclosed intervening start tags with omitted end tags''...
This means, for instance, that if you have the construct
<p>This is <font color="red"> line 1
<p>and this is line 2</font>whoa boy!
the second line will quite properly not contain any red text, because
the second <p> tag contains an implicit end tag for the first <p> tag,
and that closes ``all unclosed intervening start tags with omitted end
tags'', i.e. <font>. The </font> is just broken HTML.
Or, if you take
<p>This is <i>in italics, but
<p>this is not.</i>
there shouldn't be any italic text in the second paragraph.
But the Python 1 simple-minded SGML parser doesn't seem to be calling
either "end paragraph" or "end italic" at the beginning of the first
paragraph. Then, when it gets to the </i> in the second paragraph, it
figures the <p> is an unclosed intervening start tag, and so it calls
"end paragraph" before calling "end italic", which results in an odd
appearance.
In fact, it's probably potentially broken on all the common elements
where the end tag is optional within a given block level: P, LI, TR,
TD, DT, and DD.
I'll do something about that after we release 1.2.
Bill
