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

[Patrick R. Michaud]

On Sat, Apr 01, 2006 at 08:43:19AM -0600, Ben Wilson wrote:
> The original RFC stated that anti-change arguments would be given
> greater weight, although the responses given strongly suggest a _fait
> accompli_ in the result.

Honestly, if it was a _fait accompli_, I wouldn't have bothered 
asking.

> The superfluidity argument I raised was focused on
> the fact that PmWiki already has a way that works and is easy for an
> author to learn.

I disagree that it's easy for an author to learn how to use
CSS and wikistyles to get two consecutive paragraphs to display
without intervening whitespace.  If it were truly easy, we wouldn't
be having this discussion.

> The fact that there is only one way to render '''strong''' and not
> *strong* or ''emphasis'' and not _emphasis_ points out that PmWiki
> generally respects the one-for-one relationship between XHTML tags and
> markup. 

Totally false as to motive.  The reason that PmWiki doesn't
support *strong* or _emphasis_ has nothing to do with wanting
to preserve a one-on-one relationship with XHTML, and everything
to do with coming up with a robust pattern that produces bold and/or
emphasized text only where the author intended and not interfering
with other markups.

> The pro-change support has generally been "do it" or "how about this
> approach," which does not counter my argument against adding
> yet-another-way-to-do-it.

My counter argument to yet-another-way-to-do-it is generally that
PmWiki has always supported the idea of there being multiple ways
to do something.

> I think the argument incorporating list items fails for a key reason.
> When two groups of list items are separated by white space, doe PmWiki
> not create two separate lists? This is part of the reason why you
> can't put white space between ordered list items--it will start
> incrementing again (absent an explicit value setting). 

PmWiki does not create two separate lists when there is vertical
white space between list items, and never has used whitespace to
do so.  This is especially important when dealing with ordered lists.

> So, we are
> really talking about vertical space between <ul> and <ol>, not space
> between individual <li> within the same group. [...]

False, and the rest of your argument falls because of the incorrect
premise.

> Also, if you want extra white space between <li> in the same list,
> can't you just use \\ or [<<]? 

AFAIC, this isn't author friendly.  The way to obtain whitespace
between items in a list ought to be to "put whitespace between
items in a list".

Pm



> On 3/31/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > 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
> >
> >
> 
> 
> --
> Ben Wilson
> " Mundus vult decipi, ergo decipiatur"
>