UBB.Developers Forums UBB.threads 6 V6 Modifications Templates </font color>

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

uno momento por favor

No, it isn't:

http://validator.w3.org/check?uri=h...ly%29&doctype=XHTML+1.0+Transitional

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

Thanks

posted by Dave_L:

---

So should that be considered a bug?

---

Actually that's a "designed flaw"... lol This was the way Rick was able to deal with the new color markup code.

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.

A couple of other choices:

Use the method employed by UBB.classic, where the opening and closing tags are translated with a single regex.

Use <!--color--></font> in place of </font color>. I haven't thought this through, so I'm not sure if it would work.

[]
Actually that's a "designed flaw"... lol This was the way Rick was able to deal with the new color markup code.

Perhaps one can still simply replace the </font color> tags with </font> tags before displaying so that they are compliant?

---

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.

posted by Gardener:

---

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.

---

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
color attribute. I haven't seen the latest markup code but this is the way to do it (with perl):

code:
 
$Body =~ s/\[$lang{'COLOR_RED'}\](.*?)\[\/$lang{'COLOR_RED'}\]/<font color=red>$1<\/font>/ig; # do 
$Body =~ s/<font color=red>(.*?)<\/font>/\[$lang{'COLOR_RED'}\]$1\[\/$lang{'COLOR_RED'}\]/ig; # undo 

---

Won't work.

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 </font> end tag, and when parsing the color tag those tags would match as well.

If these tags were used:
[font:courier] Red courier, size 5 [/font]

And it would create the following html:
<font style="courier"><font color="red"><font size="5"> Red courier, size 5 </font></font></font>

Then the regexp would parse the code like this:
[font:courier] Red courier, size 5 [/font]

Because the regex would match the first occurance of </font>. In the above example, the tags are just nested wrong, but it could match other code which would break things even worse. Like </font> which is inside the quote-tag if I'm not mistaken.

That wouldn't happen.

The code I use in my font hack for UBB.classic looks like this:

my $match = 1;
while($match != 0) {
$match = 0;
$match++ if $text =~ s~(<font (.+?)>)(.+?)(</font>)~\[font $2\]$3\[/font\]~is;
}

Here's how it works:

Initially: <font style="courier"><font color="red"><font size="5"> Red courier, size 5 </font></font></font>

After iteration 1: <font style="courier"><font color="red">[font size="5"] Red courier, size 5 [/font]</font></font>

After iteration 2: <font style="courier">[font color="red"][font size="5"] Red courier, size 5 [/font][/font]</font>

After iteration 3: [font style="courier"][font color="red"][font size="5"] Red courier, size 5 [/font][/font][/font]

I still can't see how the regex can now which font closing tag it should parse?

Maybe my example was a bad one, since you could merge them into one markup tag like you have. But that wasn't the point. The point being that if different markups both have the </font> the regex will have no way of knowing which one is the one that it should match to. Some amazing things can be done with regexes, but magic isn't one of them. =]

Testing your code shows that the following happens:
Initially:
<font style="courier"><font color="red"><font size="5"> Red courier, size 5 </font></font></font>

After iteration 1:
[font style="courier"]<font color="red"><font size="5"> Red courier, size 5 [/font]</font></font>

After iteration 2:
[font style="courier"][font color="red"]<font size="5"> Red courier, size 5 [/font][/font]</font>

After iteration 3:
[font style="courier"][font color="red"][font size="5"] Red courier, size 5 [/font][/font][/font]

In this case it doesn't matter that much of course, but it shows that the replace is done with the first possible match. If the </font> tag is part of something else, it will break, and it could potentially screw up the nesting as well.

Hmmmmmm, you're right, that code does behave as you describe.

I did some fairly complex tests for that hack, and couldn't break it, but maybe I didn't find the right test case.

Pages that display posts, such as showflat.php could have the </font color> tag converted to </font> to remain standards compliant.

Just prior to this:

$postrow[$i]['Body'] = $Body;

You could use this:

$Body = str_replace("</font color>","</font>",$Body);

Then the browser would recieve compliant code for viewing and custom tags could remain for editing and other such purposes.


Am I missing something with all of this? I think I'm understanding that the main goal is to have the html that is displayed be standards compliant. How the html is handled on the backend prior to display shouldn't make a difference. (IMHO)

I'd prefer to use <!--color--></font> instead of </font color>. I think it's simpler to make the posts that are stored in the database correct HTML. Then you don't have to worry about special conversions whenever you want to display them.

That's what we've all said as well, but then we went on about discussing if we could have the non-compliant html removed completely.

It would be nice to not have to do that extra replace for the color tag (and the others that I have in the markuphack), but it works.

True, it would be nice if the correct html was in the database as well. And the html comment should work perfectly OK.

Here's the code for this if anyone wants it, do the following in ubbt.inc.php:
Find this line:

code:

          $matches[0][$i] = preg_replace("/\[\/{$ubbt_lang['COLOR']}\]/","</font color>",$matches[0][$i]);

---

Change it to this:

code:

          $matches[0][$i] = preg_replace("/\[\/{$ubbt_lang['COLOR']}\]/","<!-- color --></font>",$matches[0][$i]);

---

Find this line:

code:

       $Body = preg_replace("/\[\/{$ubbt_lang['COLOR']}\]/","</font color>",$Body);

---

Change it to this:

code:

       $Body = preg_replace("/\[\/{$ubbt_lang['COLOR']}\]/","<!-- color --></font>",$Body);

---

Find this line:

code:

       $Body = preg_replace("/<\/font color>/i","[/{$ubbt_lang['COLOR']}]",$Body);

---

And change it to this:

code:

       $Body = preg_replace("/<!-- color --><\/font>/i","[/{$ubbt_lang['COLOR']}]",$Body);

---

But after this is done, the color markup won't be parsed correctly when changing posts done with the old way. But I guess it should work by adding the given lines instead of replacing the old line, that way even old posts should be parsed correctly during editing. Haven't tested it though.

Not meaning to be too picky, but before this gets "standardized", do you think <!--color--> (no spaces) would be better than <!-- color -->?

Don't know, I always have a space before/after the --, I think some ancient browser broke if this wasn't the case. Not sure though, but I just do it by habit, removing the spaces should probably be OK and might be better for the parsing.

Also, only the code in the undo_markup should be added instead of replaced. Thus making sure that old posts are editable (is that a word? =]), but all new posts use the new markup.

I don't mind being wrong when it sparks such a useful discussion.

I solved this problem by disabling color markup since it clashes with stylesheets, and discourages those who like to distinguish themselves by posting in all violet text. Crude but effective.

That's one way of fixing the problem of course. =] If my users would start setting the color of all the text in their posts and change font styles etc I would definetely remove the function. But at the moment it's only used in signatures, or to highlight some small bits of text. But before I'd remove it completely I'd try to convince users that are overusing those markups to stop.