DocumentationAll ComponentsContact usChangelog
IntroductionAccessBug Reports and Feature RequestsContactInstallationAngularReactUsagePortalsData FormatsMobile and TouchFormsDepth levels and stacking contextsTool IntegrationHow to use SkeletonsMicrofrontends

Themes and Customization

ThemesCSS custom propertiesBuild Time ThemingFontsTool Support

Migrationguide

V2 to V3V1 to V2DeprecationsDeprecations V3 to V4Deprecations V2 to V3Deprecations V1 to V2

Known Issues

Combobox initially open menu width not alignedSetting tabindex on disabled componentsTemplating into default SlotsTextfield type number, first minus entered will disappearTruncation limitation in title stackPopover position in small iframesStorybook problemsBrowser bugsFlex layout subsampling issueDead Keys in NumberInputsInteractive icon hitarea

Browser bugs

Edge 18 zoom issue

Description

Elderly Edge browsers won zoom containers which have sizes defined with CSS calc expressions. This has been revealed in issue #423052 and a minimal reproduction case exists.

Possible workaround

The only possible fix is to set sizes explicitly. As we calculate all dimensions with a base unit, we use the CSS calc expression, which allows us to modify the base size in runtime. Setting those dimensions with e.g. a pre-processor takes this ability.

Thus we wont fix this edge case (literally) with the drawback of having non scaling items while zooming in old edge browsers.

sub-pixel calculation issue when using browser zoom

Description

Browsers are miscalculating sub-pixels when zooming, especially on borders with 1px width. But also with thin components like the zui-divider or zui-progress-bar. In the zui-progress-bar down below the exact same height of the element is set but because of the sub-pixel calculation you can see a visual difference

image.png

This problem firstly has been revealed in issue #405508 and some insights can be gained from this thread. At the moment there is no good solution to fix this in all browsers.

Possible workarounds

As mentioned in the description the three common workarounds do not apply for us:

  1. The idea to use relative units such as "thin" over "1px" does not solve our issue. Maybe because this expression is internally replaced by "1px" as well.
  2. Using "box-shadow"s is inconvenient and would make live much harder (especially if we need shadows and borders)
  3. Oversizing the borders by a little ("1.3px") didn't work either, maybe this "fix" is outdated

We only can address this implicitly by setting the background color same as the border color, or by not using any borders at all but inset the content on the filled background to simulate a border.

Note: setting the background to match the border is our temporary workaround for the thumbnail component. The second approach of getting rid of all borders is planned for the upcoming thumbnail refactoring.

Firefox on macOs Monterey scroll snap issue

Description

In some cases Firefox does not properly snap scrolled items. This is only happening for macOs Monterey and is already tracked here. We do have this issue in our MultiItemSlider component in this specific constellation as well.

Possible workarounds

We decided to wait for a bug fix of the browser vendor here, as the items can still be scrolled using the pagination. Also, the usage of Firefox on macOs Monterey has a very little share on the global browser usage.

Tooltip issue

Description

Due to the way our truncate with tooltip works (computing if scrollWidth is greater than offsetWidth), it sometimes leads to bugs in browsers. We noticed that sometimes the ellipsis is displayed and the tooltip does not (currently after changes to the toggle bar item failed to reproduce it and it looks like it works correctly) or when hovering over the item during hover due to the activation of border ellipsis appears but tootlip does not.

The computation sometimes behaves differently on different browsers, and it is only the browser that affects whether ellipsis is shown or not.

#712891

Chrome Tooltip scrolling issue

Description

In Chrome the tooltip stays visible after scrolling when the mouse not moves. Our tooltip listens on mouse events and during scrolling none is fired. In the most cases the user moves the mouse during scrolling and the tooltip disappears. This has been revealed in issue #794774 and it is already tracked here.