Default direction and border customization

[saleyn]

Is there a way to specify the default direction in css, so that for each definition of the tooltip in an html element (e.g. <div aria-label="...">...</div>, it's not necessary to add data-cooltipz-dir="top")? The documentation only shows customization of other properties such as color, but not the direction.

[jackdomleo7]

Hi Serge, thank you for raising an issue. This is not currently implemented, but this is definitely something I can build into the next minor version (v1.7.0) as it will have no breaking changes to existing projects using Cooltipz.css.

[saleyn]

Great! Looking forward to it! Another helpful feature would be to customize the "border" (and its color) of the tooltip.
Additionally, if you could come up with a way to make it work for "self-closing HTML elements" (at least for input fields), it would be pretty helpful!

[jackdomleo7]

Can definitely look at the border customisation. Unfortunately, due to it being CSS-only and being styled on the ::before and ::after pseudo-elements, we can't get it to work on self-closing elements. A simple way around this is to wrap the self-closing element with a div and put the tooltip on the div wrapper. This is also how JS tooltips libraries do it.

[saleyn]

Any idea why in the link I sent above, which also uses the "::after" approach, the tooltip works on the "input" tags and cooltipz doesn't?

[jackdomleo7]

This is interesting. It looks like Chrome has started implementing support for pseudo-elements on self-closing elements. But it doesn't appear to work in Firefox (can't test Safari as I don't own an Apple device). Why it doesn't work on Chrome for Cooltipz.css, I do not know at a glance but I will take a look for the next version. My prediction is fixing this won't have breaking changes, it will just rely on browser support.

[jackdomleo7]

After more investigation on the psuedo-elements on self-closing elements, please find below what I've been able to discover but cannot find any resources that explain why:

I only demoed a few elements to get a feel for what's going on

• The below only seems to apply to Chromium. Other browsers such as Firefox don't seem to apply any psuedo-elements at all.
• For <input />
  • When using type="checkbox", type="radio", type="color" it seems to show the tooltip you demo above.
  • When using type="text", type="button" it does not seem to show the tooltip you demo above.
• For <img /> it seems to show the tooltip you demo above.

The above findings are also true when I replace your demo tooltip with a Cooltipz.css tooltip.
From the findings above, I have determined that I do not need to make any fixes in Cooltipz.css for showing pseudo-elements on self-closing elements. It seems like whether it works or not entirely depends on the browser and whether the browser has starting trialling support for pseudo-element styling on self-closing elements.

However, this is not recommended at all since aria-label is intended to override any content that a screen reads. I.e. placing a tooltip on an input may cause issues by causing the screenreader to not describe the input to the user.

---

With the above interesting issue researched and concluded, I will be happy to look into the other suggestions you provide.

[jackdomleo7]

After some research on the default direction, I have concluded that it should not be implemented.

It will cause breaking changes if I implement (I shouldn't have prematurely stated that it wouldn't without investigation). I could implement and release it as a new major version but the point below is the main reason why I will not be implementing it.

Take the below HTML as an example for this explanation:

<span data-cooltipz-dir="top" aria-label="Helpful tip">Hover me</span>

If we implemented a default direction, this would eliminate the need for data-cooltipz-dir, thus reading:

<span aria-label="Helpful tip">Hover me</span>

This leaves us with a problem. Cooltipz.css, as a third-party package cannot safely assume that every element with aria-label is intended to have a tooltip.

We could refactor to use something like data-cooltipz-title instead, but this not only causes more breaking changes, but it causes Cooltipz.css to lose the accessibility support that is brought with aria-label. NOTE: The level of accessibility is entirely dependent on the use of the tooltip by the consuming code. Cooltipz.css provides an aid for a11y support and should be used appropriately and semantically. (See also above comment for brief explanation).

Therefore, remaining with the current method of defining a direction and a aria-label to show a tooltip, I feel the best and safest way, even if you do have to define a direction each time.

[jackdomleo7]

The customisable tooltip border will be available in v1.7.0

[saleyn]

I am not sure I follow your logic why

Cooltipz.css, as a third-party package cannot safely assume that every element with aria-label is intended to have a tooltip.

If the default behavior is defined in the cooltipz's config via a new custom css feature, only then all tags with the aria-label attributes would display tooltips. In the absence of such a default, the behavior of cooltipz would be unmodified and there would be no regression issues. And the purpose of providing such a default value in the css by a developer/designer, would be exactly to turn on tooltips in all tags with aria-label.

[jackdomleo7]

If, as you say, I implement a way of defining a custom direction in the Cooltipz.css config, this would remove the need for data-cooltipz-dir to be defined (unless you want a direction other than the default). If you were to add a tooltip and you wanted the default direction, you may implement something like the below:

<span aria-label="Message">Hover me</span>

This means the Cooltipz.css CSS will be looking for [aria-label] {} which is not safe to do because we can't assume that the developer wants to add a tooltip to every element with aria-label, being as though aria-label is not an attribute Cooltipz.css has invented. The trigger for enabling a tooltip is the data-cooltipz-dir attribute which must always be defined, much like if you were defining a src on an img.

It's a good idea, but unfortunately I don't think the pros outweigh the cons. Thank you for contributing.