Or build in a wiki/html-validator in the 'interactive' user interface for authors: show autors html-errors and wiki-code-errros when they press 'preview page'. This way, writers of articles get 'W3C-educated' automatically. One could even consider rejectiing of non-W3C-valid-articles... but that is maybe too strict. Thank for promoting W3C, Tomasz :-), kind regards, Pieter Suurmond Tomasz Wegrzanowski wrote:

On Tue, Jan 21, 2003 at 11:00:28AM +0000, tarquin wrote: This is wrong reasoning. We should allow as much HTML we do now, but make parser understand more of it, so it can fix some mistakes.

On Tue, Jan 21, 2003 at 05:04:54PM +0000, tarquin wrote: * <b> and <i> where parses breaks (happens quite often) * <center> * <tt> * <li><ul><ol> for mixed type nested lists * <br> for breaking lines (<p> is not the same as <br>) * <font> for size/color changes * probably a lot more

Dear Wiki-developers/maintainers, Wouldn't it be the best to ban HTML altogether? It has so may disadvantages. Instead, let's complete the Wiki-syntax for all our formatting-needs... Another thing: what is against a "half paragraph-break" ?? It just a way to subdivide a paragraph. It has been an accepted style in many Dutch texts for decades, why not allow this? I'm not saying it _has_ to be done by "<BR>", on the contrary: we should invent a proper Wiki-markup for a single line-break! Kind regards / sorry for bothering you (I've strong opinions about this), Pieter Suurmond Andre Engels wrote:

Pieter Suurmond wrote: Yup -- stop treating then as HTML to be passed "as is" to the browser -- treat them as wiki tags that must be parsed. <td>s must be closed <br> is deprecated etc

On Wed, Jan 22, 2003 at 03:09:57PM +0100, Pieter Suurmond wrote: I know how to fix table markup issue and it is exactly the opposite way. We should completely forbid </td>, </th> and </tr>. They are just noise and table is completely unambiguous without them. This is also completely correct in HTML, but we may automatically generate closing tags if we want to generate XHTML. This reduces weight of table markup by almost half. (Most tables on Polish Wikipedia are already written this way)

On Mit, 2003-01-22 at 18:18, Pieter Suurmond wrote: Pieter, if you know C/C++, PHP should be a breeze to get into. We could really use experienced developers. Why not give it a try? You can find some useful info in the growing (still underdeveloped) http://meta.wikipedia.org/wiki/How_to_become_a_Wikipedia_hacker on meta. BTW, do we want to build a public tasklist on meta where anyone can pick projects to work on? The SourceForge facilities are seriously underused, and it seems to me like a wiki is best for that kind of stuff. Regards, Erik - always pimpin' for new developers -- FOKUS - Fraunhofer Insitute for Open Communication Systems Project BerliOS - http://www.berlios.de

Wouldn't it be nice if those PHP-scripts http://www.wikipedia.org/wiki/Wikipedia:PHP_script is talking about became edittable via the normal, regular Wikipedia-interface itself!? (Writable by 'staff' only, of course, but at least readable to any visitor.) Is this Wikipedia itself running on some kind of CVS-like system? (Then many people could use regular CVS-software to easily edit pages, and also have their copies ('backups at home') synchronised automatically.) Can I somewhere download a (huge) weekly or monthly tarball of the complete Wilipedia-contents? How much would it actually be? 500MB or 40GB ? Sorry for bothering, Pieter Suurmond

On Wed, Jan 22, 2003 at 06:48:03PM +0100, Pieter Suurmond wrote: All in pure C without even using SQL and HTTP server ? You want to make it slow, not portable, insecure, leak memory, be hard to maintain and extend and to segfault at random or what ? It doesn't seem like a good idea to me.

On Wed, 22 Jan 2003 17:36:07 +0100, Tomasz Wegrzanowski &lt;taw=Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f(a)public.gmane.org&gt; wrote: Except Netscape 4 which will then refuse to display the page at all if there is any nesting of tables! -- Richard Grevers

On Wed, 22 Jan 2003, Pieter Suurmond wrote: Our current parser *tries* to do this (insert end tags where they're missing), but it doesn't do a very good job of it. Anyone who'd like to rewrite it is more than welcome to do so! Please take a look at removeHTMLtags() in OutputPage.html. Once you've finished wiping the tears from your eyes, write up something better. :) If you can integrate it with the rest of the markup parsing, so much the better. As long as we allow use of the HTML tags*, we should take them both with and without end tags. We should ideally produce valid XHTML from *any* given input. If the input is broken, we may not produce what the author intended, but we *must* produce something that will pass a validating parser. *(And if we some day decide not to allow them, we should provide equivalent functionality and, if possible, automatically convert articles to use the newer system at the time the change is made. If automatic conversion is not possible, we should make a conscious effort to fix anything that's broken.) -- brion vibber (brion @ pobox.com)

On Wed, Jan 22, 2003 at 12:45:57PM -0800, Brion Vibber wrote: XHTML is not completely compatible with HTML, so making XHTML default may not be very friendly to some browsers. Does anybody have experience with XHTML websites ? Are all browsers happy about that ?

On Wed, 22 Jan 2003 23:50:08 +0100, Tomasz Wegrzanowski &lt;taw=Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f(a)public.gmane.org&gt; wrote: It all depends on the MIME type you serve it with. See http://www.tntluoma.com/opera/beyond30/2002/10/confessions_of_a_browser_sni… for one description of the trouble you can end up in. THis was also discussed extensively on css-d. -- Richard Grevers

Pieter Suurmond wrote in part: I don't see any problems with <table>, which is self explanatory -- quite unlike <td>, <th> and <tr>! For several possibilities for new symbols (some of which make <table> unnecessary too, some of which don't), see: http://meta.wikipedia.org/wiki/Wiki_markup_tables (Not much happening there lately, but you could start it up again. I for one have it on my watchlist.) -- Toby

Let's not call them "<BR>" any longer, it reminds too much to html. But very sure we will still need single line-breaks here and there. Kind regards, Pieter Erik Moeller wrote:

On Wed, 22 Jan 2003, Magnus Manske wrote: Although also using HTML in this case, I still use a slightly different syntax. What I do is: <table align=right> <tr><td align="center">[[image:xyz.jpg]] <tr><td align="center"> ''Some longer caption, which is wider<br>than the image itself'' </table> And yes, I know it is bad HTML to not close the tr's and td's, but I guess I'm lazy... Andre Engels

Andre Engels wrote: OK, here's an idea: Let's keep the <table>s valid, but expand the wiki syntax for some often reoccurring cases! I'm going to use HTML-style here, but we can do | or \ or {} or whatever: <layout image right> [[image:xyz.jpg]] ''Some longer caption, which is wider<br>than the image itself'' </layout> Which would translate <layout image right> => <table align=right width=1><tr><td align=center> </layout> => </table> (or </td></tr></table>) We could also define that within <layout>, all blank lines are converted into <br>s. Similar for the "current events" on the Main Page: <layout box center> ...stuff... </layout> All this would _not_ eliminate <table> tags from wikipedia, but for every-day stuff, it would do. Things like the PSE or the nucleotide decay table would stay HTML. Comments? Magnus

Erik Moeller wrote: So the sooner the better (ban HTML). Pieter

On Wed, Jan 22, 2003 at 04:39:01PM +0100, Erik Moeller wrote: Breakng existing markup is extremely counter-productive. Please don't do that. It would be very wrong if articles broke just because someone doesn't like HTML.

On Mit, 2003-01-22 at 16:42, tarquin wrote: Yes, that was my original idea, but you have to make this optional, otherwise many layouts would be broken in the transition. Note that many of our image pages contain comments like "found this somewhere", because people treat the image description line on the upload page like the summary line on the edit page. Regards, Erik -- FOKUS - Fraunhofer Insitute for Open Communication Systems Project BerliOS - http://www.berlios.de

tarquin wrote: I'd like to have a longer description on some figures, especially some of my self-drawn diagrams, which are far from self-explaining... :-) So, how about defining the caption as "everything until the first horizontal line (----)"? We could have multiple lines on the description page, horizontal line, then the source and other information that doesn't really belong into the caption. "----" as the first line of the description would inhibit a caption automatically. Magnus

On mer, 2003-01-22 at 07:48, Erik Moeller wrote: As indeed they should, that being the intent of its creation. The copying of the upload note into the image description page on creation was done just to get _something_ in them. A single-line input is unfriendly for long descriptions, and captions are a whole nother matter. Perhaps the upload form needs to be made a little more flexible? -- brion vibber (brion @ pobox.com)

Andre Engels a écrit : About banning HTML and using wiki-like syntax, there is an interesting feature in [ http://phpwiki.sf.net/ phpwiki ] that allow wiki-like tables. the feature look like : | | My column | Other column | first line | value | value | other line | value | ''value'' every line starting with a | is part of a table (I don't thing starting a line with a pipe is something very used for anything that is not that kind of stuff...) if you write : | | My column | Other column | first line |v big value | value | other line | ''value'' You'll have "big value" in a <td> with a colspan=2 ( v mean that you want to extend the cell to the bottom) |vv mean <td colspan='3'> etc. |> mean rowspan=2 |>> mean rowspan=3 etc. I do really like this idea (I use phpwiki at home and at work, and that of tables is very usefull...) The only thing that phpwiki's table don't have is "align='right'" on the whole table (<table align='right'>), but I'm sure it can be done with a good idea (like "|[table: align=right]|" before the first line, or any other idea... The probleme is that it can be slow to render and need a lot of RAM (may be). _________________________________________________________________ "This e-mail is intended for the exclusive use of the individual or entity named above and may constitute information that is priviledged or confidential or otherwise protected from disclosure . Dissemination , distribution , forwarding or copying of this e-mail by anyone other than the intended recipient is prohibited . If you have received this e-mail in error , please notify us and completly delete or destroy any and all electronic or other copies of the original message" _________________________________________________________________

About wiki-tables, I was reading http://meta.wikipedia.org/wiki/Wiki_markup_tables and it seems that what Jocelyn Giraud was mentioning is called "Wookee"-syntax. I mentiod your name Jocelyn, on that meta.wikipedia-page, please remove it (or let me know) if you don't like that. 1: List-style syntax 2: Extended PikiePikie syntax 3: MoinMoin syntax 4: Wookee syntax <--- 5: PikiePikie syntax Seems like Tarquin and Jan Hidders already did a lot of work on this. I personally feel attracted to Wookee (just loved it at first sight, not because of any reasoning or real thinking). Any other opninions? Can someone explain this last remark? I don't see why it (what) needs a lot of CPU and/or memory. Thanks / Kind regards, Pieter Suurmond

I couldn't resist and added a new proposal to http://meta.wikipedia.org/wiki/Wiki_markup_tables Called it "Half-HTML proposal" (working title;-) Syntax is quite simple for simple tables, but allows full HTML attributes if needed, as well as nested tables. Have a look! Magnus

That's great Brion Vibber! Now http://www.wikipedia.org/ is indeed 100% valid. The Dutch site still contains some errors but that's mainly due to things like "оÑ?Ñ?иÑ?">Russkiy</a>" on http://nl.wikipedia.org. I'll try to repair those manually... I've another whish: could a script on the wikiserver do automatic character-to-entity-conversion like?: à --> &agrave; ë --> &euml; Well, I'm only suggesting... Anyhow, thanks for fixing the English front page so very quickly! Pieter Suurmond [Let's promote [the use of] Open Standards like W3C] Brion Vibber wrote: