- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Aug 2022 16:55:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] Add :open or :top-layer pseudo class`, and agreed to the following:
* ``RESOLVED: start work on an `:open` pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.``
* ``RESOLVED: start work on an `:open` as a pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.``
<details><summary>The full IRC log of that discussion</summary>
<astearns> topic: [selectors] Add :open or :top-layer pseudo class<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/7319<br>
<argyle> astearns: mason, i assume you'll take this<br>
<argyle> masonf: we have discussed this before, in june, initially propsoed as a top layer psudo class. we need something like this for the popup api<br>
<argyle> masonf: general conclusion in open ui and reading issues in css, we'd prefer to do something like :open<br>
<argyle> masonf: liek a selector that matches thigns open. both modals and dialogs included<br>
<chris> that would include open details elements?<br>
<argyle> masonf: both modal and non modal, details elements, popup api, possibily select<br>
<astearns> chris: yes<br>
<dbaron> s/both modal and non modal/dialogs (both modal and non modal)/<br>
<argyle> masonf: agenda on open ui today to discuss for a different psuedo class for select<br>
<argyle> masonf: general consensus and hoping to heaer resolution on an open speudo class<br>
<argyle> astearns: queue up if you havce questions<br>
<TabAtkins> +1<br>
<bramus> +1 for `:open`<br>
<astearns> ack fantasai<br>
<chris> +1 for :open<br>
<argyle> fantasai: may not have fully followed it, say its a details element that's oepn, this would match open?<br>
<argyle> masonf: correct<br>
<argyle> masonf: even tho it's not in the top layer, the :open class is unrelated<br>
<astearns> masonf: this is no longer a top-layer only thing<br>
<argyle> fantasai: is it going to match things like form controls while open?<br>
<argyle> masonf: that's debatable. there was discussoin on select whether or not we should allow it to be visible as a thing<br>
<astearns> q+ ntim<br>
<argyle> masonf: some platforms done preovide a calendar picker<br>
<argyle> fantasai: i like the idea of :open, useful in a number of cases, hesistant to add it due to ambiguous points. we need a definition that covers all the current and future elements, so we have a consistent story for what open means<br>
<argyle> fantasai: a clear definition where any person can look at an html element they have a clear idea of whether it can be open or not<br>
<masonf> q?<br>
<astearns> ack ntim<br>
<masonf> q+<br>
<argyle> ntim: if you put the open attr on dialog, it will visually appear open because of the user agent stylesheet, but on the dom side it wont be considered open ,what should we match for that case?<br>
<argyle> masonf: in what sense wont it be open? it will be visible<br>
<argyle> ntim: it wont be tracked as open but will be visible. if you dialog.setAttribute('open', true) as opposed to dialog.showModal()<br>
<argyle> masonf: difference will be whether or not events are fired?<br>
<fantasai> I just want to record strong +1 to plinss's comment https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1193026841<br>
<argyle> ntim: attr will confused the browser because, especially, if you put :open and then .showModal(), or wierd combinations, you end up in a broken state<br>
<plinss> q+<br>
<argyle> ntim: dom doesnt consider just setting hte open attribute to be having the dialog open. the UA will use the open attribute. maybe one thing we could do is<br>
<argyle> ntim: make the pseudo class match the dom state and change the UA to use the new pseudo class.<br>
<argyle> ntim: and make the pseudo match the dom state. so you dont have confusion between visually open and ..<br>
<argyle> masonf: there is an open issue for dialog. open attribute behaves wiedly in various cases<br>
<argyle> masonf: this proposal you make could be good tho<br>
<argyle> masonf: but i'd like to propoe a working definition for open, for things that can visually open and close, and when they are open it matches :open<br>
<argyle> ntim: i think if you want to define a def for dialog, we need tor esolve whichd efinition of open we want to take first<br>
<argyle> masonf: that's what i'm proposing, open things match :open<br>
<argyle> ntim: like visually oepn, via show or attribute change?<br>
<emilio> q+<br>
<argyle> masonf: the current dialog beavhior is funny, but i think, if you add the open attibute to a dialog, it becomes visible, i expect the pseudo class to match<br>
<argyle> astearns: mason were you on the Q to respond to tim? have you done that?<br>
<argyle> masonf: yes i've done that<br>
<astearns> ack masonf<br>
<astearns> ack plinss<br>
<argyle> plinss: first i'm generally in favor of an open pseudo, i agree with fantasai that we need a clear definition, like in the HTML spec. this thing is in the modal state, how it gets in and out of the state. i dont think we should have this in the CSS spec, that this is openish<br>
<fantasai> s/have this/have/<br>
<masonf> q+<br>
<argyle> plinss: needs a hard definition.<br>
<argyle> plinss: my other bigger concern is, coming from TAG perspective, we have a problem of managing this kind of state<br>
<argyle> plinss: this isnt welld efined on web platform, this is a mess<br>
<argyle> plinss: there's areas where things are controlled with an attribute, a property, and with toggles() we can open with a CSS property<br>
<argyle> plinss: if css can do that, we can get into circularity issues<br>
<fantasai> s/toggles()/CSS Toggle spec/<br>
<argyle> plinss: we need to take a step back and make sure it all plays nicely together<br>
<argyle> TabAtkins: we shouldnt have circularity here<br>
<bkardell_> would like to say that I like what plinss is saying here<br>
<fantasai> +1<br>
<argyle> plinss: one of the things i understand for toggles, offered defined elements, something like details with open with a toggle, shouhld that represent this pseudo class?<br>
<argyle> TabAtkins: that's entirely author controlled<br>
<bkardell_> q+<br>
<dbaron> The :open pseudo-class should reflect something that is open according to the markup language and its api.<br>
<argyle> plinss: now i have an independent method for opening and closing things. one or more of these may interact well the others<br>
<argyle> plinss: if an author is building ac ustom element, they should be able to use a simlilar method the pljatform has<br>
<argyle> plinss: so if an author is building a custom element with open/close, they should have a way to interact with this. if we say toggle()'s is the way to do that, we need to know how it shoulhd all work<br>
<fantasai> s/well the others/well the others. There are multiple ways to make something open, and this is getting all weird and inconsistent/<br>
<argyle> astearns: can we pospone this to a future call and have a separate discussion about<br>
<argyle> TabAtkins: the design of it will be about getting to his concern more directly, which i believe will resolve concerns here<br>
<argyle> TabAtkins: the issues you're bringing up has been true for CSS's lifetime, it can do something that triggers off something thats emulatable by hand<br>
<argyle> TabAtkins: nothign new about :open that makes it wierder than anything else<br>
<argyle> fantasai: depends on how you define it<br>
<argyle> TabAtkins: secondly, looping toggle()'s, only circularity if it's a pure CSS loop<br>
<argyle> TabAtkins: if toggle()'s can hook up to something that can reflect :open, it woulud be dependent on toggle() state, that is intentially not controllable by css.<br>
<argyle> astearns: the toggle() state is ddriven by js and user interaction<br>
<argyle> astearns: i'd like to close this off for now, and go back to the queue<br>
<argyle> astearns: but, i'd like to constrain this so we can get to a resoution or choose not to<br>
<argyle> astearns: just about whether we start work on an :open pseudo<br>
<masonf> - Proposed resolution: add `:open` as a pseudo class, which matches things that are in an "open" state. We need to define that state carefully.<br>
<argyle> astearns: lots of things to elaborate on that can be separate issues, i want to drill down to objections to starting work, not figuring out details<br>
<astearns> ack emilio<br>
<argyle> emilio: was going to say omething about what mason said, about the pseudo class, i dont think we shoul duse the attribute for htis. it's a separate issue and i'm happy to punt on this. dont need to discuss the rest<br>
<astearns> ack masonf<br>
<dbaron> s/rest/rest. But I think that :open should be based on the UA-internal state that happens from openDialog./<br>
<argyle> masonf: plus one yours and put a resolution into the chat. agree i'd like resolution on :open interest, then more issues for precision<br>
<argyle> masonf: regards to :modal, something similar to that would be great today. needs a careful definition too<br>
<argyle> masonf: there is no :modal definition in the HTML spec<br>
<argyle> rreno: there is one<br>
<argyle> masonf: but it's missing :fullscreen definitions, etc<br>
<argyle> masonf: there's a defnition of a modal dialog, but not :modal<br>
<astearns> ack dbaron<br>
<argyle> astearns: david you're next<br>
<argyle> dbaron: was going to support the idea that if we agree to do this, and say that we need formal definitions of what :open is, where markup defines what it si to be open, so the htmlm spec would have those defs, this would addreess some of peters other concerns, based on suggestions mason gave, dialog and details and maybe seleect, and so on<br>
<argyle> dbaron: i'm thinking then, through the process of writing those def formally, you avoid the circularity issues of a more vague definition<br>
<masonf> +1 dbaron, well said<br>
<astearns> ack bkardell_<br>
<argyle> bkardell_: i dont object to us starting to define the speudo class, i do agree with david that the act of defining it can deal with alot fo this<br>
<argyle> bkardell_: state doesnt necessarily mean the same thing all the time<br>
<argyle> bkardell_: we have contorls that are unchanging, they're immutable in their, that have particula rmeaning<br>
<argyle> bkardell_: there's other things, where plinss was detailing, something like summary/details, where perhaps it's not always shhown with a contorl nature, sometimes you want it open, sometimes you want it closed<br>
<argyle> bkardell_: they're matters of display, they're in the domain of css<br>
<argyle> bkardell_: i favor us having a wider discussion and careful articulation of that<br>
<argyle> bkardell_: and how it all plays together<br>
<argyle> bkardell_: i think that's important to make good progress<br>
<astearns> ack fantasai<br>
<argyle> fantasai: :modal was more straight forward, i think we can come up with a conceptual def of :oepn, and have the HTML spec define it, dont think HTML spec should only define it<br>
<argyle> fantasai: we want the html spec as it evovles, and other languages, to be able to easily and clearly understand what it should match when its :open<br>
<argyle> fantasai: i dont think we have a clear idea of what that means yet, and has intent to add something like this until we have a proposal, wheere everyone agrees ont he delineation where we can extrapolate clearlyl withohut arbitrary decisions because it's not a clear def that cuts through all the open or not open items<br>
<argyle> fantasai: i'm not opposed to working on it, i wouljd be opposed to adding it to the spec right now, until some of these questions are answered enough where we can make a fairly clear argument for each element whether it's open or close.<br>
<masonf> +1 to fantasai's point that we need a conceptual definition. At least at the same level of detail as we have for :modal.<br>
<argyle> fantasai: can try to draw the line, and then use that to extrapolate. but i dont want to add something so fuzzy that we end up making decisions that are inconistent over time cuz we can come up with someting clear enough<br>
<masonf> - Proposed resolution: add `:open` as a pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.<br>
<TabAtkins> I fundamentally don't understand where this is coming from. We proposed the elements it would match. There's an open question about if any <input>s should, which can be quickly argued and answered in the thread.<br>
<argyle> astearns: are you ok working on that resolution? in this issue? until the point at which fantasai and the rest of the group agree it's ready to go into the spec?<br>
<argyle> masonf: we agree with my propiosed resolution?<br>
<argyle> astearns: makes sense to me<br>
<argyle> astearns: anyone want to make changes to the proposed resolution?<br>
<argyle> fantasai: they work on defining an :open instead of just add it<br>
<argyle> astearns: start work on an :open speudo class, in the issue<br>
<dbaron> s/they work/say work/<br>
<masonf> Proposed resolution: start work on an `:open` as a pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.<br>
<argyle> astearns: any other amendments to the proposed resolution?<br>
<chrishtr> + to this resolution<br>
<masonf> Proposed resolution: start work on an `:open` pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.<br>
<argyle> astearns any objections?<br>
<tantek> +1<br>
<argyle> astearns: alirght we're resolved to start work on an :open pseudo<br>
<masonf> RESOLVED: start work on an `:open` pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.<br>
<argyle> astearns: ty mason<br>
<argyle> masonf: ty<br>
<argyle> astearns: anything else on this issue today?<br>
<argyle> RESOLVED: start work on an `:open` as a pseudo class, which matches things that are in an "open" state. We need to define that state carefully, with a general conceptual definition that can be used by HTML for the specifics per-element.<br>
<masonf> thank you for not holding on to the time box. :-)<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1225988203 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 August 2022 16:55:20 UTC