Getting around div tags

Sat Mar 20 16:05:20 EST 2004

I agree that Markdown should never, ever touch explicit inline or 
block-level markup, or anything contained within it.  To do so is more 
than just a huge can of worms:  it would change the character of the 
tool.

Asking why somebody would embed <div>s in a content blob doesn't just 
satisfy an agnostic curiosity, it points to the slippery slope.  Are we 
marking-up blobs or creating whole documents?  <div>s are only useful 
for setting context, which can be done in a wrapper to the Markdown 
blob -- or embedded explicitly in the blob if you accept the condition 
that you're on your own within your div.  Or table.  Or whatever.

Pseudomarkup goes to pot when it forgets the size of its britches, its 
node in the Venn diagram, the outermost concentric container within 
which its benefits sing -- but beyond which it's a fish out of water.  
Contextual and descendant CSS selectors can do the job without that 
div.

And if they can't, that's because the containing markup (via CMS 
implementation or document schema) hasn't been thought through.  With 
no offense to anybody, the day that Markdown tries to accommodate those 
shortcomings is the day it's ruined.  I've seen it happen.  More, more, 
more ... it doesn't stop until all XHTML structure has been 
shorthanded, and hooks for inline attribute declaration are littered 
everywhere.  It's not folly at the margins, it's folly itself.  And 
unreadable.  We already have XHTML for that.

I think it'd be useful to determine that Markdown views its purpose as 
being internal to what we now think of as the XHTML <body> element 
(which I think is already clear), and further that author-specific 
contextual constructs must reside outside of the Markdown blob or be 
embedded at the cost of forfeiting Markdown's utility within them.  
Repeat:  you don't need that div.

IMO, If nothing else, 1.0 should be built-out within these limitations 
and then frozen (not the perfect term).  There could then be a Markdown 
Plus or some such that contemplates the madness beyond without wrecking 
the core.

Cheers,

LQ

++++++++++++++++++++++++++++++++++++
Lou Quillio
P.O. Box 24
Saratoga Springs, NY, USA 12866
518.796.0256 (cell)
http://quillio.com/

On Mar 20, 2004, at 1:35 PM, John Gruber wrote:

> 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
>