-
Notifications
You must be signed in to change notification settings - Fork 673
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
[selectors-4] Should we have :open and :closed? #11039
Comments
Note in particular that the justification for |
Okay, if you purposely don't want to hook :closed to the "openability" of an element, then yeah, it's completely redundant with |
I am in favor of removing :closed |
The CSS Working Group just discussed The full IRC log of that discussion<gregwhitworth> jarhar: I was hoping this will be quick<brecht_dr> q+ <gregwhitworth> jarhar: I tried to spec the open and closed pseudo classes in HTML that are in CSS and I was informed that they are redundant and remove the :closed pseudo selector <gregwhitworth> ack brecht_dr <gregwhitworth> brecht_dr: one benefit of having :closed is you can select a sibling in CSS with that state and you can make that default and only do it on open <gregwhitworth> brecht_dr: I see some benefit to having this as well and we have this with disabled and almost no one uses enabled <gregwhitworth> anne: in those cases you can use :not(:open) <gregwhitworth> anne: if there are controls we might provide a picker; :close would not always match unless there is an open state <gregwhitworth> anne: at least until we have a better handle on that open is easier and in the scenario where you'll know there is a picker you can do :not(:open) <gregwhitworth> ack dbaron <gregwhitworth> dbaron: I think historically CSS has pairs is so that you can distinguish between the ones they apply and those they don't <gregwhitworth> dbaron: :close only matches things that could be :open <gregwhitworth> dbaron: could definition could be non-trivial to be defined and as we talk about inputs that "could" have a picker is not a trivial thing and :close would only apply to a picker like "color", "date" would match if they have a picker and they are closed now <gregwhitworth> q+ <jarhar> gregwhitworth: i feel like david you agreed with anne, you can do that with not <gregwhitworth> ack gregwhitworth <masonf> q+ <jarhar> dbaron: with input its harder to do that with not because you need to write input type= and get the selector for type exactly right and then put not open <gregwhitworth> dbaron: it's harder to do with :not on inputs is you need to get the type attribute correct <gregwhitworth> anne: I don't think we want to expose which controls have a picker <masonf> q- <gregwhitworth> anne: :closed would expose which controls have a picker <jarhar> q+ <gregwhitworth> tim: the reason that is an issue is that the picker is not set and it may vary <gregwhitworth> anne: iOS select multiple has a picker vs inline compared with Desktop <gregwhitworth> ack jarhar <ntim> ntim: the set of elements that have a picker is not finalized* <gregwhitworth> jarhar: I really would like to move this forward and I'm fine with removing closed for now, does someone have strong feelings to keep closed right out of the gate <masonf> proposed resolution: support :open for now, leave :closed for later. <gregwhitworth> argyle: yeah, it seems obvious to include them and we think :not(:open) is the same then it seems solvable and they should be provided <gregwhitworth> anne: :closed would only match an element that HAS a picker and that capability may change over time <gregwhitworth> anne: :open will only match if the picker is shown and that will require a user action <gregwhitworth> argyle: we can determine that today correct? <ntim> q+ <gregwhitworth> anne: whether it's web observable or not <gregwhitworth> argyle: isn't that a pseudo element of picker() making it web observable? <gregwhitworth> argyle: as someone coming into this we have :open but not :close? <gregwhitworth> ntim: the main problem here is someone uses :close selector on the web page and we expand the set of things that have pickers then :close will apply to more things with no action <masonf> q+ <gregwhitworth> ntim: it's a compat hazard and it doesn't require any action for it to apply <gregwhitworth> ack ntim <gregwhitworth> argyle: can we teach "closed" to be to :not(:open) <gregwhitworth> ntim: there is a difference <gregwhitworth> masonf: this is akin to appearance: base in that there is compat concerns and once we have all the controls that have pickers we may come back and address them? <gregwhitworth> anne: maybe, we have to figure out the platform "thing" <gregwhitworth> anne: there was TAG feedback on whether these should be feasible or not <gregwhitworth> anne: so I think that would be TBD <gregwhitworth> q? <gregwhitworth> ack masonf <jarhar> proposed resolution: remove :closed for now and keep :open <gregwhitworth> argyle: I'm in agreement with jarhar that sympathises and I'll not blocking it <masonf> +1 |
I didn't type the RESOLVED fast enough before the topic was switched, but we resolved on removing :closed for now and keeping :open |
It was resolved here to have both :open and :closed pseudo-classes: #7319 (comment)
@annevk mentioned here that :closed is redundant with :not(:open): WebKit/standards-positions#413 (comment)
Here is the justification for having both of them: #7319 (comment)
The HTML spec has not been merged yet: whatwg/html#10126
The text was updated successfully, but these errors were encountered: