Re: [EXTERNAL] [jats-list] inline code vs monospace in JATS

["Castedo Ellerman castedo@xxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

I've emailed PMC a bunch of details about <named-content> being rendered 
as HTML <em>. PMC is tracking it (privately) as CAS-1522258-X5W5R0.

I'm starting to lower my expectations on how consistently 
Baseprint-flavor JATS might hypothetically render on PMC. I'm shooting 
for some minimal level of potential interoperability. I'm really only 
expecting consistent presentation from free-open source software project 
https://gitlab.com/perm.pub/baseprintlens and related projects.

At the risk going off-topic with the topic of control of pandoc... I'll 
take this opportunity to sing it's praises. It's an open-source project, 
I contribute to the project (occasionally/barely), and the main 
developers (especially John MacFarlane) are free open-source source rock 
stars. They are incredibly responsive to the community of developers 
that engage with the project (like myself). Just two weeks ago John 
merged a change I made to the code/documentation. It's great being able 
to contribute to free open-source projects. Feels like a tiny bit of 
control.

Likewise for the WeasyPrint project. Guillaume Ayoub is also a free open 
source software rock-star. Great project.

Best regards,
 \xA0 Castedo


On 9/8/25 16:51, Lizzi, Vincent wrote:
>
> Hi Castedo, Laura, and all,
>
> Thanks for the link to the GitHub discussion, Castedo. The Baseprint 
> Document Format <https://perm.pub/DPRkAz3vwSj85mBCgG49DeyndaE/> that 
> you are working on as a subset of JATS looks like an interesting 
> project. Trying to get two different systems that are outside your 
> control, in this case PMC Article Viewer and Pandoc, to produce 
> consistent presentations of content can be difficult especially in 
> areas that some might consider to be uncommon or edge cases.
>
> The suggestion in the GitHub discussion to tag inline code as 
> <named-content content-type="code"><monospace>inline 
> code</monospace></named-content> looks reasonable to me. (It also 
> mirrors the convention in HTML to tag code blocks as <pre><code>block 
> code</code></pre>.) However, as you noted, PMC transforms 
> <named-content> to <em> which displays as italic which is not desired 
> for computer code.
>
> As noted in the GitHub discussion, using attribute specific-use=C"BBcodeC"BB 
> is not strictly consistent with the intended use of the specific-use 
> attribute. It would be better to use attribute content-type=C"BBcodeC"BB, 
> however the content-type attribute is not available on the <monospace> 
> element. Tagging inline code as <monospace specific-use=C"BBcodeC"BB>inline 
> code</monospace> can be a reasonable workaround if it provides you 
> with both the display and semantic identification that you need.
>
> It looks like there are two potential improvements to be made to JATS 
> based on the issue that youC"BBve raised. This could be worth submitting 
> via the comment form 
> <https://groups.niso.org/higherlogic/ws/public/document?document_id=31409> 
> for consideration in a future version of JATS.
>
>  1. Provide a way to tag code fragments that should be displayed
>     inline with the surrounding text CB C"BB possibly a new element
>     <inline-code> based on the <code> element, or possibly a new style
>     attribute on the <code> element.
>  2. Add the content-type attribute to face markup elements (including
>     <monospace>) to enable identifying the type of content (such as code).
>
> There are people on this list who are familiar with PMCC"BBs systems, 
> including Laura, who might have more to add.
>
> Kind regards,
>
> Vincent
>
> _____________________________________________
>
> *Vincent M. Lizzi*
>
> Head of Information Standards | Taylor & Francis Group
>
> _vincent.lizzi@xxxxxxxxxxxxxxxxxxxx 
> <mailto:vincent.lizzi@xxxxxxxxxxxxxxxxxxxx>_
>
> Time zone: US Eastern
>
> <https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b@xxxxxxxxxxxxxxxxxxxx?anonymous&ep=owaSlotsEmailSignature>
>
> 	
> 	
>
> Book time to meet with me 
> <https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b@xxxxxxxxxxxxxxxxxxxx?anonymous&ep=owaSlotsEmailSignature>
>
> 	
>
>
> Information Classification: General
>
> *From:*Castedo Ellerman <castedo@xxxxxxxxxxx>
> *Sent:* Monday, September 8, 2025 9:19 AM
> *To:* Lizzi, Vincent <Vincent.Lizzi@xxxxxxxxxxxxxxxxxxxx>
> *Subject:* Re: [EXTERNAL] [jats-list] inline code vs monospace in JATS
>
> Regarding <code specific-use="inline">, I consider using whatever PMC 
> has actually implemented to render HTML from XML actually archived in 
> the Open Access Subset. So if PMC wants to implement that, that sounds 
> great. <monospace specific-use="code"> is also great, if it is 
> actually implemented by PMC.
>
> That said, until PMC actually implements HTML rendering of <code 
> specific-use="inline"> there is backwards compatibility problem. The 
> way PMC is currently implemented, a <code specific-use="inline"> will 
> not gracefully degrade. It will break-up a containing block element 
> and render code content as a new block element when the author 
> intended it to be inline. In contrast <monospace specific-use="code"> 
> will gracefully degrade before is it actually supported by PMC.
>
> I'm sorry for the delayed response. An emailing lists like this one is 
> really nice and useful for certain "slow" types of communication. But 
> for detailed discussions about tech, I find GitHub far more conducive 
> to that kind of fast techy discussion. There's a related discussion on 
> this topic, but in the context of authoring using pandoc, at
>
> https://github.com/jgm/pandoc/discussions/11108
>
> There's a lot more details and thoughts from Denis Maier and myself 
> over there.
>
> Best regards,
> \xA0 Castedo
>
> On 9/5/25 00:07, Lizzi, Vincent wrote:
>
>     Hi Castedo,
>
>     I see your point about the <code> element typically being treated
>     as a block for rendering and the desire to use <code> as an inline
>     element sometimes. It may sometimes be possible to infer from the
>     context or the content whether block or inline display is
>     preferable, but not always.
>
>     Would you consider using an attribute on the <code> element to
>     specify when it is intended to be inline? For example:
>
>     <code specific-use="inline">
>
>     This would C"BBallow specifying inline when needed, and assuming
>     block as the default.
>
>     You can, if you wish, submit a comment to the JATS Standing
>     Committee to consider suggestions for improving this in a future
>     version of JATS. The comment form is at
>     https://groups.niso.org/higherlogic/ws/public/document?document_id=31409
>
>     Thank you,
>
>     Vincent