Serhii Kulykov

The issue appears to be caused by setting `width` and `height` on the overlay part when dragging starts: https://github.com/vaadin/web-components/blob/8569a89a115b7559309f959f3a76dfade714c384/packages/dialog/src/vaadin-dialog-draggable-mixin.js#L95-L97 Note: the same logic is also executed when resizing starts: https://github.com/vaadin/web-components/blob/8569a89a115b7559309f959f3a76dfade714c384/packages/dialog/src/vaadin-dialog-resizable-mixin.js#L179-L181

As a workaround, it's possible to use this to ensure the above code never runs: ```js dialog.$.overlay.$.overlay.style.position = 'absolute'; ``` However, if header or footer is provided, dragging either of...

The main reason against using a part was described here: https://github.com/vaadin/web-components/issues/727#issuecomment-676308079 > Ideally the div is replaced with a vaadin-input-container as all other fields have Please note that `vaadin-input-container` provides...

> We want to allow fields to have a wider label than the field itself Actually, with a custom field it's possible to have wider label when setting `width` on...

The issue is still valid. Can be reproduced by adding `width: 645px` to the `div` in the above example: 

Just to clarify, is this the default `Select` component or there are any custom styles? A code example would help indeed.

We have significantly improved a11y with implementing proper keyboard navigation for date elements. If we now try to make these elements hidden from screen readers, this might break them even...

Here is the original request for this feature in `vaadin-text-field`: https://github.com/vaadin/vaadin-text-field/issues/130 It has been implemented by https://github.com/vaadin/vaadin-text-field/pull/149 but not ported to other components later. > we would like to be...

Moved the issue to web components repo as it looks like a Chrome rendering bug.

I tried to reproduce this in a virtual machine on Mac M1 (Ubuntu 20.04, Chromium 103.0.5060.53) and there it works: