[ewiki] Re: make PageIndex core feature?
- From: Mario Salzer <mario@xxxxxxxxxxxxx>
- To: ewiki@xxxxxxxxxxxxx
- Date: Tue, 15 Jun 2004 03:36:21 +0200
> > > Any other ideas on what to integrate fully into the core script?
> > > Following come to mind:
> > > - markup/css
> >Having css markup core would let me have css classes end at the end of
> >list elements, please make this core.
>
> Hello - I'm new to using ewiki; have it installed and working within a
> WordPress weblog setting. It integrates nicely. Here is the URI if you
> wish to look:
>
> http://blog.openartifact.org (click on the "wiki" link to view ewiki output).
Hey Randy,
Pretty nice. But I'd like to note, that ewiki is not UTF-8 aware
as of yet. The regexs are likely to be broken (but Latin-1 characters
didn't work with any other engine anyway).
So you should at least run GNU recode over the core script:
" recode L1..UTF8 ewiki.php " (on cmdline)
>
> I recommend making CSS markup core, as well as XHTML compliant
> markup. I've been going through the core and the plugins I am using and
> trying to get the output XHTML compliant, as I have time. (I only
> implemented ewiki about a week ago.)
>
> CSS and XHTML are extremely important to many web developers and weblog
> users today, so any improvement there would help ewiki get better
> recognition. There is a lot of interest in wikis now, and ewiki's tight
> integration into existing platforms is unique!
XHTML is very difficult, especially for Wikis. That's mainly because
users may always inject invalid markup (even if it is the "safe" Wiki
markup) like ''__text''__ which will result in invalidly nested tags
then. The "plugins/filter/f_fixhtml.php" extension can work around
a few, but this does never guarantee 100% valid XHTML code.
(also see the EWIKI_XHTML setting! - ok, not too impressive still)
We've taken great care to make ewiki return valid html (magnitudes better
than with other engines), but this is currently not possible. Though
there are other Wikis that can produce valid XHTML Strict. CoWiki can,
because it stores pages already in XML, AtomWiki and Rhizome probably
also can do this much better right now.
For example the <br> tags (and others) aren't already converted to
xhtml, because I've personally using some browsers, that didn't like
"<br />" all too much until recently.
So concluding I'd say, that ewiki itself cannot be made XHTML compliant
overnight, and therefore filtering the output through libtidy (its now
a standard extension in PHP?) is a much more reliable (and faster)
solution. Extending f_fixhtml wasn't probably as useful as it'd only
got slower.
(To get quick XHTML adoption throughout the Web it is essential to
have a mod_xhtml or mod_tidy distributed with Apache. Won't happen
otherwhise IMO; but that's again a different topic)
mario
Other related posts:
