Getting around div tags

[Andy Fragen]

*This message was transferred with a trial version of CommuniGate(tm) Pro*
I was actually using CSS for an inline list that is specific to a page or
a set of pages. I wanted to use Markdown to code the list and just have
the div surrounding it for the inline block format.

It was in an effort to show a friend how much less overhead using CSS and
no tables and minimal images would do for his business site. If you
really want to see it I can put it up.

-- 
Andy Fragen

On Sat, Mar 20, 2004, John Gruber said:

>
>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.
>_______________________________________________
>Markdown-discuss mailing list
>Markdown-discuss at six.pairlist.net
>http://six.pairlist.net/mailman/listinfo/markdown-discuss