Style elements

[fred-atherden]

Description

eLife supports italics, bold, superscript, subscript, smallcaps, and monospace text. Following internal discussions, we have decided to stop supporting colour text due to accessibility concerns.

User Stories

Author

1. As an author, I want to be able to apply style formatting to my text so that I can add emphasis.
2. As an author, I want to be able to remove style formatting to my text so that I can correct errors.

PKP, Érudit

3. As production staff, I want to be able to define additional formatting options so that I can use non-standard styling on publication.

But what if . . . ?

Considerations

• We may want to consider how the display of the different formatting options in Texture matches how they will show up on publication. This might not be a major issue, but it's probably worth keeping in mind.
• Formatting options should be configurable per publisher to account for differences in allowed styles.

XML requirements

eLife currently allows the following formatting elements:

• bold
• italic
• underline
• sup
• sub
• sc
• monospace
• strike
• named-content (for gene sequences)

Érudit allows the following (in addition to the above):

• overline
• strike
• roman

styled-content

The element styled-content should be used in order to add configurable styles.

Mock ups

This is not required, but if you have mock ups of what you would like to see please provide them here.

Proposal

This will be added by the Texture team after the feature request is discussed and agreed.

[michael]

Hi there. I will use this example to demonstrate how we can iterate on user stories to bring them to a condensed general form.

3. As production staff, I want to be able to define additional formatting options so that I can use non-standard styling on publication.

That is a something that violates Texture's principles. Instead of allowing custom non-standard styling what we can do is just extending the list of available stylings. We'd like to avoid configurability because it creates non-standard islands. We want eLife to be able to open Erudit Dars etc. and vice versa.

Could we reframe the whole thing to just one general story:

1. As production staff, author or proofing author I want to be able to add and remove styling, so text can be formatted correctly (accepted)
   • Styling options: bold, italic, underline, supscript, subscript, smallcaps, monospace, strike, overline, strike
   • Examples: See this example that encodes all different style types in JATS

@FAtherden-eLife @Melissa37 @JGilbert-eLife I think we should stop scoping user stories per publisher. Instead let's combine them where possible. This is a good example where we could condense the different requirements to one user story.

In order to avoid redundancy we should not have duplicate stories just because of different roles. I'm not sure how to do this properly but I tried it by combining the roles in the story "As production staff, author or proofing author".

The user stories should not be solution-oriented, so we should remove all JATS bits from the ticket. In other tickets, instead of having the section XML Requirements, it would be better to link to XML samples from individual user stories, I sketched this)

I'm open to suggestions how to improve this further.