david said:> an option, though not a pretty one.it's ugly, yes, but that's not the worst part. the worst part is that it is a lot of work -- especially if you want a table of contents. and then it's obstacle-clutter while editing. it's really something that should be handled by the converter, not something in the text. which, by the way, many of the flavors _do_. but not to the extent that they could or should. in addition to headers, there should be anchors at significant places, such as tables and figures. and again, some flavors do indeed go that far... however there do remain coordination glitches, as different flavors create the anchors differently. some turn spaces to dashes, others to underbars, and some even delete them entirely, meaning that they didn't learn that old expertsexchange lesson. some use camel-case, others go all-lower-case... some include punctuation as-is, others delete it, and still others keep anything allowed in filenames (which varies across platforms, and on the web)... and of course there's the usual utf-8 complication. so, as is typical in this coordination-plagued sphere, users have to actually _look_at_ the anchors to see what they are, which defeats some of the purpose of auto-generating them in the first place. oh well... i'm not even going to suggest that the flavor-makers try to come to an agreement, because we all know that they aren't gonna change what they already do... -bowerbird p.s. i guess beamer has an appeal for some people, but reveal.js is so darn rad, especially its visual editor, that i would really recommend that you check it out... there are also other great web-based presentation-tools, but i can't get at the file with my notes on them right now.
This topic actually just came up at work a few days ago. I had manually inserted named links, aka anchors, into a README.md file. In the code review on my check-in, someone suggested I use "the same format we are already using for the rest of the headings" for "consistency." Puzzled at first, I realized GitHub was automatically generating IDs (and floating link icons, on render) to enable section links. (No, this is not part of GFM, Github Flavored Markdown. It seems to be a subsequent step.) I went ahead and deleted my ugly manual anchors, because Github *does* already provide this, and it made the source cleaner. The downside of this is that now the links I made to various sections will not work if viewed outside of Github (e.g., if someone edits it with a preview on the local computer). As I wrote? at work -- Generating section links is **not** part of Markdown such as it?s defined [by Gruber], and various markdown implementations either do it differently, or not at all. <h3 id="mysectionname">My Section Name</h3> <!-- showdown --> <h3 id="my-section- name">My Section Name</h3> <!-- pandoc, kramdown --> <h3 id="my_section_name">My Section Name</h3> <!-- maruku --> <h3>My Section Name</h3> <!-- most markdown convertors --> As bowerbird mentioned, there is no consistency (hey, there?s that word again) in these auto-generated IDs. Notably, most implementations do not do it at all (as would be expected, given that original Markdown does not, either). See the above example for yourself on Babelmark 2: http://ajh.us/babelmark2-section-ids Cheers, Alan Hogan -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20150708/ebb98b7a/attachment.html>