Skip to content

Add inapplicable checkboxes to GLFM

Brett Walker requested to merge gitlab-indeterminate-checkbox-gfm into master

What does this MR do and why?

Rebooting of [markdown] Add inapplicable checkboxes to GitLa... (!43208 - closed). Related to Partially Checked Checkboxes in Gitlab Markdown (#229189)

This MR modifies GFM to render [~] in a list as an inapplicable checkbox. The checkbox will be disabled and the text of the checkbox will be styled as a strikeout.

There is a huge amount of great discussion in [markdown] Add inapplicable checkboxes to GitLa... (!43208 - closed), and many ideas have gone back and forth. I think the direction we decided on is roughly this:

  • use [~] to mark a task item as "inapplicable" - it does not apply
  • it is not counted towards the number of task items
  • the checkbox will appear disabled and the user can not click on it
  • the text of the item will have the struck out styling as the main indication that it is not applicable to the list
  • sub items of an inapplicable item will continue observe their own status. In other words, the status of the parent is not propagated to the sub items. See the mockup below.

Screenshots or screen recordings

Mockup of the markdown used and how it would be rendered

How to set up and validate locally

Add the following markdown into an Issue, a Merge Request, and a Wiki page. Note the various behaviors:

  1. Inapplicable items should be
    • grayed out
    • strikethrough, including all content blocks, but not sublists
    • checkbox unclickable
    • hover should show ordering icon
    • hover should not show task creation icon
  2. Regular items should be
    • normal text color
    • no strikethrough
    • checkbox clickable
    • hover should show ordering icon
    • hover should show task creation icon

Note that on a Wiki page, all checkboxes should be unclickable.

Test Markdown
**Tight Unordered List**

- [ ] one
  - [~] one.1 (inapplicable)
  - [ ] one.2
- [~] two (inapplicable)
  - [~] two.1 (inapplicable)
  - [x] two.2
- [x] three

**Tight Ordered List**

1. [ ] one
   1. [~] one.1 (inapplicable)
   2. [ ] one.2
2. [~] two (inapplicable)
   1. [~] two.1 (inapplicable)
   2. [x] two.2
3. [x] three

**Loose Unordered List**

- [ ] one
  - [~] one.1 (inapplicable)
  - [ ] one.2
- [~] two (inapplicable)
- [x] three
- [~] four (inapplicable)

  ```ruby
  x = 1

Below is a sub list

  • four.1

    Below is some code

    x = 1
  • five

Loose Ordered List

  1. one

    1. one.1 (inapplicable)
    2. one.2
  2. two (inapplicable)

  3. three

  4. four (inapplicable)

    x = 1

    Below is a sub list

    1. four.1

      Below is some code

      x = 1
    2. five


</details>

## MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability. 

* [ ] I have evaluated the [MR acceptance checklist](https://docs.gitlab.com/ee/development/code_review.html#acceptance-checklist) for this MR.
Edited by Brett Walker

Merge request reports