Buggy when multiple inputs are both storing in tags

[muffinman404]

Please fill out these Check-boxes

• I checked for existing similar issues
• I checked that the plugin is up to date
• The issue persists with all other plugins and themes disabled

Plugin Version

1.3.3

This Issue Occurs on

• Windows
• Linux
• macOS
• Android
• iOS

Debug Info

SYSTEM INFO:
	Obsidian version: v1.8.4
	Installer version: v1.7.7
	Operating system: Windows 10 Home 10.0.19045
	Login status: logged in
	Language: en
	Catalyst license: insider
	Insider build toggle: on
	Live preview: on
	Base theme: dark
	Community theme: none
	Snippets enabled: 3
	Restricted mode: off
	Plugins installed: 25
	Plugins enabled: 4
		1: Templater v2.9.2
		2: Meta Bind v1.3.3
		3: Dataview v0.5.67
		4: Book Search v0.7.5

RECOMMENDATIONS:
	Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Describe the Issue

(I disabled all but the plugins needed for this note template.)

I use Obsidian to keep detail-heavy notes on books. I've been doing this a while just with Book Search, Templater, and manual addition of tags in the note, but I'm porting everything over to Meta Bind for neatness. I should say these aren't "normal" notes I keep, so much as technical data on the books that would interest a writer, so most of the details I've connected to tags and would prefer to keep it that way (e.g., #pov/first, #tense/past).

As a lot of "category groups" of tags are relevant to this endeavor, I've traditionally had little subsections in my book notes to help me with my workflow (e.g., headings that prompted me for related tags: Perspective, Tense). I've tried to maintain that structure while adding Meta Bind inputs that store to the special "tags" property. Unfortunately, I've found that using Meta Bind inputs to store to the same property causes overwriting rather than the amending behavior I expected.

I would switch to properties entirely and move away from tags, but...that'd require a lot of work on old notes that I don't want to do.

Steps to Reproduce

Create an input that stores information to tags. For example:

INPUT[select(
   option(#author/gender/women, Women Writing),
   option(#author/gender/men, Men Writing),
):tags]

Now create another input that also stores information to tags. For example:

INPUT[inlineListSuggester(
    option(#published/2020s),
    option(#published/2010s),
    option(#published/2000s), 
    option(#published/1990s), 
allowOther(true)):tags]

Select an option in the first input. It adds it to tags. Good! Buuut it also thinks I added it to the second input and shows it selected in both input types since both point to tags.

If you then select an option in the second input, it will append. Now you've got gender and publishing decade both in tags. This is okay in the most technical sense, even if the journey there has been clunky. But if you go back and change the selection on the first input, everything is overwritten. The new gender selection appears, and the publishing decade is no longer selected, having been overwritten by the first input.

Expected Behavior

Honestly just expected it to work and add/remove the tags without affecting each other's inputs. 😂 It feels like there needs to be a unique identifier for each input, so it won't interfere with another input's behavior. Associating the input with where it is storing something is sure to cause conflicts like this when it comes to tags.

[mProjectsCode]

Sorry for the late response, I just noticed this bug report.

The behavior you are seeing is 100% correct and intentional. The select input treats its property not as a list, whereas the inlineListSuggester does. The best option is to use list type input fields for both inputs, or a more fragile option is to bind the select to tags[0] so that it always targets and overrides the first element of the list and not the entire list.

[Graywaren]

Chiming in with an idea. I also use the method of multiple list inputs for a single frontmatter property that contains multiple categories of items. I really didn't want the separate inputs to display each other's options as it would get overwhelming to have 4 or 5 copies of them on a single page. Thankfully I was able to achieve this with css because I was using note links, so it seems to me that muffin's idea of "unique" identifier could be implemented with a data-attribute being added to the list item itself. Showing/hiding them wouldn't be dynamic as it is based on the unique options rather than the specific inputs and requires you to update your css snippet when you add new options, but it would be amazing for situations like this.

What I did with css was first set the specific list input's list-items to display: none, then I set items that had data attributes (in my case containing specific groups of page names in the data-href field) back to display visibly. So for example:

INPUT[inlineListSuggester(optionQuery("folder1"),useLinks(partial),class(hide-show input1)):target]
INPUT[inlineListSuggester(optionQuery("folder2"),useLinks(partial),class(hide-show input1)):target]

// Hide all list items
.hide-show .mb-inline-list-item {
     display: none;
}
// Input 1 - Show only Note 1 & 2
.hide-show.input1 .mb-inline-list-item:has([data-href=Note-Title1], [data-href=Note-Title2]) {
     display: inline-flex;
}
// Input 2 - Show only Note 3 & 4
.hide-show.input2 .mb-inline-list-item:has([data-href=Note-Title3], [data-href=Note-Title4]) {
     display: inline-flex;
}

Unfortunately this method currently isn't possible for #tags or other non-link options as they're just plain text which css has no way of targeting. It would also be more efficient if it could be .mb-inline-list-item[data-internal-value="Note Title/Tag Name"] instead of using :has().

List wrapper elements already have a data-internal-value attribute, so perhaps this could attribute could be added to individual list item's elements as well? That way targeting specific list items becomes possible for plain text items as well as a more efficient css selector (which would be amazing for my use cases). So an example of the HTML would be <div class="mb-inline-list-item" data-internal-value="#apple" role="listitem">. This would work for the non-inline list as well.

This also allows for other item specific css styling, say making a specific note title in a list bold or a specific color (I do this a lot) to highlight it.

I could make this a separate feature request if that's better, but this discussion was already pretty close to it I thought it might be better to comment here.

[mProjectsCode]

I could make this a separate feature request if that's better, but this discussion was already pretty close to it I thought it might be better to comment here.

Please open a separate FR. On second thought I will implement this now real quick, so you don't have to do the extra work of writing a separate FR.

[mProjectsCode]

All list elements that aren't links should now have data attributes in the latest canary release.

[Graywaren]

Awesome! Thanks so much! Though I'm a bit unclear on what that means html-wise & why it excludes links. Is it:

<div class="mb-inline-list">
    <div class="mb-inline-list-item" role="listitem" DATA-ATTRIBUTE="HERE">
          <span> #tag </span>
     </div>
</div>

which is what would allow the most efficient css targeting without the use of :has(), for display e.g. .mb-inline-list-item[data-attribute="value"] {display: inline-flex;}

or

<div class="mb-inline-list">
    <div class="mb-inline-list-item" role="listitem" >
         <span  DATA-ATTRIBUTE="HERE"> #tag </span>
     </div>
</div>

which would still require using :has(), for display e.g. .mb-inline-lists-item:has([data-attribute="value"]) {display: inline-flex;}

If it's the first, that would help quite a bit with lag caused by css I have for metabind in my vault I think, but I'm confused as to why exclude links since links don't have an attribute at that DOM level either and would still leave them needing to use :has(). If it's the second I understand excluding links, but it may be more prone to lag. At least... in my experience, since obsidian seems to take issue with my css all the time >.> Others may not have that experience, in which case I'll accept that I'm just cursed by the lag gods lol.

Either way, many kudos for such a fast implementation! you rock!🧡

[mProjectsCode]

Just updated the code, it now works like your first example and also includes links.