W3C home > Mailing lists > Public > www-style@w3.org > June 2021

[CSSWG] Minutes Telecon 2021-06-23 [css-fonts-5] [css-color-4] [css-contain] [css-images] [css-grid-1] [css-overflow-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Jun 2021 18:53:47 -0400
Message-ID: <CADhPm3sR9JXgx1FEj1x4akUmj7aP4pjrXdZa7+G7PZdZWYYj8A@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 Fonts 5

  - RESOLVED: css-fonts-5 to FPWD

CSS Color 4

  - RESOLVED: Add leaverou as co-editor css-color-4

CSS Contain

  - The editors of Contain 3 will add a bit more detail to the 1D
      containment section and then request FPWD; hopefully next week.
  - RESOLVED: Update spec to acknowledge effects of filters. No other
              change. (Issue #6325: paint containment vs filter effects)

CSS Images

  - RESOLVED: Degenerate aspect ratios derived from SVG width/height
              attributes fall back to viewbox aspect ratio (whether due
              to negative values or zero values) (Issue #6286: SVG
              degenerate aspect ratios)

CSS Grid 1

  - RESOLVED: Accept proposal for continuous distribution of space to
              intrinsic grid tracks (Issue #6078: Distribution of
              intrinsic sizes according to flex factors doesn't handle
              sum < 1)
  - RESOLVED: Alignment via auto margins disables content
              baseline-alignment the same way as align-self values with
              the same effect (Issue #5923: baseline-alignment and auto

CSS Overflow 3

  - Issue #5896 (overflow-clip-margin + border-radius continuity
      adjustment) needs spec text and/or images added to better
      understand the examples.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0018.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  David Baron
  Christian Biesinger
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Jonathan Kew
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Morgan Reschenberg
  Miriam Suzanne
  Lea Verou

  Javier Fernandez
  Greg Whitworth

Scribe: fantasai
Scribe's Scribe: emeyer


  Rossen: Dael will not be able to scribe the 9am calls anymore.
  Rossen: We're going to try to rotate scribes.
  Rossen: We'll try to organize that outside the calls.
  [discussion of scribing candidates]

CSS Fonts 5

  chris: Merged PR listed in the agenda
  Rossen: So ready for FPWD?
  chris: Yes
  Rossen: Any other comments?
  Rossen: Any objections to FPWD on css-fonts-5?

  RESOLVED: css-fonts-5 to FPWD

CSS Color 4

  Rossen: Suggestion to add Lea as co-editor
  Rossen: Any reason not to?
  <florian> +1
  <fantasai> +1
  <emeyer> +1
  <dbaron> +1
  <miriam> +1
  <chris> +1

  RESOLVED: Add leaverou as co-editor css-color-4

CSS Contain 3

  <miriam> https://drafts.csswg.org/css-contain-3/

  Rossen: There are some open topics and issues, but is there any
          reason to hold the FPWD?
  <chris> +1 to fpwd
  florian: I'm not worried about the issues, it's FPWD, not Last PWD.

  florian: Concerned about parts that are missing
  florian: Description of queries is good enough, but the description
           of containment is mostly missing
  florian: There are some experiments, maybe something can be written up
  florian: Similarly, state and style querying, they're stated to
           exist, but there's nothing about how they work at all
  florian: For state and styles, can do it later probably
  florian: but description of 1D size containment needs something
  Rossen: There are open issues for this
  fantasai: If we have stuff to write, we should usually do that before
            FPWD. We’re just not sure what to write on this, and that
            shouldn’t block FPWD as long as there’s enough material to
            understand what’s missing.
  florian: Fair, but 1D containment for awhile was not thought to be
  florian: So we should have an explanation of how it's become doable.

  Rossen: OK, that's fair. Request to the editors then, to work on this
          and maybe FPWD next week or so?
  miriam: OK
  Rossen: Appreciate pushback, what Florian is saying is valid.
  Rossen: Hopefully next week we can come back and go to FPWD

CSS Images

SVG degenerate aspect ratios
  github: https://github.com/w3c/csswg-drafts/issues/6286

  iank: We were going to ask Amelia, but she had to defer
  iank: So it's up to us
  iank: I posted a comment describing the various behaviors
  iank: I still slightly prefer the WebKit/Blink behavior
  iank: ...
  iank: Reminder that this is just about interop on an edge case for
        which we have testcases in WPT, not something that impacts web
  Rossen: Can you summarize?
  iank: With negative widths, Blink/WebKit will treat as invalid
        whereas Firefox will treat as zero
  iank: Blink/WebKit will use the viewbox aspect ratio as a fallback
  iank: whereas Firefox will have no aspect ratio
  iank: If there is a negative width/height specified, it gets clamped
        to zero and then continue
  iank: Firefox's behavior from there was to treat aspect-ratio as null
  iank: Whereas when we have a negative width/height, we treat as
  iank: So we use fallback aspect ratio
  iank: Separate issue of when we have explicit width of zero and
        height of 50
  iank: Blink/WebKit will fallback to viewbox of 1:1
  iank: and Firefox will behave as if there is no aspect ratio
  <fantasai> Note: spec currently says “If the <ratio> is degenerate,
             the property instead behaves as auto.”
  Rossen: So your preference is to fall back from degenerate width/
          height on SVG to the viewbox aspect ratio
  iank: Right. This mirrors how the aspect-ratio property itself falls
        back from degenerate ratio value to intrinsic ratio of image

  dholbert: Are you proposing just for negative case, or also for zero
  fantasai: So the proposal is to fall back to the viewbox aspect ratio
  fantasai: In all degenerate cases
  dholbert: OK, would not object to that
  <dholbert> iank, got it, thanks
  fantasai: So the proposal is that in the same way that the
            aspect-ratio property's explicit degenerate aspect ratios
            fall back to the intrinsic aspect ratio of the image, the
            proposal is that a degenerate aspect ratio from an SVG
            derived from its width/height attributes also falls back:
            to its viewbox ratio

  RESOLVED: Degenerate aspect ratios derived from SVG width/height
            attributes fall back to viewbox aspect ratio (whether due
            to negative values or zero values)

CSS Contain

paint containment vs filter effects
  github: https://github.com/w3c/csswg-drafts/issues/6325

  florian: Had not realized earlier, but there's a problem with paint
  florian: The point of paint containment is to ensure that if anything
           changes inside an element with paint containment, nothing
           leaks in terms of changing painting outside it
  florian: However, filter-effects, when specified on an ancestor of
           the contained element,
  florian: e.g. consider a large blur radios
  florian: In order to calculate the result of pixels outside the box,
           need to consider the painting of pixels inside the box
  florian: I think there's no infinite-range filter? So maybe you just
           need to calculate a margin of error to repaint.

  chris: FE-flood, which can fill an entire region?
  florian: Fills the entire region, but does it take the entire region
           as input?
  chris: No
  florian: Yeah, that's the trouble. Blur does that.
  smfr: Also FE-displacement, which can take arbitrary displacement.
  florian: Can be arbitrary, but can't be infinite at least
  <chris> standard deviation of feGaussianBlur is not bounded, but
          can't be infinite
  <chris> https://drafts.fxtf.org/filter-effects/#element-attrdef-fegaussianblur-stddeviation

  Rossen: ... considering chrishtr's comment
  florian: If talking about bg of element or things inside it, issue
           still applies. Filter on parent will still fetch those
  florian: If you have a 15px blur filter on BODY element
  florian: and somewhere inside tree have a paint-contained element
  florian: then even if it's 3px off-screen, have to repaint it so you
           know what pixels to spread into the screen area
  florian: Because you have a 15px blur on the BODY, know it's within a
  florian: but you have to walk up the tree to figure out what filters
           might apply

  smfr: Do any implementers think this is a problem?
  <chrishtr> I don't think it's a problem.
  Rossen: Do you?
  smfr: I haven't implemented yet, I think it's fine.
  florian: Well, the spec says as soon as element is off-screen can
           stop painting, that point definitely is not true
  chrishtr: Yes, spec will need to be updated to account for filters.
  florian: Is that good enough? or do we need to find some other
  chrishtr: I think it's good enough
  Rossen: How about we start with this, and if we find additional
          evidence we'll come back
  florian: Alternative might be to say that paint-contained elements
           are not taken as input into filters
  fantasai: That sounds worse
  chrishtr: Sounds weird
  chrishtr: Browsers can compute this, don't see a big problem
  florian: If you don't think it'll be expensive, then fine
  chrishtr: e.g. browser could apply simple heuristic if page doesn't
            have an any pixel-moving filters on it, then apply
            reasonable margin, or whatever
  fantasai: Proposal: update spec to acknowledge effects of filters?

  RESOLVED: Update spec to acknowledge effects of filters. No other

CSS Grid 1

Distribution of intrinsic sizes according to flex factors doesn't
    handle sum < 1
  github: https://github.com/w3c/csswg-drafts/issues/6078

  oriol: The specification says when taking into account the intrinsic
         contributions of items spanning flexible tracks, we distribute
         according to flex ratios of the tracks
  oriol: We had a problem that all flexible tracks have 0fr, then have
         to divide by zero which is not well-defined.
  oriol: So we resolved that in that case the distribution is done
  oriol: Now we have the problem that this is not continuous
  oriol: If you have 0fr to 0.00001fr, suddenly change from
         distributing equally to that track getting all the contribution
  oriol: So proposal is to do the distribution continuously
  oriol: If sum is >= 1 no change from now
  oriol: if sum is zero, equal distribution as before
  oriol: in between, we would [...]
  oriol: we would multiply the space by the sum (which is < 1) and
         distribute that space proportionally
  oriol: and distribute the rest of the space equally
  oriol: This gives continuity between 0 and 1

  Rossen: Any feedback?
  fantasai: I think it’s a good change that makes sense and gives us
            continuity between 0 and 1.
  dbaron: Does anything else in CSS act like this?
  fantasai: Flex acts a little like this.
  <dholbert> yeah, the flexbox spec says something similar for
             flex-grow < 1 -- we should be sure to make this as similar
             as possible.
  <dholbert> for coherence
  iank: Table percentage distribution acts a bit like this
  fantasai: The main difference between this and flex is that here you
            distribute all the space but in flex you distribute some of
  dbaron: Ok, seemed a little weird to only make the change in this

  iank: Modulo web-compat...
  iank: I have a bug about 0frs and things
  iank: Depending on how widespread that is...
  oriol: I don't think web-compat is problematic for this specific thing
  oriol: Currently implementations are not taking into account
         intrinsic contributions of items spanning multiple flexible
  oriol: gridNG implemented the right thing
  oriol: If we had a compat problem, it would be more general problem
  Rossen: Not hearing any objections

  RESOLVED: Accept proposal for continuous distribution of space to
            intrinsic grid tracks

baseline-alignment and auto margins
  github: https://github.com/w3c/csswg-drafts/issues/5923

  fantasai: The interaction isn’t well defined. We found there’s a lot
            missing about grid and auto margins. We made a
            non-normative section normative. We brought some alignment
            into harmony with flexbox.
  fantasai: When you have content baseline alignment across multiple
            items, and you’re trying to add padding, the ‘align-self’
            property can move the box.
  fantasai: If boxes are moved, baseline alignment gets weird. We have
            some working in alignment that says you have to have a
            coordinating alignment, start or end.
  fantasai: We didn’t account for how auto margins can move boxes.
  fantasai: Option 1, we require a coordinated alignment effect. If the
            auto margin cause the box to be centered, baseline
            alignment is disabled.
  fantasai: Option 2, any auto margins disable baseline alignment.
  fantasai: We went with option 1 but are open to other options.

  iank: We don't implement content baseline alignment yet
  iank: but I think it sounds fine
  iank: for self-alignment though, any auto margins don't participate
        in baseline alignment, right?
  fantasai: If that’s what’s implemented, the spec should say so.
  iank: If we have align-self: baseline and any auto margin, we ignore
        that align-self
  fantasai: Right, they're both trying to align the box, so have to
            pick one
  iank: but for content alignment, this seems fine
  iank: One thing I might need to check is, if they participate in the
        propagation of a baseline
  iank: but that might be a separate issue...

  [discussion of javier's comments, possible mixing up self- vs
      content-alignment causing confusion]
  <dholbert> which option are we proposing?
  <dholbert> (1 vs 2)
  <fantasai> I think we're proposing 1, unless anyone has a problem
             with it
  <dholbert> (I'm fine with either, I think)

  Rossen: Anyone else with an opinion?
  <fantasai> proposed: alignment via auto margins disables content
             baseline-alignment the same way as align-self values with
             the same effect

  RESOLVED: Alignment via auto margins disables content
            baseline-alignment the same way as align-self values with
            the same effect

  Rossen: if Javier or Tab has concerns, can come back to it later

Overflow 3

overflow-clip-margin + border-radius continuity adjustment
  github: https://github.com/w3c/csswg-drafts/issues/5896

  fantasai: The border radius applies to the border edge but it affects
            the padding content edges. Are you offsetting from the
            shape of the offsetting box, or against the border edge?
  fantasai: The border radius should not be affected by
  florian: The question is how these should interact
  florian: There's a formula for rounding, it will give different
           results depending on how you apply it
  florian: Maybe we just need to spec what's implemented so far?
  Rossen: We're at time
  chrishtr: Sounds like we should go back to issue
  [note: smfr asked for pictures also]
Received on Wednesday, 23 June 2021 22:54:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:18 UTC