Meeting minutes
<chrishtr> https://
Rossen_: We've tallied the summer f2f results
Rossen_: Decided to hold as much of an f2f as possible in person
Rossen_: For those who can make their way to NYC
Rossen_: For everyone else, we'll make sure we have proper virtual facilities for participation
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
<astearns> This will also allow us to test out substantial virtual participation pre-TPAC
Rossen_: No one's going to be perfectly satisfied unless they're already in east coast time zone
Rossen_: Putting it earlier would be hard for lack to warning for travel and location
Rossen_: So fyi to everyone
<fremy> @astearns: good point, a rehearsal might be a good idea
<jensimmons> Aug 4-6 are the proposed dates
Rossen_: Also wanted to give a chance to talk about hosting
TabAtkins: 4-6 wasn't the dates proposed, 1-3 was
jensimmons: Rossen sent 4-6 in the email
Rossen_: Oh I got confused, was looking at july
DATES ARE AUGUST 1-3
<fremy> ^_^
<fantasai> TabAtkins: Plan is to rent a loft in Tribeca with excellent ventilation, able to host 20 ppl in common spaces
<fantasai> TabAtkins: Need confirmation on dates and location in order to confirm the venue
lea: Is this an fyi on date/location or are we stilld eciding?
Rossen_: This is the current proposal. If you have a hosting proposal elsewherre we can consider...
florian: There's not much time to hesitate
fantasai: I have all the logistics ready, all I need is absolute confirmation
TabAtkins: I have about a day and a half to cancel the reservation if we go elsewhere
Rossen_: Okay so this is time-sensitive. If anyone has another proposal this is when to surface it, otherwise I'm claling for resolution
fremy: Do you know how many people will amke it in person vs remotely?
Rossen_: Looks like more than a dozen people from confirmations
lea: Note that speculative survey responses are diff from actual confirmations
fantasai: We're very time-sensitive, can we do a survey on this call? we need to make a call on this particular venue
<astearns> 1
<smfr> 2
<faceless> 2 - dateclash, sorry
<lea> 2
<jensimmons> 1
<jfkthame> 2
<chris> 2
<dandclark> 2
<Rossen_> 1
<vmpstr> 2
<emilio> 1
STRAW POLL: (1) will attend in person in NYC Aug 1-3 (2) will not attend in person
<futhark> 2
1
<florian> 1, probably
<bradk> What time/venue?
<fremy> 2 (date range includes my birthday)
<fantasai> 1
<plinss> 1, tentative
<fantasai> bradk, NYC august 1-3
<bramus> 1
<argyle> 1 tentative
<miriam> 1, tentative
<emeyer> 2 (most likely)
<bradk> Virtual for me
<dbaron> likely 2, though remote chance of 1 if I hear more details about ventilation etc. in venue
(8 attendees on call, with 3 tentative attendees)
<delan> 2
<fremy> sounds like a good enough group to me
Rossen_: So that answers the participation question, and this'll be as hybrid as we can make
<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.
Rossen_: This looks like a reasonable number. Final call for resolution.
https://
https://
<astearns> I suggest we start with TPAC plans for vaccination requirements, inside masking, etc.
RESOLUTION: CSSWG f2f in NYC Aug 1-3, further details incoming on private list
fantasai: Tab just linked to wiki page, plz register asap to participant list so we can get logistics together
fantasai: Let us know dietary restrictions so we can make sure everyone has food
fantasai: Allergies but also dislikes are fine
<fantasai> (please distinguish which!)
<fantasai> (and level of allergy)
Color 4 CR
github: https://
Rossen_: Looks like you wanted to ask for additional resolutions?
chris: Last week we made some Color 4 and 5 resolutions
<castastrophe_> late logging onto IRC but I'm a 1 for attending as well
chris: I wanted to request a new WD
chris: Not many changes from a couple months ago, but want an up-to-date WD
chris: Takes at least a week for CR
Rossen_: So repubbing Color 4 and 5, what changes?
chris: Some changes we agreed on last week; Color 5 punted color-contrast() to Color 6
Rossen_: Objections to republishing?
RESOLUTION: Republish Color 4 and 5
chris: Color 4 has good test results and is being implemented, we should get CR quick
Rossen_: Anyone need more time to look over test results?
Rossen_: In order to move Color 4 to CR? If not we can resolve today
Rossen_: Objections for Color 4 CR?
<chrishtr> Congratulations!
RESOLUTION: Color 4 to CR when timing permits
overdue republications
github: https://
chris: We just resolved to ship something in Images 4 and the spec hasn't been updated in 5 years, come one
TabAtkins: Chris, you're married to one of the editors
fantasai: Need to evaluate the changes list, which I can do and we can revisit next week?
chris: I've updated the changes list
fantasai: Okay I'll review. I'm okay with provisional resolution to repub.
Rossen_: Let's do it next week when there's been review. Taking the resolution isn't hard.
Republishing tasks
github: https://
chris: That was color 4 and 5
Revisit decision to make style the default container type
miriam: There's been more discussion. I left a summary, well, longer than that, at the end fo the thread. No responses since.
miriam: So same question as last time - last time we talked about it it split into several questions.
<fantasai> https://
miriam: 1) Do we need style queries? I think we do, I argued for it.
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.
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
miriam: If you're going the other way and matching containers first, and everything's a container, you don't get much filtering.
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
miriam: I don't know how bad that perf hit would be, so hard for me to judge on that.
miriam: Proposal moving forward is [whoops, missed]
miriam: If we start now with an initial value of none, browsers can release size queries, and I think that's the right syntax
miriam: Other question: people will set contianer types in various places, also names
miriam: Suggestion was to set type in another longhand. But that doesn't work for names.
miriam: I think the general solution is an additive cascade. No specific solution, need general solution here.
Rossen_: Any further comments?
futhark: I'm supportive, I said so on her writeup
futhark: Positive to the proposed resolutions
<astearns> read the comment and support the suggested resolution
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 whether everything's a style container
futhark: We're exploring style queries; right now it doesn't sound that bad to have them as default
fantasai: I'm in favor of miriam's points
Rossen_: Miriam could you summarize?
miriam: First resolution, initial value is `none`
<chrishtr> +1 to Miriam's proposed resolution.
Rossen_: Objections?
<SebastianZartner> +1 from me, too
RESOLUTION: Initial value is `none`
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.
fantasai: Resolution si that every element *is* a style container, regardless of `container-type`.
emilio: Still skeptical about this.
emilio: Gecko's CQs are like Blink's. It's a little more annoying to have every element be a style container.
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.
fantasai: That's our expectation.
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.
RESOLUTION: All elements are style containers by default.
<SebastianZartner> Congrats Miriam!
<fantasai> Side question, should 'none' be 'normal' now since everything's a style container?
<bramus> Nice!
Default color in :root highlight
github: https://
<delan> https://
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
delan: Editors agreed this is what should happen if color hasn't been set anywhere for a highlight
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
delan: Three steps
delan: First, when you have an inherited property (all props are inherited for highlights), they do the defaulting by way of "inherited value"
delan: Second, inherited value is value from parent, unless you're at root, in which case it's initial value
delan: Third, initial value of color property is CanvasText
delan: Which is generally black (in light mode)
delan: So this raises the question of how to fix it
delan: Which step we add an exception for affects what happens when you use initial/inherit/unset
delan: One option is to say that for highlights, the initial value isn't CanvasText, it's currentcolor
delan: Here if you set color to initial/inherit/unset, they'll become currentcolor
delan: Second option is for highlights, the inherited value isn't the initial value at root, but instead currentcolor
delan: So when you set color to inherit/unset you get currentcolor, but initial means canvastext
delan: I like this the best
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.
delan: So all the keywords would become canvastext
delan: Not sure my understanding is correct, but it's how I see things. What should we do?
fantasai: That was a great epxlanation of a complicated issue
fantasai: I think either first or second makes sense to me
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.
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.
emilio: Doesn't 2 change the - fix the weirdness around currentcolor in highlights?
emilio: If we change how it inherits doesn't it fix all the shenanigans about what currentcolor means in highlights?
emilio: Or is this orthogonal
delan: I don't think it does
delan: Are you talking about where we have the exception for currentcolor where it means this special thing for highlights?
emilio: yes
delan: Then no, this actually relies on that.
delan: Unless we don't literally use the word "currentcolor" in our fix and just say that it "keeps the same color"
delan: But as worded it relies on that currentcolor behavior
emilio: More generally, currentcolor refers to the computed value of the color property, how can you inherit it?
emilio: In impls the color property is special bc you don't want to resolve currentcolor by walking all the way to the root
emilio: and currentcolor disappears at computed value time, before inheritance
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
Rossen_: So hearing some gravity towards options 1 and 2, particular 2 as delan's fave. Is this something we can resolve on?
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.
<fantasai> currentColor does not disappear at computed value time... that's one of the important things about it
Rossen_: objections?
RESOLUTION: Go with Delan's option 2.
<fantasai> WFM
box-shadow roundness/sharpness
github: https://
[looking for Oriol on the call]
fantasai: Let's push to next week
should :fullscreen be a modal state?
github: https://
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
chrishtr: Think we should resolve on whethe rfullscreen is modal, which both affects inert and whether :modal applies to it
chrishtr: Don't have a strong opinion on how we go
ntim: I think it makes sense to make the stuff behind fullscreen inert
ntim: But not sure webdevs would expect :modal pseudoclass tomatch in this case
Aka *my exact argument for why we should have named it :modal-dialog*
emilio: Unsure what webkit does for fullscreen
ntim: webkit's impl is old but if we redid it I'd make it inert
emilio: In firefox you can interact with stuff behind it; you can set pointer-events:none and then interact with the page
ntim: I don't have strong opinion, but it seems unexpected that you can do that
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
fantasai: This is less of a style question. I think the inertness is less significant
fantasai: Think we need toudnerstand if there are use-cases for being not inert
fantasai: Unsure we're equipped to resolve on this during this call
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
ntim: This issue aside, it seems unexpected either way for :modal to apply to fullscreen elements, regardless of whether stuff behind is inert
ntim: :modal comes from modal dialogs
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
<flackr> +1
<masonf> +1
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
emilio: fair
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
jensimmons: I'm wondering what the use-cases would be for making the contents behidn a fullscreen *not* inert
jensimmons: Maybe there should be a way to toggle it off, but default should be for inert
fantasai: I buy that
<bkardell_> agree
<masonf> +1
Rossen_: strong agree
<bramus> +1
<chrishtr> Agree on inert making sense given these arguments
<SebastianZartner> +1 for what jensimmons said.
emilio: fair point. Then :modal should apply to fullscreen.
<florian> +1 to Jen
fantasai: Right, so decision is whether it's inert, and whether :modal applies is a consequence
masonf: Strong agree with points, think fullscreen should inert the rest of the page
masonf: Do we include special provisions for fullscreen escaping that inertness, like dialogs have?
masonf: Like if you inert the entire page the fullscreen shoudln't be inert, need provisions for that
ntim: That's what fullscreen does
masonf: Sure just want to make sure it's captured
Rossen_: additional thoughts or objections?
plinss: In conext of dialogs there's clear spec ni html of what puts the dialog into a modal state
plinss: in my mind that is what puts into a :modal pseudoclass
plinss: think it's important to not just catch things that are modal-ish
emilio: Yeah fullscreen spec should define the modalness
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
Rossen_: so if i understand, fullscreen elements *are* modal from html behavior like dialogs, and rely on same behavior. is that clarification?
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.
plinss: So if fullscreen uses that same definition it's fine.
<ntim> https://
<SebastianZartner> Maybe we can at least resolve on fullscreen elements making the reset inert.
masonf: +1 to that
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.
RESOLUTION: Fullscreen elements should inert the stuff behind them, and match :modal
end
<fantasai> https://