Attribute references
John Gruber
gruber at fedora.net
Sun Jan 9 20:40:45 EST 2005
Aaron VonderHaar <gruen0aermel at gmail.com> wrote on 01/09/05 at 11:49am:
> ===
> <h2 id="the_louisiana_purchase">The Louisiana Purchase</h2>
>
> <p>Napolean was, unquestionably, a brilliant military strategist, but
> he was not a very good real estate manager.</p>
> ===
>
> using some hopefully simple mechanism of convert-to-lowercase,
> remove-symbols, replace-spaces to generate the id.
>
> That is, /every/ header would automaticaly have an id.
I thought of this prior to released 1.0 publicly, but the problem is
how Markdown would manage duplicates. You could have input
structured like this:
## Product A
### Pros
Blah Blah.
### Cons
Blah blah blah.
## Product B
### Pros
Blah Blah.
### Cons
Blah blah blah.
In which case Markdown would need to assign unique id's to multiple
<h3>'s which contain the same tag content. You could do something
where you add numbers to the end of the auto-assigned id's, but,
then if you rearrange the article during editing, the id attributes
for certain elements might change.
Same if you change the text of a title -- the id for that title
would change too.
I think this is too hard for a human to predict while writing. You'd
need to process your Markdown first, to see what id values were
generated, before you created your inline references to those id's.
Plus, you also run into the potential problem where you might use
the same structure for each post on a weblog. E.g. if you always
have an h3 called "Conclusion" at the end of every entry. Now, what
happens if your weblog home page displays your N most recent
entries? You'd have N `<h3>` tags each with the id "conclusion" or
"conclusion-1".
So, to be rigorous, I think automatically generated id attributes
would need to contain some sort of GUID, which in turns means
they're not going to be short or human-guessable.
-J.G.
More information about the Markdown-Discuss
mailing list