Systematic in-browser comparison between rendered markdown & expected literal html

[ellisonbg]

Just wrote some JS that can be put into a notebook that can compare the rendered markdown with the target HTML.

%%javascript
var items = $("div.text_cell_render.rendered_html").map(function() {
    return this.innerHTML;
});
var n = items.length;
var i;
for (i=0; i<n; i=i+2) {
    if (!(items[i]===items[i+1])) {
        console.log("Doesn't match: ", i, items[i])
    }
}

This will compare even with odd numbered cells. For the notebooks that have the headers, will need to play with the loop variables.

[mpacer]

I think it'd be better to test it using the script (i.e., in python) directly rather than switching languages (just to make it easier to incorporate as one CI step).

I think rather than relying on a numbering scheme it would be better to use cell-tags to do two things.

1. Label which cells are markdown cells and which are direct renders. (equivalent to the odd/even distinction we have now)
2. Pair each individual cell and it's direct render.

So there will be a total of 2+number of tests unique tags being applied in this scheme and it will allow us to uniquely identify the matches even if they got shuffled around.

[ellisonbg]

The issue is that the rendered markdown is not saved in the notebook, so we have to do the testing in the live notebook. But I like the idea of using cell tags to help organize the code.

On Fri, Jun 16, 2017 at 2:53 PM, M Pacer notifications@github.com wrote:

I think it'd be better to test it using the script (i.e., in python) directly rather than switching languages (just to make it easier to incorporate as one CI step).

I think rather than relying on a numbering scheme it would be better to use cell-tags to do two things.

1. Label which cells are markdown cells and which are direct renders. (equivalent to the odd/even distinction we have now)
2. Pair each individual cell and it's direct render.

So there will be a total of 2+number of tests unique tags being applied in this scheme and it will allow us to uniquely identify the matches even if they got shuffled around.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter_markdown/issues/2#issuecomment-309143083, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0AKp66Jdcl42SMYCy9OH64NK-ytmks5sEvlpgaJpZM4N8-o2 .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[jzf2101]

@mpacer this issue seems sprint friendly?

[mpacer]

The original scope of this seems reasonable for a sprint — it's not really programmatic though in that it cannot be run programmatically, but only with human input (#8 is more what I would mean by programmatic).

I'd say that as originally suggested, this could be sprint friendly. However, I think the even odd distinction is decently indirect should not be the mechanism that is used to link together the rendered markdown vs. literal html. That would suggest that while this is (somewhat) sprint friendly implemented it should only be implemented after #5 has been.

[mpacer]

I would suggest that #11 should also be completed before pursuing this issue.