Bugzilla

Thanks for the bug report!  Here's a testcase.

You brought up `input`-with-datalist vs. `select`, and your perception was that `input`-with-datalist is specially broken -- but really, there are a handful of other relevant comparable elements and categories of popup-UI -- and really, `select` is the special one in that it **does** scale, rather than `input`-with-datalist being special in not-scaling.

And there's a good reason that it scales -- it's not directly for accessibility, but rather because the whole `select` element and its `option`s are stylable as part of the web page, and are exposed to the web developer for styling.   e.g. the web developer might set a particular `font` and `font-size` on an `option`, and they'd rightly expect for that `font`/`font-size` to render the same whether it's on an option vs. some other piece of content.

In contrast, the textfield dropdown element (as well as all the other popups shown in my attached testcase, and e.g. the right-click context menu) is not stylable by the web page, and does not grow with full-page-zoom -- these other popups are just "native" pieces of the browser UI.  Given that they render the same everywhere, it would be a bit odd for them to respond to full-page zoom.  It would also be bad for accessibility if someone needed to zoom *out* in order to see a web page's content, and these bits of UI got smaller & inaccessible as part of that zoom-out operation.

I think the user-facing solution here is to allow users to establish a minimum desired size for the text in these bits of "browser-native" UI, like text dropdowns. I suspect/hope there is a way to do that, independent of full-page-zoom... let me ask around and find out.  If not, then that's probably what this bug should really track.

Thanks for the bug report!  Here's a testcase.

You brought up `input`-with-datalist vs. `select`, and your perception was that `input`-with-datalist is specially broken -- but really, there are a handful of other relevant comparable elements and categories of popup-UI -- and really, `select` is the special one in that it **does** scale, rather than `input`-with-datalist being special in not-scaling.

And there's a good reason that the `select` dropdown does scale with full-page-zoom-level -- it's not directly for accessibility purposes, but rather because the whole `select` element and its `option`s are stylable as part of the web page, and are exposed to the web developer for styling, so their sizes are inherently tied to the rest of the web page.  e.g. the web developer might set a particular `font` and `font-size` on an `option`, and they'd rightly expect for that `font`/`font-size` to render the same whether it's on an option vs. some other piece of content.  See for example my second `select` dropdown in this testcase -- it has `font-size:200%` on one of the options, which needs to render 2x as big as the others and 2x as big as the surrounding text, regardless of the full-page-zoom level. 

In contrast, the textfield dropdown element (as well as all the other popups shown in my attached testcase, and e.g. the right-click context menu) is not stylable by the web page, and does not grow with full-page-zoom -- these other popups are just "native" pieces of the browser UI.  Given that they render the same everywhere, it would be a bit odd for them to respond to full-page zoom.  It would also be bad for accessibility if someone needed to zoom *out* in order to see a web page's content, and these bits of UI got smaller & inaccessible as part of that zoom-out operation.

I think the user-facing solution here is to allow users to establish a minimum desired size for the text in these bits of "browser-native" UI, like text dropdowns. I suspect/hope there is a way to do that, independent of full-page-zoom... let me ask around and find out.  If not, then that's probably what this bug should really track.

Thanks for the bug report!  Here's a testcase.

You brought up `input`-with-datalist vs. `select`, and your perception was that `input`-with-datalist is specially broken -- but really, there are a handful of other relevant comparable elements and categories of popup-UI -- and really, **`select` is the special one in that it does scale**, rather than `input`-with-datalist being special in not-scaling.

And there's a good reason that the `select` dropdown does scale with full-page-zoom-level -- it's not directly for accessibility purposes, but rather because the whole `select` element and its `option`s are stylable as part of the web page, and are exposed to the web developer for styling, so their sizes are inherently tied to the rest of the web page.  e.g. the web developer might set a particular `font` and `font-size` on an `option`, and they'd rightly expect for that `font`/`font-size` to render the same whether it's on an option vs. some other piece of content.  See for example my second `select` dropdown in this testcase -- it has `font-size:200%` on one of the options, which needs to render 2x as big as the others and 2x as big as the surrounding text, regardless of the full-page-zoom level. 

In contrast, the textfield dropdown element (as well as all the other popups shown in my attached testcase, and e.g. the right-click context menu) is not stylable by the web page, and does not grow with full-page-zoom -- these other popups are just "native" pieces of the browser UI.  Given that they render the same everywhere, it would be a bit odd for them to respond to full-page zoom.  It would also be bad for accessibility if someone needed to zoom *out* in order to see a web page's content, and these bits of UI got smaller & inaccessible as part of that zoom-out operation.

I think the user-facing solution here is to allow users to establish a minimum desired size for the text in these bits of "browser-native" UI, like text dropdowns. I suspect/hope there is a way to do that, independent of full-page-zoom... let me ask around and find out.  If not, then that's probably what this bug should really track.