- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Mar 2020 19:18:44 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Align & CSS Grid
--------------------
- RESOLVED: All boxes can participate in baseline alignment. If they
don't have a baseline one is synthesized (Issue #4675:
Do grid items that have "no baseline set" participate in
baseline alignment?)
Constructable StyleSheets
-------------------------
- RESOLVED: Keep the two interfaces the same as each other (WICG
Constructable Stylesheets Issue #45: Decide whether to
change from FrozenArray to ObservableArray for
adoptedStyleSheets)
- Though the group agreed that the interfaces should be the same, it
has not yet been agreed what the same thing should be. There
were three options listed during the call:
- Option 1: Both .sS and .aSS use StyleSheetList; ShadowRoot
gains methods to mutate .aSS
- Option 2: Both .sS and .aSS use a readonly ObservableArray;
ShadowRoot gains methods to mutate .aSS
- Option 3: .sS is upgraded to a readonly ObservablyArray; .aSS
is an ObservableArray
- Discussion focused around options 2 and 3; there wasn't much
discussion around option 1.
- Some group members will reach out to TC39 about adding .item to
arrays which closes the gap between options 2 and 3.
Additionally there was interest in possibly creating a usage
counter for .item to see if there's any option to remove it.
- The final decision needs to be based around the decision of how to
handle the race conditions inherit in "assignment".
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Mar/0012.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Domenic Denicola
Elika Etemad
Javier Fernandez
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Ian Kilpatrick
Chris Lilley
Peter Linss
Theresa O'Connor
Ryosuke Niwa
Anton Prowse
Florian Rivoal
Devin Rousso
Jen Simmons
Alan Stearns
Miriam Suzanne
Scribe: dael
Virtual F2F
===========
Rossen: Let's get started
Rossen: As usual, asking for any extra items for the agenda
Rossen: 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
Rossen: Idea is pick a topic that's ideally going to attract wide
and active audience as well as ask and encourage as much
participation as possible so we can put stress on the tool
Rossen: 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.
Rossen: In absence of better proposals we can proceed with this
Rossen: In terms of tech we want something with video and audio but
there's good discussion about something with a11y built in.
Good ongoing discussion in chairs area
Rossen: Once we land on something that works for everyone we'll
proceed with that
Rossen: That's everything about housekeeping and F2F
Rossen: 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
Rossen: We don't have a resolution yet. Can we
fantasai: I thought we had discussed if such items participate and
decided that they do. Happy to re-resolve unless someone
thinks different.
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 the considered empty
items were different. It's not clear in the spec that those
items participate
lajava: Only thing to clarify in spec is if empty items participate
or not in baseline
lajava: Only sentence I found in spec is the one I added in my last
comment
lajava: If I understood having alignment properties set to baseline
implies any item should participate. Mats prefers something
more explicit to be added.
lajava: That's only thing up for discussion I think
<fantasai> baselines of empty boxes:
https://github.com/w3c/csswg-drafts/issues/439
<AmeliaBR> Resolution from 439: Have grid and flexbox keep saying
that empty boxes have no baseline and they're synthesized
with bottom border edge.
Rossen: fantasai linked to a discussion about empty boxes for
alignment in grid
Rossen: There's a clear resolution in the past. With that resolution
linked into the minutes and GH I'm happy to move on
lajava: I mentioned that to Mats in bugzilla. Point is this only
clarifies how to synthesize. He continues to state that they
don't participate in baseline
lajava: I'd prefer Mats to define his point.
lajava: 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
Rossen: Anything else on this?
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 revisit he can do so
fantasai: Can we resolve because there are unclear cases
fantasai: All boxes can participate in baseline alignment. If they
don't have a baseline one is synthesized
Rossen: Objections?
RESOLVED: All boxes can participate in baseline alignment. If they
don't have a baseline one is synthesized
CSS Pseudo
==========
Custom state pseudo class proposal
----------------------------------
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 constructible style sheets.
Constructable StyleSheets
=========================
Decide whether to change from FrozenArray to ObservableArray for
adoptedStyleSheets
-----------------------------------------------------------------
github: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-600279738
TabAtkins: Web components F2F happened yesterday and Monday.
Discussed constructable stylesheets. While Web components
has no power, we came to consensus on issues. Need to
record here.
TabAtkins: Proposal is 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
TabAtkins: 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.
TabAtkins: 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
adoptedStyleSheets. Use this new once it's added to WebIDL
TabAtkins: Still want consistency so should make stylesheet lists if
possible a subclass of observableArray, 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.
TabAtkins: Switching from mutable version to ObservableArray
TabAtkins: 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 interrupt. Different issue. Not about assignment.
Just switch to ObservableArray
rniwa: Tied, though.
TabAtkins: If we need to do both issues at the same time we can. But
if possible to separate we should do that
rniwa: Objection to switch to ObservableArray is we shouldn't unless
we can change document.stylesheet to same model
Domenic: Mutable is new concept 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 against
domenic: We're creating a third interface
TabAtkins: In parts were it overlaps it would be consistent.
Domenic: ObservableArray would also be consistent. No parts
TabAtkins: StyleSheet list has terrible but existing...
Domenic: Benefit is it fails array.isarray check?
TabAtkins: Acts same between two. Only difference is things that
correspond to mutability.
TabAtkins: 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
Rossen: 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.
Rossen: 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 FrozenArray to ObservableArray 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 Coruña resolution
Rossen: Going through F2F minutes
<fantasai> https://lists.w3.org/Archives/Public/www-style/2020Feb/0012.html
<fantasai> A Coruña minutes ^
<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)
TabAtkins: My argument doesn't change, though. The two are
isomorphic. It subs in for the same reasoning in my
argument.
rniwa: Clarifying there's no resolution at web components because
don't have formal methods to come to resolution. That's why
we're here.
<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
<fantasai> rniwa, actively avoiding recording resolutions because
you don't have the power to bind any WG to it means your
minutes lack clarity
<rniwa> fantasai there was no consensus. we were in disagreement.
<fantasai> rniwa, that might also be worth noting explicitly then.
Basically any discussion should have its conclusion
clearly called out, whatever it is
<fantasai> this is why I hound Rossen on explicit resolutions
whenever we're missing one :)
<Rossen> yes, fantasai does that to us :)
TabAtkins: Now that we're up to speed on previous resolution.
Keeping things consistent with both APIs being legacy
stylesheet or moving both to ObservableArray, the nice
new thing that works like people want.
TabAtkins: I push for both with document.stylesheet becoming a
read-only but they both act like an array.
TabAtkins: Objections to doing that? Otherwise I seek resolution
hober: Agree with TabAtkins and rniwa that they should have similar
interfaces.
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 methods emilio mentioned on
shadow root to mutate
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 Coruña 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.
hober: If we move on I think there are 3 options. But I think we can
resolve on that
Rossen: Your proposal doesn't negate the proposal to keep them the
same
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
RESOLVED: keep the two interfaces the same
<masonfreed> point of clarification: same as each other, not
necessarily the same as they are now
RESOLVED: 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 adoptedStyleSheets would be by some other
means. I think that's option 2 of what TabAtkins typed
TabAtkins: Yep
TabAtkins: Making read only observable that's only available by out
of bad method seems bad. Whole point of observable is
it's mutable. If you're doing exactly observable but
moving mutable somewhere else I don't see the point of
that. To be slightly impolite hober it seems asinine.
<TabAtkins> Hmm, looking up definition of "asinine", it seems
stronger than I intended. Apologies, hober.
<hober> apology accepted
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
ObservableArray 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 concern is about race conditions?
TabAtkins: No, that's about assignment question which is after this
stuff.
chrishtr: assignment is also race conditions?
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 Coruña resolution
and what TabAtkins proposed. Thought in doing that was to
have stronger consistency between existing object and the new
thing than in TabAtkins proposal
chrishtr: Because 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 reuse code with
small modifications
hober: Also argument to collapse 2 and 3 if you're willing to add
item
Domenic: Way I'm going. We could go to TC39 and ask to add item
method to array. Then it's consistent between every array
on platform
TabAtkins: ObservableArray extends...
Domenic: Doesn't. It is an array
TabAtkins: On hober note I guess a lot of the legacy items have .item
hober: Right. Helps ObservableArray be a good substitution
Domenic: Right. Should go to TC39. Add counters too for usage. But
going to TC39 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: Loathe to upgrade document.stylesheet if remove method
Domenic: Three paths to that. Use counters and remove if no usage.
Second, TC39 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
TabAtkins: I propose we take ObservableArray, subclass to add.item.
Keep both consistent. There's already people proposing to
add this method and I can lend support to that and
champion in TC39
TabAtkins: It's option 3 but make sure document.adoptedStyleSheets
has item
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 .item so we
maintain compat
rniwa: Improvement but we still have issue of assignment
TabAtkins: Yes, but that can go either way regardless of what we
decide
rniwa: Not sure. Someone argument mutable could be made the same. If
someone is making that argument we need to discuss together
TabAtkins: Assignment is if it's declared read-only. Nothing to do
with reach interface
chrishtr: rniwa's 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 wait 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 plausibly 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]`
<TabAtkins> Which you'd just do as `.aSS.push(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
rniwa: Previous argument that we should allow assignment so I don't
see how I can agree with your argument
TabAtkins: If it's assignment allow is if we put read-only on.
Either way we can allow direct assignment
rniwa: Argument made in how to solve race condition people argued it
exists due to this approach. You're 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 promise 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 awkward
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 Coruña resolution. We did record to
keep them same. Folks will follow up with TC39 and see about
adding .item.
Rossen: 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.
Rossen: astearns made a good observation to use this as a virtual
F2F tryout. If people are interested in doing this in a
breakout I'm happy to make this an experiment
hober: I think a great idea
rniwa: Sounds great
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
Rossen: Thanks to everyone who called in and participated.
Rossen: If people want to make this in virtual F2F please chime in
on mailing list. TabAtkins and hober can wrangle people
Received on Wednesday, 25 March 2020 23:19:45 UTC