Re: BBCodeParser (another CVS commit)

I'll go into a bit more detail about the BC breaks, the problem, what I did, and you guys can decide: * One break is for custom list numbering. This simply isn't supported in XHTML 1.1 and CSS 2.0 from what I can tell. So I simply ignore any numbering attributes in the input. Note that the list style is still supported and converted to the proper CSS styles on the fly. It may be doable in CSS 2.1+ or JavaScript, but I haven't been able to find any examples. * Single quotes by default. This is the way it is in the current "stable" package but not in CVS. I personally prefer double quotes, but I couldn't find any reason to switch in the W3C XHTML 1.1 documentation, so I'm reverting back. * HTML is now escaped by default (this is probably the biggest BC break). In the "stable" package there is no html escaping that I can see. This can be handled simply by escaping all input, but I didn't see this documented anywhere, and there were several bugs reported where html wasn't escaped. They must not have seen the documentation that didn't exist. I decided that it wasn't good to have an unwritten rule that required htmlspecialchars() on the input, so I took care of escaping html in a more intelligent manner inside the rendering function. Note that the worst BC problem that happens with HTML escaping is that things are escaped twice. "<" is converted to the code "&amp;lt;" which looks to the viewer like "&lt;" when rendered. * Filter var formats have changed. Two reasons: The old filters did not have enough information to do a good job correcting or even validating XHTML. They had problems with the "<li>txt" -> "<ul><li>txt" correction or the "<ul>txt" -> "<ul><li>txt" correction. They also had problems when tags were deeply nested inside other tags. "<strong><em><strong>" is an error, but you have to check more than one level up or down in the stack. The other reason for the change is that the old vars were simply a string of text. Every time a rule was checked, it had to be parsed first with 0 - 2 explode() calls. This is rather goofy if we can just put the arrays into the var of the filter and have no need to do parsing. The good news for BC is that if these vars are not set, then they are ignored and a default rule is used. This rule is right most of the time, but not always, and may lead to broken XHTML or things being "corrected" that are already valid. I would guess that most people haven't rewritten their filters, so they can just use the provided ones. ~Seth On Oct 19, 2005, at 12:35 AM, Helgi Þormar wrote:

On Wed, 19 Oct 2005 07:21:47 +0200, Arnaud Limbourg wrote:

* I've attempted to maximize BC, but here are the only ways in which BC is broken (to my knowledge):

Hi, If this is the case there will have to be a HTML_BBCodeParser2 package as BC is not allowed. It will be possible to mark BBCodeParser as superceeded by BBCodeParser2 on pear.php.net

Well it's okey to break BC if it was documented in the right way but implemented in the wrong way, thus resulting in wrong output, I've not followed the thread all the way through, but is the case now ? - Helgi --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php