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

H. Fox haganfox at users.sourceforge.net
Sat Apr 1 12:25:34 CST 2006


I don't care to add to any bloviated arguments, so I'll point these things out:

* We already know you like writing legal papers.
* Adding the feature won't spoil PmWiki's versatility.
* Just because you don't see a need doesn't mean it's not there.
* The arguments against (particularly yours) aren't holding up.
* The W3C is not on your side.
* There isn't an existing way satisfy the RFC's requirement.
* A one-for-one relationship between XHTML tags and markup isn't the point.
* PmWiki is author-centric, not XHTML tag centric.
* The majority of authors don't even  know or care about XHTML tags.
* Your argument against adding yet-another-way-to-do-it doesn't fly.
* PmWiki doesn't already have a good enough way to do this.
* White space doesn't mean paragraphs, it means white space.
* The argument for allowing white space in lists makes perfect sense.
* Someone not complaining doesn't mean they don't need something.
* It's pointless to argue just for the sake of argument.

Hagan

On 4/1/06, Ben Wilson <dausha at gmail.com> wrote:
> 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




More information about the pmwiki-users mailing list