Implement slot for title in ListItem

[Antreesy]

Signed-off-by: Maksim Sukharev antreesy.web@gmail.com

Problem

Right now there is no stable opportunity to manipulate 'Title' sub-component (see issues and PR below) - only through the access to DOM element via querySelector or using :deep selector for scoped styles.

Related:

• Feature request: native title tooltip on NcListItem title #3687
• Fix tooltip appearance for long names in ConversationList nextcloud/spreed#8605

Proposal

Add the ability to integrate a developer-controlled sub-component via Vue slot. Proposed solution should not affect current realisations, because required prop title is provided as a fallback for slot.

• Examples for documentation is provided

⚠️ IMPORTANT

.list-item selector doesn't inherit box-sizing: border-box by default (If NcContent is not used). Fixed by this PR.

[raimund-schluessler]

I am not really fond of this solution. I think it's overkill to make this a slot, just for having the option to set the (native) title attribute. What's wrong with simply using <span class="line-one__title" :title="title">?

Edit: Although I have to admit that this is already a lot cleaner than the watch and DOM magic implemented in nextcloud/spreed#8605.

[Antreesy]

What's wrong with simply using <span class="line-one__title" :title="title">?

The trick is, we don't need this all the time. For example, in Talk it's only implemented for long names, which are covered with ellipsis and aren't fully visible. So it is better to have controlled tag, where you can apply attributes, logic, styles, e.t.c. locally.

I also want to note that, as it's an open-source library, we shouldn't mess with components working good before changes. So, attribute title could conflict with someone else local realisation.

[nickvergessen]

For example, in Talk it's only implemented for long names, which are covered with ellipsis and aren't fully visible.

Which is a nice gimmic, but if that blocks a proper and performant solution I prefer to have the title just displayed all the time.

[raimund-schluessler]

The trick is, we don't need this all the time. For example, in Talk it's only implemented for long names, which are covered with ellipsis and aren't fully visible. So it is better to have controlled tag, where you can apply attributes, logic, styles, e.t.c. locally.

If that really is a requirement, we can also introduce a new prop for it. Implementation wise, we could go the same way as in #3617, introduce a new name prop for what is now called title and make name fallback to the value of title if its not provided and use title as the native title value, to prevent a breaking change until the next major.

I also want to note that, as it's an open-source library, we shouldn't mess with components working good before changes. So, attribute title could conflict with someone else local realisation.

We cannot possibly anticipate all possible ways someone is using this library. What is not documented, is not supported in my opinion. We frequently introduce new features and props. If we couldn't do this because it might break someones undocumented and unintended use-case, we would be left with an unmaintained library without progress, because every little change could break something.

[Antreesy]

Superseded by nextcloud/spreed#11455