W3C home > Mailing lists > Public > www-style@w3.org > March 2020

[CSSWG] Minutes Telecon 2020-03-25 [css-align] [css-grid] [constructable-stylesheets]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Mar 2020 19:18:44 -0400
Message-ID: <CADhPm3ugoz=zRwwcY8JY6Q0=YzUvigRdv6GDqEDWt7Purz0C-w@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 25 March 2020 23:19:47 UTC