New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stylable <select>
element
#9799
Comments
@whatwg/forms |
This comment was marked as spam.
This comment was marked as spam.
Thank you for bringing this proposal to the WHATWG Joey! I thought this would be a good opportunity to outline how colleagues and I feel about extending HTML in this area. In particular, we feel that new and existing form controls:
We understand that the (Aside: #5791 seems very related to this issue.) |
I think the explainer doesn't explain the need for a new element in a convincing way, because the multiple examples look addressable in the context of (From off-explainer examples, I gather that the ambition level of the feature is much higher than the explainer makes appear.) |
Thanks for taking a look and discussing with colleagues Anne!
If we made appearance:none or a new appearance value like appearance:base as discussed here and here have a standardized style, then the default appearance:auto appearance could look the same as OS controls. That would be up to each UA to decide, as it is currently for all other form controls.
Agreed! Styleability is the primary driving use case for the current proposal.
Agreed! Domenic left some feedback in this vein and we completely revamped the proposal to use existing HTML element patterns by using new tag names instead of slot and behavior attributes.
Agreed! Existing elements conform to this by letting the browser/OS provide a native picker which unfortunately can’t be styled or customized by web developers, right? It was recommended that we let the browser use native pickers for selectlist on mobile here. Ideally developers would be enabled to make their own pickers that work on these platforms when they want to as well.
Agreed! This is also a core requirement for the proposal. I have been working closely with accessibility experts participating in OpenUI to ensure that the accessibility mappings and keyboard behaviors follow the current best practices in ARIA.
Agreed! The content is fully customizable/replaceable, so it should be localizable and internationalizable, right? The only thing I can think of is supporting right-to-left and vertical writing modes when rendering where the listbox popup goes, which is something we are doing for other form control elements and we can easily do via Anchor Positioning for selectlist. Is there anything else you had in mind here?
It sounds like yall would prefer to reuse the existing
I agree that duplication should be avoided. Selectlist is not a complete duplicate of select. |
Thanks for the feedback! I am improving the examples here: openui/open-ui#918 |
I just wanted to point out Windows doesn't provide flag emojis so this specific example is a good use case for needing images not emoji. |
If you use
For It would also have the benefit of having a consistent design with (There are some challenges here with how to match these options and their elements from CSS, but that seems like a surmountable problem.) I haven't looked at survey in detail, but I'd assume that if |
I’ve been discussing with @annevk and @pxlcoder about how to move forward here, and we have reached agreement on some things. Please correct if I misrepresent anything!
|
I'm concerned by the implications of the multiple attribute. How does it work with the new parsing? That being said I am excited by the progressive enhancement possibilities. |
@annevk The majority you cannot and it isn't solely about styling but also extending them. While
@josepharhar @annevk so will this likewise have the child of |
The idea (as I see it) is to still have a The UA shadowroot will certainly adapt if and when needed to support slotting in and replacing the default button and listbox. Does that answer your question? I'm not sure if I understood it well. |
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177
Adding agenda+ to move this to stage 1 |
I updated the explainer to be |
To me that does not seem like the right approach. That's still the line in the sand approach I referred to above. Showing options as a "popover" should purely be the result of I'm not sure what's lacking about keyboard focus, and a11y, but it seems like that should also be a universal improvement. |
@annevk said:
I just want to note that if this was one of the big worries, that it should be out of the way with an attribute as well. It does feel as @mfreed7 mentioned that an attribute is likely the more natural pattern and that children deciding parser behaviour feels like an anti-pattern (declaring the intent twice, based on children). Parsing based on children could also lead to more author errors. |
Why would it be out of the way with an attribute? An attribute as you all have envisioned creates the exact kind of mode switch we'd want to avoid. I also don't follow what you're saying about the HTML parser. Perhaps you can describe the dilemma you see there in more concrete terms? The entire parser is structured around branching on tag names which is exactly what we'd be doing here. It wouldn't affect the parent one bit. And as I mentioned above it seems worthwhile investigating if we can allow things like |
Even if it doesn't really affect the parent in a technical way. It feels like I'd be telling the browser: I want a select, and then telling again in the children: I still want a select, but I want it styleable. This is a complete different way than saying it inside of an attribute, that is what authors are used to. Example: I want an input and I want it to be a (type)date. aka: do those things for me based on the attribute. This would be the equivalent that HTML should be like this:
Note that a select without any options in, still looks like a select. So in that case, children don't matter. Except it won't show a listbox. (Exaggerated example, but wanted to make a point of how it feels) I'm sorry if I can't give you any more technical reasons as I'm not a browser engineer, just an interested front-end developer (from what I hearing, both ideas are technical possible). I think I made my point as it is about consistency and general tutoring and feeling (yes, I believe that last one can be important). I would be utterly astonished if I would be the only developer thinking that way. Consider this "user feedback" from me. Maybe it could be asked around in developer communities a bit more. |
You're still thinking of a mode switch. I'm saying that the select element we know today should be styleable as well in the exact same way. There's no before and after. The parser changes will enable developers to include more types of descendants, but that's it. Everything else should apply universally. |
Given the very high usage of the existing select, with its current behaviors and idiosyncrasies, I would have serious doubts that we could just change all of them in a way that would be web compatible. There will need to be an opt-in. |
Agreed, there are bound to be sites that have complex content that currently we're throwing away for a variety of reasons and would not be backwards compatible. An additional thing to consider is that this has to be contained within the viewport for security reasons. So there has to be some opt-in to get this new behavior.
@brechtDR just a reminder that this solution we're discussing is solely for changing the DOM structure and its defined behaviors on that structure. The opt-in to make it base styles so that you can interoperabley style it will come from the CSS property. |
The opt-in for different styling (within viewport) is |
Isn't the viewport security model relevant to new parsing too? If we're allowing arbitrary content isn't that bad enough without full styling? |
User agents get to decide what they propagate. I would imagine we would not let anything through but images and text. The richer data structure ultimately needs to be able to flatten to text options for a11y and cross-platform purposes anyway. That happens to also work well for native popup windows. |
I feel like we're going in circles and possibly conflating the issues since you can theoretically add support for images on their own in Regarding the below comment @annevk: Apologies I am still confused on the "line-in-the sand". We'll need to fix up the DOM in some manner that is backwards compatible. The Open UI CG decided on attribute, am I understanding your position correctly that you only want a CSS solution for that?
|
@gregwhitworth I'm not really sure what you're saying. The DOM can already be whatever (using |
No? We need HTML parser changes. And if we're going to allow more elements we also need various semantic changes and possibly API changes. I just don't see the need for a mode switch / line in the end / whatever on the HTML side. There's no need for an old and a new select element. |
One important thing, for compat, is that doing this with <select id=s></select>
<script>
const div = document.createElement('div');
div.innerHTML = '<option>Hello<option>there';
s.appendChild(div);
</script> With your current proposal, that would start rendering the options, I believe. Because the parser would now allow HTML with the equivalent wrapper |
I don't think that's true. We will need to define the semantics of the Let's try what @domenic suggested in Chat and explore the different pieces to the
|
Ok, that might alleviate some of the compat concerns. We're going to try to measure how often existing However, the primary #1 use case is support for arbitrary content. It might be ok to restrict the direct children of the
Agreed. Likely just
Agreed. There was a concern raised by Apple - that conditioning the shadow tree based on CSS property values might be difficult to implement. Is that not the case any longer? (We are going to try to prototype it in Chromium to see what breaks, but we haven't done that yet.)
Here, doing this is likely web-incompatible, since the behavior changes will be quite observable. Did you read through the various behaviors? 1, 2, 3, 4, 5, 6, 7, 8. Many of those differ from existing browser behavior, for at least some browser/platform permutations. My guess is that many of those changes would need to be opt-in. I'd be happy to be proven wrong here. |
1 — I don't think I said otherwise? 3 — I'm not sure the concern was raised by Apple? The minutes suggest Emilio brought it up. In any event, we went over that already here: w3c/csswg-drafts#5998 (comment). I'm not sure why you keep coming back to a 2021 set of minutes when there's been ample discussion since. 4 — Those will need further discussion looking at those issues. In particular for the "native appearance" we would not want to deviate from platform conventions and at least thus far we haven't been that prescriptive on specific end user interactions. |
Oh good! I think I misunderstood this comment of yours: '"img" as a child of "option" would also make sense to me'. I took that to mean only img would be allowed as a child. I suppose based on this comment you meant only when the
The comment you made immediately after the one linked above says "WebKit at least hasn't fully ruled out that option", which isn't the same as "WebKit supports this option". You also said "I think the details of the CSS-based solution are still up for debate." I didn't see any more conclusive comments - please link them if I missed it! If you read my comment, I'm just trying to get some directional clarity before we invest further in changing the behavior of the prototype again.
I think perhaps I misunderstood your initial comment as saying you wanted the keyboard and a11y behavior to work the same in "native" and "interoperable" mode. If not, great. |
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5118452 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1248491}
As per the spec discussion, we are going to allow <button>s in <select> to replace the opener button and <datalist>s in <select> to replace the listbox instead of creating a <selectlist> element. whatwg/html#9799 Bug: 1511354 Change-Id: If2ee766c57faf655ab31c6714be7fd682efcc177 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5118452 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1248491} Former-commit-id: 9dbf01fc6602197c0d8626e5268b6c6a54fe76b3
Edit: I am proposing stylability and other improvements for the
<select>
element rather than a new element based on the discussion in this issue. The explainer has been updated.Original description below:
I'd like to propose the new
<selectlist>
element, as described in this explainer: https://open-ui.org/components/selectlist/This element still has a lot of open issues as listed in openui, but for now I'd at least like to know if people agree that this is a problem worth solving. The problem is that the existing
<select>
element is not customizable in terms of appearance or behavior which leads web authors to build their own and miss out of the usability, accessibility, and autofill features of builtin elements like<select>
.The text was updated successfully, but these errors were encountered: