Re: [Phpwiki-talk] transform.php

[Jeff D. <da...@da...>]

>I doubt that you will be able to ensure HTML4 compliance.

I'm not sure I understand this comment.  Why not?  Surely it's not impossible.
Whether it's worth the effort or not is (as always) open to debate.

>As far as I have tested out, "correct" markup will produce correct HTML.
>Why deal with stuff like double-intended lists without a single list first? 
>Wrong markup produces wrong HTML - simple enough.

';:' is often used to introduce a "block-indented paragraph", not a "list
item."    There's no reason ';;:' shouldn't produce
a block paragraph with more indentation --- and no reason it should have
to be nested within another list.  (Note that even though it produced
"invalid" HTML, this construct worked, at least with my browser.) Why
not fix things  (especially, since, in this case, the fix was easy) so that
this generates correct HTML?

And I see your point, that if given garbage, one shouldn't worry if one
outputs garbage.   On the other hand, if it's not too hard, why not
output valid garbage?  (Perhaps one could even try to flag the offending
garbage to help the user guess what he did wrong.)

>>(Paragraphs all on one line...)
>I think this is a frequent complaint. Maybe we should deal with this.
>I'm not sure if it's a good idea, but maybe (if modifications are small)
>we could add this as option?

Yes, I think it's simple to implement --- a minor modification to the
current transform code.  (Except maybe for tables  -- I have to think
about that a bit more.)

Just as an aside, I think proliferation of options (particularly one like this
which doesn't really change the functionality of PhpWiki at all) should be
avoided.  Having numerous options makes testing harder and also complicates
wiki-administrations and plug-and-playability.

Another idea (though I think it's more trouble than it's worth) is to
auto-convert the old pages when restoring (from a zip- or serialized- dump)
to a new version of PhpWiki.  Currently, the old-style tab-delimited lists,
and triple-quote bold are unsupported in the 1.3.x branch. This could be a
way to deal with that as well.

>> (I don't see any reason why italicization and boldizization shouldn't be
>> able to span these continuation lines as well.)
>
>Because, "errors" are then contained to one line? The thing I really like abou
> t 
>wiki markup is, that no matter what I (or others!!) do on line 3, line 4 will 
>always be shown as I have meant it to be displayed. Furthermore, currently if 
>there's only one '' in the line, italics won't even be opened. It needs an ope
> n 
>and close tag to be recognized by the regexp.

Yes, but it's a common wiki-idiom to italicize an entire paragraph.  Currently,
the paragraph is supposed to be on one line (though it may span many lines in 
the
textarea display).  I'm just suggesting that if we relax the restriction that
the paragraph must be on one line, we should similarly relax the restriction
for italics.  (The italics markup must still be contained within the paragraph,
but since the paragraph can be split across lines, so can the italicization.)


Just to reiterate a point from the my last message, since I think I've found
a better way to say it:

I think the current transform code generally marks-up the inline and 
block-level
elements in the wrong order.   The block-level markup should be processed 
first,
then the in-line markup should be processed on a block-by-block basis.
 
Jeff