Andy Fragen <lists at thefragens.com> wrote on 03/19/04 at 10:41a:
> I just joined the list and I've already encountered this problem.
Can I ask why you're using `<div>` tags within an article body? Just
curious -- is there a URL where I can see what you're doing in
action?
> Textile seems to work around the problem in the following manner.
>
> If there is an empty line surrounding the markup, eg a list inside a div
> then the textile markup occurs.
>
> <div>
>
> * item1
> * item 2
> * item 3
>
> </div>
>
> The above would cause texile to markup a list. The following would not.
>
> <div>
> * item1
> * item2
> * item3
> </div>
>
> Is this a potential solution?
Well, yes, it's a potential solution.
But I don't like it. It strikes me as too arbitrary, and also seems
counter to be basic rule-of-thumb for using inline HTML blocks in
Markdown. Which rule of thumb is basically: "Put the start and end
tags for an inline HTML block at the left margin, and Markdown will
preserve the block and not touch the contents."
A "sometimes it will, sometimes it won't" rule adds a lot of
complexity.
It's also the case that Markdown's existing HTML block parser is, in
my opinion, too dumb. For example, if you pass in the following:
<div>
<div>
*Crazy*.
</div>
*Crazy*.
</div>
Markdown *should* leave that completely untouched. But it actually turns it into:
<div>
<div>
*Crazy*.
</div>
<p><em>Crazy</em>.
</div></p>
Because it thinks the outermost `<div>` ends at the first `</div>`.
What you'd need to do, currently, is write the input like this:
<div>
<div>
*Crazy*.
</div>
*Crazy*.
</div>
So that the real end tag for the block is the only one at the
outermost level.
I plan to fix this so that the parser does the right thing and
matches from `<tag>` to `</tag>` with support for nested, balanced
instances of `<tag></tag>` within -- but that's going to be
complicated enough without adding a special case for a blank line
around the outermost tags.
I think the rule is going to remain the same: Once you start an
inline HTML block, Markdown ignores the contents until you close the
block.
So if we want some way to have a div where Markdown *does* process
the contents, it's going to need special syntax, like:
<<div class="foo">>
* Item 1
* Item 2
* Item 3
<</div>>
This way, the rule for raw inline HTML stays the same, and stays
very simple. What we'd be doing is adding a new rule, with new
(non-HTML) syntax.
This is definitely worth thinking about, but it's definitely not
making the cut for 1.0.
-J.G.