Extending/overriding link parsing behavior

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Extending/overriding link parsing behavior

thoraxe
I am trying to generate a link that looks like the following:

<a href="#" class="js-scroll-to" data-target="#tutorial-intro">Introduction</a>

The following gets me close:

. link:#[The first thing, role="js-scroll-to", data-target="#first-thing"]

Yes, this is in a list.

The resulting HTML looks like:

<a href="#" class="js-scroll-to">The first thing</a>

The "data-target" is either not being processed or the underlying parser/processor doesn't know what to do with it.

I poked around in the backends (https://github.com/asciidoctor/asciidoctor-backends/tree/master/haml/html5) but "link" doesn't appear to an item processed by a template, so it's probably in the guts of asciidoctor somewhere.

I searched around in the code for "http" and then realized I should search for linkattrs, and that ultimately leads me to:

https://github.com/asciidoctor/asciidoctor/blob/v1.5.4/lib/asciidoctor/substitutors.rb#L1238-L1254

And there I am lost.

It looks like it *should* work... but it does not?
Reply | Threaded
Open this post in threaded view
|

Re: Extending/overriding link parsing behavior

mojavelinux
Administrator

On Wed, Mar 30, 2016 at 2:41 PM, thoraxe [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I poked around in the backends (https://github.com/asciidoctor/asciidoctor-backends/tree/master/haml/html5) but "link" doesn't appear to an item processed by a template, so it's probably in the guts of asciidoctor somewhere.

The node is called "inline_anchor". It handles all the different link varieties (anchors, xrefs, bibrefs and regular links).


Since you are making an xref (in the template, the :xref key), you can type it as follows:

. <<tutorial-intro,Introduction>>

or even just:

. <<tutorial-intro>>

Then you can customize the inline_anchor template to generate:

<a href="#" class="js-scroll-to" data-target="#tutorial-intro">Introduction</a>

You probably don't want to add the role "js-scroll-to" to the AsciiDoc since this is an implementation detail and better to be handled in the template.

 so it's probably in the guts of asciidoctor somewhere. 

All output is generated by the converter (and thus the templates), so there's no output that is buried in the core (aside from some very specific exceptions such as the source highlighter integration).

-Dan

--
Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen
Reply | Threaded
Open this post in threaded view
|

Re: Extending/overriding link parsing behavior

mojavelinux
Administrator
In reply to this post by thoraxe

On Wed, Mar 30, 2016 at 3:30 PM, Dan Allen <[hidden email]> wrote:

You probably don't want to add the role "js-scroll-to" to the AsciiDoc since this is an implementation detail and better to be handled in the template.

The general rule of thumb is that the AsciiDoc should only contain information that absolutely must be in AsciiDoc. If the converter can add the information, it should.

-Dan


--
Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen
Reply | Threaded
Open this post in threaded view
|

Re: Extending/overriding link parsing behavior

thoraxe
mojavelinux wrote
On Wed, Mar 30, 2016 at 3:30 PM, Dan Allen <[hidden email]> wrote:

>
> You probably don't want to add the role "js-scroll-to" to the AsciiDoc
> since this is an implementation detail and better to be handled in the
> template.
>

The general rule of thumb is that the AsciiDoc should only contain
information that absolutely must be in AsciiDoc. If the converter can add
the information, it should.
In this particular case this type of link is a scroller link, so why would the role not be appropriate?

How else would the template know what type of link it is?

I guess I am a little lost on the mapping between "roles" and "styles"...
Reply | Threaded
Open this post in threaded view
|

Re: Extending/overriding link parsing behavior

thoraxe
From the Asciidoc user guide:

http://asciidoc.org/userguide.html#_common_attributes

Role contains a string used to classify or subclassify an element and can be applied to AsciiDoc block elements. The AsciiDoc role attribute is translated to the role attribute in DocBook outputs and is included in the class attribute in HTML outputs, in this respect it behaves like the quoted text role attribute.

DocBook XSL Stylesheets translate DocBook role attributes to HTML class attributes; CSS can then be used to style the generated HTML.
So in this particular instance where I am classifying the link as a scroller link (js-scroll-to), how would I not put this in the Asciidoc?
Reply | Threaded
Open this post in threaded view
|

Re: Extending/overriding link parsing behavior

mojavelinux
Administrator

On Wed, Mar 30, 2016 at 4:05 PM, thoraxe [via Asciidoctor :: Discussion] <[hidden email]> wrote:
So in this particular instance where I am classifying the link as a scroller link (js-scroll-to), how would I not put this in the Asciidoc?

If this is a special treatment for a particular link (or cross reference), unique from other links (or cross references), then yes, a role would be appropriate. (That meets the criteria of essential information). Not aware of the larger context, I made the assumption you were making all links this way.

I would still use a different role name that describes the semantics so that it's not hard-wired to the output. Think of it like a hint.

-Dan

--
Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen