in reply to Re: Markdown syntax useful to the Monestary?
in thread Markdown syntax useful to the Monastery?

I also think that some form of simplified markup would benefit PM, even if it only persisted until the node was commited.

It's rarely a chore to edit existing html for correction of typos and similar, but hand generating lists and tables is a pain.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^2: Markdown syntax useful to the Monestary?

Replies are listed 'Best First'.
Re^3: Markdown syntax useful to the Monestary?
by davido (Cardinal) on Oct 29, 2005 at 07:17 UTC

    Speaking of editing...

    Currently Janitors can look at how a node was originally typed-in, and make judgements as to how it was intended to be formatted, even if formatting is missing. They can also look at a node where formatting was used, but used improperly, and quickly ascertain what needs to be done to repair an unreadable node. Imagine if we had to learn all these different flavors of markup. I know you mentioned that the alternate markup form could persist only until the node is committed. But that presents its own problems for Janitors: Nodes that have passed through some sort of preprocessor probably won't retain the original characteristics of how they were typed-in. In other words, we may not be able to see where the author hit enter expecting a new line in his post, if the node has passed through a preprocessor. ...that's just one simple example.

    So if the node persists in its typed-in format, we'll have to learn multiple flavors of markup. If it doesn't persist in its typed-in format, we won't be retaining the node's original behind-the-scenes characteristics. Either scenario presents its own problems for Janitors.

    Now putting all that aside... If some sort of alternate markup were to be implemented here, rather than making it an explicit "user settings" checkbox, how about making it a tag at the beginning of the post, such as:

    <!-- use Markdown --> The rest of the post goes here, in its alternate layout. <!-- use HTML (the default) --> Everything after this point can be typed in HTML format.

    The advantage to this is that an individual node could be typed using several markup formats, switching between them using some sort of tag. In practice, people who prefer one format could simply include the necessary tags for that format in their node template, also contained in user settings.


    Dave

      It's probably a naive view by someone that hasn't witnessed the range of errors that you guys correct, but it seems to me that something like markdown ought to reduce your workload.

      If the conversion filter is any good, it will fail to allow commitment of a post that fails to produce acceptable html from it's markup and prompt the user to correct it before it will perform the conversion.

      The way I envisage it working is that once the filter accepts the markup, it sends the html back to the user and discards the markdown. The user then has to preview the html in raw and formatted states (as now) before submitting, giving them the chance to amend the html if desired. They could also hit the back button to return to the markdown version and tweak it further, before again attempting the conversion.

      In this way, the only markup stored is the html, the markdown would simply be an intermediate shortcut to arriving at acceptable html. And if that html is produced by a filter, it ought to be free of errors. If the user modifies the html, there is the possibility that they will screw it up, but that's no different to now, accept that they would be starting from an acceptable starting point without missing end tags or (PM) illegal tags.

      The same thing could be achieved by using an offline conversion I suppose, which would have the advantage of allowing a proper editor to be used instead of the editbox I'm currently typing in. The problem with that is either everyone has to produce their own filter/editor/submit/verify/re-edit script, with the consequent mish-mash of complience with site html standards. Or, someone produces a standard module for doing it and tries to make it general enough to work with the 1000 varieties of preferred editor.

      It's far from a big thing, just a convenience, if it is possible, and it doesn't impact the servers too much.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.