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

Ben Wilson dausha at gmail.com
Sat Apr 1 08:43:19 CST 2006


I was going to get into a line-by-line arguement, but that is too far
into the weeds. I mean, I could go into lavish explanation on how your
agreeing that separating form from function in some contexts satisfies
the _prima facia_ test, and your providing a specific set of
conditions moves beyond that test, but then I'd be writing a legal
brief. I think what I have here is a strong  argument against the
change, and offer that in many ways problems raised to counter my
argument also have ready solutions within current PmWiki.

I mean, one of the reasons I not only use PmWiki but recommend it to
my client base is because it is so versatile the way it is today.
After two years, I have never had anybody ask me "yes, but how to I
put two paragraphs together with different text-alignment?" That is,
the change offered solves a problem I have not encountered "in the
wild." Granted, that is pure anecdotal, but as I argue below, the
problem is likely rare enough that individual admins can impliment it,
so it should not be allowed into the core absent a strong showing it
is necessary. PmWiki is supposed to be resistant to feature creep.

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.
I thought that since the PmWiki is generally against feature creep
that my argument would carry more weight than it seems. Others who
have argued against the change have offered substantive reasons
against as well.

The point is this. There is an RFC regarding adding a second way to
markup a standard tag. This is different than '''strong''',
''emphasis'', and {-del-}, which offer a one-on-one correspondence
with XHTML tags. The W3C has stated that <del>, <strong> and <em> are
"function" by making them available in XHTML. I suppose that this
determination is on a sliding-scale as arguably everything is either a
span or a div, and anything more specific is style. So, <del>,
<strong>, and <em> are representatives of the "more function than
form" side of the scale. But, we could slug it out all day about this.
However, by offering the W3C, I'm making an appeal to the fact that
I'm not the only one saying this.

More importantly, there is already a way in PmWiki to satisfy the
requirement the RFC seeks to satisfy. I thought that by providing a
straight-forward PmWiki-way to render the solution (even if not
exactly correct syntactically), then I would demonstrate that the
requirement was satisfied, and so there is no need for another way to
render a paragraph. 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.

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. I know tables and divs offer exceptions to this rule, but I
think we can all agree that offering both simple-but-elegant and
advanced-but-specific approaches to tables improves tables.

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.

Pm and I disagree on the degree of control given authors. Or, do we?
I'm more willing to support Python's response to Perl's TIMTOWTDI,
which is "but some ways are better than others." What I am saying is
PmWiki _already_ has a way to do this, why add a second? Both my
"solution" and the suggested change to the core offer the same result.
The suggested change gives the author fewer key presses--but both seem
to require a CSS change behind the scenes. I argue that when a
neophyte author shows up and sees the page, he will scratch his head
at what he sees. If all paragraphs have white space in source, then he
will assume that each is a paragraph.

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). So, we are
really talking about vertical space between <ul> and <ol>, not space
between individual <li> within the same group.

As the <u|ol> are blocks, I think that my argument remains
cohesive--if you want two separate lists to join by default, then set
that in the style and allow the author to state via %style% when he
wants variation. If you want lists separated by default, set the style
accordingly and let the author state via %style% when he wants lists
joined.

Also, if you want extra white space between <li> in the same list,
can't you just use \\ or [<<]? That's what I do on the extremely rare
occasion that I want to break format.

Also, I strongly believe the <p class='vspace></p> is not
necessary--which is why I've killed it in many of the sites I support.
That is, not necessary even under PmWiki's core concept. I've never
had a complaint for taking it out.

Ben

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"




More information about the pmwiki-users mailing list