Post by bigballofyarn on Nov 15, 2024 14:53:56 GMT -5
Reminder: Tapatalk is a free alternative to using a mobile browser and will not deduct any ad-free views while you browse or post.
Background<svg viewBox="0 0 16 16" height="24" version="1.1" width="24"
The <select> element does not provide enough customization for web developers, which leads them to implement their own. These implementations can lead to reduced performance, reliability, and accessibility compared to the native form control elements. More on that is in Custom Control UI.
The 2020 MDN browser compatibility report had feedback that form controls are neither interoperable nor customizable. Customizable <select> will be fully interoperable and customizable.
Opting in to the new behavior<svg viewBox="0 0 16 16" height="24" version="1.1" width="24"
The <select> element will continue to behave as it currently does unless it has the appearance:base-select CSS property. Based on standardization discussions, appearance:base-select must also be applied to the select::picker(select) pseudo-element in order to opt in the picker popup element. Previously proposed opt-ins included a new tag name, an additional HTML attribute, and the presence of a child <button> or <datalist>.
Here is a basic <select> element with the appropriate CSS to opt in to customizable <select>
Testing out the customizable select element<swidth="24" xlmns="http://www.w3.org/2000/svg"><path d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2
Customizable <select> is currently implemented behind a flag in Chromium. To use it, enable the Experimental Web Platform features flag in about:flags. Using chrome canary is recommended to get the latest state of the API.
If you encounter bugs or limitations with the design of the control, please send your feedback by creating issues on the open-ui GitHub repository. Here is a list of open select bugs in open-ui.
Read More...
There may apparently be a bug where Chrome Mobile on Android automatically opts in for page author (Mobile Issue)
Do you mind if I quote your message here and post it on my forum in the thread regarding this issue?
The issue is present in Chromium 131 but not 133 (unsure of 132, untested), and thus I'm more and more inclined to believe this sudden incompatibility will be fixed in a future stable public release of Chrome. The timetable for that is uncertain, however. It could just as easily be three months as it could be a week.
Other browsers may be affected! All major browsers are Chromium-based. As others update their rendering engines to 131, the issue can spread to them as well. This could still be affecting some users well after others are in the clear.
For those curious: it's a CSS issue at play. The "post options" buttons are illusions hiding invisible <select> elements. To achieve the blue glow effect, the buttons are wrapped in <a> tags. It's perfectly valid to do this, but anchors aren't containers, and the <select> tags are breaking out of their parent elements.
The CSS styling rules tell this class of <select> to take up their entire parent, but their parent anchors aren't supplying boundaries. As such, these invisible input controls are taking up the entire page. They're stacked on top of each other with the first post's <select> element on the bottom and the last on top. Users are completely unaware that they're tapping these inputs because of their invisible styling.
The solution is to replace each <a> with <div> and everything (minus the glow effect we don't even notice because our sausage thumbs are in the way) goes back to normal.
