The color markup tag translates its closing tag to </font color>. Is this standards-compliant?

I don't think so... would need to do a test page and check <img src="/forum/images/icons/smile.gif" alt="" /><br /><br />uno momento por favor

No, it isn't:<br /><br />http://validator.w3.org/check?uri=http%3....0+Transitional<br /><br />needs to be plain </font>

So should that be considered a bug?

technically yes, as the current closing tag really isn't compliant to any html standard <img src="/forum/images/icons/wink.gif" alt="" />

Thanks <img src="/forum/images/icons/smile.gif" alt="" />

<blockquote><font class="small">posted by Dave_L:</font><hr /> So should that be considered a bug? <hr /></blockquote><br /><br /><br />Actually that's a "designed flaw"... lol This was the way Rick was able to deal with the new color markup code.<br /><br />Perhaps one can still simply replace the </font color> tags with </font> tags before displaying so that they are compliant?

That sounds like it would work, except that the translation would have to be done every time a post is displayed, which seems inefficient.<br /><br />A couple of other choices:<br /><br />Use the method employed by UBB.classic, where the opening and closing tags are translated with a single regex.<br /><br />Use <!--color--></font> in place of </font color>. I haven't thought this through, so I'm not sure if it would work.

[]<br />Actually that's a "designed flaw"... lol This was the way Rick was able to deal with the new color markup code.<br /><br />Perhaps one can still simply replace the </font color> tags with </font> tags before displaying so that they are compliant? <hr /></blockquote><br /><br />Yes, it should be possible. I've been thinking of adding this to the markuphack since there are even more tags that aren't really xhtml compliant in the same way.

why wouldn't a plain </font> work? You are only closing the opening <font color= tag

That sounds like a better idea to have the html comment in front of the closing font tag, and I don't see why it shouldn't work.

I don't think that would work, because there may be other </font> tags that don't correspond to the color markups. (Unless the UBB.classic method were used.)

Other markup tags also have the </font> tag so the undo_markup function won't be able to distinguish which one is used for the color tag.

<blockquote><font class="small">posted by Gardener:</font><hr /> Other markup tags also have the </font> tag so the undo_markup function won't be able to distinguish which one is used for the color tag.<hr /></blockquote> <br /> <br />undo_markup could easily tell which closing font tags are used for color tags because they are the ones that follow a font tag with a <br />color attribute. I haven't seen the latest markup code but this is the way to do it (with perl): <br /> <br /><pre><font class="small">code:</font><hr> <br />$Body =~ s/\[$lang{'COLOR_RED'}\](.*?)\[\/$lang{'COLOR_RED'}\]/<font color=red>$1<\/font>/ig; # do <br />$Body =~ s/<font color=red>(.*?)<\/font>/\[$lang{'COLOR_RED'}\]$1\[\/$lang{'COLOR_RED'}\]/ig; # undo <br /></pre><hr> <br />

Won't work.<br /><br />Well, it will, but start nesting tags and it will break. That's the reason the start and end font tag is replaced separately and the reason that the </font> has the extra info so that it differs from other </font> tags.

Actually, mod_perl's post describes the method used by UBB.classic that I referred to earlier. Nested tags are handled properly if you loop over the regex replacement operations. Each loop iteration handles one layer of nesting.

Granted, with added code, the code would work. =] Sort of, at least. There would still be problems with extra tags inside the color tag that would also use the </font> right? Because that would match first.

I'm not sure what you mean. Could you provide an example?

More tags than the color-tag could generate the &lt;/font&gt; end tag, and when parsing the color tag those tags would match as well.<br /><br />If these tags were used:<br />[font:courier] [color:red] [size:5] Red courier, size 5 [/size] [/color] [/font]<br /><br />And it would create the following html:<br />&lt;font style="courier"&gt;&lt;font color="red"&gt;&lt;font size="5"&gt; Red courier, size 5 &lt;/font&gt;&lt;/font&gt;&lt;/font&gt;<br /><br />Then the regexp would parse the code like this:<br />[font:courier][color:red][size:5] Red courier, size 5 [/font][/color][/size]<br /><br />Because the regex would match the first occurance of &lt;/font&gt;. In the above example, the tags are just nested wrong, but it could match other code which would break things even worse. Like &lt;/font&gt; which is inside the quote-tag if I'm not mistaken.

That wouldn't happen.<br /><br />The code I use in my font hack for UBB.classic looks like this:<br /><br />my $match = 1;<br />while($match != 0) {<br /> $match = 0;<br /> $match++ if $text =~ s~(<font (.+?)>)(.+?)(</font>)~\[font $2\]$3\[/font\]~is;<br />}<br /><br />Here's how it works:<br /><br />Initially: <font style="courier"><font color="red"><font size="5"> Red courier, size 5 </font></font></font><br /><br />After iteration 1: <font style="courier"><font color="red">[font size="5"] Red courier, size 5 [/font]</font></font><br /><br />After iteration 2: <font style="courier">[font color="red"][font size="5"] Red courier, size 5 [/font][/font]</font><br /><br />After iteration 3: [font style="courier"][font color="red"][font size="5"] Red courier, size 5 [/font][/font][/font]