- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Jun 2021 18:53:47 -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 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
margins)
CSS Overflow 3
--------------
- Issue #5896 (overflow-clip-margin + border-radius continuity
adjustment) needs spec text and/or images added to better
understand the examples.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0018.html
Present:
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
Regrets:
Javier Fernandez
Greg Whitworth
Scribe: fantasai
Scribe's Scribe: emeyer
Scribing
========
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?
[silence]
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
doable.
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
devs
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
invalid
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
case?
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
containment
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
range
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
solution
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
change.
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
equally
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
it.
dbaron: Ok, seemed a little weird to only make the change in this
place
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
tracks
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
overflow-clip-margin.
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