new tooltip is not only progress perse....

[Mariusthvdb]

Aware tooltips might need restyling, and I didnt do that yet to be able to spot the difference, I must say I am rather let down..
But, it might all be user issues, so not yet posting an issue-tracker ;-)

most problematic:

the tooltip is no longer being shown on the button itself, but at some distance above it, covering other elements, and seemingly no longer attached to the button itself

or even worse:

second: on mobile, we can no longer get the tooltip to show, where before, that was very simple, and also very useful, especially on buttons that have no text, but only an image.

aware that is per new design ((Not supported on touchscreens)), but it is functionality truly missed.

I have these 2 templates

styles_menu_tooltip:
  styles:
    tooltip:
      - transition: opacity 0.5s
      - color: var(--card-background-color)
      - font-size: 12px
      - background: var(--primary-color)
#       - opacity: 0.5
      - padding: 2px
#       - width: 80%
#       - height: 80%
#       - word-break: break-word
#       - overflow: scroll
#       - justify-content: space-evenly !important;
#       - border-width: 0px
# set in resource
#       - position: absolute
#       - top: 50%
#       - left: 50%
#       - transform: translate(-50%, -50%);

styles_tooltip:
  styles:
    tooltip:
      - transition: opacity 0.5s
#       - font-size: 12px
      - color: var(--primary-color) #var(--card-background-color)
      - border-color: var(--primary-color)
      - padding: 2px

and this obviously no longer works. Must lookup the replacement and will report back. since this has no influence on the 2 points I mentioned above, I hope to be able to somehow fix all that....

trying to make a start at showing the effect of my templates and setting background to red has a rather unexpected result:

all small dots, on all button cards, not even hovering them?

for comparisons sake, I downgraded to 500dev4 and this is what it looked like (what I wanted it to look like....)

this is a first time for me, but I wont upgrade just yet, those tooltips are not yet a feature to me

[RomRider]

You can attach the tooltip to the button with:

tooltip:
  content: XXXX
  arrow: true

For the part about touchscreens, I need to discuss with @dcapslock about a potential option

[dcapslock]

I must be missing something about touchscreens. The current doco says not supported. @Mariusthvdb what magic do you do with touchscreens?

[Mariusthvdb]

I must be missing something about touchscreens. The current doco says not supported. @Mariusthvdb what magic do you do with touchscreens?

well, nothing actually...
the tooltips simply showed when touching those buttons a bit more than tapping them...

might have been a fluke, but I did use that functionality

[Mariusthvdb]

maybe the documentation needs to updated still, that arrow isnt there (btw also the link to the styling options points to a wrong line I believe)
currently https://github.com/custom-cards/button-card/blob/master/src/styles.ts#L30-L46
needs to point to

button-card/src/styles.ts

Line 62 in 3e2c761

:host(.tooltip) .tooltiptext {

?

honestly, that should be made more user friendly, those lines of code dont really help the enduser to set their styling

besides that, my stylings set to tooltip dont work at all? colors, background, border etc, all show differently, so that requires a bit of adjusting, (and also documenting)

that small dot was also in the 3d screenshot I now notice, still being the primary color (gray).
that must be an issue?

[Mariusthvdb]

I might be able to live with that center position being gone…. ;-)

but styling the tooltip border is still on the wishlist.

I’ll need to check again but I haven’t found options for that.

managed to migrate all tooltips, so will see what the feeling will be in a few days.

about the delay, it somehow feels different than what I had before . Even set at 0.1s. Especially when moving from 1 button to an other .
Can’t put my finger on it yet

O and the loss on mobile, I will open a fr for that, it really takes away from the usability

[RomRider]

For the border, you can try modifying those variables (it's not documented, because not exposed by HA by default but we should probably add it to the documentation):

--wa-tooltip-border-width
--wa-tooltip-border-style
--wa-tooltip-border-color

They are defined like that in the web awesome component.

border: var(--wa-tooltip-border-width) var(--wa-tooltip-border-style) var(--wa-tooltip-border-color);

styles:
  tooltip:
    - color: red
    - --wa-tooltip-border-width: 4px
    - --wa-tooltip-border-style: dashed
    - --wa-tooltip-border-color: red

[Mariusthvdb]

yes!, just what I need!
please do document those, perfect

the control freak in me has issues with those names:

  styles:
    tooltip:
      - --ha-tooltip-font-size: 14px
      - --primary-text-color: var(--primary-color)
      - --secondary-background-color: var(--card-background-color)
      - --wa-tooltip-border-width: 2px
      - --wa-tooltip-border-style: solid
      - --wa-tooltip-border-color: var(--primary-color)

it works, but wouldn't it be much nicer to have at least tooltip-text-color and tooltip-background-color?

as for the loss of styling, I have to see where this leads too:

#       - opacity: 0.5
#       - padding: 2px
#       - width: 80%
#       - height: 80%
#       - word-break: break-word
#       - overflow: scroll
#       - justify-content: space-evenly !important;
# set in resource
#       - position: absolute
#       - top: 50%
#       - left: 50%
#       - transform: translate(-50%, -50%);

😜

[Mariusthvdb]

They are defined like that in the web awesome component.

is there also a box-shadow available?

all of my buttons use that, and the tooltip now is very flat, love to set that same box -shadow to make it really stand out of the background.

I've set the ha-tooltip-border-radius: var(--ha-card-border-radius) (set to 0px) in my theme, so that takes care for all tooltips nicely

btw this is the odd rhythm on the delay off for the tooltip I referred to above

[Mariusthvdb]

@dcapslock check how nice this shows now in release 6.0.0

styles_menu_tooltip:
  tooltip:
    placement: top-start
    delay: 0.1s
    distance: -5
    skidding: 0
#     arrow: true
  styles:
    tooltip:
      - --wa-tooltip-content-color: var(--card-background-color)
      - --ha-tooltip-font-size: 12px
      - --wa-tooltip-background-color: var(--primary-color)
      - --wa-tooltip-border-width: 2px
      - --wa-tooltip-border-style: solid
      - --wa-tooltip-border-color: var(--card-background-color)

delay-off is now immediate, and just as I had hoped, and we can position those tooltips anywhere we want, even out of the WA defaults .... ;-)

[dcapslock]

@Mariusthvdb Thanks you for your feedback. Just reviewing now over morning coffee. I will summarise what has not been answered yet.

Placement

I tested distance: -<num> and that works to place the tooltip within the button. You also need to set pointer-events: none on tooltip style otherwise you will get a strobing tooltip. When you move the tooltip inside, arrow does not make any sense.

Variable names

the control freak in me has issues with those names:

it works, but wouldn't it be much nicer to have at least tooltip-text-color and tooltip-background-color?

Trying to follow what ha define for tooltips so makes it easiest all round. The best would be for HA to implement your wishes with naming for text color and backgorund color, as well as exposing --ha- variants for border styling. Doing things this way, should HA ever migrate to another tooltip, it should be almost seamless for button-card. The more button-card diverges, the more there is to manage when HA changes.

Box Shadow / Opacity

Not supported by wa-tooltip via CSS. It could be possible to consume wa-tooltip directly and cut out ha-tooltip. This gives access to the CSS parts directly for button-card to style without worry for shadow roots. Will need to discuss with @RomRider on how we feel about that maintenance wise, with sinmilar thoughts as to variable names. Other styling would remain the same as we would copy HA style sheet for wa-tooltip.

Max-width

Can you check on this? Max-width is a specific test case in the repo and it is working fine.

Text styling

It would be pretty straightforward to expose text styling. However it is in a specific span to target and not the tooltip element, so we would likely need to introduce --tooltip-text- variables. Goes against what I said above, but would provide for styling the text with the usual CSS text styles.

Show/hide delay

I think what you are seeing here is that the hide delay is default of 400 with ha-tooltip. With the underlying wa-tooltip it is 0. Possibly here would be to make hide delay the same as show delay if defined.

I assume if this is addressed that answers your delay-off query as posted in the issue

Way forward

In summary, using wa-tooltip directly would allow for better flexibility for button-card tooltips. If we did this I would then create --button-card... css vars that do all the work and these use --ha-... variants where available, like we do for ripple. However this would possible future maintancne issues if/when HA diverges from webawesome. If we can conisder this quite minimal then using wa-tooltip directly would be the way to go.

[dcapslock]

Also, for delay, 0 currently will provide default of 150ms. That will get fixed as well as allowing hide-delay.

[dcapslock]

A further comment about placement. I believe webawesome has taken the approach to place outside the control extent as that allows for active HTML (link etc) in the tooltip without interfering with the control. As noted above, distance can be negative, but without seting tooltip pointer-events to none you then get a focus battle between the button and the tooltip. So in button placement is supported, but at the expense of no active HTML in tooltip.

[Mariusthvdb]

0 currently will provide default of 150ms. That will get fixed as well as allowing hide-delay.

a that explains what I noticed.
would be perfect if that got fixed yes, cool

the negative placement compromise seems obvious, and sweet if at all possible

Max-width

Can you check on this? Max-width is a specific test case in the repo and it is working fine.

sure, its what I said yesterday, using a silly 10px for testing purposes: