Hi there, I have recently published a blog post on how I use Bike as a scientist to streamline my participation the peer review process: Scientific refereeing using Bike Outliner.
Potentially of interest is that I have created an XSLT stylesheet to more reliably convert Bike outlines to idiomatic HTML, which can then be processed by Pandoc into reasonable Markdown. This is important because of the plain text and Markdown format requirements of most scientific conference peer review systems. You can see my scripts here: ~jonsterling/bike-convertors - Scripts to convert Bike outlines to standard HTML and Markdown. - sourcehut git
Thanks for sharing, this looks really interesting. I haven’t had a chance to really look into it and run the scripts, but will try it out this weekend.
Excellent ! Many thanks for doing this, and for sharing it with us.
Out of interest – you are are choosing to skip | xhtml:s in your main match ?
(if added, it seems to work, and leads to markup like ~~someString~~ in pandoc markdown output, for example, but perhaps there are other considerations ?)
so I guess that, for other applications, it might prove feasible to generalise your XSL a little to allow for a differentiation between task and ordered.
For some purposes … not sure that pandoc reads that html pattern back …
P.S. @complexpoint Thanks so much for the kind words! I have thought a lot about these topics and it is really exciting to see that others are interested in them too, and seeing vibrant communities around tools like Bike (and hopefully, in the future, Forester) is a breath of fresh air. Always happy to chat about such things
I look forward very much to chatting – perhaps in a parallel channel ? – about questions posed by this latest crisis in the life of text (Forester is the most encouraging development that I have seen).
Thanks for sharing this very interesting-looking book — I will certainly add it to my reading list. As for a venue to chat further, feel free to email me to discuss more — for private communications, I can be reached at js2878 [at] cam.ac.uk, and for public communications, you can use ~jonsterling/public-inbox [at] lists.sr.ht.
All the excitement here motivated me to try this out early, before I take the day off for a boat ride.
It’s really nice! The examples and scripts were easy to get going. I always hoped using html as a file format would enable more projects like this.
Your site is really eye opening too. All those links and references, felt like a hypertext fantasy from the old days, except it was real. I haven’t yet looked into Forester, but that’s on my list now.
It’s maybe a bit superficial, but one thing I got from reading over your site is that Bike’s links are way too bright. I think after I work on outline paths in next release I need to work on styling. Give everyone else a chance to define how outlines look, then I’ll steel my favorite ideas as new defaults :).
I haven’t really thought about links very much… but thinking now… is it kinda backward how links are normally highlighted brighter than the surrounding text? The point of a link (at least one embedded in content, as opposed to navigation) is to expand upon the surrounding text.
When they are bright they instead mostly distract attention away from the surrounding text. It becomes harder to read, and as a result the link loses context. I enjoyed reading through your site where I mostly just read text, and the many links were there in the background if I wanted to expand that text.
Probably missing many other points, but that’s my though for the moment. I want my Bike outline to work like that!
Out of curiosity, have you considered allowing a style option to render links as underlined text in the upcoming styling settings? I’ve found that using color for links can be a bit subtle, particularly in dark mode, where a colored link is sometimes made to appear darker than the other text, which can be harder to read. I always liked the simple underline (particularly if the color of the underline can be controlled!) as one possible option.
<?xml version="1.0"?>
<xsl:stylesheet version="2.0"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xhtml="http://www.w3.org/1999/xhtml" exclude-result-prefixes="xhtml">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />
<xsl:strip-space elements="*" />
<!-- Draft extension of Jon Sterling's jms-0084 template
http://www.jonmsterling.com/jms-0084.xml
1. Handles Bike task rows by prepending Unicode ballot box chars.
2. Includes Bike strikethrough (xhtml:s)
Note: Pandoc reads ballot chars from HTML back to MD - [ ] and - [x],
and in time it should also read the task output format of the HTML writer.
See: https://github.com/jgm/pandoc/issues/9047
Rob Trew @2023-09-04
Draft adjustment 0.1
-->
<xsl:template match="xhtml:html | xhtml:body | xhtml:code | xhtml:strong | xhtml:em | xhtml:mark | xhtml:s">
<xsl:copy>
<xsl:apply-templates select="node()|@*">
</xsl:apply-templates>
</xsl:copy>
</xsl:template>
<!-- Bike leaves a lot of empty <span> elements behind; we drop these. -->
<xsl:template match="xhtml:span">
<xsl:apply-templates />
</xsl:template>
<!--
Bike uses <ul> for all lists; the list type is determined not at this level, but rather by each
individual item's @data-type attribute. To get this data into the HTML list model, we must group
items that have the same @data-type and wrap them in an appropriate list-forming element.
To do this, we use XSLT 2.0's <xsl:for-each-group> instruction to group adjacent <li> items by
their @data-type attribute. We must convert @data-type to a string: otherwise, the transformer
will crash when it encounters an item without a @data-type attribute.
-->
<xsl:template match="xhtml:ul">
<xsl:for-each-group select="xhtml:li" group-adjacent="string(@data-type)">
<xsl:choose>
<xsl:when test="@data-type='ordered'">
<ol>
<xsl:apply-templates select="current-group()" />
</ol>
</xsl:when>
<xsl:when test="@data-type='unordered' or @data-type='task'">
<ul>
<xsl:apply-templates select="current-group()" />
</ul>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="current-group()" />
</xsl:otherwise>
</xsl:choose>
</xsl:for-each-group>
</xsl:template>
<xsl:template match="xhtml:li">
<xsl:apply-templates />
</xsl:template>
<xsl:template match="xhtml:li[@data-type='ordered' or @data-type='unordered']/xhtml:p">
<li>
<xsl:apply-templates />
</li>
</xsl:template>
<xsl:template match="xhtml:li[@data-type='task']/xhtml:p">
<li>
<p>
<xsl:choose>
<xsl:when test="../@data-done">
☒ <xsl:apply-templates />
</xsl:when>
<xsl:otherwise>
☐ <xsl:apply-templates />
</xsl:otherwise>
</xsl:choose>
</p>
</li>
</xsl:template>
<xsl:template match="xhtml:li[@data-type='heading']/xhtml:p">
<xsl:element name="h{count(ancestor::xhtml:li[@data-type='heading'])}">
<xsl:apply-templates />
</xsl:element>
</xsl:template>
<xsl:template match="xhtml:li[@data-type='quote']/xhtml:p">
<blockquote>
<xsl:apply-templates />
</blockquote>
</xsl:template>
<xsl:template match="xhtml:li[@data-type='note']/xhtml:p">
<p>
<em>
<xsl:apply-templates />
</em>
</p>
</xsl:template>
<xsl:template match="xhtml:li[not(@data-type)]/xhtml:p">
<p>
<xsl:apply-templates />
</p>
</xsl:template>
</xsl:stylesheet>
@complexpoint This looks fine, would you like to submit a Git patch to ~jonsterling/public-inbox@lists.sr.ht using the instructions here? https://git-send-email.io
[If this is too arduous, lmk and I will adapt your changes when I have a chance.]
