Include URL's in PDF-ized paper about article-reproducability HOT 14 CLOSED

New solution for the original problem: mark all links that need to be printed with a mandatory class.
For instance:

[Components.js](https://github.com/LinkedSoftwareDependencies/Components.js){:.mandatory}

from article-reproducability.

I couldn't go for the footnote option, as this would create a discrepancy between footnotes on screen and on print (i.e., "footnote 5" would not be the same anymore). I have now turned on full URLs for all external URLs in print, but that seems too much.

I would propose that we give such URLs a special CSS class. Something like expand, except that CSS classes shouldn't be behavior based. It should be something to indicate the importance of the URL. Any suggestions?

from article-reproducability.

Regarding the footnote option, what about adding something like a "link" prefix? So instead of having "footnote 5", you would have "footnote link 5". This would solve the discrepancy, but may be less clean than having pure footnotes all the way.

Alternatively we can just hardcode the links as footnotes, or let the preprocessor do that automatically.

from article-reproducability.

The problem is that it doesn't really make sense to have those links as footnotes in the browser version. We can automatically create footnotes, that's okay, but we don't need them in the browser version.

If we would remove them from the browser version, then the footnote numbering would become incorrect, because some would be missing.

from article-reproducability.

Ok, then prefixing the footnote id for links or expanding the URL's inline seem like the only options for print.

Alternatively, we could try to do some CSS magic to automagically create footnotes for links in print only, and calculate the id's with CSS (maybe calc() can do this?).

from article-reproducability.

There's no current way in CSS to fix the references to footnotes in such cases, so I'd go for inlining.

from article-reproducability.

Some ideas for classes:

• informative for links that should not be expanded.
• important for links that should be expanded.

Maybe there is an ontology around for these things?

from article-reproducability.

We could also not use footnotes in the screen version at all, and just keep them for the URLs. The information currently represented in footnotes could then be represented in some other way (I always find it weird to have footnotes on a website tbh)

from article-reproducability.

That's a good idea, @joachimvh. However, it requires moving the footnotes (JavaScript can do this).

from article-reproducability.

We don't have to remove the idea behind footnotes, we can use sidenotes, I think @pietercolpaert did that in his paper.

from article-reproducability.

@joachimvh I also found it weird to use references and footnotes on websites, only to find out that wikipedia actually uses these all the time. Still not a big supporter of these on screen however ;)

@rubensworks - Indeed! Doing that for my PhD and @RubenVerborgh did that as well :)

from article-reproducability.

Just some info on what https://github.com/linkeddata/dokieli is doing with footnotes at the moment:

<aside class="note"> is used at the end of a <section> (like a particular heading would be in a section).

• If the code is manually entered, i.e., the aside and whatever freestyle markup is placed within, on screen that shows up at the end of the respective section, however on print it'll be wherever - unfortunately, CSS paged media is still not well implemented in browsers. Normally, the reference point (an anchor) just points at an identifier inside that aside.

• If dokieli's interface is in Edit mode, the user can select a span of text in content, click the note option, and then annotate it by entering some text, tags, and license. On screen, the footnote will show up in marginalia (next to the reference point) and the reference (the selected text in body) will be marked and point to the footnote. Semantically speaking, this is the most accurate way of doing references. The RDFa and Web Annotation bling-bling is in there. Having said that, when printed the marginalia bit doesn't show up at the moment - this is a bug / incomplete / dokieli needs to make an exception to this sort of content and actually display it in print.

The other option is of course to add footnotes at the end of the document, just like references (and I think that's what you have now). I have experimented with this in the past, but didn't stick to it in dokieli because it didn't seem like it added much on top of the ordinary References section The rationale was that, if it is going to end up at the end of the document in print, might as well add sufficient information around it and move it under References. That sort of footnote is of course not a reference (a "proper" citation), but again, the rationale is that everything is some sort of a reference, so it can go in there :) Not perfect, but whatever.

Without getting JS and some extra CSS involved, there is no ideal print for footnotes for traditional academic article views (like ACM/LNCS) at this time (to the best of my knowledge). So, something has to give. For screen, there are many options.

See examples at https://dokie.li/lncs-splnproc or https://dokie.li/acm-sigproc-sp

from article-reproducability.

Another problem: I want to have normal URLs in my html. As far as I know I have to do this as [http://google.com](http://google.com) since just putting the URL in the text doesn't convert it (which normally does happen in markdown I think?). Problem then is that I get the URL twice in the print version.

from article-reproducability.

So apparently you can also get URLs with <http://google.com>, still has the same url duplication problem though.

from article-reproducability.