LDC wrote:
http://www.piclab.com/cgi-bin/wiki.pl?Wikipedia_Text_Syntax
So as I said, this is a vision. I invite comment and criticism. But I think it's important to Wikipedia's future that we do a good job of this.
I agree - but when you said "ALL HTML is forbidden" I went ahead and looked at the table specification part of your document and saw some things that seem rather Spartan to me. For example, the document doesn't indicate whether or not nested tables would be allowed and it doesn't seem to say how one would do bgcolor-type cell fills, or how to set border width.
If those things cannot be replicated in wikicode then all the already-converted elements, country, ship, organism and battle tables would be broken (not to mention the main pages of fr.wiki, ja.wiki, eo.wiki and others - including a partially crippled en.wiki Main Page) . This would be a very bad thing and I for one would be not be too happy if much of the work I've done with the Elements project over the past year is destroyed (not to mention the several other WikiProjects I helped nurture).
So if the table at http://www.wikipedia.org/wiki/Beryllium cannot be replicated pretty much as-is in wikicode then I for will have a fit (I'm sure many others will join me).
Also; if all HTML is going to be 'forbidden' then what do we do with all the HTML we already have? Fire-up the Conversion Script again perhaps (just when I was about to pass the damn thing on the Most Active Wikipedian's page! ;).
An alternative solution is to only allow HTML syntax to be rendered if it is in a table:namespace page. So the HTML table code in [[Beryllium]] could be placed at http://www.wikipedia.org/wiki/Table:Beryllium and in the Beryllium article that table can be displayed by typing [[table:Beryllium]] (much like the image:namespace now works). Your more simple table wikicode could then be used for less complex and shorter tables.
That way the dense table code now in [[Beryllium]] won't be in the way of users who are only concerned about editing the prose of the article (even a wikicode table would be dense and intimidating to many people).
A more long-term solution is to have a WYSIWYG GUI - then grandma can edit even a very complex table by clicking inside the cell she wants to write in.
Please forgive me if these things are already explained somewhere in the document - I only had time to glance at a few sections.
-- Daniel Mayer (aka mav)
I agree - but when you said "ALL HTML is forbidden" I went ahead and looked at the table specification part of your document and saw some things that seem rather Spartan to me. For example, the document doesn't indicate whether or not nested tables would be allowed and it doesn't seem to say how one would do bgcolor-type cell fills, or how to set border width.
There's no provision for nested tables. I don't think there's a good enough case for their necessity. Cell backgrounds and borders can be done with styles.
So if the table at http://www.wikipedia.org/wiki/Beryllium cannot be replicated pretty much as-is in wikicode then I for will have a fit (I'm sure many others will join me).
Yeah, that nested table is a nuisance. I'll have to think about that.
An alternative solution is to only allow HTML syntax to be rendered if it is in a table:namespace page.
As I said before, I want to eliminate the complexity, not just move it around. I want newbies to have some chance of being to edit the table as well as the prose around it.
So if the table at http://www.wikipedia.org/wiki/Beryllium cannot be replicated pretty much as-is in wikicode then I for will have a fit (I'm sure many others will join me).
Just joining
Yeah, that nested table is a nuisance. I'll have to think about that.
Its not a nuisance, it's an advanced feature of HTML
An alternative solution is to only allow HTML syntax to be rendered if it is in a table:namespace page.
As I said before, I want to eliminate the complexity, not just move it around. I want newbies to have some chance of being to edit the table as well as the prose around it.
A Table - and especially a table with complex structure, nesting etc - *IS* a complex thing. You will not be able to eliminate that complexity. As soon as you are trying to do it, you will greatly reduce the flexibility. As soon as you add that flexibility again, you add the complexity again. So why re-invent the wheel by having (in the end) the same problems in just another markup language?
I strongly support the table:namespace concept: It offers all the the HTML flexibility you need, and you keep the article source clean of the table code.
If we can have the table syntax proposed additionally, thats just fine: A newbie will start with a simple table, as soon as it gets more complex, an experienced user can move it into a full-fetaured html-table in the new namespace and link it from the article.
Uli
(Ulrich Fuchs mail@ulrich-fuchs.de):
Yeah, that nested table is a nuisance. I'll have to think about that.
Its not a nuisance, it's an advanced feature of HTML
WIKIPEDIA IS NOT HTML. Wikipedia is a collection of free encyclopedic content, currently being delivered to users by the technology available to us at the time, which happens to be HTML. Wikipedia's content should be described in unambiguous ways that preserve the content and structure of documents, and that can be rendered readably and edited easily. HTML fails to meet at least some of those criteria (notably ease of editing).
A Table - and especially a table with complex structure, nesting etc - *IS* a complex thing. You will not be able to eliminate that complexity. As soon as you are trying to do it, you will greatly reduce the flexibility. As soon as you add that flexibility again, you add the complexity again. So why re-invent the wheel by having (in the end) the same problems in just another markup language?
Believe me, I won't let that happen. I have no interest in translating the complexity into a different language just for the hell of it either. If I can't make it simpler, I won't change it.
Yes, I think we might have to give up some "flexibility", if it's only the flexibility to do things that don't really improve the user experience. Tables in general are important: they organize information neatly and ease comparisons of similar things. But I'm not at all convinced that nested tables are of any use other than to show off coding skills.
I strongly support the table:namespace concept: It offers all the the HTML flexibility you need, and you keep the article source clean of the table code.
The contents of the table IS IN THE ARTICLE, whether you hide it off in another page or not. The tables are part of Wikipedia's content, and if they aren't easily editable, they aren't useful.
That said, I'm still open to the idea of transclusion in general: that is, having pages whose whole contents are included into a referencing page. That would allow us not only to separate things like tables, but also things like boilerplate text. A syntax like [[include:xxx]] could be used. That would also get us nested tables (and it might also be a performance nightmare!)
If we can have the table syntax proposed additionally, thats just fine: A newbie will start with a simple table, as soon as it gets more complex, an experienced user can move it into a full-fetaured html-table in the new namespace and link it from the article.
I don't like that idea much either.
Lee-
WIKIPEDIA IS NOT HTML. Wikipedia is a collection of free encyclopedic content, currently being delivered to users by the technology available to us at the time, which happens to be HTML. Wikipedia's content should be described in unambiguous ways that preserve the content and structure of documents, and that can be rendered readably and edited easily. HTML fails to meet at least some of those criteria (notably ease of editing).
True. But I agree with Uli that the flexibility of HTML tables is important. I also do not think the proposed {{style}} syntax really makes things easier. Case in point: I did not really understand it before reading it a second time. I think the idea of weak attachments, e.g. {{red}}foo, is a counter-intuitive one. On the other hand, the HTML-style <math> tag is in wide use on Wikipedia -- people seem to grasp it easily.
I think having styles usable with a <foo></foo> syntax is perfectly acceptable. Those who do know HTML will find it immediately easy to use, and those who do not know only have to learn one thing: <xy> starts something, </xy> ends something. I think that's more than simple enough, whereas the "What does {{xy}} refer to" question raised by your syntax is more complex. And it has the additional disadvantage that those who do not know HTML have to learn an entirely new syntax. Also, {{}} looks ugly, code-ish.
I think retaining HTML tables within their namespace, while ignoring all HTML outside of it would be the best solution. I know what you think: It would be cleanest to get rid of all HTML. But consider this case more like having TeX or SVG support. We want to support existing markup languages where they provide us with better results than hacking our own. We can view HTML-tables as one such markup language, even if they are only a subset of one.
The table namespace does not necessarily have to be a real namespace whose contents would be transcluded (eat your heart out, Ted Nelson), it would also be possible to use a syntax like
[[Table:Periodic table]] <table>... </table>
Where the table is hidden in the editable wikitext (user option), and a small "edit" link is added at the bottom of the table in the rendered HTML. No impact on server performance, no silly "Table talk" namespace, but the same effect. Existing tables could be converted easily simply by adding a [[table:name]] link at the top.
Regards,
Erik
On Thu, May 15, 2003 at 01:08:18PM -0500, Lee Daniel Crocker wrote:
The contents of the table IS IN THE ARTICLE, whether you hide it off in another page or not. The tables are part of Wikipedia's content, and if they aren't easily editable, they aren't useful.
That said, I'm still open to the idea of transclusion in general: that is, having pages whose whole contents are included into a referencing page. That would allow us not only to separate things like tables, but also things like boilerplate text. A syntax like [[include:xxx]] could be used. That would also get us nested tables (and it might also be a performance nightmare!)
We discussed this on #wikipedia some days ago. There would be another namespace for HTML-Snipplets. Those snipplets can contain variables, e.g. enclosed by %%. A snipplet might be a piece of code to include an image with a label, it might be a table, or a boilerplate text. The snipplet ImageFloatingRight might perhaps look like this:
<div style="float: right"> [[Image:%%Image%%]]<BR> <center> ''%%Label%%'' </center> </div>
In an article, it can be used by its name:
{{ImageFloatingRight Image=Eiffel tower.jpg Label=The Eiffel Tower in Paris }}
A Countrybox might start like this: {{CountryFactBox Flag=usa.png Motto=In God We Trust Capital=Washington D.C. ... }}
This is more flexible than just stylesheets: - More features of HTML can be used. - More users can edit the HTML snipplets than edit the CVS-based stylesheets. - It's easier to edit than having various stylesheet elements in the text. - Layout and Content are strictly divided.
Possible later additions: - Factsheet wizard that users without HTML-Skills can use to generate the normal factsheet tables used in so many variants - Fill-in wizard that shows the rendered snipplet and has input fields where the variables are.
Regards,
jens
(Jens Frank JeLuF@gmx.de):
<div style="float: right"> [[Image:%%Image%%]]<BR> <center> ''%%Label%%'' </center> </div>
In an article, it can be used by its name:
{{ImageFloatingRight Image=Eiffel tower.jpg Label=The Eiffel Tower in Paris }}
That's about 10 times more complex than
{{floatright}}[[image:usa.png]]
but I am intrigued by the idea of parameterized transclusions. Another, perhaps simpler, way to do it is to use existing link syntax with an "include" namespace:
[[include:snippet1 | val1 | val2 | namedvar1=val | namedvar2=val]]
This is more flexible than just stylesheets:
Then you obviously don't know stylesheets well. Besides, they give a much better separation of content and style, and are a performance boost because the style code doesn't change among pages often, and so doesn't have to be reloaded by the client.
Possible later additions:
- Factsheet wizard that users without HTML-Skills can use to generate the normal factsheet tables used in so many variants
- Fill-in wizard that shows the rendered snipplet and has input fields where the variables are.
I'm not opposed to the ideas of GUIs in general either; but there's a lot to be said for a content model and text-based interface simple and universal enough to not require one.
On Fri, May 16, 2003 at 03:04:45AM -0500, Lee Daniel Crocker wrote:
(Jens Frank JeLuF@gmx.de):
<div style="float: right"> [[Image:%%Image%%]]<BR> <center> ''%%Label%%'' </center> </div>
In an article, it can be used by its name:
{{ImageFloatingRight Image=Eiffel tower.jpg Label=The Eiffel Tower in Paris }}
That's about 10 times more complex than
{{floatright}}[[image:usa.png]]
Where is the label below the image? Sure it's easier to generate just an image to the left than also adding a label beneath it.
but I am intrigued by the idea of parameterized transclusions. Another, perhaps simpler, way to do it is to use existing link syntax with an "include" namespace:
[[include:snippet1 | val1 | val2 | namedvar1=val | namedvar2=val]]
Not sure about syntax yet. Just developing the idea of parameterization. I would prefer something spanning multiple lines. Some tables for example are rather long, having all fields in a single row would look
This is more flexible than just stylesheets:
Then you obviously don't know stylesheets well. Besides, they give a much better separation of content and style, and are a performance boost because the style code doesn't change among pages often, and so doesn't have to be reloaded by the client.
You've cut the reasons I provided. I know a little about stylesheets I think. You are right: Includes will cost CPU power. This probably is the biggest open issue. The flexibility we get by "parameterized transclusions" are more than we can reach by stylesheets alone.
- We are not limited to the options provided by the developers I do not believe it might be useful to have the style sheet editable. Looking at all the different colours used by the element table or the taxoboxes, I assume we would have a bottleneck: Developers adding colour by colour to the stylesheet. - Some time ago Karl proposed to use definition lists instead of tables. This for example would be rather hard to realize using stylesheets. Changing a few snippets is a little work, but manageable. - Some report generator languages have means to indicate that a block has to be repeated for every dataset:
Snippet:
<table> ... <TR><TH>Isotope</TH><TH>Decay Product</TH></TR> %#REPEAT#% <TR><TD>%%Isotope%%</TD><TD>%%Decay Product</TD></TR> %#END REPEAT#% </table>
The code inside of the %#REPEAT#% - %#END REPEAT#% block is repeated, e.g. by numbering the variables:
[[include:ElementBox ... Isotope1=Be^9 Decay1=C^7 Isotope2=Be^10 Decay2=Cl^6 ]]
This would solve the nested-tables-issue. The tables can be nested using all the power HTML provides. The details are hidden from the user of the table.
Those snippets should be supported by the stylesheet, e.g. to define table backgrounds depending on the skin used.
Possible later additions:
- Factsheet wizard that users without HTML-Skills can use to generate the normal factsheet tables used in so many variants
- Fill-in wizard that shows the rendered snippet and has input fields where the variables are.
I'm not opposed to the ideas of GUIs in general either; but there's a lot to be said for a content model and text-based interface simple and universal enough to not require one.
OK, the later should not be necessary when the syntax is done "right". The former might perhaps be interesting. On the other hand, the most needed tables would be created very fast. The REPEAT-Syntax would allow the creation of some simple tables covering a wide range of applications.
Regards,
JeLuF
--- Jens Frank JeLuF@gmx.de wrote:
There would be another namespace for HTML-Snipplets. Those snipplets can contain variables, e.g. enclosed by %%. A snipplet might be a piece of code to include an image with a label, it might be a table, or a boilerplate text.
The snipplet ImageFloatingRight might perhaps look like this:
<div style="float: right"> [[Image:%%Image%%]]<BR> <center> ''%%Label%%'' </center> </div>
In an article, it can be used by its name:
{{ImageFloatingRight Image=Eiffel tower.jpg Label=The Eiffel Tower in Paris }}
A Countrybox might start like this: {{CountryFactBox Flag=usa.png Motto=In God We Trust Capital=Washington D.C. ... }}
I find this approach very simple and elegant. The Countrybox code above is self-explanatory and can be immediately edited by anyone; the implementation of the snipplet in the snipplet namespace would be rather technical, would involve colors, nested tables etc., would rarely have to be edited, and could be safely ignored by most. As an additional benefit, all country pages would look exactly alike.
This approach is clearly superior to pushing the complete table into its own namespace, because then only technically proficient users could savely edit the table contents.
We could even use simplified wiki Table syntax in the main namespace and restrict the use of HTML tables (and other fancy HTML features) to the snipplet namespace, since virtually all current uses of complicated HTML tables belong to similar project pages that would benefit from unifying snipplets.
This is more flexible than just stylesheets:
- More features of HTML can be used.
- More users can edit the HTML snipplets than edit the CVS-based
stylesheets.
- It's easier to edit than having various stylesheet elements in the
text.
- Layout and Content are strictly divided.
Yup.
Axel
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Axel Boldt axelboldt@yahoo.com writes:
A Countrybox might start like this: {{CountryFactBox Flag=usa.png Motto=In God We Trust Capital=Washington D.C. ... }}
I find this approach very simple and elegant.
It looks very cryptic to me; don't invent yet another markup language! Please, go for proper SGML based on the so called 'Reference Concreate Syntax':
<CountryFactBox> <Flag>usa.png <Motto>In God We Trust <Capital>Washington D.C. ... [empty line]
The [empty line] will end the block.
On Fri, May 16, 2003 at 10:23:10PM +0200, Karl Eichwalder wrote:
Axel Boldt axelboldt@yahoo.com writes:
A Countrybox might start like this: {{CountryFactBox Flag=usa.png Motto=In God We Trust Capital=Washington D.C. ... }}
I find this approach very simple and elegant.
It looks very cryptic to me; don't invent yet another markup language! Please, go for proper SGML based on the so called 'Reference Concreate Syntax':
<CountryFactBox> <Flag>usa.png <Motto>In God We Trust <Capital>Washington D.C. ... [empty line]The [empty line] will end the block.
Can we agree on starting it with something else than just the name? E.g. Include:CountryFactBox? This would ease the parsing. Having the variable names in <> brackets is just syntactical sugar and fine with me.
JeLuF
Jens Frank JeLuF@gmx.de writes:
Can we agree on starting it with something else than just the name? E.g. Include:CountryFactBox? This would ease the parsing. Having the variable names in <> brackets is just syntactical sugar and fine with me.
Sure, it's just a little bit longer. But don't use "xi:...", that's XML'ish and means something different (roughly: including _external_ data).
Can someone please explain what we're talking about here? I am totally confused. Are we talking about inventing some sort of new language to create country codes? If not, just what ARE we talking about? I'm so confused, I dont't think I'd ever use whatever it is we're talking about.
Zoe
--- Karl Eichwalder ke@gnu.franken.de wrote:
Jens Frank JeLuF@gmx.de writes:
Can we agree on starting it with something else
than just the name?
E.g. Include:CountryFactBox? This would ease the
parsing. Having
the variable names in <> brackets is just
syntactical sugar and fine
with me.
Sure, it's just a little bit longer. But don't use "xi:...", that's XML'ish and means something different (roughly: including _external_ data).
--
| ,__ohttp://www.gnu.franken.de/ke/ | _-_<, ke@suse.de (work) / keichwa@gmx.net (home) | (*)/'(*) _______________________________________________ Wikipedia-l mailing list Wikipedia-l@wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikipedia-l
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
On Fri, May 16, 2003 at 10:26:59PM -0700, Zoe wrote:
Can someone please explain what we're talking about here? I am totally confused. Are we talking about inventing some sort of new language to create country codes? If not, just what ARE we talking about? I'm so confused, I dont't think I'd ever use whatever it is we're talking about.
Hello Zoe,
Wikipedia normally uses an easy markup language. It uses ''' to make things bold or == for headings. After a user has hit the 'edit'-button for the first time, he gets an idea of how to fix an article very fast. The learning curve is rather flat.
For some articles, we use those nice tables. E.g. http://www.wikipedia.org/w/wiki.phtml?title=Beryllium&action=edit It starts like this:
[[de:Beryllium]][[eo:Berilo]][[nl:beryllium]][[pl:Beryl]][[fr:B�ryllium]] <table border="1" cellpadding="2" cellspacing="0" align="right"> <tr><td colspan="2" cellspacing="0" cellpadding="2"> <table align="center" border="0"> <tr><td colspan="2" align="center">[[Lithium]] - '''Beryllium''' - [[Boron]]</td> </tr> <tr><td rowspan="3" valign="center"> <br>'''Be'''<br>[[Magnesium|Mg]] <br> <br> </td></tr> <tr><td align="center">[[image:Be-TableImage.png|Click for description]]<br> [[Periodic table/Standard Table|Full table]]</td></tr> </table> </td></tr>
Those articles are not easy to edit. They are frightening.
Lee proposed a new syntax for tables, similar to what some other wiki engines already provide. It was rather easy to read and to understand. He provided some extensions to add color and such to the tables. Not that simple any- more but OK. But: The new syntax for tables wasn't power- full enough to generate the Beryllium-table. It might have been OK for Countryboxes, though.
Some others proposed: Take the tables into a different article (in a seperate namespace) and include them like an image is included. On first sight, an editor would just see pretty Wiki markup and a link [[Table:Beryllium]]. He would have to click on a new button to edit the table.
Two things I didn't like about this: - The article's content should be in the article, not distributed to several places. - A lot of duplication will be done. All Countryboxes are identical except for the content. "Write it once, use it multiple times" is a principle to increase efficiency.
My proposal in short: - The ugly HTML-code for tables will be banned from the article-namespace. - HTML will be written to pages in a seperate namespace. - Those pages will be parametrizable. So a table can be layouted once and used multiple times. - They are included into the article by some simple syntax assigning text to the parameters.
The concept is not only useable for tables but for other text blocks, too: Copyright infringement notices, images, "I am not a lawyer/doctor"-Warnings, etc: [[Include:IANAL]] or [[Include:Copyright infringement|URL=http://where.he.got.it.from/]]
It's not about country codes. This is just an example to illustrate what we are thinking about. In this mail, I used the Beryllium-table as an example.
I hope I summarized the thread correctly.
Best regards,
JeLuF
Jens Frank wrote in part:
For some articles, we use those nice tables. E.g. http://www.wikipedia.org/w/wiki.phtml?title=Beryllium&action=edit It starts like this:
[[de:Beryllium]][[eo:Berilo]][[nl:beryllium]][[pl:Beryl]][[fr:Béryllium]]
<table border="1" cellpadding="2" cellspacing="0" align="right"> <tr><td colspan="2" cellspacing="0" cellpadding="2"> <table align="center" border="0"> <tr><td colspan="2" align="center">[[Lithium]] - '''Beryllium''' - [[Boron]]</td> </tr> <tr><td rowspan="3" valign="center"> <br>'''Be'''<br>[[Magnesium|Mg]] <br> <br> </td></tr> <tr><td align="center">[[image:Be-TableImage.png|Click for description]]<br> [[Periodic table/Standard Table|Full table]]</td></tr> </table> </td></tr>
Those articles are not easy to edit. They are frightening.
This is just a stopgap, but I'd like to encourage people to write this:
"[[de:Beryllium]][[eo:Berilo]][[nl:beryllium]][[pl:Beryl]][[fr:Béryllium]] " "<!-- To edit the text of this page, skip past the ugly table markup below.--> " "<table border="1" cellpadding="2" cellspacing="0" align="right"> "<tr><td colspan="2" cellspacing="0" cellpadding="2"> "<table align="center" border="0"> "<tr><td colspan="2" align="center">[[Lithium]] - '''Beryllium''' - [[Boron]]</td> "</tr> "<tr><td rowspan="3" valign="center"> <br>'''Be'''<br>[[Magnesium|Mg]] <br> <br> </td></tr> "<tr><td align="center">[[image:Be-TableImage.png|Click for description]]<br> "[[Periodic table/Standard Table|Full table]]</td></tr> "</table> "</td></tr>
It at least tells people that there ''is'' text that they can edit easily, even though it doesn't fix things to make the table itself easily editable. Hopefully some new editors won't be scared off as quickly in that case.
-- Toby
Axel Boldt wrote:
--- Jens Frank JeLuF@gmx.de wrote:
There would be another namespace for HTML-Snipplets. Those snipplets can contain variables, e.g. enclosed by %%. A snipplet might be a piece of code to include an image with a label, it might be a table, or a boilerplate text.
The snipplet ImageFloatingRight might perhaps look like this:
<div style="float: right"> [[Image:%%Image%%]]<BR> <center> ''%%Label%%'' </center> </div>
Yuck. Please can we use CSS for this sort of thing?
The best HTML output would be:
<DIV class="imagefloatright> <IMG src="foo"> <p>caption</p> </DIV>
float the div, center the P within it and apply character formatting such as bold italic:
div.imagefloatright { float:right /* maybe put it on a grey background or a border */ } div.imagefloatright p { /* nice character formatting */ }
Lee Daniel Crocker lee@piclab.com writes:
HTML fails to meet at least some of those criteria (notably ease of editing).
As often, I disagree. It would be much better to go for a subset of HTML "tags" plus shortcuts for [[links]]. Basically, H1-Hx, simple lists, CODE, EM, B, I, P, BLOCKQOUTE, and PRE would do the trick. Plus tables, where necessary. Plus BR, maybe.
Things like ==...==, ''...'' and the list codes in combination with the line ending restrictions are not that easy to learn. And don't for get the indentations tricks. Once the user gets these cryptic control code, he must learn to use them properly! And the nice thing about wikis is, their is more than one, thus you are force to get used to more than one wiki format ;-)
I'm pretty sure, HTML 2 (plus simple table tags) are not difficult _and_ more rubust. TEI-like tag names would even be better :)
Karl Eichwalder wrote in part:
Things like ==...==, ''...'' and the list codes in combination with the line ending restrictions are not that easy to learn. And don't forget the indentations tricks. Once the user gets these cryptic control code, he must learn to use them properly! And the nice thing about wikis is, their is more than one, thus you are force to get used to more than one wiki format ;-)
I think that the list markup is quite intuitive and easier than HTML. Other than that, I'm inclined to agree with you. Still, "''" is shorter than "<em>" (and usually more correct than "<i>"), as well as well known to writers of wikis other than ours, so we should still allow it.
One change that we really need to make in PediaWiki, however, is to not allow things like <span onmouseup="...">. This can be done by explicitly parsing all apparent HTML encountered -- if the parser renders it into HTML exactly the same as the source, then that's no loss, but it should still be parsed.
-- Toby
Brion Vibber wrote:
Toby Bartels wrote:
One change that we really need to make in PediaWiki, however, is to not allow things like <span onmouseup="...">.
Well, that's an easy change request to accomodate, since we already do that. :)
So we do! We didn't once upon a time.
That makes some of my recent comments obsolete. That is, things are already closer to perfect.
-- Toby
On Thu, 15 May 2003 11:23:14 -0500, Lee Daniel Crocker lee@piclab.com gave utterance to the following:
I agree - but when you said "ALL HTML is forbidden" I went ahead and looked at the table specification part of your document and saw some things that seem rather Spartan to me. For example, the document doesn't indicate whether or not nested tables would be allowed and it doesn't seem to say how one would do bgcolor-type cell fills, or how to set border width.
There's no provision for nested tables. I don't think there's a good enough case for their necessity. Cell backgrounds and borders can be done with styles.
So if the table at http://www.wikipedia.org/wiki/Beryllium cannot be replicated pretty much as-is in wikicode then I for will have a fit (I'm sure many others will join me).
Yeah, that nested table is a nuisance. I'll have to think about that.
That nested table could be a separate table, particularly if we used a wrapper div and performed the float on that.
I suggest that we look at some way of introducing classes based on the semantics of the data. For example, a wiki-method of entering <span class="species"> - although if we go that far we may as well look at an xml-based wiki (<species>) using server-side XSLT with a range of standard and personal-choice stylesheets.
Whatever we do, the aim must be to produce valid (x)HTML and CSS, maximising the chances of consistent behaviour across platforms and browsers. No inserting of <p> </p> to generate space below headers (etc).
(Richard Grevers lists@dramatic.co.nz):
I suggest that we look at some way of introducing classes based on the semantics of the data. For example, a wiki-method of entering <span class="species"> - although if we go that far we may as well look at an xml-based wiki (<species>) using server-side XSLT with a range of standard and personal-choice stylesheets.
Did you read the proposal? I suggest doing exactly that with a very simple syntax. Re-read it:
http://www.piclab.com/cgi-bin/wiki.pl?Wikipedia_Text_Syntax
wikipedia-l@lists.wikimedia.org