- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 15 Dec 2022 18:43:18 -0500
- 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 Grid
--------
- The group will work on the issues raised with the editor's draft
for Masonry Layout before moving forward to FPWD (Issue #8195:
FPWD for Masonry Layout)
Resize Observer
---------------
- There are several open questions on issue #7808 (Firing
observations on insert/remove when rendered size is (0, 0)) that
need to be answered to reach resolution. Please engage in the
issue so that the topic can move forward.
- RESOLVED: We will use an empty array when there are no fragments
(Issue #7734: What should the fragment-aware behavior be
when there are no fragments?)
- Issue #7734 will stay open while discussion continues on handling
non-atomic inlines.
- RESOLVED: If internal parts of an svg are sliced we will return
size before slicing (Issue #7736: Fragment-aware
behavior for SVG?)
CSS Transitions
---------------
- RESOLVED: If a discretely animatable property is listed in a
transition it will. By default the all keyword will not
transition (Issue #4441: Start transitions on discrete
animation types)
- A note will be added to the spec that we are considering a
discrete keyword and ask authors for use cases to support an
addition.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Dec/0009.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Paul Grenier
Chris Harrelson
Daniel Holbert
Brad Kemper
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Peter Linss
Alison Maher
Jen Simmons
Miriam Suzanne
Alan Stearns
Bramus Van Damme
Chair: astearns
Scribe: bramus
CSS Grid
========
FPWD for Masonry Layout
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/8195
jensimmons: Created CSS Nesting survey doc
jensimmons: PTAL
https://docs.google.com/document/d/1oGk4wqKhj7E8m57PqVgdKZwdCSQLpjJWATmhYuHqYNE/edit#
jensimmons: Feedback in docs itself is fine
jensimmons: We are interested in moving spec forward
jensimmons: Issue to revive conversation. Thanks iank with thoughts
astearns: My assumption is that we should start engaging on the
brought up issues
<chrishtr> +1 to resolving those issue before fpwd
astearns: After that we can come back to publishing FPWD or not
astearns: open to suggestions
jensimmons: I don't think we have suggestions, but there was lots of
talk going on when firefox was working on it.
astearns: I assume you will also find new issues a your engineering
team is working it. Great to see engagement on this as its
a highly requested feature
jensimmons: Work is happening now, not in Safari TP yet but that is
the next step
astearns: Call to all to take a look at the issues
Resize Observer
===============
Firing observations on insert/remove when rendered size is (0, 0)
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7808
vmpstr: We recently resolved to set … to -1 so resize observer would
fire when size is 0,0
vmpstr: I think that may break some of the spec because once it
fires and you then remove and read the element, the last
reported size will now be 0,0 and the reinsertion wont fire
again which is not what we expect
vmpstr: We expect the process to be consistent. Have a proposal to
have a nullable last reported size as opposed to -1,-1
vmpstr: when removed it would be null
vmpstr: I think oriol listed all cases to consider
oriol: Best to go over issues in list
oriol: 1st question listed in issue at
https://github.com/w3c/csswg-drafts/issues/7808#issuecomment-1263694781
– should we add a notification here?
astearns: Maybe take the list back to the issue? unless vpmstr has a
summary?
vpmstr: No strong opinion. most things listed should have a
notification. ok with taking back to issue
astearns: Let's do that
astearns: Once we have answer to all issues we can bring a proposed
resolution to the agenda
oriol: Call for people to reply in issue, its been open for a while
astearns: Yes, please record opinions in our issues
What should the fragment-aware behavior be when there are no fragments?
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7734
oriol: We had resolution in the past that resize observer should
expose size of all fragments, which is exposes as an array by
the API. Spec is only populating single item in array (1st
fragment)
oriol: What should happen when el has no fragments? Do we keep 0,0
as the single entry or do we want an empty array?
oriol: Empty array makes more sense but there is a compat argument
there because there are scripts out there at assume the entry
is there
oriol: On the other hand if there is no fragment the size is 0x0
then the previous behavior was that the callback was not
called anyway.
oriol: So a change might not affect existing behavior that much
oriol: Can we risk with empty array or should we go with safe bet of
1 entry in array?
<fantasai> I think the correct thing would be a zero-sized array
<TabAtkins> Empty array sounds good to me.
<fantasai> If we can get away with it, let's do that
emilio: I think we are probably gonna have to have no item but maybe
keep existing behavior and call it a day.
emilio: Fine with empty. If compat issue then try the other
dbaron: I have mixed feelings about this
dbaron: In one sense it seems like it is the right thing and
encourages people to know there are fragments
dbaron: Are people going to iterate over fragments?
dbaron: Having an array increases the risk devs can do wrong
oriol: Array we have right now, changing it is not web compatible
I'm sure
oriol: Changing from arrays to something else that is
oriol: People assume it is an array
dbaron: I agree with you there
dbaron: I am worried that an empty array - even though it increases
awareness - will also lead to a lot more JS errors
dbaron: including future ones
<fantasai> I think it's reasonable. This is querying things that
*don't have a box*
<fantasai> Why would you query the size/position of things that
don't have a box in the first place? Most people won't
astearns: Rough consensus that empty array is correct thing to do
astearns: fear that it leads to errors, but we can try it
astearns: and if there is a webcompat issues can try the other thing
dbaron: I'm fine with that, taking webcompat into account and
listening to devs
astearns: Devs who want to process all can do the right thing
emilio: I think it is a useful thing. if we can, we should go with
empty
astearns: Proposed resolution to we will use an empty array when
there are no fragments
oriol: Also the case of inline elements
oriol: Should we treat this case of having no fragments or
fragments-size-0?
astearns: Let's resolve on simpler case first
astearns: Objections?
RESOLVED: We will use an empty array when there are no fragments
astearns: what about other case?
astearns: (non-atomic inlines)
<fantasai> We do have fragments in that case, should we return an
array of those?
astearns: They have a size of 0, so we would be returning an array
of 0-size fragments
astearns: oriol?
oriol: No strong opinion
oriol: We are special casing inline elements and ignoring their size
oriol: seems arbitrary
oriol: Saying no fragments seems better?
oriol: Other option we could try to stop ignoring the size of the
inline fragments
oriol: not sure if compat issues
oriol: people have asked before to know the size of inline elements
<fantasai> Returning an array of 0,0 fragments is not great. An
array of the actual size of the fragments would make
sense, though
astearns: For purpose of this issue, we can return an empty array
only if there are non-atomic inlines. Should raise issue
for other case. Currently we don't have useful info for
inline boxes
astearns: Seems like it could be useful to do something else for
inlines
<fantasai> Since we're discussing this now, do we want to consider a
resolution to just return an array of actual sizes?
<fantasai> If anyone has a concern with that, then we can open issue
and return to it
astearns: Proposed resolution: given the state of inline box
handling in current spec, since we have nothing useful to
give the developers, we will give them empty array
astearns: Have separate issue for things fantasai just raised
astearns: Proposed resolution: return empty array for inlines but
also raise issue for returning better issue
<oriol> The issue is https://github.com/w3c/csswg-drafts/issues/6358
fantasai: If we are ready to decide we should do instead of
postponing
fantasai: I would say to leave open and not resolve
astearns: Can you open issue for this oriol?
oriol: Link already pasted in IRC
astearns: Leave thing for inlines open
Fragment-aware behavior for SVG?
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7736
oriol: This about internal svg elements. They do not generate
…-boxes, the generate svgboxes
oriol: spec handles them specially and says their size should be the
bounding box
oriol: Question is: what happens if svg is fragmented? Then we have
different sizes in different places. Some of the internal
elements are sliced. Should we report size before slicing or
something different?
oriol: Leaning to size before slicing
oriol: The svg does not know it is fragmented
<emilio> +1
oriol: Maybe someone with more expertise has more info/details?
astearns: So we say we handle svg and img in the same way when
things get sliced?
oriol: Yes [missed] they don't not follow css rules but do svg
behaviors
oriol: Maybe we should just use the concept in svg and report a
single fragment/size
astearns: Opinions?
astearns: Proposed resolution: If an svg or its internal parts are
sliced we will return the size before slicing
oriol: Just for the internal parts; the outer SVG box should be
treated same as img and return its slices
dbaron: Wondering if there should be a difference between an svg doc
vs an outer svg element that gets sliced
dbaron: If it's a doc it should behave as if it is not sliced
astearns: Reason for different behavior?
dbaron: Not specifically.
dbaron: Just that if we were to expose the slicing, I think it
wouldn't make sense to do so for something that's its own
document but is sliced by a containing document
astearns: Updated proposed resolution: if internal parts of an svg
are sliced we will return size before slicing
astearns: Objections?
RESOLVED: If internal parts of an svg are sliced we will return size
before slicing
astearns: thanks oriol
CSS Transitions
===============
Start transitions on discrete animation types
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4441
flackr: In current spec we explicitly don't transition discrete
animations types; we skip
flackr: With resolution to animate display it would be useful for
devs to transition discrete properties
flackr: Example in linked issue
flackr: Proposal is that we allow transitioning discrete properties
but to preserve compat the all keyword would only match
animatable types
flackr: only if dev lists explicitly lists a discrete property it
would transition
smfr: … timing function? Steps timing to control when the value
flips?
flackr: Sure you can
flackr: step and step-start
smfr: Is there [missed] … the animation? wondering if timing
function >.5 that is where discrete things flip
flackr: My proposal is not to do something special here
flackr: means that you can use any fn that crosses .5 threshold
<dbaron> You can also use a different transition-delay for the
discrete property if you want to.
smfr: Trying to understand implications
flackr: All would only include animatable props
smfr: Mechanism for keyframes?
flackr: Already the case. Not building any new animation behavior
here
smfr: Haven't quite got in my head yet. Is there a difference
between properties that animate discretely and those not at
all?
flackr: Yes. You can't animate animation-name for example
smfr: What about display?
flackr: we resolved on display last week
<fantasai> well, we resolved to draft such a proposal into the
css-display-4 draft
smfr: Doesn't this already work by virtue of .5 behavior?
flackr: There is line in spec that limits to only animatable and not
discrete
tabatkins: You can animate a discrete property but not transition one
flackr: With web animtions API (waapi), devs can listen to
transitionstart
flackr: they could use this to enable transitions we do not
support yet
astearns: Easier access
flackr: Possible to access. before no transitionstart
(= customization point)
plinss: Some properties are discrete because they are difficult to
animate
plinss: If an engine figures out how to make a discrete property
animate: is that allowed and would it then be treated as
normal animated property?
<fantasai> plinss++
flackr: Yes and yes
flackr: and would then be picked by up by `transition: all`
plinss: Can we detect this?
fantasai: Example: animate between 2 background imgs-
fantasai: if author transitions with a particular easing curve
assuming discrete
fantasai: what would happen if it became animatable? compat
problems? might be fine
flackr: Cases for waapi and css animations. They don't have a
mechanism to know when the become animatable
flackr: You could use this to feature detect if property is discrete
or not
plinss: We may want to consider an `@supports` for this
astearns: Yes
astearns: Do we add ability to tell something is discrete or
animatable?
masonf: Point out that there is an optional part 2 to add a new
keyword
astearns: Lets discuss after
fantasai: Proposal is that you explicitly list a property that is
discrete it will transition. When you provide an easing
curve it will flip at 50%?
flackr: Yes. Latter part already implied by how animations work
fantasai: Seems reasonable
astearns: Proposed resolution: if a discretely animatable property
is listed in a transition it will. by default the all
keyword will not transition
flackr: anders said it better there, but effect is the same
RESOLVED: If a discretely animatable property is listed in a
transition it will. By default the all keyword will not
transition
astearns: 2nd part: can we have all opt in to this behavior?
flackr: 2 options: other type of all keyword that is actually all,
or a keyword to target discrete
fantasai: I think if there is no demand we should not add it. Idea
to add discrete makes more sense.
fantasai: you can then use it to apply a certain curve to only the
discrete ones
<flackr> E.g. transition: all 1s ease, discrete step-end 1s;
flackr: example in irc is something devs might do
masonf: +1 on discrete keyword
astearns: I can see theoretical value in this
astearns: but I might want to see actual real transitions with
particular groups of discrete properties that would be
solved by this keyword before we resolve to add it
dholbert: Concern where prop changes from discrete to not discrete
dholbert: could be problem for minor content
dholbert: also curious for use cases
flackr: First part already problem because all matches [missed]
flackr: Second part less defined right now
astearns: You can do customization now by having discrete property
explicitly listed, separately from all
flackr: Yes
flackr: Do see value in discrete keyword
flackr: but also fine with exploring use cases first
astearns: What about a note in the spec that we are considering this
keyword and ask authors for use cases (or if we come up
with some)?
<masonf> +1
flackr: Sure
astearns: That's it; we are at time
Received on Thursday, 15 December 2022 23:43:58 UTC