Re: BBCodeParser (transition to Text_Wiki)
| From: | Seth Price | Date: | Mon, 17 Oct 2005 14:21:00 +0000 |
| Subject: | Re: BBCodeParser (transition to Text_Wiki) | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-40215@lists.php.net to get a copy of this message | ||
I think we are agreeing. I don't like the idea of invalid code passing through to invalid XHTML. Some people lean more towards "throw an error" and other people lean more towards "lets fix it".
I think that I'm more for "lets fix it". But "fixing it" is easier said than done. But there should be some protection against invalid input.
~Seth
On Oct 17, 2005, at 8:30 AM, Ants Aasma wrote:
Chipping in my 2 cents here. I agree with Justin in that the parser/implementation guessing the intention of the user is bad. One solution would be to have the BBCode language rules guessing the intention of the user. As the intention of BBCode is AFAICS make text formatting simpler some simplifications are welcome. Otherwise you just have the equivalent of XHTML with different tag delimiters which is somewhat pointless. (I tend to consider BBCode a result of crappy HTML strippers anyway) The softened rules could simply state that any sequence of [*]...\n tokens make up a string. Or for another example that "[b]some text [i]other text[/b] yet another text[/i]" is the semantical equivalent of "<b>some text <i>other text</i></b><i> yet another text</i>". If such specifing is done rigourosly then invalid BBCode doesn't exist. I think that giving unspecified output on invalid input is a BC problem waiting to happen. Specify that some inputs throw errors and provide tidy-alike methods to clean input automatically or specify the input so that there are no invalid inputs, but please don't silently ignore errors. They *will* come back and haunt you. Ants Aasma --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php