Re: [csswg-drafts] [dialog element] <dialog> positioning should be describable in CSS (#4645)

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