Properties: Prevent/Lock Changes in Reading Mode

Feature requests
1

Use case or problem
While in reading mode, changes can still be made to the properties section.

It is easy to accidentally click “x” on a tag or list item for example and thus unintentionally change note content. I could see this being a larger issue on mobile with accidental touches.

Proposed solution
Locking the fields while in reading mode would prevent this.

11 Likes
2

Css quasi-workaround below for anyone interested. This removes the “Add property” button and “x” from tags. It doesn’t prevent the tags from being backspaced but it makes it look more polished.

Only affects the inline Properties pane. The sidebar properties remains unchanged.

Targeting with css class “lock-metadata”:

/* Remove add properties button */
.lock-metadata .metadata-container > .metadata-content > .metadata-add-button {
  display: none
}

/* X button on tags and lists */
.lock-metadata .metadata-container .multi-select-pill-remove-button {
    display: none
}
  
/* X button on tags and lists */
.lock-metadata .metadata-container .multi-select-pill {
    padding-right: 0.7em;
}

Alternatively apply to all notes:

/* Remove add properties button */
.mod-header .metadata-container > .metadata-content > .metadata-add-button {
  display: none
}

/* X button on tags and lists */
.mod-header .metadata-container .multi-select-pill-remove-button {
    display: none
}
  
/* X button on tags and lists */
.mod-header .metadata-container .multi-select-pill {
    padding-right: 0.7em;
}
2 Likes
3

It would be great if this becomes a core feature.

4

Another option applying to reading mode only (Hides add property and tag X while in reading mode)

/* Remove add properties button */
.markdown-preview-view .mod-header .metadata-container > .metadata-content > .metadata-add-button {
  display: none
}

/* X button on tags and lists */
.markdown-preview-view .mod-header .metadata-container .multi-select-pill-remove-button {
    display: none
}
  
/* X button on tags and lists */
.markdown-preview-view .mod-header .metadata-container .multi-select-pill {
    padding-right: 0.7em;
}
5

I agree it’s a worry on mobile to accidentally e.g. delete a tag when you just wanted to scroll down.

And it makes sense to make properties read-only in Reading view because the content is read-only, so why not the properties?

Perhaps make it a setting to “Make Properties read-only when in Reading view”.

2 Likes
6

Properties should match the current view:

  • Editing view (source mode): edit properties in source mode
  • Edting view (live preview): edit properties with bells and whistles
  • Reading view: display properties read-only

Why should properties behave differently than the rest of the note?

3 Likes
7

This should really be a core setting, honestly. It’s silly how you can make changes by mistake just scrolling through notes even when you’ve specifically chosen to be in reading, aka not editing, mode.

2 Likes
8

Editing tools in reading view? Heck no! That’s what editing view is for.

1 Like
9

I can’t believe this is still an issue until now :sweat_smile:

I stumbled across this thread again because I was still trying to figure out how tp revent the text input boxes from being editable. So far that’s the only straggler left with my CSS setup.