<scribe> ScribeNick: dael

Rossen_: We'll get going in about a minute
... Let's get started
... As usual, asking for any extra items for the agenda
... One I have is about virtual F2F trial meeting we wanted to run soon to check and see how a typical virtual F2F meeting would run
... Idea is pick a topic that's ideally going to attrack wide and active audience as well as ask and encourage as much participation as possible so we can put stress on the tool
... Only topic proposed so far was from myself which is Color Scheme discussions. I had combed through GH and this topic spans a fair number of issues and specs.
... In absense of better proposals we can proceed with this
... In terms of tech we want something with video and audio but there's good discussion about something a11y built in. Good ongoing discussion in chairs area
... Once we land on something that works for everyone we'll proceed with that
... That's everything about housekeeping and F2F
... Comments or questions?

[css-align][css-grid] Do grid items that have "no baseline set" participate in baseline alignment?

github: https://github.com/w3c/csswg-drafts/issues/4675

Rossen_: This was discussed a couple weeks back
... We don't have a resolution yet. Can we make any progress now?

fantasai: I thought we had discussed if such items participate and decided that they do. Happy to re-resolve unless someone thinks different.

<lajava> oh, sorry

<Rossen_> lajava, are you talking?

Rossen_: lajava we can't hear you

<lajava> yes, I don't know what happens with my mic

Rossen_: While lajava looks into audio issue...fantasai I'm happy to move on and remove agenda tag. Re-reading discussion we left it as leaning on previous resolution and making progress. Since additional information I wanted to see if there's need to re-resolve or discuss

lajava: I wanted to comment for me examples from fantasai are clear. We already resolved for orthogonal flow items synthesize. Only doubt that triggered discussion is he considered empty items were different. It's not clear in the spec that those items participate
... Only thing to clarify in spec is if empty items participate or not in baseline
... Only sentence I found in spec is the one I added in my last comment

<fantasai> baselines of empty boxes: https://github.com/w3c/csswg-drafts/issues/439

lajava: If I understood having alignment properties set to baseline implies any item should participate. Mats prefers something more explicit to be added.
... That's only thing up for discussion I think

Rossen_: fantasai linked to a discussion about empty boxes for alignment in grid
... There's a clear resolution in the past. With that resolution linked into the minutes and GH I'm happy to move on

<AmeliaBR> Resolution from 439: Have grid and flexbox keep saying that empty boxes have no baseline and they're synthesized with bottom border edge.

lajava: I mentioned that to Mats in bugzilla. Point is this only clarifies how to syntesize. He continues to state that they don't participate in baseline
... I'd prefer Mats to define his point.
... I'm okay closing this issue and resolve that any item that has align or justify self as baseline participates in baseline alignment

Rossen_: Reasonable
... Anything else on this?

[css-pseudo-4] Custom state pseudo class proposal

github: https://github.com/w3c/csswg-drafts/issues/4805

fantasai: Do we have resolution on last?

Rossen_: No I thought way we closed last time was valid. I'm assuming if Mats wants to revist he can do

github: none

fantasai: Can we resolve b/c there are unclear cases

css-align][css-grid] Do grid items that have "no baseline set" participate in baseline alignment?

github: https://github.com/w3c/csswg-drafts/issues/4675

fantasai: All boes can participate in baseline alignment. If they don't have a baseline one is syntesized

Rossen_: Objections?

RESOLUTION: All boxes can participate in baseline alignment. If they don't have a baseline one is synthesized

[construct-stylesheets] what kind of array

github: https://github.com/w3c/csswg-drafts/issues/4805

AmeliaBR: Did you mean to agenda +?

TabAtkins: I put a comment in the wrong thing. Last comment from me on 4805 is part of contructable style sheets.
... Web components F2F happened yesterday and MOnday. Discussed const ss. While Web components has no power, we came to consensus on issues. Need to record here.

github: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-600279738

TabAtkins: Change from last F2F resolution. At F2F we weren't sure what to switch to. Matching stylesheet list with new mutable version which no one likes since it was an old dumb API where it's not an array in many ways. But it's well known
... Option 2 is wait for someone to put down details for a good fake array in webIDL. Fake array option was better but had no timeline so we went with mutable stylesheet.
... Domenic has since written it and it's been well reviewed.

<Domenic> https://heycam.github.io/webidl/#idl-observable-array

TabAtkins: I believe we should revisit and change to have adopted stylesheets use this new once it's added to WebIDL
... Still want consistency so should make stylesheet lists if possible a subclass of obserable array, read only one, so looks same and it's only read only with some legacy things

rniwa: I don't think there was consensus

TabAtkins: Okay, so first part first.

<rniwa> s/??/rniwa/

TabAtkins: Switching from mutable version to observable array
... I vote aye, let's get the part for nay

rniwa: Issue with assignment is as I mentioned in comment on thread people are writing racy code where grab content of array.

TabAtkins: Let me inturrupt. DIfferent issue. not about assignment. Just switch to observable array

rniwa: tied, though.

TabAtkins: If we need to do both we can. But if possible to sep we do

rniwa: Objection to switch to observable is we shouldn't unless we can change document.stylesheet o same model

domenic: Mutable is new consept which is not inconsistent. If we're choosing between two concepts that are new we should pick the better

TabAtkins: It's a necessary point of difference. It's not an inconsistency that should count againt

domenic: We're creating a third interface

TabAtkins: In parts were it overlaps it would be consistent.

Domenic: observable would also be consistent. No parts

TabAtkins: Stylesheet list has terrible but existing...

Domenic: Benefit is it fails arra.isarray check?

TabAtkins: Acts same between two. Only difference is things that corrispond to mutability.
... Agree we need consistent. One mutable one not or one read only and one not.

Rossen_: Sounds like we're going to have debate going. To avoid talking over each other, let's use the queue. We have emilio on next. Before we do that I want to make sure we have the right issue
... I'm hearing push back from rniwa if we can resolve on switching first given gCS has an effect. Happy to switch, but let's define a logical order to discuss.
... Who will propose order?

TabAtkins: I introduced #5 as first thing to discuss and that's what we're talking about

Rossen_: Declaring change from frozen to observable and I'm hearing push back about needing another resolution about gCS using same API

TabAtkins: It's in the same issue. That's why I said it was a sub issue we need to discuss together.

Rossen_: Okay. Back to the queue

emilio: We didn't resolve on mutable, we resolved on adding methods to document.shadowRoot so methods are consistent.

TabAtkins: I don't remember that. Have to expose array somehow

emilio: Yes, as immutable. I think we resolved on adding insert and so on to DocumentOrShadowRoot

TabAtkins: Gotcha. Essentially the same thing. Sure. Yeah

hober: Confirming emilio is right about that resolution I'm pretty sure

fantasai: COmment on web components. Can you put it as a resolution in your minutes? Even if it's non-binding, at least it's clear

hober: That was the A Coruna resolution

Rossen_: Going through F2F minutes

<fantasai> https://lists.w3.org/Archives/Public/www-style/2020Feb/0012.html

<fantasai> A Coruña minutes ^

TabAtkins: My arguement doesn't change, though. The two are isomorphic. It subs in for the same reasoning in my argument.

<fantasai> - RESOLVED: Make adopted stylesheets a CSSStyleSheetList and add the

<fantasai> appropriate add/remove methods to the document or

<fantasai> shadowRoot interface (WICG Constructable Stylesheets

<fantasai> Issue #45: CSS() and FrozenArray)

rniwa: Clarifying there's no resolution at web components b/c don't have formal methods to come to resolution. That's why we're here.

TabAtkins: Now that we're up to speed on previous resolution. Keeping things consistent with both APIs being legacy stylesheet or moving both to observable array, the nice new thing that works like people want.

<fantasai> rniwa, yeah, but if you record consensus in your meeting clearly as such, then even if it's not a formal WG resolution, at least your minutes are clear on what you agreed on

TabAtkins: I push for both with document.stylesheet becoming a read-only but they both act like an array.

<fantasai> rniwa, actively avoiding recording resolutions because you don't have the power to bind any WG to it means your minutes lack clarity

TabAtkins: Objections to doing that? Otherwise I seek resolution

hober: Agree with TabAtkins and rniwa that they should have similar interfaces.

<fantasai> rniwa, that might also be worth noting explicitly then. Basically any discussion should have its conclusion clearly called out, whatever it is

hober: One of the ways to do that and make very consistent and match resolution spirit is make both same subclass or read-only observable area and then add menthods emilio mentioned on shadow root to mutate

<fantasai> this is why I hound Rossen on explicit resolutions whenever we're missing one :)

hober: Gets consistency, underlying data structure. Avoids footgun. I think that's the middle ground that satisfies all desires

TabAtkins: I don't see why we make this mutable but only through unrelated functions when you have array editing functions. Observable array lets you do mutations that work correctly. This feels worse. I don't like it

Rossen_: Do we have a resolution for keeping both interfaces the same?

hober: I think it's implied by a coruna resolution. It resolves they should both be stylesheet lists

Rossen_: Not sure it's same. Sounds like consensus they should be same. Let's resolve they should and then work on what

hober: I think that works.
... If we move on I think there are 3 options. But I think we can resolve on that

Rossen_: Your prop doesn't negate the proposal to keep them the same

rniwa: [missed]

<emilio> rniwa: keeping both the same is a good resolution

Rossen_: Objections or comments as to why we shouldn't keep the two interfaces the same?

Domenic: I don't think consistent is highest value. I think users better served by good apis. Willing to go along

<TabAtkins> GitHub: https://github.com/WICG/construct-stylesheets/issues/45

<TabAtkins> github: https://github.com/WICG/construct-stylesheets/issues/45

RESOLUTION: keep the two interfaces the same

<masonfreed> point of clarification: same as each other, not necessarily the same as they are now

RESOLUTION: keep the two interfaces the same as each other

Rossen_: Now let's move on to what the same means

<TabAtkins> Option 1: Both .sS and .aSS use StyleSheetList; ShadowRoot gains methods to mutate .aSS

<TabAtkins> Option 2: Both .sS and .aSS use a readonly ObservableArray; ShadowRoot gains methods to mutate .aSS

<TabAtkins> Option 3: .sS is upgraded to a readonly ObservablyArray; .aSS is an ObservableArray

hober: One way to keep the same is for both to be read only which implies mutation of adopted stylesheets would be by some other means. I think that's option 2 of what TabAtkins typed

TabAtkins: Yep
... Making read only observable that's only available by out of band method seems bad. Whole point of observable is it's mutable. If you're doing exactly obserable but moving mutable somewhere else I don't see the point of that. To be slightly impolite hober it seems assinine.

Domenic: Another dimension is consistency with rest of platform. There's a lot of arrays that would like to be with observable and would use the full observable approach. If we look at the 20-ish APIs that would want to do this observable array will be the best bet there

rniwa: I wanted to say there's no proof that would happen. We have not done deep studies if that's possible. So removing the other idea isn't a good idea for that reason

Domenic: We can delay until we deploy this for html since it's backwards compat there

chrishtr: Question on reason to consider option 2 as opposed to option 3. Am I correct conern is about race conditions?

TabAtkins: No, that's about assignment question which is after this stuff.

chrishtr: assignment is also race consitions?

TabAtkins: Assignment is only race conditions. This has nothing to do with race conditions

chrishtr: hober why prefer option 2 over 3?

hober: Trying to find a middle ground between A Coruna resolution and what TabAtkins proposed. Thought in doing that was to have stronger consistency between exsiting object and the new thing then in TabAtkins proposal

chrishtr: b/c more read only?

hober: One of the ways, yes. Another is they both have weird legacy document.stylesheets has. If you're already using it you know how to use it

Domenic: document.stylesheets only has one method: item(). Not a big mismatch

hober: People are used to coding to document.stylesheets when they want to interrogate. Making the new thing consistent with that is of high value. More likely people can resuse code with small modifications
... Also argument to collapse 2 and 3 if you're willing to add ident

Domenic: Way I'm going. We could go to T39 and ask to add item method to array. Then it's consistent between every array on platform

TabAtkins: Observable array exends..

Domenic: Doesn't it is an array

TabAtkins: On hober note I guess a lot of the legacy items have .item

hober: Right. Helps observable be a good substitutue

Domenic: Right. SHould go to T39. Add counters too for usage. BUt going to T39 is safer.

Rossen_: Until have resolution from TC39 which way to go?

TabAtkins: If observable is just an array it's still possible to sub-class and add a .item method for use of document.stylesheets

Domenic: Not possible now but could add

TabAtkins: Lothe to upgrade docuemnt.stylesheet if remove method

Domenic: Three paths to that. use counters and remove if no usage, T39 adds it. Third is add a subclass adhoc

TabAtkins: That third is my preferred

rniwa: Object to try and remove item

Domenic: We can measure and see usage. Might be moot

TabAtkins: Without data we won't remove .item
... I propose we take obserable array, subclass to add.item. Keep both consistent. There's already people rpoposing to add this method and I can lend support to that and chamption in TC39
... It's option 3 but make sure document.adoptedStyleSheets has ident

chrishtr: hober and rniwa okay with this?

hober: It's an improvement on previous option 3

rniwa: That's the option?

TabAtkins: #3 but for both we use a subclass with .ident so we maintain compat

rniwa: IMprovement but we still have issue of assigment

TabAtkins: Yes, but that can go either way regardless of what we decide

rniwa: Not sure. Someone arguement mutable could be made the same. If someone is making that argument we need to discuss together

TabAtkins: Assignment is if it's ddeclared read-only. Nothing to do with reach interface

chrishtr: rniwa point is valid. It's possible to have race conditions when splicing in using similar syntax

Domenic: Also with methods proposed adding to shadow root

TabAtkins: All apply equally well regardless of the method we choose here

rniwa: Don't see why issue. Adding I'm not sure how it's racy.

TabAtkins: A await in an argument list is racy because pauses in middle of argument

Domenic: Array starts in one state, you try and add, your program pauses, you then add and array is in a different state

rniwa: THat's not the race. If someone has stylesheet h1 and h2, someone adds h3, you have a wait, someone adds h4. You could end us with s1 s2 and s4 but not s3. If you have method to add a stylesheet you're not removing anything. [??]

TabAtkins: But that can only plausably happen with old frozen array. Only way to append is read, make a new, and then assign it. If you had to wait in there underlying data could change. That is still a thing you can do if you assign but it's weird when you can push to the array.

<TabAtkins> Ryosuke's concern is `.aSS = [...document.aSS, await s4]`

Domenic: Problem before is assignment was overused. It has valid uses but when overused it introduces races. Point of this is to minimize the overuse of assignment when you can use .push

<TabAtkins> Which you'd just do as `.aSS.push(await s4)`

rniwa: Previous argument that we should allow assignment so I don't see how I can argee with your argument

TabAtkins: If it's assignment allow is if we put read-only on. Either way we can allow direct assignemnt

rniwa: Arguement made in how to solve race condition people argued it exists due to this approach. You'r saying they're independent but other say they're the same. If we resolve mutable array will never use argument for assignment ever maybe, but how do you enforce that? I don't know. I don't think I can agree

TabAtkins: I rpomise you we will not use this resolution as input to if it should allow assignment. If I promise you that they should be separable, right.

rniwa: If WG agrees maybe. But if it allows [missed] it's also race

TabAtkins: But every array has a possible race if you splice and wait

rniwa: Evidence people are writing racy code. I don't see why this is better then option 2 which does not have that issue. Why adding API where even those that are experts write racy code?

TabAtkins: Because not our place to say all JS is wrong and we produce a new type of array. TC39 is right arbiter of that. It effects all JS arrays. We shouldn't do awk API contortions to reflect this.

Rossen_: Couple minutes remaining. rniwa are we ready to get to resolution of modification for #3?

rniwa: I think there is an issue with race condition. At this moment I'm not comfortable with that resolution.

Rossen_: Options are stay with A Coruna resolution. We did record to keep them same. Folks will follow up with TC39 and see about adding .item.
... Any other resolution we can take now? If not we can move on

TabAtkins: No, we can't decide on any resolution until they're all decided.

Rossen_: Then we'll end here.
... astearns made a good observation to use this as a virtual F2F tryout. If people are interested in doing this in a greatout I'm happy to make this an experiment

hober: I think a great idea

rniwa: Sounds great

end

Rossen_: We have to care enough not just CSS itself. object model is important in how people use CSS and make it successful. DOn't often have API related discussion in that depth. I know some members are expressing concerns on how the call went but this is fundamental part of CSS we need to make platform successful
... Thanks to everyone who called in and participated.
... If people want to make this in virtual F2F please chime in on mailing list. TabAtkins and hober can wrangle people

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/[css-pseudo-4] Custom state pseudo class proposal/[construct-stylesheets] what kind of array/
Succeeded: s/Dominik/Domenic/
Succeeded: s/??/rniwa/
FAILED: s/??/rniwa/
Succeeded: s/dominic/domenic/
Succeeded: s/tot he queue/to the queue/
Succeeded: s/document.shadowRoot/DocumentOrShadowRoot/
Succeeded: s/binding/binding, at least it's clear/
Succeeded: s/same?/same/
Succeeded: s/one item/one method: item()/
Succeeded: s/ident/item/
Succeeded: s/.ident/.item/
Succeeded: s/ident/item/
Succeeded: s/document.stylesheet/document.adoptedStyleSheets/
Succeeded: s/break/a great/
Succeeded: s/break/great/
Default Present: dael, Rossen_, rachelandrew, dauwhe_, AmeliaBR, plinss, florian, dbaron, chrishtr, dholbert, antonp, lajava, jensimmons, miriam, Domenic, astearns, fantasai, rniwa, oriol, TabAtkins, emilio, GameMaker, drousso, iank_, cbiesinger, hober, chris
Present: dael Rossen_ rachelandrew dauwhe_ AmeliaBR plinss florian dbaron chrishtr dholbert antonp lajava jensimmons miriam Domenic astearns fantasai rniwa oriol TabAtkins emilio GameMaker drousso iank_ cbiesinger hober chris
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)