[pmwiki-users] Fwd: RFC: Core candidate offerings

Ben Wilson dausha at gmail.com
Fri Mar 31 20:42:37 CST 2006


I forget that Pm likes to send to the list and the individual when he
replies. :-) So, I have to explicitly resend to the list. However, as
my email is sort of long, I will try to summarize it:

First, the predominate behavior of authors of electronic content is to
delineate paragraphs via white space. Look at every email sent to this
list do see the inherent validity of this statement. We all use
whitespace for paragraphs.

Second, matters of style should be in stylesheets, not in markup (or
in code). This argument has been waged in many other places, and I
would hope that it has _prima facia_ validity. PmWiki provides this
via the %style% markup.

Third, the model of PmWiki is "vertical space is only vertical space"
is essentially the same model as older WYSIWYG editors. The WYSIWYG
model essentially follows the typewriter model. Essentially, this is
turning newlines into <br /> or <p  class='vspace'></p>, although this
oversimplifies the point. I argue that if so, then PmWiki follows a
broken model in this respect, and needs to adopt the near universal
model of "whitespace delineates paragraphs (absent more specific
markup).

Two paragraphs _not_ separated by whitespace (on screen) is a
deviation from the normal behavior. This can be remedied via
stylesheets without resorting to changing markup. I have demonstrated
this before--although it might have been better to have p
{padding-top: 1.5em;} so the deviation could be implimented in one
%style% of the deviant paragraph rather than in the deviant and its
predecessor.

Therefore, it is wrong to add superfluous markup to provide for
aberrant conditions.

Additionally, using %p% or %li% is visually irritating. Might as well
resort to Bbcode.

Look at the Markdown syntax (google for it). Very visually appealling,
although admittedly meant to be a simple subset. The wiki source
should be as easy to read as the marked up page. That fits in with the
"author-centric" approach of wiki.


---------- Forwarded message ----------
From: Ben Wilson <dausha at gmail.com>
Date: Mar 31, 2006 8:26 PM
Subject: Re: [pmwiki-users] RFC: Core candidate offerings
To: "Patrick R. Michaud" <pmichaud at pobox.com>


On 3/31/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Fri, Mar 31, 2006 at 04:55:02PM -0600, Ben Wilson wrote:
> >
> > In some of my wikis, I just zeroed out the variable that sets vspace,
> > then added padding-bottom to paragraphs w/in #wikitext. I get all of
> > the space I want without having superfluous HTML tags. (I also
> > text-indent: 1em;)
>
> Out of curiosity, how do you get blank lines between list items?

I'm not sure I understand your question well enough. I don't put white
space between list items.   HTML's default behavior is that each list
item is on a separate line--as I know you know. So, I am not aware of
this being an issue. I don't expect list items to have white space
between themselves. Then again, I do expect white space between
paragraphs. Although, I'm also assuming I misunderstand your question.

> If your answer is "add padding-bottom to <li>", then how would
> you generate a list itesm without vertical space?

As I argue below, the default should be in the stylesheet, and any
deviation to style should be something that is marked up. Thus, as I
do not put whitespace between list items, I would generate a list with
white space by using a >>style<< and then putting that style's
behavior in a sheet.

<snip>

> Wikistyles with apply=block or apply=p will modify the <p> tag
> instead of producing a span.
>
> > As there appears to be a
> > ready solution to the problem without adding superfluous markup, I
> > still do not see a reason to add alternative paragraph markups to the
> > core.
>
> At the moment, I disagree that there is a 'ready solution' --
> I think the solution you've described just pushes the complexity
> into different areas, or breaks the model that PmWiki has (namely,
> blank lines do not mean "paragraph", they mean "vertical space",
> which is usually and exactly what the author intended them to mean).

The near-universal way to delineate paragraphs online is via
whitespace. So, when I see vertical space online or in "source," I
assume that means the author is delineating paragraphs. Read the
assundry emails sent to the PmWiki discussion list. How often does an
email's author use whitespace to delineate a paragraph? Or, should I
say, how often does an author _not_ use whitespace for that purpose?
Almost never. Because web sites use white space to delineate
paragraphs, and because email authors do likewise, I argue that this
is behavior a wiki engine should model.

I'm sure when I disabled a default behavior that I was breaking the
PmWiki model. I personally dislike empty paragraph tags as they remind
me of older WYSIWYG editors that would interject those tags whenever
the author provided a newline. WYSIWYG editors were modeling
typewriters with the carriage return. That is, WYSIWYG modeled _print_
technology because: 1) it was easy to code and 2) CSS back then was
either non-existent or woefully inadequate. CSS2 has remedied this,
IMO.

Respectfully, I would argue that "vertical space means only vertical
space" would be a flaw in the PmWiki model as, I believe and argue, it
is/was a flaw in WYSIWYG design. Authors predominately mean whitespace
to be paragraphs--unless there is more specific markup such as a list
or blockquote. PmWiki's model should reflect that preconception. That
should be the "core" behavior. I would argue having two paragraphs of
different format to be rare enough that the individual site admin
should make the requisite effort.

Regardless, my personal opinion is this issue is a matter of style,
not function. Style belongs in the stylesheets, not in the markup. An
exception could be made to this general rule when the markup needs to
show a deviation from the norm. This rule/exception fits into my
earlier example--although logically it might be better to have p
{border-top: 1.5em} so the same paragraph that abuts the preceding
paragraph can create that abutment and its own formatting. "Markup
allows deviation" is how PmWiki works now, with %style%. So I would
opine we are in general agreement here, although we may argue
triffles.

My point is this: if you can do it in style, why do it in markup?
Making this a style issue keeps the markup cleaner. How many different
keys on your keyboard create a newline? Why, then, should PmWiki have
more than one way to create a paragraph?

In the alternative, if you are proposing '%' or '/' to create a new
paragraph (newlines be damned), then I would unequivocally argue that
will carry PmWiki down a dark road. All this time I assume you mean
these symbols to supplement the current behavior. If they mean to
replace, you will make it more difficult for new users. PmWiki today
is easy enough that I have not had to do much to train new authors,
except in adding inline images and a few other
intermediate-to-advanced issues.

This said, I am presently teaching myself Python by creating a wiki. I
picked up PHP on the side when I was programming for the National
Geospatial-Imagery Agency (never used in production). Now that I'm
feeling idle in law school I figured I should pick up another
language. When I graduate in December I'll be returning to IT
consulting in the DC area. I'm also writing a Sci-Fi RPG star system
generator (web CGI). For the wiki I'm looking at some of the design
suggestions found in Markdown.

--
Ben Wilson
" Mundus vult decipi, ergo decipiatur"


--
Ben Wilson
" Mundus vult decipi, ergo decipiatur"




More information about the pmwiki-users mailing list