This might be more of a documentation question than a software question. Chapter 15 of the Learning OJS document for 3.2 says:
The HTML viewer renders HTML files within an iframe, which may affect navigation to hyperlinked web pages. You can bypass this feature by opening hyperlinks in a new browser tab, by adding the target="_blank" attribute to your href tags.
That’s not true in either 3.1 or 3.2, is it? I know it was true in 2.x (maybe it’s not an iframe, but the HTML galley at least inherits some elements from the OJS site), when I’ve played with HTML galleys in 3.1 or 3.2, they always open as their own web pages.
Am I confused or does the documentation need updating?
You’re correct – this was my mistake. We do still use iframes. I believe @ajnyga or @Vitaliy has a theme/galley generation toolset that presents HTML article contents on the article landing page without needing to follow a link to an iframe-based secondary page to view.
Regards,
Alec Smecher
Public Knowledge Project Team
JATS Parser Plugin provides an ability to display the article’s full-text on the landing page but it accepts JATS XML as input for text generation. It may require additional styling unless Old Gregg theme is used.
I’m interested in enabling this more generally via the HTMLArticleGalley plugin.
I’m presuming we would use the following assumptions:
Allow for the plugin to turn on or off an option which embeds the HTML directly in the page rather than using an iframe.
Allow for the journal to continue to upload the well-formed HTML as a galley. This version would continue to be served out when the article is “downloaded”.
When displayed without an iframe, the uploaded HTML would have the contents of the body tag extracted and embedded directly in the article template.
The contents could be wrapped in a new div tag, with a new class, like “htmlArticleGalleyBody”. If the editor wants a containing div, it should be entered as part of the HTML galley. This way, the journal staff can choose, and can apply their own class names.
The contents of the head would be explicitly excluded, not merged into the OJS rendering.
Journal staff would be required to replicate any CSS and javascript desired in both presentations, once in the head of the HTML galley upload, and once in the custom stylesheet(s) and custom header(s) of OJS.
Duplication of header levels, like h1, h2, which could occur in both the galley body and the OJS body, is not addressed.
What else should be considered here?
Question: How should download links to the HTML be exposed? Should it be done on the abstract page, on the galley view, or both? Should it be optional?
Please, help me! I have already load a lot of HTML galleys on OJS. None of them have the attribute “target=_blank” on a link -a silly UX recomendation-, even in references lists, wich are huge.
How can I add the attribute as a bulk action?
Do you know a javascript or jquery to add to every HTML document in order to activate the correct opening of links? I have tried some, but no one is working, I don’t know why.
What is the nature of the recommendation of target="_blank"? Is this specific to showing links in an iframe?
A bulk update of the files would be challenging (you would need to update both the actual files on the filesystem, and the corresponding metadata in the database). A javascript could modify the links at the point of display, but is a bit of a kludge.
The recommendation of target="_blank" is unfamiliar to me however.