[pmwiki-users] Elimination of class='vspace' (WAS: RFC Core Candidate Offerings)

Ben Wilson dausha at gmail.com
Sat Apr 1 10:11:55 CST 2006


Pm raises a fair question (cited at the end of this argument). So, in
order to "get rid" of <p class='vspace'></p> (hereinafter Vspace),
there should be a compelling reason. Rather than offer a compelling
reason, I would instead like to show how I have gotten rid of Vspace.
For the record, I like Pm and love PmWiki--so my emails are supposed
to be more academic arguments. However, we all know how we let our
egos get caught up in our academics--I'm probably the worst offender.
Also, sorry for long emails--curse of law school.

Sans Vspace Demonstration
-------------------------------

I have a page[1] that demonstrates how I operate sans Vspace. The CSS
I use to put white space around the blocks is the following CSS:
  #wikitext p { padding-top: 1.0em; padding-bottom: 0.5em }
  #wikitext ul, #wikitext ol { padding-bottom: 0.5em; }

Here's what I'm doing. P, UL and OL are blocks. Between paragraphs, I
want a 1.5em, but between P and U/OL I only want 0.5em. After U/OL, I
want 1.5em before the next paragraph.

For the sake of illustration, I have set $HTMLVspace to "<!-- vspace
-->". If you inspect the HTML source of my example page[1], then you
will note that the comment appears essentially whereever there is a
newline.

Changing PmWiki Behavior
------------------------------

If you look at the wiki source, you will see that each list item is
separated from the other via whitespace. This is in the original post
that I copied. In other places, the list items are stacked sans
whitespace. In these places, I changed the markup to show that it does
not appear that an author can create two separate lists back-to-back
under the core. This characteristic seems to exist with or sans
Vspace. PmWiki converts separated list items into one group. So that:

* item
* item

* item

* item

becomes:
<ul>
<li>item</li>
<li>item</li>
<li>item</li>
<li>item</li>
</ul>

However, if you accept the argument that whitespace is a block
delineator, then the same markup would be rendered thus:
<ul>
<li>item</li>
<li>item</li>
</ul>
<ul>
<li>item</li>
</ul>
<ul>
<li>item</li>
</ul>

I would argue that it is more "logical" _if_ you consider whitespace
to delineate different blocks of HTML. Using whitespace as the
"universal block delineator" is also more uniform. This is how PmWiki
delineates paragraphs. Why should it delineate other blocks any
different?

What's interesting is that Markdown has a way to add a BR when wanted:
   "When you do want to insert a <br /> break tag using Markdown,
    you end a line with two or more spaces, then type return."[3]

Of course, so does PmWiki. Perhaps when the author wants to put space
between otherwise "non-whitespaced" list items, he could use that
markup.

Argument To Remove
------------------------

I agree with Pm on this. Before there is a change to the the core,
there should be a compelling reason. That approach resists
feature-creep. Although, I have argued elsewhere there I see no
compelling reason to implement the RFC that spawned this debate, but
it appears I am a vocal minority.

I am also the only "people" to actually suggest living without
Vspace--although others have offered support after I mentioned it. So,
I stepped up. However, I did not say that Vspace should be removed
from the core. What I said is that _I_ have removed Vspace because as
a site admin I prefer a different approach. That is the glory of
PmWiki--the power given the individual admins. If others wanted to
follow suit and had a problem, I suppose I could write a recipe.

What I have said is that it is possible to implement a solution to
Pm's problem if the site admin abandons Vspace and uses CSS to give
authors more control.

Conclusion:
-------------

I think it is possible to live without Vspace, although there may also
need to be some change to how PmWiki manages blocks to make this
possible. White space should represent a break in blocks.

Reference:
------------
1. http://dausha.net/Camping/SlashdotTips
2. http://dausha.net/Camping/SlashdotTips?action=source
3. http://daringfireball.net/projects/markdown/syntax#p

On 4/1/06, pmwiki-users-request at pmichaud.com
<pmwiki-users-request at pmichaud.com> > Message: 1
> Date: Sat, 1 Apr 2006 00:16:15 -0600
> From: "Patrick R. Michaud" <pmichaud at pobox.com>
> Subject: Re: [pmwiki-users] RFC: Core candidate offerings
> To: Allister Jenks <arj at zkarj.co.nz>
> Cc: pmwiki-users at pmichaud.com
> Message-ID: <20060401061614.GC13154 at host.pmichaud.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Apr 01, 2006 at 03:11:03PM +1200, Allister Jenks wrote:
> >    I agree that's how they're interpreted.  I do not agree that vertical
> >    space is the *intent* of the authors.  I disagree because there is no
> >    distinction between paragraph spacing and vertical space.  No matter which
> >    the author is intending, they only have one choice.
> >    [...]
> >    I am thinking that the blank line in the source should be interpreted as
> >    "new paragraph" and implemented as you have described with appropriate
> >    padding instead of the extra vspace paragraph.  The questions that then
> >    remain are:
> >
> >    1. What is the meaning of multiple contiguous blank lines?
> >    2. How does the author alter the padding on a specific paragraph?  And
> >    considering top and bottom.
>
> This once again totally oversimplifies the issue by ignoring the
> impact of vertical space in list and other constructs.  Blank
> lines in the markup do more than mark the beginnings and ends
> of paragraphs.
>
> It's not at all fair (to me) for people to continually claim that we
> can simply eliminate the <p class='vspace'></p> tags from PmWiki's
> output,  until and unless such claims also include an explanation
> of how we can achieve equivalent vertical spacing effects in the
> middle of lists and other constructs.  *That* is why the
> <p class='vspace'></p> tags exist.
--
Ben Wilson
" Mundus vult decipi, ergo decipiatur"




More information about the pmwiki-users mailing list