Jan Hidders wrote for the most part:
>Toby Bartels wrote:
>>The question isn't how easy "'''" is to learn.
>>The question is how easy "<b>" is to learn.
>>The answer to that is, it's pretty darned easy;
>>therefore, since people will try it, it should be allowed.
>Just for clarity, I wasn't arguing that simple HTML like <b> is more
>difficult than ''', but just reacting to the suggestion of the reverse.
I do disagree with you there, thinking that ''' is more difficult,
although *only* because more newbies will know <b> to begin with --
they are inherently of pretty much the same complexity
(I see two minor arguments each for relative simplicity).
This is minor, and the difference will probably only lessen with time.
My major disagreement with you in these matters
is your desire to find a nonHTML wiki markup for
every one of the HTML tags that's reasonable to implement,
and your ultimate goal to discontinue HTML support at all.
I argue that the HTML tag itself is the best wiki markup for most of these.
It's just a few situations where we have something better,
or where the HTML is so complicated that we *need* something better.
Then I'm with you; I just wish that this weren't an antiHTML crusade.
>It's
>when people start using <DIV> and complex <TABLE>s and <VAR> and <STRONG>
>when things start becoming harder to understand and edit for the average
>user. Other than that there are also technical reasons such as the
>simplicity of the parser and the control that we would have over the HTML
>that we send to the browsers of the reader.
Well, Lee has just informed me that <strong> and <em> are taken care of;
it was only Phase II that rendered ''' and '' suboptimally as <b> and <i>.
We're discussing <var> on your user subpage, and people are working on <table>.
<div>, even when used on regular web pages, is almost never appropriate,
and I could see disallowing it (but maybe someone else knows why we need it).
So I think that we're closer to agreement than it appears at first;
I don't object to the practical results that you're likely to achieve,
only to the fundamental philosophy that underlies your efforts ^_^.
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
Jan Hidders wrote:
>Steve Callaway wrote:
>>nevertheless. HTML is //much// simpler.
>That is simply not true. One of the reasons that the WikiWiki mark-up was
>invented is exactly because HTML didn't work well and was seen as
>unecessarily difficult.
I don't see how you can establish this in any objective manner.
Even a survey would only shows that most people feel that one as simpler,
which is not at all the same thing as one's actually *being* simpler.
Myself, I think that <h6> is simpler than ======,
because it's simpler to read the "6" than to count the "="s.
But == is simpler than <h2>, because I don't have to count the "="s there.
We can do psychological testing to determine when simplicity switches,
but other people will switch it at slightly different times.
Best all around to allow both methods.
You know, this is like allowing both American and Commonwealth spellings.
I find it difficult to remember to write "analyze" or "spelt",
but it's easy as pie to learn to read them.
Similarly, if Steve has trouble writing ===, he can still read it,
and if you have trouble writing <h3>, then you can still read that too.
It's just that here the reading is occuring on the edit page
rather than in the text of the article directly.
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
Tarquin wrote:
>Toby Bartels wrote:
>>The question isn't how easy "'''" is to learn.
>>The question is how easy "<b>" is to learn.
>>The answer to that is, it's pretty darned easy;
>>therefore, since people will try it, it should be allowed.
>>If having two ways to write the same thing is bad,
>>then honestly "'''" should go before "<b>" does.
>>(Note the "if"; I think that "'''" is great -- easier to type.
>>In fact, it should actually be rendered as <strong>,
>>which is even harder to type but is almost always more correct.)
>Or <em> maybe?
''' = <strong>, '' = <em>.
>Many people comne to wikipedia completely ignorant of HTML. Many people
>on the net don't even know what HMTL is -- really! Some of them are my
>friends! Many people *with websites* use Dreamweaver or some such and
>have no idea what <b> means.
I don't see the relevance of that.
It's not like they know what ''' means either before they arrive.
Surely *more* people will know <b> than ''' before coming here,
and most of these people won't be ace programmers either.
>I think the most important point is that wiki must be easily readable in
>both raw & rendered formats. The eye skims over ''' very easily, whereas
><b> and </b> arrest the flow.
This I think *is* relevant.
Since I don't believe that we need only one method for every purpose,
I would keep both <b> and ''' but still prefer '''
(barring making a distinction between them as suggested below).
>I would hesitate before [removing support for] <b> and <i> in wiki markup, but I
>change those to the equivalent ' whenever I see them, and I don't think
>they should be encouraged.
I do the same changes myself, except in very special cases
where <b> is actually more appropriate than <strong>.
Then one day when I convince y'all to render ''' as <strong> instead of <b>,
then everything will be perfect!
I'm not about to get upset if you change by <b> to ''', however,
and could be convinced to follow your lead exactly if you work at it;
I'll only get upset if you mess with <var>, as explained in another post
(not yet made, or look on Jan's page).
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
> * Delete uploaded files
> o There's also a revert-to-previously-uploaded-version feature,
> I'm not sure if this is sysop or everybody.
Anybody can revert, and anybody can delete a single old revision;
but only sysops can delete the whole image and its description.
> * Protect and unprotect pages (locking them against edit by other
> users who are not also logged in as sysops).
Forgot about that one.
> Traditionally this was in fact used only on the main page, but
> some of the policy pages are also locked, which I'm not sure I
> approve of. Here are all the pages currently protected:
> o Wikipedia:Upload_log
> o Wikipedia:Deletion_log
These are a special case: the software requires that they be in
a special format so that it can add to them. While it would be OK
to make certain edits (adding text, etc.), some would break things,
so this is just a safety precaution.
> o Wikipedia:What_Wikipedia_is_not
> o Main_Page
> o Wikipedia:Neutral_point_of_view
> o Wikipedia:Copyrights
> o Wikipedia:Policies_and_guidelines
> o United_States_Constitution/Article_One (I'm a little
> confused by this one; I've since unprotected it. It's just a
> redirect anyway...)
> o Wikipedia:IP_probation_watchlist
> o Wikipedia:Most_common_Wikipedia_faux_pas
> o
Wikipedia:Wikipedia_policy_on_permanent_deletion_of_pages
> o Wikipedia:Blocked_IPs
> o Wikipedia:Naming_conventions
> o Wikipedia:Administrators
> o Wikipedia:Policy
I think some of these may have had a history of vandalism, but I'm
with you that most of them should be unprotected. Anyone else
remember more details here--they seem to have been protected when
my head was buried in software, so I missed a lot of discussion.
> There are also a handful of 'developer' features available only
> to a few of the programmers for purposes of finding and fixing
> bugs: database queries, showing the PHP configuration variables,
> and enabling/disabling a read-only mode to prevent edits to the
> database in the middle of certain upgrades. --Brion VIBBER »
Sysops can do "SELECT" queries on the database. Only developers
can do updates and deletes.
Stephen Gilbert wrote:
>What if you want a bold italic font? I know of only
>three ways to do it on Wikipedia, and none are pure
>wiki syntax: <b>''Bold italic''</b>, <i>'''Bold
>italic'''</i>, or <b><i>Bold italic</i></b>.
''''' gives bold italic (more precisely, <em><strong>),
but this is buggy on some browsers.
If you find that it makes a difference to your browser
exactly how you go about specifying the effect,
then you might consider reporting that to Lee;
he could choose the rendering method that bugs the fewest browsers.
(But I suspect that he would give this very low priority ^_^.)
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
> Then one day when I convince y'all to render ''' as (strong)
> instead of (b), then everything will be perfect!
'' and ''' are already rendered as (em) and (strong).
I'll have a more detailed reply later, but for now let me
say that I'm definitely on the side of removing the _need_ for
HTML as much as possible, but I'm open to allowing it.
>>Sysops can do "SELECT" queries on the database. Only developers
>>can do updates and deletes.
> There had been some discussion a while ago of changing that and
> restricting all direct DB access to developers; I guess I got it
> mixed up with the implementation in my memory. As I recall the
> points of contention were:
> 1) Users' passwords were stored in the database in plaintext.
Hr. Daniel Mikkelsen wrote:
>My idea with the "controversial issue" flag/page-link would be to use it for
>articles that are still "contested" at Wikipedia. Many articles that in
>themselves regard controversial issues have been splendidly NPOVed, and
>wouldn't need to be flagged.
>But others, where people bicker back and forth, or where someone still doesn't
>consider the article to be NPOVed, would benefit from it.
First, I don't think that this should be encouraged just because
a reader doesn't think that an article is NPOV but hasn't time to fix it.
Although you can't vote automatically from a page anymore,
the listing at [[Wikipedia:Votes for NPOVing]] serves this purpose.
You apparently think that this won't be used widely
because there's a threshold of trouble involved;
but adding "This is a [[controversial issue]]."
at the end of the introductory paragraph is quite easy,
and it's hard to justify removing it if the statement is literally true.
Listing on [[Wikipedia:Votes for NPOVing]] is a more reasonable threshold IMO.
However, the pages where people bicker back and forth
could reasonably stand be flagged for the benefit of casual readers
(or to calm down the authors, although I don't think that that will work).
But casual readers won't be tipped off by a link to [[controversial issue]].
The only way that I think that this will work is an entire paragraph,
placed after the introductory paragraph in Wikipedia's patented '', say:
''This is a [[controversial issue]], and the authors of Wikipedia
have yet to come to a consensus on the best way to present it
from a [[neutral point of view]]. Please bear that in mind while reading,
and if you wish, help us to craft this article in a way
that will be fair to all viewpoints.''
Since the existence of bickering is fairly clear cut,
people can easily justify including or removing this.
Even the bickering authors of the article know that they're bickering,
even if each does think that said bickering is all the other side's fault.
(A computer script to determine whether there's bickering might be better,
except that I have no idea how this could be implemented.
Lots of edits is no evidence; even lots of reverts could just be vandalism.)
People that just jumped in from Google are told up front what's going on,
and a page like [[Wikipedia:Controversial issues]] (redirected to from
[[controversial issue]] for ease of linking) will explain the policy,
not serve as a list (although a list would appear on "What links here").
I'm not convinced that this is necessary at all, but if it is,
then I think that it'll work better out front like this
than as a subtle flag that only insiders will notice.
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
Vicki Rosenzweig wrote in part:
>Toby Bartels wrote:
>>Neil Harris wrote:
>>>(Name of issue here) is a [[controversial issue]], with widely differing
>>>points of view... &c.
>>"'''Evolution''' is a [[controversial issue]],
>>with widely differing points of view."
>Also, of course, "'''God''' is a [[controversial issue]], with widely
>differing points of view",
>Seriously. Evolution isn't half as controversial as whether Jesus is God.
That's kind of the point;
[[Evolution]] shouldn't be flagged but it *will* be (my prediction),
rendering the flag largely useless.
That said, [[God]] probably shouldn't be flagged either --
although I haven't looked at that article, so ¿who knows?.
-- Toby Bartels
<toby+wikipedia-l(a)math.ucr.edu>
Resent after bounce, change in subscriber name.
- ------- Start of forwarded message -------
|From: tarquin <tarquin(a)planetunreal.com>
|Date: Tue, 30 Jul 2002 12:55:57 +0100
|
|Steve Callaway wrote:
|
|>It occurs to me that there is going to be an awful lot of reworking if we
|>ever do go to an XML format Wikipedia (and this definitely needs discussion
|>at some point soon). I would have said that HTML is a more generally
|>accepted standard and that Wiki formatting is a highly localised phenomenon.
|>You can do a lot more with HTML format than you ever can with Wiki
|>formatting.
|>
|Au contraire. The beauty of Wiki Markup is that is is independent of
|what is sent to the browser.
|When XML finally (!) hits the road, all it will take is a few tweaks to
|the script so '' is converted to a different tag instead of <I>, and we
|can go on writing wiki markup as before.
|If anything, XML is another reason for preferring wiki markup to HTML.
|Another good reason, from http://c2.com/cgi/wiki?WhyWikiWorks, is:
| > It's an intelligence test of sorts to be able to edit a wiki page.
|It's not rocket science, but it doesn't appeal to the VideoAddicts
|<http://c2.com/cgi/wiki?VideoAddicts>. If it doesn't appeal, they don't
|participate, which leaves those of us who read and write to get on with
|rational discourse.
|
My markup experience goes back to 1978, when Runoff was a pup found on
the doorstep by the FAA in Oklahoma City, and goes on through the
various *ROFFS, DEC's own RNO, Symbolics Concordia (where I was doc
manager), VAX Document (whose development group I managed), HTML, XML
(a disastrous experience with Arbortext products), and a couple of
others I can't now recall, as well as Framemaker and other word
processors, so it is with some authority that I can say that Wiki
Markup is the best, most comfortable, pound-for-pound most functional
markup language I have ever used.
It is simple, easy to learn, and provides almost all that any writer
needs to do the job of putting words in order. Tables are dreadful,
but they almost always are. Some kind of simple table specifier that
would permit creation of two-column and three-column tables is about
the only thing I miss. Even there, you can do most of what you want
just by putting a blank space at the beginning of a line.
The ability to sneak out into HTML is handy, but prone to non-wikiness
if the next person to come along can't figure out some arcanely nested
construction. A back door to XML would be a mistake in my opinion
because you can do *anything* with XML and I don't think we want to be
able to *anything*, we want *anyone* to be able to edit a page.
Implement in XML, sure, but hide it, because I don't ever want to code
in it. I don't really want to code at all, and Wiki Markup gives me
the impression that I'm not coding and I don't have to.
Ortolan88
- ------- End of forwarded message -------