Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

anchor id's are inconsistent #278

Closed
jonschlinkert opened this issue Nov 4, 2013 · 7 comments
Closed

anchor id's are inconsistent #278

jonschlinkert opened this issue Nov 4, 2013 · 7 comments

Comments

@jonschlinkert
Copy link

This:

<h1>{{gist}} helper</h1>

produces:

<h1 id="-gist-helper">{{gist}} helper</h1>

For this feature to be useable, I'm resorting to regex replacements on the ID's - which is just as hacky (and almost as much work) as implementing a complete workaround.

I love marked.js, we use it extensively on assemble projects, it would be great if one of the more complete PR's for this was merged in.

@DTrejo
Copy link

DTrejo commented Nov 5, 2013

hey, it is replacing the characters it can't put into the hash with dashes. I'd think the problem is with the {{ rather than the way it makes hashes. Is it like that for templating or something?

@jonschlinkert
Copy link
Author

http://assemble.io/helpers/helpers-code.html

the problem is with the {{ rather than the way it makes hashes. Is it like that for templating or something?

Yes, it's for documentation. So the problem is with the expectation that users should only use certain characters in headings for this solution to work. And if the HTML spec allows me to put those characters in the heading, then the problem is with the overly simplistic regex being used to slugify the heading.

IMO, the implementation for headings is self-indulgent to maintain an ideal with the parser, rather than being sensitive to the needs of users. e.g. "Hey, since marked.js can only properly transform A-Z, don't use any other characters in headings and everything will be fine". I've already commented this effect here: #181 (comment)

@DTrejo
Copy link

DTrejo commented Nov 5, 2013

Ah I see there is some complicated history with this feature. I shouldn't butt in ;)

@jonschlinkert
Copy link
Author

Sorry if I came across like that. You have just as much of a right to weigh in on this as anyone else

Sent from my iPhone

On Nov 5, 2013, at 12:49 PM, David Trejo notifications@github.com wrote:

Ah I see there is some complicated history with this feature. I shouldn't butt in ;)


Reply to this email directly or view it on GitHub.

@DTrejo
Copy link

DTrejo commented Nov 5, 2013

No I wasn't offended or anything don't worry.

What do you think you would like the behavior to be for this?

On Tue, Nov 5, 2013 at 10:51 AM, Jon Schlinkert notifications@github.comwrote:

Sorry if I came across like that. You have just as much of a right to
weigh in on this as anyone else

Sent from my iPhone

On Nov 5, 2013, at 12:49 PM, David Trejo notifications@github.com
wrote:

Ah I see there is some complicated history with this feature. I
shouldn't butt in ;)


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com//issues/278#issuecomment-27800793
.

See my projects at dtrejo.com

@jonschlinkert
Copy link
Author

I like @ChrisWren's solution here: #181 (comment). However it's achieved I think a simple interface for custom functions would provide users with as much power and flexibility as they need. And really, I'd prefer almost any solution over having marked.js make decisions about how to attributes to my markup.

@ChrisWren
Copy link
Contributor

you can now use the renderer to have custom ids

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants