Getting around div tags
public at quillio.com
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
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
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
P.O. Box 24
Saratoga Springs, NY, USA 12866
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
>> 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
>> then the textile markup occurs.
>> * item1
>> * item 2
>> * item 3
>> The above would cause texile to markup a list. The following would
>> * item1
>> * item2
>> * item3
>> 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
> 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:
> Markdown *should* leave that completely untouched. But it actually
> turns it into:
> Because it thinks the outermost `<div>` ends at the first `</div>`.
> What you'd need to do, currently, is write the input like this:
> 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
> 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
> 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.
> Markdown-discuss mailing list
> Markdown-discuss at six.pairlist.net
More information about the Markdown-discuss