Markdown parsing for heading tags
Follow-up from this tweet:
https://twitter.com/falkowski/status/145235916569575424
Screenshot: http://cl.ly/CVPH
The update must have been in the last month or so. Could be just the WYSIWYG code.
Previously, Markdown in Harmony didn't auto-generate an ID for
the element in the processed output. While this is a very nice
addition it potentially invalidates a document by duplicating ID
selectors.
- in the content area - or already existing in the site
A prefix solution (like id="md-old-result-h1") doesn't alleviate this problem in a future-proof or language-agnostic way so I'm ok with the risk.
I suppose the heavy dashes improve Markdown readability in the page editor, but I still prefer the consistent # and ## methods. It's a bit disorienting scanning for both methods.
More importantly I think this hurts longevity (should Markdown fall out of style) because find/replace for the # or ## is simpler than backtracing/replacing if three(?) or more dash/equal chars are found. Overall I'd prefer if the WYSIWYG editor consolidated to one syntax, and I think #'s are the more succinct and realistic option.
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Jonathan Hoyt on 09 Dec, 2011 09:53 PM
Thanks for the heads up, I'll look into it.
Support Staff 3 Posted by Jonathan Hoyt on 26 Jan, 2012 05:22 PM
Brendan, sorry it took me so long to get back with you but I figured out why its adding the id's... The difference is using
vs
The first doesn't add an ID and the second one does. Our editor is setup to use the 2nd style for header 1 and a similar style for header 2, thus adding the ID for easy linking to that spot.
You can switch back to the the first style of headers if you'd like to drop having an ID attached.
Jonathan Hoyt closed this discussion on 26 Jan, 2012 05:22 PM.
Brendan Falkowski re-opened this discussion on 27 Jan, 2012 12:04 AM
4 Posted by Brendan Falkowski on 27 Jan, 2012 12:04 AM
That's incorrect though. Both syntaxes will place a generated ID on the heading element (just tested it again). I think the auto-ID behavior should be removed entirely.
The future-proofness and find/replace problems of the ===== and ------- syntax mean I'll never use it. Clients will click the WYSIWYG 'H1' and 'H2' button though, and that's a problem. Littering their content with mixed syntaxes doesn't help anyone. It would be cleaner to use # and ## syntax only.
Developers are aware and can avoid polluting the unique ID requirement, but clients can't. The only alternative is namespacing all structural IDs which shouldn't be necessary.
In the end, Markdown's implementation simply isn't verbose enough to auto-ID without potential for conflicts. The only fool-proof alternative is not auto-IDing, which still allows raw HTML for creating hashlinks when required.
This is a two-part problem in my mind, and it hasn't been appropriately solved yet.
Support Staff 5 Posted by Jonathan Hoyt on 27 Jan, 2012 07:18 PM
I'll have to see if our markdown processor lets us configure that then and I'll get back with you.
Support Staff 6 Posted by Jonathan Hoyt on 16 Feb, 2012 09:51 PM
Brendan, after much discussion and implementing the fix you requested, we eventually decided that it was not something we wanted to ship to production. While we agree with your argument in principle, the current behavior has been the behavior since 2010, and we have no way of telling who's sites we would be breaking by making this change.
So we will be leaving the markdown processor as is, and headings will get auto ids.
Thanks for your patience on this, sorry its not the answer you were looking for.
Jonathan Hoyt closed this discussion on 16 Feb, 2012 09:51 PM.
Brendan Falkowski re-opened this discussion on 19 Feb, 2012 09:18 PM
7 Posted by Brendan Falkowski on 19 Feb, 2012 09:18 PM
Thanks Jonathan, I can appreciate the legacy content issues.
Since the MD processor won't change with regard to auto-id, is it feasible to change the editor to use #, ##, and ### only? The output is identical but readability and regex-wise consecutive hashes are simpler.
I'm imagining a scenario where the content needs to be stripped of Markdown, and that's not trivial for ===== syntax without manual combing because of newlines and the need to scan backwards in a text stream to evaluate prior lines.
Support Staff 8 Posted by Jonathan Hoyt on 19 Feb, 2012 09:20 PM
That may be feasible. I'll talk it over with a couple of the guys tomorrow and if they agree I'll make it happen.
Support Staff 9 Posted by Jonathan Hoyt on 20 Feb, 2012 04:54 PM
Updating the toolbar right now to use #'s for 1st and 2nd level headings and deploying it to production.
Jonathan Hoyt closed this discussion on 20 Feb, 2012 04:54 PM.
Brendan Falkowski re-opened this discussion on 20 Feb, 2012 06:34 PM
10 Posted by Brendan Falkowski on 20 Feb, 2012 06:34 PM
Thanks guys, working great.
Brendan Falkowski closed this discussion on 20 Feb, 2012 06:35 PM.