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
Fix pre issue + update marked.js #732
Conversation
973bece
to
efaf538
Compare
@tobie, git blame says this is mostly your baby. Hopefully I didn't break it. Would you mind having a looksy. |
gfm: false, | ||
pedantic: false, | ||
sanitize: false | ||
sanitize: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the ones I removed default to either true or false.
Your best bet is to compare https://coremob.github.io/coremob-2012/ with both scripts. |
@tobie, ah, super helpful... some breakage 😢 |
I am concerned about a comment you made in the spec-prod email about IDs on section elements no longer being provided. I wonder about the A11Y impact of that on screen readers and navigation. Also on other parts of ReSpec or plugins that might expect sections to have IDs. @LJWatson can you provide any insight on the A11Y front? |
Very few people use markdown, afaict. |
I am sure you are right. I had forgotten it was supported. |
Specs I've found - mostly by @igrigorik: |
Found via: Will check those tomorrow and see what I broke with Core Mob. |
hmm... seems I need to convert all HTML nodes except section into text, then parse them as markdown. should be easy to do... famous last words. |
d471db2
to
ea80498
Compare
Ok, this seems happy |
And it passes!!!! 💃 woot woot! |
* <h3>Another subtitle</h3> | ||
* <p>More text.</p> | ||
* </section> | ||
* </section> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The //
to /* ... */
style change makes it super hard to figure out if the content changed or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. Sorry about that.
ea80498
to
5b41c6f
Compare
I've checked the spec list also. They all seem to parse correctly. |
@tobie, maybe you could give it a once over? let me know if it looks ok to merge. |
define( | ||
['core/marked'], | ||
function (coreMarked) { | ||
marked.setOptions({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So there's something fishy going on here with regards to the global marked
object and the module coreMarked
object. My hunch is that I had reasons to do this. I'm not sure why I didn't document them, though. It could also just be a refactoring mistake that I failed to notice because I was then hitting the global marked object.
You might want to check whether coreMarked
and marked
now point to the same thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will check. Remember I also updated marked... so there should not be a global (coreMarked).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked. Marked no longer leaks into global scope.
@tobie I only did very minor refactor of |
I wrote this a while back, now, so memory fails me, but iirc, the reason for this is that the rest of the pipeline expects nested sections, so you basically have to recreate the nesting from the flat H1-6 hierarchy that the markdown parser provides. |
if (typeof text !== "string") { | ||
throw TypeError("Invalid input"); | ||
} | ||
var hasOpeningPre = testRegex(/<pre\b[^>]*>/i); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conceptually hostile to the idea of recreating your own mini HTML parser using regexes here given you're in a browser and can leverage the native one. Maybe that's the onlu sane solution, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give this some thought... I could work with a live DOM, and check if .parentElement
is <pre>
Alright--done with the questions/comments here. |
Thanks @tobie! Great feedback. Will fix up! I'm wanting to add language-based syntax highlighting next via highlight.js Moar goodies coming soon 5 May 2016, at 8:09 PM, Tobie Langel notifications@github.com wrote:
|
5b41c6f
to
5705209
Compare
@tobie, I rewrote it to use a HTML parser as you suggested. You were right: using regex for parsing HTML was a disgrace. |
5705209
to
d8f5944
Compare
* develop: v3.2.122 Fix pre issue + update marked.js (#732) Chore(TravisCI): Test against Node 6 chore(package): update karma-mocha-reporter to version 2.0.3 (#740) chore(package): update nightmare to version 2.4.0 (#741) chore(package): update karma-safari-launcher to version 1.0.0 (#739) chore(package): update karma-firefox-launcher to version 1.0.0 (#738) chore(package): update karma-opera-launcher to version 1.0.0 (#737) chore(package): update karma-jasmine to version 1.0.2 (#736) chore(package): update karma-jasmine to version 1.0.0 (#734) chore(package): update karma-requirejs to version 1.0.0 (#733) chore(package): update karma-ie-launcher to version 1.0.0 (#735)
No description provided.