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

Patrick R. Michaud pmichaud at pobox.com
Fri Mar 31 23:55:46 CST 2006


On Fri, Mar 31, 2006 at 08:42:37PM -0600, Ben Wilson wrote:
> 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.

I'm not disputing this.

> 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.

I'm sorry, it does *not* have _prima facia_ validity to me.

I totally understand the many arguments that have been made
about separating style from structure, especially from a document
handling and storage perspective.  I even agree with them in those
contexts.  

What I do not necessarily agree with is that separating style from 
structure is author-friendly.  When writing, authors (except those who
have been trained otherwise) do not normally think in terms of
style versus structure -- they think "How do I get this to look
the way I want it to look?"  Authoring and reading is a 
visually-oriented activity for most people, and they naturally
think in terms of how things look and not how they are structured.

So, in the name of author friendliness, PmWiki takes the
model that blank vertical space in the markup should produce blank
vertical space on output.  It's perfectly valid to disagree with 
me on this point, but we'll just have to agree to disagree on it.
Of course, the nice thing is that PmWiki supports both.  :-)

> Third, the model of PmWiki is "vertical space is only vertical space"
> is essentially the same model as older WYSIWYG editors. 

I'm sorry, I really wasn't meaning to imply that vertical space would
be "only vertical space", or that it would no longer delineate
paragraphs.  The main point I was getting across is that vertical
space is used for more than just paragraph delimiting.

> 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. 


As you say, this *greatly* oversimplifies the point.  The only
reason PmWiki turns blank space into <p class='vspace'></p> is
because HTML doesn't provide me a clean alternative.  If it
were possible for <p> tags in HTML to contain other block markups,
there wouldn't be any <p class='vspace'></p> tags in the output.
Here it is HTML that is broken, and PmWiki has to use something
like <p class='vspace'></p> to work around it.

> 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).

But isn't this *exactly* what is being proposed -- i.e., to
use whitespace to delineate paragraphs except if a more
specific markup is present (in this case, a backslash at the
beginning of a markup line)?!?

> 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. 
> [...]
> Therefore, it is wrong to add superfluous markup to provide for
> aberrant conditions.

I'm afraid I totally disagree again.  The whole point of
markup in PmWiki is to simplify the authoring task, and
if a "superfluous markup" can do that, it's worth having.
As an example, one could say that all of the ''emphasized'',
'''strong''', {-del-}, {+ins+}, etc. markups are "superfluous",
since one could achieve similar effects using %style%.  But
the fact is that '''important''' reads far better than
%strong%important%% or even <strong>important</strong>, and
that's why we make additional markup sequences available.

And I don't think that in the name of consistency we should
box authors into a single way of doing things.  Just because
we already have a way of achieving a specific effect
shouldn't preclude having shortcuts available where needed.

Pm





More information about the pmwiki-users mailing list