[CSSWG] Minutes Telecon 2020-12-16 [css-text-3] [css-images-3] [css-grid-1] [css-grid-2] [css-contain-1] [css-contain-2] [css-box-3] [backgrounds-3] [css-color-4] [snapshot-2020] [css-variables] [css-font-loading] [css-color-adjust] [css-scroll-snap]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

EOY Publications

  - RESOLVED: Publish CSS Text 3 as CR
  - RESOLVED: New CRD for Images 3
  - RESOLVED: New CRD for Grid L1
  - RESOLVED: Republish a new CRD for Grid 2
  - RESOLVED: Update Containment 1 REC
  - RESOLVED: Accept the PR (
              and republish WD of containment 2
  - RESOLVED: Move CSS Box Model 3 to CR
  - RESOLVED: Publish a new CR for Backgrounds and Borders 3

2020 Snapshot

  - RESOLVED: Move CSS Box Model to the top
  - RESOLVED: Move images 3 to stable bucket
  - RESOLVED: Moving sizing 3 to stable limited test
  - RESOLVED: Color L4- move to stable needs testing
  - RESOLVED: Add grid 2 to snapshot in same place as grid 1
  - RESOLVED: Publish snapshot 2020 as a note

CSS Variables

  - There has been further discussion about the possibilities for
      issue #5624 (Higher level custom properties that control
      multiple declarations) which are summarized in
      Several of the proposals from the last meeting have been ruled
      out and more details have been added to the proposal to de-sugar
      @if into inline if() calls. Discussion will continue on GitHub
      to look into if there are better ways to handle some difficult

CSS Font Loading

  - RESOLVED: Change css-connected by css created bool where it cannot
              be unset until removed from a document (Issue #5707:
              Browsers disagree on what it means for a FontFace object
              to be "CSS-connected", and what effect does it have)
  - RESOLVED: Have document.fonts.add when called with CSS created
              FontFace object throw an error (Issue #5707)

CSS Color Adjust

  - RESOLVED: Close no change (Issue #5779: It's a bit unfortunate
              that user stylesheets can't specify arbitrary colors)
  - RESOLVED: Scrollbar colors should compute to auto in forced-colors
              mode (Issue #5778: scrollbar-color should probably
              compute to auto in forced-colors mode)

CSS Scroll Snap

  - RESOLVED: Mark this property at-risk (Issue #4496: Snap area
              trapping behavior of non scrollable elements)


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Dec/0011.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Emilio Cobos Alvarez
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brad Kemper
  Daniel Libby
  Chris Lilley
  Peter Linss
  Alison Maher
  Tess O'Connor
  François Remy
  Morgan Reschenberg
  Florian Rivoal
  Devin Rousso
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

  Hui Jing Chen
  Greg Whitworth

Scribe: dael

  Rossen: I think we have a quorum and a full agenda
  Rossen: Before we get going wanted to hear if there are any extra
  florian: No changes, but a bunch of things within the EOY
           publications that were requested late
  Rossen: Yes, I intentionally didn't list because I know it would be
  Rossen: Any other things?

EOY Publications

  Rossen: I think fantasai had a bunch. Let's start with the one that
          are ready

CSS Text 3

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0099.html
  fantasai: First is CSS Text 3
  Rossen: Woohoo!
  fantasai: At 0 issues for first time in 18 years
  Rossen: If anyone has an objection to this one...^-^
  Rossen: Let's follow the order. Objections to publish css text 3
          as CR

  RESOLVED: publish css text 3 as CR

  <florian> \(^o^)/

  fantasai: We sent 2/3 to CR already. Writing modes and text decor
            require this. This is the last piece
  chris: DoC, up to date changes, usual questions
  fantasai: All in the email
  florian: In terms of tests we're beyond what we need
  fantasai: Should have been CR a long time ago, never got it together
  chris: Who is going to raise the issue?
  fantasai: I can file the transition request

CSS Images 3

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0103.html
  fantasai: Next is css images L3
  fantasai: Minor update
  Rossen: That's a WD?
  fantasai: CR
  Rossen: What's the update?
  fantasai: Several...4 substantive changes and one editorial change.
            Have to publish this so all other specs can crosslink the
  florian: CRD?
  fantasai: Yes, CRD for this.
  Rossen: CRD or CR?
  fantasai: CRD is easier so that
  Rossen: Objections to new CRD for images 3?

  RESOLVED: New CRD for images 3

CSS Grid 1 & 2

  fantasai: CSS grid 1 and grid 2
  fantasai: Handful of mainly editorial fixes
  Rossen: Have 1 issue on grid for today. Any implications if we
  fantasai: I believe there are a few minor editorial tweaks for that
            but they're included
  Rossen: Okay, so can proceed without
  Rossen: New CRD to Grid L1
  Rossen: Objections?

  RESOLVED: New CRD for Grid L1

  fantasai: And grid 2
  Rossen: Grid 2. Objections to republish a new CRD for Grid 2?

  RESOLVED: Republish a new CRD for Grid 2

CSS Contain 1 & 2

  fantasai: florian contain?
  florian: Would like contain 1 and contain 2. Start with 1
  florian: contain 1 is rec, made a few editorial and 2 substantive
  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0104.html
  florian: One is how we deal with computed values and the other is
           re-write of contain sizing. Didn't change behavior but old
           text was vague and short
  florian: Resolved to do this, under p2020 we can make a new
           publication without requesting approval but by making
           annotations in spec we attend to do this. Done that
           editorially and can push with approval
  florian: This would be the first use of this process and plh waiting
           on us to try
  chris: This is the we can update the rec with new features or is
         this something else?
  florian: Not new feature, just a correction
  Rossen: We just need a resolution?
  florian: Yes. I think for mechanics a team member needs to do it,
           but we need resolution
  Rossen: Objections to update Containment 1 REC?

  RESOLVED: Update Containment 1 REC

  <chris> Okay, if that is ready I can prep it for publication on
  florian: Just a REC. As before can do editorial. Substantive things
           are not done but are notes we want to so it's just a rec

  florian: Containment 2. Mostly resolved or editorial. I could almost
           republish without a resolution but there's 1 item
  <florian> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-contain-2%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-contain-2%2F#cv-notes
  florian: This diff ^
  florian: Discussed in a PR with several people but merged without
           resolution. Seems innocuous, but if anyone wants to not
           publish now is the time to say so
  Rossen: Besides the note the addition is the new restriction for
          visibility [reads]
  Rossen: That's the essence of it?
  florian: Yes, everything else is resolved or editorial

  Rossen: Any objections to accepting the PR and republishing WD of
          containment 2?
  chrishtr: Can you repeat the change?
  florian: You approved it, you merged the PR where it was approved.
           There's a link to the diff in IRC
  chrishtr: I approve that ^-^

  RESOLVED: Accept the PR (
            and republish WD of containment 2

  Rossen: Other requests?
  fantasai: Yes

CSS Box Model 3

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0106.html
  fantasai: CSS box model L3
  fantasai: Requesting CR transition. No new features from css 2.
            Redefines padding and margin. Created so we had something
            to refer to and add terms.
  fantasai: Couple issues asking for more terms but I think can do in
            CR. i18n completed review. I can't think reason why anyone
            else would care about a module with nothing new in it.
  fantasai: I suggest we transition to CR so we have stable reference
  Rossen: I don't have issue with that. Question, what is benefit of
          advancing this to CR?
  fantasai: So we can get to REC
  Rossen: If it doesn't add anything?
  florian: Adds terminology
  Rossen: Okay

  chris: So that means it passes all tests in css 2?
  fantasai: Yes
  Rossen: Can we go directly to rec :)
  fantasai: I don't think so
  Rossen: Objections to moving css box model 3 to CR?

  RESOLVED: Move css box model 3 to CR

Backgrounds and Borders 3

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0107.html
  fantasai: backgrounds and borders L3
  fantasai: Very stable, few changes. But should be republished
  fantasai: Summary of tests ^
  Rossen: You said only editorial?
  fantasai: 3 normative. First 2 have tests in wpt. 3rd is practically
            unobservable. I'm sure someone can write a test but I
            don't think will make a difference
  Rossen: Objections to new CR for Backgrounds and Borders 3?
  Rossen: And next time we can do CRD for it

  RESOLVED: Publish a new CR for Backgrounds and Borders 3

2020 Snapshot
  github: https://github.com/w3c/csswg-drafts/issues/4715#issuecomment-745856263

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0105.html
  fantasai: Last publication issue. florian and I reviewed 2020
            snapshot. It is ready based on earlier discussion. We
            think a few specs should be added/shifted though
  fantasai: If it's okay I'd like to ask WG about possible changes.
  <astearns> what about publishing 2020 snapshot as-is, and using your
             list as input for 2021?
  <florian> astearns publish with the discussed tweaks

  fantasai: First is add css box module L3 to top tier since it has no
            new functionality. Pretty stable
  fantasai: Let's go one by one for resolutions
  Rossen: Objections to moving box to the top?

  RESOLVED: Move CSS Box Model to the top

  fantasai: Next sizing 3
  fantasai: ditto for images L3 since we cleaned that up
  fantasai: It is now in sync with all the changes and pretty stable
  fantasai: Not top level as top, but stable spec with limited testing
  <fantasai> https://drafts.csswg.org/css-2020/
  Rossen: Objections to moving images 3 to stable bucket?

  RESOLVED: Move images 3 to stable bucket

  Rossen: Moving sizing 3 to stable limited test

  RESOLVED: Moving sizing 3 to stable limited test

  fantasai: Next few less sure
  fantasai: There was an issue against snapshot about transforms L2 to
            rough interop bucket
  chris: It has one impl
  chris: Chrome has a bug on it
  fantasai: Transforms 2 I thought multi implementations of 3d
  chris: Yes, but single transform is only one impl
  florian: Seems short for rough interop
  fantasai: Could add and exclude those bits or save for next year
  florian: Save it
  <emilio> hmm, Gecko ships individual transform properties iirc
  <gsnedders> WebKit has an impl of individual transform properties,
              but not shipped in Safari

  fantasai: Other was color adjust 1. Maybe save for next year as well
  chris: Doesn't have any tests so claim of interop is hard to
         substantiate. Is it only human testable?
  fantasai: Shouldn't require human interaction to work. We can do it
            next year

  fantasai: I asked about color and font 4
  chris: I responded.
  Rossen: 2021
  chris: Color 4 is stable. A few bits are not. Closed enough that I
         expect to request CR in Jan or Feb. Stable and getting impl
  fantasai: Color 4 in stable needs testing or save for 2021
  chris: Let's say stable and needs testing.
  chris: Same with fonts 4
  Rossen: Color l4 move to stable needs testing
  <gsnedders> do we not have tests for most of color l4 in WPT from
              when impls implemented it?

  RESOLVED: Color L4- move to stable needs testing

  fantasai: Fonts 4 has a lot of open issues. Lot of impl happening
            but spec text maybe not stable
  chris: It is. I disagree on issue. 2 groups of long running issues.
         generic font families and privacy issues. It's stable apart
         from those bits.
  florian: There are 76 open issues. Are they all what you said?
  chris: At least 3/4 of them
  Rossen: Seems a little early with number of issues
  chris: I'll push a little but I'll fallback with graceful degradation
  fantasai: I think we want to save that for next year
  chris: Fine

  fantasai: Propose publishing the snapshot 2020 as a note
  chris: Grid 2?
  fantasai: Oh, yes. Grid 1 is rough interop but needs more testing.
            Grid 2 is a superset of 1.
  fantasai: Part that's different in L2 has had no issues
  fantasai: Might make sense to put L2 in the same bucket as 1, since
            what's holding 2 back is the shared part
  chris: Makes sense to me
  Rossen: Publishing snapshot as a note. Objections?
  fantasai: Didn't resolve on grid 2.
  Rossen: I thought we were not going to move
  fantasai: Add to snapshot in same place as grid 1
  Rossen: Objections?

  RESOLVED: Add grid 2 to snapshot in same place as grid 1

  Rossen: And now, are we ready to push snapshot 2020 as a note?

  RESOLVED: Publish snapshot 2020 as a note

  chris: What state is it in and when to prepare for publication?
  fantasai: Need to make resolution edits. Tomorrow, I'm guessing
  Rossen: Anything else for publication?
  fantasai: That's all I got
  florian: I'm done
  <jensimmons> Does that mean we get a CSS 2020 in 2020??
  <astearns> just barely

CSS Variables

Higher level custom properties that control multiple declarations
  github: https://github.com/w3c/csswg-drafts/issues/5624

  leaverou: I didn't explicitly add this. We discussed last time and
            didn't get resolution. Interesting discussion in issue and
            off GH
  <leaverou> https://github.com/w3c/csswg-drafts/issues/5624#issuecomment-746339609
  leaverou: I summarized current state in ^ comment
  leaverou: Summary: It looks like best course of action for block
            conditionals...Can't use pseudo class, cause issues. If
            if() cascades have to carry extra context and increases
            too much complexity
  leaverou: Best is impl if based on idea of de-sugaring to inline
            if() calls and take into account properties in same rule.
            Example in comment
  leaverou: Raises some issues because certain values evaluate
            differently depending on property. Hasn't come up that
            much. Length in some MQs
  leaverou: For example, ones we could come up with TabAtkins is
            percentage, em values, rem, lh, rlh, currentColor.
  leaverou: Problem. If it de-sugars to inline if calls and
            conditional has relative values you may have cases where
            part of rule evaluate to true and a part of false. Example
            in comment.
  leaverou: Agreed don't want partial applications. How to solve?
  leaverou: Came up with defining how these relative values would be
            evaluated. currentColor is as if in color and so on. New
            inline conditional function to de-sugar @if
  leaverou: Doesn't sound good, but couldn't come with better
  leaverou: Addresses single conditional. CSS nesting has same partial
            application problem. May have condition true for a rule
            but not decedents.
  leaverou: Might have var warning = on and a value for --warning on
            parent and different value on the child
  leaverou: You again have @if block applied partially
  leaverou: Not sure if there's a way to address this. Couldn't come
            up with anything but just discussed yesterday. Don't know
            if there are ideas

  fantasai: What do you do if content has if clause with a property
            that effect evaluation. If on a em and evaluate em against
            font size
  leaverou: Can you put example in IRC?
  <fantasai> @if (var(...) > 1em) { font-size: 35pt; }
  leaverou: I see
  leaverou: I'm not sure
  leaverou: What would you suggest should happen?
  leaverou: It's basically same as if you have inline if

  Rossen: In interest of time, are we ready to resolve or should we
          take it back to GH and continue there?
  leaverou: I suppose we could go back to issue
  Rossen: Let's do that. Let's continue discussing there. I was hoping
          we were closer to resolution then we are. We'll come back

  <leaverou> fantasai: 1em evaluated against font-size refers to the
             *parent* font-size, so there's no conflict there. That's
             *why* we'd evaluate ems against font-size, to avoid that
             sort of thing
  <fantasai> leaverou, I think it would be super unexpected if you
             evaluated em against parent font-size, unless all of the
             if clause lengths evaluate against the parent or something
  <fantasai> leaverou, and in that case, seems a lot less useful?
  <leaverou> fantasai: then the other options are: a) it evaluates
             differently per property, so you have partial application
             b) it evaluates against another property, e.g. width, so
             you have a cycle in font-size.
  <fantasai> leaverou, sure I recognize those are bad... but also, it
             seems to me that the use cases would want to evaluate
             against the element itself
  <fantasai> leaverou, if that's not the case and evaluating the
             parent font size is useful and expected, great, but if
             not, then making it implementable isn't actually solving
             the problem
  <leaverou> fantasai: If you look at the use cases wrt WC, none of
             them really seems to need ems. We just need to define
             what happens when someone uses it that way. I agree that
             parent is not that useful, but not sure the alternatives
             are better. I'm hoping there might be a 4th alternative
             we haven't considered, but I think the top priority would
             be to make sure that either the entire @if is applied or
             none of it, even if some values become less useful in

CSS Font Loading

Browsers disagree on what it means for a FontFace object to be
    "CSS-connected", and what effect does it have
  github: https://github.com/w3c/csswg-drafts/issues/5707

  emilio: Browsers behave really oddly. Spec-wise spec says FontFace
          object once the rule is removed you should be able to use
          like it's not css-connected. A bit messy, browsers don't
          impl to the letter. Simpler would be if FontFace created for
          a css rule it is considered css-created. Then impl and spec
          are simpler
  emilio: Given behavior is all over the place and it's an edge case
          it would be nice to simplify
  TabAtkins: What impacts does it have on the connection between
             properties if we just make a flag for css-created
  emilio: afaict is chrome and ff don't allow change of descriptor of
          FontFace object. Per spec it's 2-way mapping. I think FF and
          Chrome don't impl. I don't see an issue with 2-way mapping
          as is.
  TabAtkins: If keeping the connection I'm unclear what the change is
  emilio: Per spec once you remove the rule from the style sheet, even
          though om wrapper for rule exists, the FontFace object is
          disconnected from it. Means a lot of functions that need to
          check for css connection need to also update stylesheets and
          other expensive stuff
  TabAtkins: So if you move a cssom FontFace object into another
             stylesheet in another document so it shows in a different
             FontFace set would that make 1 more object
  emilio: afaict you can't do that. cssom method is strings so you
          need to stringify
  TabAtkins: Okay. If purely when an om rule is created it gets a
             corresponding object and that's a permanent connection
             I'm okay with that. Simplification. Fine with me
  emilio: I think so too

  Rossen: Other opinions?
  Rossen: Summary?
  emilio: Proposed: Change css-connected by css created bool where it
          cannot be unset until removed from a document
  Rossen: Objections?

  RESOLVED: Change css-connected by css created bool where it cannot
            be unset until removed from a document

  emilio: Another issue in this. That was changing definition. Now
          what happens to document.fonts.add with that object
  emilio: It's in the same issue, but needs different resolution
  emilio: It's when it's from a rule created in another document. I
          think blink does nothing. Spec says throw which is what
          gecko does. Doesn't match WK or blink. Happy to use either,
          both are reasonable.
  emilio: It does nothing if called on same document which is odd. I
          think easiest is follow blink
  TabAtkins: Meaning it doesn't get added to set?
  emilio: Right
  TabAtkins: No opinion on throw or ignore. Whichever
  emilio: I don't care either. Throw to do nothing is a bit easier for
          use. Doing nothing to throwing may break. No strong opinion.
          Whatever gets faster interop
  TabAtkins: Seems rare to do this. I suspect we could move to throw
             and I would prefer because it's an error. Do we have an
             issue to fix in chrome?
  emilio: I'm okay change to throw
  TabAtkins: I'll try that and talk to Rune. If not we'll come back
  Rossen: With my TAG hat I'd argue strongly for throwing. There's a
          pretty clear guidance on this pattern. Should do most
          observable. Let's not have silent error. I agree with
  Rossen: Objections?

  RESOLVED: Have document.fonts.add when called with CSS created
            FontFace object throw an error

CSS Color Adjust

It's a bit unfortunate that user stylesheets can't specify arbitrary
  github: https://github.com/w3c/csswg-drafts/issues/5779

  emilio: I don't think it's huge. Came up when reviewing changes to
          forced colors. It's a bit unfortunate user colors stop
  emilio: I don't have a super great use case for user stylesheets
          spec arbitrary colors. I don't think it's huge but wanted to
          raise because it's weird.
  fremy: I think we did consider it. You can spec any color and say
         forced color adjust none
  emilio: Yeah
  fremy: You want to do it anyway to disable backplate. You can say
         anything in stylesheet.
  <fantasai> or stick to the forced colors palette
  emilio: Would need to disable for everything but yeah. It's a
          different behavior. Not a huge issue. Can disable
          forced-colors all together or change system colors to match
          what you want
  Rossen: Doesn't sound like there's anything to resolve
  emilio: Resolve no change
  Rossen: Objections?

  RESOLVED: Close no change

scrollbar-color should probably compute to auto in forced-colors mode
  github: https://github.com/w3c/csswg-drafts/issues/5778

  emilio: This was the case I could think of because we don't have
          system color for scrollbars. Probably should force to auto
          and have system scrollbar colors to show
  <fremy> sounds reasonable to me
  Rossen: Sounds sensible. Other opinions?
  Rossen: Proposal: Scrollbar colors should compute to auto in
          forced-colors mode

  RESOLVED: Scrollbar colors should compute to auto in forced-colors

CSS Scroll Snap

Snap area trapping behavior of non scrollable elements
  github: https://github.com/w3c/csswg-drafts/issues/4496

  fantasai: Added because we had original set up scroll-snap-type
            where if it's non-initial it traps snaps. If elements
            inside asking for snap position we ignore. Scroll
            containers have to trap. Added additional behavior for
            scroll-snap-type so if someone wants to say in this area
            ignore a snap position they could do so
  fantasai: Seems this is difficult to impl for Blink. Do we want to
            not have the behavior? Would mean only way to prevent
            contents from having snap behavior is put in a scroll

  Rossen: It's a hack. The hack will work. People will hate the hack.
          It'll probably end up in css hacks books.
  Rossen: Is it really that difficult that we should go to that extent.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-706333521
  fantasai: Here's comment from impl ^
  fantasai: I'm not aware of any requests for the behavior
  Rossen: non-Blink implementor with opinion?
  smfr: My hunch is it doesn't make sense for non-scrollable things to
        trap snapping
  fantasai: Within that element we don't track snap position
  Rossen: Image in a carousel scenario?
  fantasai: No. a section and in that section there's properties
            setting snap points, you can turn that off. You can say
            this element ignore the snap positions inside. We can just
            not have that behavior and see if someone complaints
  Rossen: In interest of time we can resolve here. If there are no
          strong arguments for keeping it I'm fine with that
  smfr: Looked at WK and would be easy to impl
  Rossen: Argument for reverting doesn't seem to be a problem for WK

  Rossen: What if we keep issue open and when we get to actual impl
          and get experience I think that's when we come back and
  fantasai: Mark at-risk?
  Rossen: Sensible
  Rossen: Objections?

  RESOLVED: Mark this property at-risk

End of Year

  Rossen: We're at the end of the call.
  Rossen: I'd like to use the last few seconds for the yearly summary
  Rossen: Have resolved and made 52 publishings. 4 notes, 31 wd, 16 cr
          and 1 REC
  Rossen: Over 192 resolutions
  Rossen: Crazy year, very busy. I want to thank all the members for
          participating, editors for working, staff for helping us,
          dael for scribing, and everyone for putting up with what
          2020 brought us. WG showed up strong.
  Rossen: Thank you everyone for going through this together and let's
          hope for a better 2021
  [lots of cheering]

Received on Wednesday, 16 December 2020 23:55:36 UTC