IRC log of css on 2022-06-22
Timestamps are in UTC.
- 14:57:17 [RRSAgent]
- RRSAgent has joined #css
- 14:57:17 [RRSAgent]
- logging to https://www.w3.org/2022/06/22-css-irc
- 14:57:20 [Zakim]
- RRSAgent, make logs Public
- 14:57:21 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 14:58:08 [Rossen_]
- Zakim, end meeting
- 14:58:08 [Zakim]
- As of this point the attendees have been (no one)
- 14:58:09 [Zakim]
- RRSAgent, please draft minutes v2
- 14:58:09 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/06/22-css-minutes.html Zakim
- 14:58:13 [Zakim]
- I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye
- 14:58:17 [Zakim]
- Zakim has left #css
- 15:02:16 [chris]
- chris has joined #css
- 15:18:42 [jensimmons]
- jensimmons has joined #css
- 15:49:30 [gtalbot]
- gtalbot has joined #css
- 15:54:39 [Rossen_]
- Rossen_ has joined #css
- 15:55:13 [Zakim]
- Zakim has joined #css
- 15:55:25 [Rossen_]
- Zakim, start meeting
- 15:55:26 [Zakim]
- RRSAgent, make logs Public
- 15:55:26 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 15:57:39 [jfkthame]
- jfkthame has joined #css
- 15:58:46 [lea]
- lea has joined #css
- 15:58:58 [lea]
- present+
- 15:59:00 [vmpstr]
- vmpstr has joined #css
- 16:00:18 [bramus]
- bramus has joined #css
- 16:00:28 [ydaniv]
- ydaniv has joined #css
- 16:00:48 [futhark]
- futhark has joined #css
- 16:00:51 [TabAtkins]
- present+
- 16:01:03 [xiaochengh]
- xiaochengh has joined #css
- 16:01:10 [bramus]
- present+
- 16:01:17 [jfkthame]
- present+
- 16:01:23 [vmpstr]
- present+
- 16:01:25 [TabAtkins]
- ScribeNick: TabAtkins
- 16:01:34 [chrishtr]
- https://github.com/w3c/csswg-drafts/issues/7317#issuecomment-1154394479
- 16:01:53 [futhark]
- present+
- 16:02:03 [smfr]
- smfr has joined #css
- 16:02:29 [faceless]
- present+
- 16:02:31 [flackr]
- flackr has joined #css
- 16:02:41 [argyle]
- present+
- 16:02:41 [plinss]
- present+
- 16:02:45 [Sebo]
- Sebo has joined #css
- 16:02:50 [emilio]
- present+
- 16:02:52 [flackr]
- present+
- 16:02:54 [chris]
- present+
- 16:02:54 [delan]
- present+
- 16:02:56 [smfr]
- present+
- 16:03:02 [Rossen_]
- present+
- 16:03:03 [miriam]
- present+
- 16:03:06 [masonf]
- masonf has joined #css
- 16:03:16 [masonf]
- present+
- 16:03:26 [jensimmons]
- present+
- 16:03:33 [rachelandrew]
- present+ (irc only for the first half)
- 16:03:37 [fremy]
- fremy has joined #css
- 16:03:45 [fremy]
- present+
- 16:04:18 [TabAtkins]
- Rossen_: We've tallied the summer f2f results
- 16:04:27 [TabAtkins]
- Rossen_: Decided to hold as much of an f2f as possible in person
- 16:04:29 [Sebo]
- present+
- 16:04:33 [TabAtkins]
- Rossen_: For those who can make their way to NYC
- 16:04:44 [TabAtkins]
- Rossen_: For everyone else, we'll make sure we have proper virtual facilities for participation
- 16:05:15 [TabAtkins]
- Rossen_: Picked timing and place based on allowing other participants to allow TAG f2f, as well as having a geo location that's okay for global participation
- 16:05:25 [astearns]
- This will also allow us to test out substantial virtual participation pre-TPAC
- 16:05:30 [TabAtkins]
- Rossen_: No one's going to be perfectly satisfied unless they're already in east coast time zone
- 16:05:50 [TabAtkins]
- Rossen_: Putting it earlier would be hard for lack to warning for travel and location
- 16:05:51 [dandclark]
- present+
- 16:06:02 [TabAtkins]
- Rossen_: So fyi to everyone
- 16:06:03 [fremy]
- @astearns: good point, a rehearsal might be a good idea
- 16:06:12 [jensimmons]
- Aug 4-6 are the proposed dates
- 16:06:14 [TabAtkins]
- Rossen_: Also wanted to give a chance to talk about hosting
- 16:06:33 [lea]
- q+
- 16:07:10 [TabAtkins]
- TabAtkins: 4-6 wasn't the dates proposed, 1-3 was
- 16:07:20 [TabAtkins]
- jensimmons: Rossen sent 4-6 in the email
- 16:07:53 [TabAtkins]
- Rossen_: Oh I got confused, was looking at july
- 16:07:57 [TabAtkins]
- DATES ARE AUGUST 1-3
- 16:08:30 [fremy]
- ^_^
- 16:09:01 [fantasai]
- TabAtkins: Plan is to rent a loft in Tribeca with excellent ventilation, able to host 20 ppl in common spaces
- 16:09:14 [fantasai]
- TabAtkins: Need confirmation on dates and location in order to confirm the venue
- 16:09:21 [Rossen_]
- q?
- 16:09:29 [Rossen_]
- ack lea
- 16:09:42 [TabAtkins]
- lea: Is this an fyi on date/location or are we stilld eciding?
- 16:09:55 [TabAtkins]
- Rossen_: This is the current proposal. If you have a hosting proposal elsewherre we can consider...
- 16:09:59 [bradk]
- bradk has joined #css
- 16:10:00 [TabAtkins]
- florian: There's not much time to hesitate
- 16:11:07 [TabAtkins]
- fantasai: I have all the logistics ready, all I need is absolute confirmation
- 16:11:41 [TabAtkins]
- TabAtkins: I have about a day and a half to cancel the reservation if we go elsewhere
- 16:11:57 [TabAtkins]
- Rossen_: Okay so this is time-sensitive. If anyone has another proposal this is when to surface it, otherwise I'm claling for resolution
- 16:12:21 [TabAtkins]
- fremy: Do you know how many people will amke it in person vs remotely?
- 16:12:42 [TabAtkins]
- Rossen_: Looks like more than a dozen people from confirmations
- 16:12:54 [TabAtkins]
- lea: Note that speculative survey responses are diff from actual confirmations
- 16:13:15 [TabAtkins]
- fantasai: We're very time-sensitive, can we do a survey on this call? we need to make a call on this particular venue
- 16:13:27 [astearns]
- 1
- 16:13:28 [smfr]
- 2
- 16:13:28 [faceless]
- 2 - dateclash, sorry
- 16:13:29 [lea]
- 2
- 16:13:29 [jensimmons]
- 1
- 16:13:31 [jfkthame]
- 2
- 16:13:31 [chris]
- 2
- 16:13:31 [emeyer]
- emeyer has joined #css
- 16:13:31 [dandclark]
- 2
- 16:13:31 [Rossen_]
- 1
- 16:13:32 [vmpstr]
- 2
- 16:13:32 [emilio]
- 1
- 16:13:32 [TabAtkins]
- STRAW POLL: (1) will attend in person in NYC Aug 1-3 (2) will not attend in person
- 16:13:32 [futhark]
- 2
- 16:13:32 [TabAtkins]
- 1
- 16:13:32 [florian]
- 1, probably
- 16:13:34 [bradk]
- What time/venue?
- 16:13:39 [fremy]
- 2 (date range includes my birthday)
- 16:13:39 [fantasai]
- 1
- 16:13:42 [plinss]
- 1, tentative
- 16:13:48 [fantasai]
- bradk, NYC august 1-3
- 16:13:49 [dbaron]
- Present+
- 16:13:52 [bramus]
- 1
- 16:13:52 [argyle]
- 1 tentative
- 16:13:54 [miriam]
- 1, tentative
- 16:13:56 [emeyer]
- 2 (most likely)
- 16:14:11 [gtalbot]
- gtalbot has left #css
- 16:14:13 [bradk]
- Virtual for me
- 16:14:19 [dbaron]
- likely 2, though remote chance of 1 if I hear more details about ventilation etc. in venue
- 16:14:36 [TabAtkins]
- (8 attendees on call, with 3 tentative attendees)
- 16:14:41 [delan]
- 2
- 16:14:52 [fremy]
- sounds like a good enough group to me
- 16:14:59 [TabAtkins]
- Rossen_: So that answers the participation question, and this'll be as hybrid as we can make
- 16:15:26 [jensimmons]
- Like dbaron I'd love to hear details about ventilation. (Link to Airbnb venue would be one way to do so. I'm presuming it has windows that open.) It'd be good to agree about masking policy as well.
- 16:15:29 [TabAtkins]
- Rossen_: This looks like a reasonable number. Final call for resolution.
- 16:15:31 [castastrophe]
- castastrophe has joined #css
- 16:15:35 [TabAtkins]
- https://wiki.csswg.org/planning/nyc-2022 for details,
- 16:16:15 [SebastianZartner]
- SebastianZartner has joined #css
- 16:16:21 [TabAtkins]
- https://www.airbnb.com/rooms/53428467?source_impression_id=p3_1655914572_%2BSlp4jp%2FDP%2B%2B8OJl
- 16:16:22 [astearns]
- I suggest we start with TPAC plans for vaccination requirements, inside masking, etc.
- 16:16:46 [TabAtkins]
- RESOLVED: CSSWG f2f in NYC Aug 1-3, further details incoming on private list
- 16:17:04 [TabAtkins]
- fantasai: Tab just linked to wiki page, plz register asap to participant list so we can get logistics together
- 16:17:16 [TabAtkins]
- fantasai: Let us know dietary restrictions so we can make sure everyone has food
- 16:17:23 [TabAtkins]
- fantasai: Allergies but also dislikes are fine
- 16:17:35 [fantasai]
- (please distinguish which!)
- 16:17:40 [fantasai]
- (and level of allergy)
- 16:17:56 [TabAtkins]
- Topic: Color 4 CR
- 16:17:57 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/7393
- 16:18:01 [castastrophe_]
- castastrophe_ has joined #css
- 16:18:10 [TabAtkins]
- Rossen_: Looks like you wanted to ask for additional resolutions?
- 16:18:22 [TabAtkins]
- chris: Last week we made some Color 4 and 5 resolutions
- 16:18:25 [castastrophe_]
- late logging onto IRC but I'm a 1 for attending as well
- 16:18:27 [TabAtkins]
- chris: I wanted to request a new WD
- 16:18:39 [TabAtkins]
- chris: Not many changes from a couple months ago, but want an up-to-date WD
- 16:18:45 [TabAtkins]
- chris: Takes at least a week for CR
- 16:19:14 [TabAtkins]
- Rossen_: So repubbing Color 4 and 5, what changes?
- 16:19:28 [TabAtkins]
- chris: Some changes we agreed on last week; Color 5 punted color-contrast() to Color 6
- 16:19:51 [TabAtkins]
- Rossen_: Objections to republishing?
- 16:19:57 [TabAtkins]
- RESOLVED: Republish Color 4 and 5
- 16:20:57 [TabAtkins]
- chris: Color 4 has good test results and is being implemented, we should get CR quick
- 16:21:11 [TabAtkins]
- Rossen_: Anyone need more time to look over test results?
- 16:21:24 [TabAtkins]
- Rossen_: In order to move Color 4 to CR? If not we can resolve today
- 16:21:36 [TabAtkins]
- Rossen_: Objections for Color 4 CR?
- 16:21:45 [chrishtr]
- Congratulations!
- 16:21:46 [TabAtkins]
- RESOLVED: Color 4 to CR when timing permits
- 16:22:04 [TabAtkins]
- Topic: overdue republications
- 16:22:05 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/7043
- 16:22:29 [TabAtkins]
- chris: We just resolved to ship something in Images 4 and the spec hasn't been updated in 5 years, come one
- 16:22:48 [TabAtkins]
- TabAtkins: Chris, you're married to one of the editors
- 16:23:04 [TabAtkins]
- fantasai: Need to evaluate the changes list, which I can do and we can revisit next week?
- 16:23:10 [TabAtkins]
- chris: I've updated the changes list
- 16:23:18 [TabAtkins]
- fantasai: Okay I'll review. I'm okay with provisional resolution to repub.
- 16:23:40 [bkardell_]
- bkardell_ has joined #css
- 16:23:41 [TabAtkins]
- Rossen_: Let's do it next week when there's been review. Taking the resolution isn't hard.
- 16:23:54 [TabAtkins]
- Topic: Republishing tasks
- 16:23:56 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/6900
- 16:24:07 [bkardell_]
- present+
- 16:24:08 [TabAtkins]
- chris: That was color 4 and 5
- 16:24:25 [TabAtkins]
- Topic: Revisit decision to make style the default container type
- 16:24:41 [Rossen_]
- q?
- 16:24:49 [TabAtkins]
- miriam: There's been more discussion. I left a summary, well, longer than that, at the end fo the thread. No responses since.
- 16:25:01 [TabAtkins]
- miriam: So same question as last time - last time we talked about it it split into several questions.
- 16:25:05 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/7066#issuecomment-1158184820
- 16:25:09 [TabAtkins]
- miriam: 1) Do we need style queries? I think we do, I argued for it.
- 16:25:24 [TabAtkins]
- miriam: 2) If we have them, should every container be a style container by default. I think answer is yes for authors, question is perf.
- 16:25:42 [TabAtkins]
- miriam: In convo with emilio it seems the perf issues are less (maybe not none) if the impl first matches selectors then looks for containers
- 16:25:49 [chris]
- rrsagent, draft minutes
- 16:25:49 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/06/22-css-minutes.html chris
- 16:25:58 [TabAtkins]
- miriam: If you're going the other way and matching containers first, and everything's a container, you don't get much filtering.
- 16:26:19 [TabAtkins]
- miriam: Those perf issues are only for people using broad container queries (not using name, etc) and broad selectors. Multiplying those together means lots of searching
- 16:26:28 [TabAtkins]
- miriam: I don't know how bad that perf hit would be, so hard for me to judge on that.
- 16:26:41 [TabAtkins]
- miriam: Proposal moving forward is [whoops, missed]
- 16:26:59 [TabAtkins]
- miriam: If we start now with an initial value of none, browsers can release size queries, and I think that's the right syntax
- 16:27:11 [TabAtkins]
- miriam: Other question: people will set contianer types in various places, also names
- 16:27:24 [TabAtkins]
- miriam: Suggestion was to set type in another longhand. But that doesn't work for names.
- 16:27:38 [TabAtkins]
- miriam: I think the general solution is an additive cascade. No specific solution, need general solution here.
- 16:27:43 [Rossen_]
- q?
- 16:27:52 [TabAtkins]
- Rossen_: Any further comments?
- 16:27:59 [futhark]
- q+
- 16:28:31 [TabAtkins]
- futhark: I'm supportive, I said so on her writeup
- 16:28:36 [TabAtkins]
- futhark: Positive to the proposed resolutions
- 16:28:43 [Rossen_]
- ack futhark
- 16:28:53 [astearns]
- read the comment and support the suggested resolution
- 16:28:59 [TabAtkins]
- futhark: Important thing now for chrome and safari is to end up with th einitial value of `none`, will let us ship CQs without having to worry about this idea
- 16:29:18 [TabAtkins]
- s/this idea/whether everything's a style container/
- 16:29:31 [TabAtkins]
- futhark: We're exploring style queries; right now it doesn't sound that bad to have them as default
- 16:29:49 [TabAtkins]
- fantasai: I'm in favor of miriam's points
- 16:30:11 [TabAtkins]
- Rossen_: Miriam could you summarize?
- 16:30:23 [TabAtkins]
- miriam: First resolution, initial value is `none`
- 16:30:24 [chrishtr]
- +1 to Miriam's proposed resolution.
- 16:30:29 [TabAtkins]
- Rossen_: Objections?
- 16:30:33 [SebastianZartner]
- +1 from me, too
- 16:30:38 [TabAtkins]
- RESOLVED: Initial value is `none`
- 16:31:03 [TabAtkins]
- miriam: Since style queries are in the spec, probably need a resolution for every element being a style container by default. We'll spec that out and adjust as needed as impls start showing up.
- 16:31:42 [TabAtkins]
- fantasai: Resolution si that every element *is* a style container, regardless of `container-type`.
- 16:31:48 [TabAtkins]
- emilio: Still skeptical about this.
- 16:32:10 [TabAtkins]
- emilio: Gecko's CQs are like Blink's. It's a little more annoying to have every element be a style container.
- 16:32:30 [TabAtkins]
- fantasai: Argument is a lot of people will do that anyway because it's useful to query, so you'll take that hit on a lot of pages anyway.
- 16:32:34 [TabAtkins]
- fantasai: That's our expectation.
- 16:32:54 [TabAtkins]
- emilio: I don't know if my expectation matches, but you know more about CSS authors. Okay with that for now, guess I don't object.
- 16:33:37 [TabAtkins]
- RESOLVED: All elements are style containers by default.
- 16:33:47 [SebastianZartner]
- Congrats Miriam!
- 16:33:50 [fantasai]
- Side question, should 'none' be 'normal' now since everything's a style container?
- 16:33:52 [bramus]
- Nice!
- 16:34:01 [TabAtkins]
- Topic: Default color in :root highlight
- 16:34:02 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/6774
- 16:34:11 [delan]
- https://github.com/w3c/csswg-drafts/issues/6774#issuecomment-1083055006
- 16:34:45 [TabAtkins]
- delan: For highlight pseudos, setting color:currentcolor means the color doesn't change when you highlight with that pseudo, compared to the original color underneath
- 16:34:56 [TabAtkins]
- delan: Editors agreed this is what should happen if color hasn't been set anywhere for a highlight
- 16:35:31 [TabAtkins]
- delan: I think the way this is achieved isn't actually specified. My best interp of Cascade is that we don't actually do that, and the spec says the default color of a highlight pseudo becomes black
- 16:35:36 [TabAtkins]
- delan: Three steps
- 16:35:58 [TabAtkins]
- delan: First, when you have an inherited property (all props are inherited for highlights), they do the defaulting by way of "inherited value"
- 16:36:14 [TabAtkins]
- delan: Second, inherited value is value from parent, unless you're at root, in which case it's initial value
- 16:36:21 [TabAtkins]
- delan: Third, initial value of color property is CanvasText
- 16:36:22 [GameMaker]
- GameMaker has joined #css
- 16:36:27 [GameMaker]
- present+
- 16:36:32 [TabAtkins]
- delan: Which is generally black (in light mode)
- 16:36:39 [Rossen_]
- q?
- 16:36:41 [TabAtkins]
- delan: So this raises the question of how to fix it
- 16:36:55 [ntim]
- ntim has joined #css
- 16:36:56 [TabAtkins]
- delan: Which step we add an exception for affects what happens when you use initial/inherit/unset
- 16:37:12 [TabAtkins]
- delan: One option is to say that for highlights, the initial value isn't CanvasText, it's currentcolor
- 16:37:27 [TabAtkins]
- delan: Here if you set color to initial/inherit/unset, they'll become currentcolor
- 16:37:40 [TabAtkins]
- delan: Second option is for highlights, the inherited value isn't the initial value at root, but instead currentcolor
- 16:37:52 [TabAtkins]
- delan: So when you set color to inherit/unset you get currentcolor, but initial means canvastext
- 16:37:55 [TabAtkins]
- delan: I like this the best
- 16:38:20 [TabAtkins]
- delan: Third option is to change defaulting for highlight pseudos and say that for root highlights, you don't inherit, we just set the value.
- 16:38:29 [TabAtkins]
- delan: So all the keywords would become canvastext
- 16:38:40 [TabAtkins]
- delan: Not sure my understanding is correct, but it's how I see things. What should we do?
- 16:38:58 [TabAtkins]
- fantasai: That was a great epxlanation of a complicated issue
- 16:39:00 [Rossen_]
- ack fantasai
- 16:39:12 [TabAtkins]
- fantasai: I think either first or second makes sense to me
- 16:39:35 [TabAtkins]
- fantasai: If no one has a reason to do something different your pref makes sense to me. I suspect your pref is the easiest to implement.
- 16:40:02 [TabAtkins]
- delan: I think all three are possible to implement. I preferred 2 over 1 because in option 2 you can say color:initial and get black, and I feel like that intuitively makes sense.
- 16:40:19 [Rossen_]
- ack emilio
- 16:40:32 [TabAtkins]
- emilio: Doesn't 2 change the - fix the weirdness around currentcolor in highlights?
- 16:40:44 [TabAtkins]
- emilio: If we change how it inherits doesn't it fix all the shenanigans about what currentcolor means in highlights?
- 16:40:50 [TabAtkins]
- emilio: Or is this orthogonal
- 16:40:54 [TabAtkins]
- delan: I don't think it does
- 16:41:12 [TabAtkins]
- delan: Are you talking about where we have the exception for currentcolor where it means this special thing for highlights?
- 16:41:14 [TabAtkins]
- emilio: yes
- 16:41:20 [TabAtkins]
- delan: Then no, this actually relies on that.
- 16:41:45 [TabAtkins]
- delan: Unless we don't literally use the word "currentcolor" in our fix and just say that it "keeps the same color"
- 16:41:56 [TabAtkins]
- delan: But as worded it relies on that currentcolor behavior
- 16:42:11 [TabAtkins]
- emilio: More generally, currentcolor refers to the computed value of the color property, how can you inherit it?
- 16:42:49 [TabAtkins]
- emilio: In impls the color property is special bc you don't want to resolve currentcolor by walking all the way to the root
- 16:43:12 [TabAtkins]
- emilio: and currentcolor disappears at computed value time, before inheritance
- 16:43:29 [TabAtkins]
- emilio: But if this is just an impl detail, eh, this just makes color more special, but given previous things we're past that point
- 16:44:09 [TabAtkins]
- Rossen_: So hearing some gravity towards options 1 and 2, particular 2 as delan's fave. Is this something we can resolve on?
- 16:44:49 [TabAtkins]
- delan: Restating option 2: For ::highlight pseudos, we redefine the "inherited value" of 'color' at the root, so instead of being the initial value (as normal) it is currentcolor.
- 16:45:09 [fantasai]
- currentColor does not disappear at computed value time... that's one of the important things about it
- 16:45:15 [TabAtkins]
- Rossen_: objections?
- 16:45:21 [TabAtkins]
- RESOLVED: Go with Delan's option 2.
- 16:45:24 [fantasai]
- WFM
- 16:46:08 [TabAtkins]
- Topic: box-shadow roundness/sharpness
- 16:46:12 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/7103
- 16:47:04 [TabAtkins]
- [looking for Oriol on the call]
- 16:47:08 [TabAtkins]
- fantasai: Let's push to next week
- 16:47:22 [TabAtkins]
- Topic: should :fullscreen be a modal state?
- 16:47:24 [TabAtkins]
- github: https://github.com/w3c/csswg-drafts/issues/7311
- 16:47:51 [TabAtkins]
- chrishtr: We introduced :modal, which brought ot our attention that Chrome impl of FullScreen makes it modal (stuff behidn is inert) but other impls don't do that
- 16:47:59 [ntim]
- q+
- 16:48:09 [TabAtkins]
- chrishtr: Think we should resolve on whethe rfullscreen is modal, which both affects inert and whether :modal applies to it
- 16:48:15 [TabAtkins]
- chrishtr: Don't have a strong opinion on how we go
- 16:48:50 [Rossen_]
- ack ntim
- 16:49:03 [TabAtkins]
- ntim: I think it makes sense to make the stuff behind fullscreen inert
- 16:49:13 [TabAtkins]
- ntim: But not sure webdevs would expect :modal pseudoclass tomatch in this case
- 16:49:24 [TabAtkins]
- Aka *my exact argument for why we should have named it :modal-dialog*
- 16:49:39 [TabAtkins]
- emilio: Unsure what webkit does for fullscreen
- 16:49:51 [TabAtkins]
- ntim: webkit's impl is old but if we redid it I'd make it inert
- 16:50:10 [TabAtkins]
- emilio: In firefox you can interact with stuff behind it; you can set pointer-events:none and then interact with the page
- 16:50:25 [TabAtkins]
- ntim: I don't have strong opinion, but it seems unexpected that you can do that
- 16:50:46 [TabAtkins]
- emilio: I don't particularly mind either way, was just pointing out that you can, unless you do the chromium thing of makign the undelrying page inert
- 16:50:57 [flackr]
- q+
- 16:50:58 [TabAtkins]
- fantasai: This is less of a style question. I think the inertness is less significant
- 16:51:02 [jensimmons]
- q=
- 16:51:06 [jensimmons]
- q+
- 16:51:11 [TabAtkins]
- fantasai: Think we need toudnerstand if there are use-cases for being not inert
- 16:51:18 [TabAtkins]
- fantasai: Unsure we're equipped to resolve on this during this call
- 16:51:38 [TabAtkins]
- fantasai: probably need info from people authoring fullscreen stuff and see if it's necessary to fullscreen something that doesn't take up the whole screen
- 16:51:58 [TabAtkins]
- ntim: This issue aside, it seems unexpected either way for :modal to apply to fullscreen elements, regardless of whether stuff behind is inert
- 16:52:09 [TabAtkins]
- ntim: :modal comes from modal dialogs
- 16:52:30 [TabAtkins]
- fantasai: They might not, but we decided it means things with modal qualities. Fullscreen might not be first in mind, but if it has those qualities it should match
- 16:52:39 [flackr]
- +1
- 16:52:44 [masonf]
- +1
- 16:52:52 [Rossen_]
- ack flackr
- 16:53:03 [TabAtkins]
- flackr: If the content behidn wasn't inert it would be in tab order as well, which could be confusing if you could tab out of the fullscreen element
- 16:53:07 [TabAtkins]
- emilio: fair
- 16:53:47 [TabAtkins]
- jensimmons: this raises a11y memories, if visually a fullscreen element covers everything, so assumption is the stuff behidn isn't accessible, having it not be inert could make it different for people using other a11y tools
- 16:54:04 [TabAtkins]
- jensimmons: I'm wondering what the use-cases would be for making the contents behidn a fullscreen *not* inert
- 16:54:14 [TabAtkins]
- jensimmons: Maybe there should be a way to toggle it off, but default should be for inert
- 16:54:18 [TabAtkins]
- fantasai: I buy that
- 16:54:19 [bkardell_]
- agree
- 16:54:20 [masonf]
- +1
- 16:54:21 [TabAtkins]
- Rossen_: strong agree
- 16:54:22 [bramus]
- +1
- 16:54:23 [chrishtr]
- Agree on inert making sense given these arguments
- 16:54:28 [SebastianZartner]
- +1 for what jensimmons said.
- 16:54:31 [TabAtkins]
- emilio: fair point. Then :modal should apply to fullscreen.
- 16:54:38 [florian]
- +1 to Jen
- 16:54:39 [masonf]
- q+
- 16:54:44 [Rossen_]
- q?
- 16:54:45 [TabAtkins]
- fantasai: Right, so decision is whether it's inert, and whether :modal applies is a consequence
- 16:54:52 [Rossen_]
- ack jensimmons
- 16:55:00 [TabAtkins]
- masonf: Strong agree with points, think fullscreen should inert the rest of the page
- 16:55:04 [Rossen_]
- ack masonf
- 16:55:13 [TabAtkins]
- masonf: Do we include special provisions for fullscreen escaping that inertness, like dialogs have?
- 16:55:25 [TabAtkins]
- masonf: Like if you inert the entire page the fullscreen shoudln't be inert, need provisions for that
- 16:55:34 [TabAtkins]
- ntim: That's what fullscreen does
- 16:55:43 [TabAtkins]
- masonf: Sure just want to make sure it's captured
- 16:55:52 [Rossen_]
- q?
- 16:56:21 [TabAtkins]
- Rossen_: additional thoughts or objections?
- 16:56:36 [TabAtkins]
- plinss: In conext of dialogs there's clear spec ni html of what puts the dialog into a modal state
- 16:56:47 [TabAtkins]
- plinss: in my mind that is what puts into a :modal pseudoclass
- 16:56:56 [TabAtkins]
- plinss: think it's important to not just catch things that are modal-ish
- 16:56:58 [masonf]
- q+
- 16:57:14 [TabAtkins]
- emilio: Yeah fullscreen spec should define the modalness
- 16:57:22 [masonf]
- q-
- 16:57:43 [TabAtkins]
- plinss: So as long as it's defined that fullscreen puts it into this state just like dialog, unsure that we should just auto-apply it because it resembles modalness
- 16:58:08 [TabAtkins]
- Rossen_: so if i understand, fullscreen elements *are* modal from html behavior like dialogs, and rely on same behavior. is that clarification?
- 16:58:42 [TabAtkins]
- plinss: I'm saying :modal shoudln't apply unless something is *defined as* "being modal", not just because it's kinda modal-ish in some respects. HTML is very clear about modal, need to respect that.
- 16:58:51 [TabAtkins]
- plinss: So if fullscreen uses that same definition it's fine.
- 16:59:08 [masonf]
- q+
- 16:59:09 [ntim]
- https://html.spec.whatwg.org/multipage/interactive-elements.html#is-modal
- 16:59:39 [SebastianZartner]
- Maybe we can at least resolve on fullscreen elements making the reset inert.
- 16:59:43 [TabAtkins]
- masonf: +1 to that
- 17:00:04 [TabAtkins]
- masonf: Note that HTML doesn't define "being modal", it defines how a dialog become smodal. But that can probably be pulled out into a proper definition.
- 17:00:29 [TabAtkins]
- RESOLVED: Fullscreen elements should inert the stuff behind them, and match :modal
- 17:00:33 [TabAtkins]
- Topic: end
- 17:01:02 [fantasai]
- https://wiki.csswg.org/planning/nyc-2022
- 17:01:34 [Rossen_]
- Zakim, end meeting
- 17:01:34 [Zakim]
- As of this point the attendees have been lea, TabAtkins, bramus, jfkthame, vmpstr, futhark, faceless, argyle, plinss, emilio, flackr, chris, delan, smfr, Rossen_, miriam, masonf,
- 17:01:37 [Zakim]
- ... jensimmons, (irc, only, for, the, first, half), fremy, Sebo, dandclark, dbaron, bkardell_, GameMaker
- 17:01:37 [Zakim]
- RRSAgent, please draft minutes v2
- 17:01:37 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/06/22-css-minutes.html Zakim
- 17:01:39 [Zakim]
- I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye
- 17:01:43 [Zakim]
- Zakim has left #css
- 17:01:48 [castastrophe]
- castastrophe has joined #css
- 17:01:54 [astearns]
- TabAtkins: fantasai: Iasked about remote participation equipment on the private list
- 17:02:06 [jfkthame]
- Hmm, "New York City F2F August 2018" seems a bit outdated....
- 17:02:47 [TabAtkins]
- yeah, answer is "we'll have to figure it out" since we're doing stuff ourselves
- 17:02:51 [emeyer]
- emeyer has left #css
- 17:02:59 [TabAtkins]
- (i don't trust an office setting to have adequate ventilation for a large meeting)
- 17:04:09 [jensimmons]
- I do so deeply appreciate the care and thinking that's going into the f2f planning.
- 17:11:30 [jfkthame]
- jfkthame has left #css
- 17:23:26 [dholbert]
- dholbert has joined #css
- 17:59:42 [GameMaker]
- GameMaker has joined #css
- 18:12:35 [jensimmons]
- jensimmons has joined #css
- 18:17:05 [plh]
- plh has joined #css
- 18:44:19 [jamesn]
- jamesn has joined #css
- 18:44:21 [CSSWG_LogBot]
- CSSWG_LogBot has joined #css