- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Oct 2020 15:00:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Dialog element`, and agreed to the following: * `RESOLVED: Add a hidden pseudo-class for this purpose, in order to solve styling issue while leavine open the possibility of HTML improving its API` <details><summary>The full IRC log of that discussion</summary> <florian> topic: Dialog element<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4645<br> <florian> TabAtkins: there's a discussion in HTML about fixing the dialog element to use CSS instead of being a hack<br> <florian> TabAtkins: they realized that there's a big difference between<br> <florian> TabAtkins: when it's opened normaly vs as a moal<br> <florian> s/moal/modal/<br> <florian> TabAtkins: it's based purely on which js method you use to open it<br> <florian> TabAtkins: so we need some way to distinguish, and a pseudo class seems most natural<br> <leaverou> q+<br> <florian> TabAtkins: the proposal is :modal<br> <astearns> ack leaverou<br> <florian> TabAtkins: seems good to me, but we need to make sure we don't want to use it for something else<br> <florian> leaverou: feels like defining a pseudo class to work around a problem with the API<br> <florian> leaverou: seems to me that there should be a modal attribute<br> <florian> leaverou: don't see why we need to fix it in css<br> <fantasai> +1<br> <emilio> q+<br> <miriam> +1<br> <brandon> +1<br> <florian> leaverou: seems weird that you need to use JS, and cannot do it in markup<br> <astearns> ack emilio<br> <leaverou> s/seems weird that you need to use JS, and cannot do it in markup/seems weird that you need to use JS, and cannot do it in markup, when you can already use the `open` attribute to open it in a non-modal way/<br> <florian> emilio: toggling the attribute is not the same as calling dialog.open<br> <florian> emilio: it's bad, but that's the way it is<br> <emilio> https://github.com/whatwg/html/issues/5802<br> <florian> iank_: it is a strange API, don't want to add more attributes to it<br> <smfr> q+<br> <leaverou> if the API is messy, maybe it needs more work before we add things to CSS for it?<br> <florian> gregwhitworth: if this is so bad, and is so confusing, why are we ducktaping this?<br> <florian> iank_: many sites use it, so there's a big compat risk<br> <florian> iank_: we aren't happy with how the modal works today, and we're willing to change<br> <florian> iank_: ... to make it describable in css<br> <florian> iank_: if we were doing it from scratch today, we'd do it differently<br> <florian> SimonSapin: modal go in a magic layer of over the page<br> <smfr> s/SimonSapin/smfr/<br> <florian> smfr: ...<br> <florian> iank_: ......<br> <gregwhitworth> smfr: I would like to define the top layer to be used by other elements, it could be used here<br> <fantasai> scribenick: fantasai<br> <fantasai> smfr: I suggest to use UA stylesheet rules to also describe the top-layer behavior of the modal dialog<br> <fantasai> iank_: Broadly speaking, this is what the HTML pull request does today. It adds one new pseudo-class, :modal, and removes all of the special-case rendering logic<br> <fantasai> iank_: and replaces it basically with one additional UA stylesheet rule<br> <fantasai> iank_: What gives me confidence in this approach is that this is what Gecko does today, using an internal pseudo-class<br> <fantasai> iank_: One thing it doesn't describe, broader issue, is how does the "top layer" work.<br> <fantasai> iank_: Tab has previously wanted to explain how that works somewhere else<br> <bkardell_> q+<br> <smfr> q-<br> <fantasai> iank_: This fixes all the special-casing text that was there previously, except fixing top-layer<br> <fantasai> iank_: Moves us significantly closer<br> <astearns> ack bkardell_<br> <fantasai> bkardell_: There are a few proposals going back to 2014/15 or so<br> <fantasai> bkardell_: to explain top layer<br> <fantasai> bkardell_: not in CSS<br> <fantasai> bkardell_: but there's prior attempts that exist that are worth looking at<br> <TabAtkins> fantasai: Going back to Lea's point, why isn't this an attribute on the element?<br> <TabAtkins> fantasai: We could do all this in the UA stylesheet keyed off an attribute, wouldn't that be more consistent?<br> <TabAtkins> fantasai: Maybe removing/adding modal doesn't do anything because it's really the show()/hide() methods and how they sync with [open] that's important...<br> <fantasai> iank_: the open attribute is very special and strange<br> <fantasai> iank_: wouldn't want to add anything like that<br> <fantasai> emilio: adding/removing the open attribute doesn't fire the relevant events<br> <fantasai> emilio: dialog element is expected to be used via JS APIs<br> <gregwhitworth> iank_: emilio and it wouldn't be web compatible to add those linkages?<br> <fantasai> emilio: already weird that it has this reflection already<br> <fantasai> gregwhitworth, if you're talking to someone, use a comma<br> <fantasai> gregwhitworth, that looks like you're correcting the minutes<br> <fantasai> emilio: ...<br> <fantasai> astearns: Her proposal is to add a new modal attribute, not to re-use open<br> <fantasai> leaverou: can the issues be fixed?<br> <fantasai> emilio: tangential to this<br> <fantasai> emilio: removing [open] doesn't fire the right events and fix the behavior currently<br> <gregwhitworth> q+<br> <fantasai> emilio: it's not great<br> <fantasai> emilio: might want to fix it, but it's a separate issue<br> <astearns> ack gregwhitworth<br> <fantasai> gregwhitworth: I agree fixing them is a separate issue, but not separate wrt this discussion<br> <fantasai> gregwhitworth: because I like what leaverou is proposing here<br> <fantasai> gregwhitworth: In order to make dialog more cohesive, I think we should go back and fix it<br> <fantasai> gregwhitworth: Is there a massive web-compat problem with making open do the right thing and fire all the events?<br> <fantasai> iank_: There's a few other pressures here<br> <fantasai> iank_: I would be concerned with any compat change around that area. Been there for a long while.<br> <fantasai> iank_: Took us 6 months to do compat analysis just for this change<br> <fantasai> iank_: and it's a bit pressing<br> <fantasai> iank_: and with any major compat change, the window closes the longer it exists<br> <leaverou> it seems to not have shipped in Gecko or WebKit, how popular can it be? https://caniuse.com/?search=dialog<br> <fantasai> iank_: Yes, we can potentially fix open and how that work, yes we can add modal, but that would take a long time<br> <fantasai> emilio: My other concern with magic attributes that fire events is XSS<br> <fantasai> emilio: ? fires an event even when you parse it<br> <fantasai> emilio: and we only realized about DETAILS way too late<br> <fantasai> s/?/DETAILS/<br> <fantasai> iank_: I don't think having an attribute API for dialog is a good idea<br> <fantasai> iank_: I would push back against adding a modal attribute on that basis<br> <fantasai> gregwhitworth: Then, channeling Rossen from Grid, I think we should be going for symmetry<br> <fantasai> gregwhitworth: Not fixing open maybe but get rid of it<br> <fantasai> astearns: This discussion seems to be opening wider and wider. Maybe kick over to Open UI?<br> <fantasai> astearns: to discuss pseudo vs. attribute vs. no attribute?<br> <emilio> q+<br> <fantasai> iank_: If we want to get rid of Chrome's special dialog behavior here, we can only do this for another few months<br> <fantasai> iank_: People will be relying on dialog, and will rely on our behavior. So would like a decision now.<br> <fantasai> iank_: At the request of this group and other browser vendors, did a lot of compat analysis<br> <fantasai> iank_: ...<br> <gregwhitworth> fantasai, I'll scribe ya<br> <fantasai> emilio: My other bit about why I think modal attibute is not a great idea is that it breaks how the JS APIs structure<br> <astearns> ack emilio<br> <fantasai> emilio: Whether modal pseudo-class applies depends on how you open the dialog<br> <fantasai> emilio: but you could toggle modal attribute while the dialog is open<br> <leaverou> re: webcompat, <dialog> is used in <0.005% of websites (6000 in HTTPArchive): https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/edit#gid=781932961<br> <fantasai> emilio: At the point you can toggle modal, ...<br> <fantasai> emilio: I think that would be great<br> <fantasai> emilio: but fixing dialog positioning is important, would rather not get side-tracked<br> <TabAtkins> q+<br> <astearns> ack fantasai<br> <gregwhitworth> fantasai: so I agree with iank_ we should fix the styling issue for compat<br> <gregwhitworth> fantasai: clearly, it will take a while for a modal attribute - maybe that's still a possibility<br> <gregwhitworth> fantasai: one is that we intro a new pseudo class that everyone can use<br> <gregwhitworth> fantasai: other option is to do one internally the way that FF is doing<br> <gregwhitworth> fantasai: then we decide how to move forward via a pseudo class and attribute<br> <leaverou> q+<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: We seem to have fairly broad implementer agreement that they likely don't want to add modal<br> <fantasai> TabAtkins: Going back, we could maybe pursue removing open attribute<br> <fantasai> TabAtkins: so that's a possibility for us<br> <astearns> ack leaverou<br> <emilio> q+<br> <fantasai> leaverou: Adding a modal attribute is just a possibility. Could alternately add a value to open<br> <fantasai> leaverou: open=modal<br> <fantasai> leaverou: But goes back to ???<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fantasai> leaverou: Introducing HTML elements that can't be used without JS is an issue<br> <fantasai> leaverou: Shouldn't we fix this generally?<br> <astearns> ack emilio<br> <leaverou> It sounds like the same arguments apply to <details> as well<br> <leaverou> Is the direction we want to go to be adding interactive HTML elements that can't work without JS?!<br> <leaverou> shouldn't these issues be addressed instead of giving up on HTML attributes altogether?<br> <fantasai> emilio: leaverou, and gregwhitworth, would you be opposed to defining a hidden pseudo-class, so we can move forward with the styling issue without changing the public API of this ?<br> <fantasai> emilio: It's nice to expose the pseudo-class from the UA stylesheet<br> <fantasai> emilio: but also fine with keeping it internal<br> <iank_> i can live w/ that as well.<br> <fantasai> emilio: and address the open/modal attributes separately from this<br> <fantasai> astearns: So proposed solution is to add a hidden :modal pseudo-class for now.<br> <fantasai> florian: Do we need to define that a hidden pseudo-class exists? Do we need to spec anything?<br> <fantasai> TabAtkins: no<br> <fantasai> emilio: Define in HTML spec using prose instead of a pseudo, but that's fine<br> <fantasai> astearns: We'd spec as browser-internal thing, and then if it proves out, then we write spec text to expose it<br> <fantasai> leaverou: Is a hidden pseudo-class undocumented or unusable by authors?<br> <fantasai> TabAtkins: only usable in UA style sheet<br> <fantasai> gregwhitworth: I think it's a good compromise.<br> <fantasai> gregwhitworth: Deals with compat issue, but leaves the door open to imprve the API<br> <fantasai> gregwhitworth: Maybe worth noting it somewhere?<br> <fantasai> iank_: We'll be adding this to the HTML spec , most likely way to specify this<br> <TabAtkins> Yes, this is the correct way to do it<br> <fantasai> iank_: is to define the :modal pseudo-class and define that it's only usable in UA stylesheet<br> <fantasai> iank_: maybe call it :-internal-modal<br> <fantasai> RESOLVED: Add a hidden pseudo-class for this purpose, in order to solve styling issue while leavine open the possibility of HTML improving its API<br> <TabAtkins> ScribeNick: TabAtkins<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-715396081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 October 2020 15:00:51 UTC