Well, recently I have run into a few situations where I wanted to be able to inject raw HTML and JavaScript into my blog entries without relying on the mercy of the Markdown parser. So, I prototyped a quick solution earlier today, and polished implementation this evening. Now, to write raw HTML/JavaScript inside of a LifeFlow blog entry, you can now type:
~~~
Can I do this now?
~~~
But, since I was already in the neighborhood, I took it a bit further. If you have the docutils package installed, you can render a segment of reStructuredText like this:
~~~ReST
+------------------------+------------+----------+
| Header row, column 1 | Header 2 | Header 3 |
+========================+============+==========+
| body row 1, column 1 | column 2 | column 3 |
+------------------------+------------+----------+
| body row 2 | Cells may span |
+------------------------+------------+----------+
~~~
It doesn't matter if you capitalize ReST correctly or not, as long as its spelled correctly. You can also use this same trick to render Textile markup as well (if you have the Python Textile module installed):
~~~textile
|_. Header |_. Header |_. Header |
| Cell 1 | Cell 2 | Cell 3 |
| Cell 1 | Cell 2 | Cell 3 |
~~~
Although, I'd readily admit that this is a bit of an inane thing to do, I think being able to mix and match markup languages (and temporarily disable the markup language altogether) will actually end up being rather helpful. In particular when trying to incorporate the work of other authors (or trying to post snippets of documentation). Also, it can be a real pain to write about Markdown syntax using Markdown, so now the (overachieving) author could switch temporarily to Textile to write about Markdown before reverting to Markdown. A bit of a head trip, that.
If anyone is interested, extracting this into a generic Python Markdown module wouldn't be difficult, just the matter of moving a copy of the django.utils.encoding.smart_str function into the lifeflow.markdown.mdx_foreign_formats file.
Are my <code> tags not using a fixed width font? Really? Is that what is happening here? Hrm.
Looks like the first declaration in screen.css is the culprit. Either take pre out of the reset, or change its font-family.
Cool. Went in and fixed it up first thing this morning (may have to reload the page to get a refresh of the css file), so code blocks are making a bit more sense now.
Thanks for pointing out where it was going wrong Luke.
Reply to this entry