[pmwiki-users] processing wikistyles (was: Using inote markup as a systemwide LatestNews flag/sticky)

John Rankin john.rankin at affinity.co.nz
Sun Aug 14 23:25:53 CDT 2005


Thank you for the explanation on how wikistyles work and other
suggestions, which are helpful as always.

I have (of course) a few follow-up questions and comments.
One clarification: we don't attempt to translate html markup 
at all, so we never see <div>, <span>, <p class='...'>. What
we do is use pmwiki to translate wiki markup into a print-
oriented xml dtd (html is of course screen-oriented), then 
transform that into LaTeX for typesetting, using xslt.

On Friday, 12 August 2005 2:00 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>On Fri, Aug 12, 2005 at 12:15:28PM +1200, John Rankin wrote:
>> This raises an issue which I have been dodging for a while.
>> I would welcome advice and help.
>> 
>> It's *really* *really* hard to transform wikistyles and style blocks 
>> into print for our wikipublisher typesetting project. I think I'm 
>> missing something at the conceptual level.
>
>No, I think you're running into the same problem I struggled with
>for many years -- the inherent limitations of HTML.  In theory
>HTML is supposed to be a semantic markup language.  Unfortunately,
>it doesn't provide any way to create new custom semantics (i.e.,
>custom tags) -- the best one can do is overload an existing
>semantic such as <div> or <span> and then do the rest in CSS.

I think we are also running into a problem that %...% and 
>>...<< are a bit too html-like, in that they are used to
create, in effect, new custom tags and to style bits of text.
>
>In my ideal world, HTML would provide a way for me to define
>a custom <postitnote>...</postitnote> tag, and then use CSS
>styles to tell the browser how it should be rendered --
>something like:
>
>    postitnote { display:block; float:right; width:200px; }
>
>Instead the best we can generally do is <div class='postitnote'>, 
>which is somewhat less than ideal because semantic information
>associated with 'postitnote' is now tied into the CSS attribute 
>and not into the HTML tag (where the semantics are *supposed*
>to go).

But can't we 'do it right' in wiki markup, then map it into html?
Suppose we:

(:define postitnote display:block; float:right; width:200px; :)

<postitnote>
some note text
<>

In this formulation, every <name> must have a corresponding
(:define:). Similarly,

(:define hotnews color:red; :)

This is <hotnews>an idea<> worth exploring.

I can't think of a reason why we would need separate markups
for block and inline wikitags. So the formulation might be

(:define block=postitnote:)
(:define inline=hotnews:)

In other words: explicitly separate meaning from presentation,
rather than the current data model, which allows separation
and styling using the same wiki markup.

For completeness and backwards compatibility, a separate 
styling wiki markup would also be required. All the named
styles would move to the new wikitag markup, where they
(arguably) belong.

>
...
>> Where I'm stuck is how to map wiki structures like >>sidenote<<
>> and %sidenote% into something other than xhtml in a way that
>> is meaningful. Most wiki markup is intrinsically simple to
>> deal with, because it describes what the object is and we just 
>> have to map it to a corresponding print element. HTML css
>> is a tougher nut.
>
>Well, it depends on what one thinks of as "most wiki markup".

Well, 'most' means everything except %...% and >>...<<.

>Certainly %red%, %blue%, %bgcolor=white% are examples of
>wiki markup, but they're different in that the same markup
>sequence (%...%) is used for a number of different
>effects.  It's a way for us to not have to invent a unique
>(and sometimes cryptic) character sequence for every
>possible thing we might want to encode.  (HTML is the same 
>way, except it uses <...> as its delimiters.)

My suggestion above is that %red% and %bgcolor=white% are
using the same markup for intrinsically different purposes.
The first is defining a new semantic tag, which may have 
certain style rules associated with it (such as bgcolor=pink;)
and potentially different style rules in different situations,
using (:if:) markup, for example.

The second is purely a presentation rule.

I suggest that we would be better off using different markups.
Indeed, the very name 'wikistyles' is misleading, as it glosses
over the whole issue of semantics. I'd like to see 'wikistyles'
restricted to styles and 'wikitags' used to define new tags.
>
>> A simple example: {=a small note=} is easy to translate into
>> a marginal note for printing. But how do we decide what to do 
>> with %stickynote%a small note% and having decided, how to we
>> then apply the correct markup rule?
>
>If we want to create a special markup for every possible
>structure and meaning we can identify, then this remains easy.
>But the problem is coming up with the special markups in
>a way that people can use and remember them.

Hence my suggestion of a (:define wikitag:) directive.
>
>> <whatWouldHelp>
>> 1. detailed comments in scripts/wikistyles.php that explain
>>    how the code actually works -- please!
>
>That may take a little while.  

(a really clear explanation snipped -- thanks)

>One possible first step would be to drastically limit wikistyle
>use in such applications.  If one changed the $WikiStylePattern
>to only recognize things of the form %stylename% (no spaces,
>no other parameters), then authors would be limited to the
>wikistyles predefined by the administrator or markup rules,
>and it'd be fairly easy to translate them into the appropriate
>print-oriented semantics.  

In other words, just recognise what I called above 'wikitags'.
Yup, I agree!
>
>Another possibility is to replace the ApplyStyles function
>with something that still computes the wikistyle attribute
>arrays as described above, but then translates those values
>into something more readily understood by the printing
>mechanism.

With possibly different rules for inline and block styles.
>
>Combined with the above, one could decide to allow only
>a subset of the existing WikiStyle attributes; i.e.,
>allow things like color, bgcolor, and float, but don't
>try to accept all of the attributes that PmWiki defines
>by default (which are themselves a fairly small subset of
>everything that CSS defines).

Yes.
>
...
>
>If I were working on something like this, I think I'd
>probably start by trying to move as much stuff into
>class='somestyle' attributes and ignoring anything
>that appears in the style='...' attribute of HTML
>output tags.  Printing would then focus on the standard
>set of class='...' attributes that are defined by the
>administrator and look for delimiting things based on
><span class='xyz'>...</span>  and <div class='xyz'>...</div>,
>where the xyz's are already predefined by the administrator
>and the formatter.

Yes, except that we never see the html, only the wiki markup.
So we'd pick up a subset of %...% and >>...<< tags. The
rest would be ignored.
>
>It's not a great answer, but it's the best I have at the
>moment.
>
>Oh wait, no it's not -- I just thought of another.  :-)
>Instead of trying to parse the HTML, it certainly wouldn't
>be hard to associated custom names with specific wikistyles
>that are generated into the output.  Thus if we defined
>%postit% as
>
>   %define=postit rframe bgcolor=yellow latex=postit%
>
>then the wikistyles code could generate
>
>    <!--latex=postit-->
>    ...
>    <!--/latex=postit-->

What I think we'd do is generate:

<tbook:group type='postit'> 
...
</tbook:group>

Where <group> is a tag in the print dtd namespace.
We'd handle inline wikitags in a similar way, with a
<tbook:style type='hotnews'> tag.
>
>around the text to be styled.  Or, the value 'postit'
>for 'latex=' could be a lookup key for an array that has
>the custom latex start-and-end sequences to be generated
>for anything being styled by the postit wikistyle -- i.e.,
>something like
>
>    /postit{ ... }
>
This part would be done in the xslt processing of the 
<group type='postit'> tags -> LaTeX.

>This wouldn't entirely help with combined wikistyles like
>
>   >>postit bgcolor=blue<<
>   ...
>   >><<
>
>but at least the markup interpreter would be correctly
>render the enclosed thing as a postit note block as
>opposed to some other block.

I think we'd probably ignore the style specification...
And IMHO, we are really overloading the wikistyles markup
when we allow it to include both wikitags and styles.
If they were separated, 

<postit>%bg-color=blue%
...
<>

wouldn't that make it simpler to process? What do you
think, is this approach worth discussing further?



-- 
JR
--
John Rankin






More information about the pmwiki-users mailing list