neo4j-contrib / graphgist

Easy publishing with graph data included
http://gist.neo4j.org/
208 stars 68 forks source link

AsciiDoc's "+++" directive/syntax no longer rendering #39

Closed Jim-Salmons closed 8 years ago

Jim-Salmons commented 8 years ago

The Graphgist 'engine' used to respect and render user-defined CSS and HTML using the opening/closing "+++" tag. This no longer works and is essential for supporting more creative #graphgist presentations. This example in source:

 https://gist.github.com/Jim-Salmons/8bdcc380cbb240c7d17a

And as currently rendered:

http://neo4j.com/graphgist/
mojavelinux commented 8 years ago

@nawroth was this change intentional or an unintended consequence of an upgrade?

@Jim-Salmons I'm assuming you mean both the inline syntax (+++) and the delimited block:

++++
<style media="screen" type="text/css">
...
</style>
++++
cheerfulstoic commented 8 years ago

Probably easy to fix, I'll have a look now.

The state of GraphGists is still being worked on, but probably the best place to preview a gist currently is here:

http://portal.graphgist.org/submit_graphgist

Jim-Salmons commented 8 years ago

I'll try the new portal to see if it behaves differently and report if there are any observable differences.

One thing to remember is that no matter how much you want to direct gist submissions through the new portal, there are a LOT of significant link references that point to and use the rendering "home url" pointing to the neo4j.ORG domain name (which currently redirects to the .COM variation). So it is important to keep that rendering option open otherwise a LOT of older Graphgist references on the web will be broken and that would be bad for both the authors AND Neo4j.

Thanks for looking into this. My #TextSoup2SmartData research partners will be submitting two entries in the upcoming Knight News Challenge on "Libraries in the 21st Century." We'll want our old and new Graphgists to have plenty of WOW factor to them. :-)

And yes on support for both in-line HTML and CSS style blocks. For example, the FactMiners' "Where Facts Live..." graphgist mentioned in my initial tweets rendered perfectly when it was written. The Contents block was styled and sized as were the various images, margins and alignments handled, etc. IOW, if there is a fix for this issue, it would be reasonable to test with this gist as it used to work and look WAY better.

http://goo.gl/gS2FJk For the rendered version and
https://goo.gl/ZfOZR1 for the Github source
Jim-Salmons commented 8 years ago

Okay progress! Here is the URL for this old gist processed by the new submission/rendering portal:

http://portal.graphgist.org/graph_gists/54e1f7e2-4e7a-469e-a60d-ea34c904b020

The style block is still visible and the embedded styles are not tweaking the Contents block or sizing/aligning images, but it is not bad looking in general.

I'll update my other issue, too, as you can see in this example that the new portal correctly renders the full-screen and SVG download icons in the //graph pane. However, my clicks on full-screen in Chrome on iOS did not trigger the full-screen display.

Once this issue is understood across the old new submission portals, it will be important to bring the old portal in line with the new one to ensure that old Graphgists don't deteriorate.

mojavelinux commented 8 years ago

no matter how much you want to direct gist submissions through the new portal, there are a LOT of significant link references that point to and use the rendering "home url" pointing to the neo4j.ORG domain name

:+1:

The new portal uses a different technology stack (Asciidoctor Ruby instead of Asciidoctor.js, AFAIK), so it's understandable why the results would be different.

cheerfulstoic commented 8 years ago

<style> tags can be used now. In the new portal after gists are processed they are stripped of any non-whitelisted tags/attributes for security. If you'd like to see the list the code for the portal is here:

https://github.com/neo4j-examples/graphgist_portal

And the list of whitelisted tags / attributes is here:

https://github.com/neo4j-examples/graphgist_portal/blob/master/app/models/graph_gist.rb#L74

I'm happy to add others as you catch them, though I don't think we can allow the <script> tag.

The two older GraphGist portals did use Asciidoctor via javascript, but I thought it was all Opal'ed from the Ruby gem. ASFAIK all of the actual rendering has happened from the original asciidoctor gem.

cheerfulstoic commented 8 years ago

I commented too soon, it's not quite yet done deploying. See status here:

https://snap-ci.com/neo4j-examples/graphgist_portal/branch/master

cheerfulstoic commented 8 years ago

You're welcome to use the style, though as we start putting GraphGists on neo4j.com I do worry that there will be style conflicts between custom style and the neo4j.com style which can't be predicted. I'd suggest being defensive in your CSS rules.

Jim-Salmons commented 8 years ago

There may be edges to polish etc., but the progress of seeing the styling back on my old gist through the new portal is SUPER. Congrats on that.

cheerfulstoic commented 8 years ago

:+1:

FYI, be aware that in addition to previewing on the submission page, there is a "Open preview in new page" link that appears on the submission page which allows you to preview the gist full-screen without submitting it into the portal, if that's what you want.

mojavelinux commented 8 years ago

The two older GraphGist portals did use Asciidoctor via javascript, but I thought it was all Opal'ed from the Ruby gem.

That's true, but based on how Asciidoctor.js works (and JavaScript in general), it has to inject the result into the page after it loads instead of it just rendering a standalone HTML file. That changes how things get processed (esp script and style tags), hence the differences.

mojavelinux commented 8 years ago

I'd suggest being defensive in your CSS rules.

This is a good recommendation, in general. You should try to avoid at all costs using custom CSS in the AsciiDoc file because that doesn't ensure portable results. Better is to agree on known role name with the platform (perhaps via a platform style guide) and stick to using those. Yes, this does make things more limited, but it also makes everything more predictable and secure.

mojavelinux commented 8 years ago

In my opinion, GraphGist shouldn't be treated/seen as a general publishing tool which allows arbitrary, custom layouts. Then you are making AsciiDoc do something for which it wasn't designed. AsciiDoc is really about using built-in semantics or semantics added by agreed upon extensions.

mojavelinux commented 8 years ago

That gives the platform the ultimate flexibility in transforming those inputs into a very professional result.