Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section about the task element #233 #296

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dariavladykina
Copy link
Contributor

This PR aims to add a subsection about the task element to the Structure and Markup chapter #233

@dariavladykina
Copy link
Contributor Author

Hi @tomschr , could you please have a look? I get strange output in the example, although I tried to copy the structure that you used in your example.
image

@tomschr
Copy link
Contributor

tomschr commented May 15, 2024

Yes, that's to be expected. 🙂 The task element is only partially supported by the stylesheets. There is still an open issue for that, see openSUSE/suse-xsl#307. I haven't worked on this since Nov 2022.

Maybe my memory is wrong, but we haven't discussed it in the SLE Writer's call, have we?

As such, before we describe it, we should first define when and how we use it. Additionally, task comes also with some limitations so we should be aware of those:

  • A task is NOT a replacement for an article or a topic. The latter are division elements, the former is a block element.
  • As task is a block element, you can't insert (sub)sections inside.

Therefore, it might be useful for a smaller task or if you split a huge task into small sub-tasks. However, that could impose some structural changes that is not always wanted.

On the other side, it could be beneficial is you want to enforce a specific structure.

Therefore, I'd suggest to discuss this in a broader audience if we want to live with the restrictions and use it, or if the existing structures are enough for us.

@jfaltenbacher
Copy link
Contributor

I have worked a lot with tasks elements before and never felt limited. I am in favor of having it

@janajaeger
Copy link
Contributor

I'm fine with our without it. It might be an additional crutch for writers to come up with a decent structure. Those who feel limited, can still opt to go without ;)

@cwickert
Copy link
Member

+1 for having it. I think it could be applied to 99% of our topics and will further unify them (if used consistently). And if the structure doesn't fit, well, you can still go without it.

Copy link
Contributor

@tomschr tomschr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dariavladykina I have added a minor question.

xml/docu_styleguide.structure.xml Outdated Show resolved Hide resolved
Comment on lines +3160 to +3165
<tasksummary>
<para>This is the summary of this task.</para>
</tasksummary>
<taskprerequisites>
<para>This contains the requirements.</para>
</taskprerequisites>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we require a <title> for <tasksummary> and <taskprerequisites>?

Copy link
Contributor

@jfaltenbacher jfaltenbacher May 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my experience <tasksummary> is only a repetition of the title itself in most cases, having it as an optional element is sufficient

<taskprerequisites> should have a default title like 'Prerequisites'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. "Requirements" are rendered as a headline by the style sheets, and the summary does not really need another title.

Co-authored-by: Tom Schraitle <tomschr@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants