- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 May 2023 19:02:46 -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.
=========================================
Upcoming F2F
------------
- The preference from current survey respondents was for a F2F on
the west coast hosted by Apple the week of July 17th. Unless
anyone reaches out either on the private list or directly to
Rossen by next week's telecon, that will be the final decision.
Scroll Animations
-----------------
- RESOLVED: We will accept this PR and close the issue (Issue #8694:
Handling changed size/position in current frame)
- RESOLVED: Return positive infinity for time values after the
range, and negative infinity for times coinciding with
and before (Issue #8114: Clarifying behavior of
getCurrentTime(rangeName))
CSS Overflow
------------
- RESOLVED: Explicitly define that overflow:clip does clip
scrollable overflow (Issue #8607: What clips scrollable
overflow?)
- RESOLVED: 'clip' and 'clip-path' do not clip scrollable overflow
(Issue #8607)
CSS UI
------
- The group reviewed the proposal to add
min-intrinsic-sizing:from-textarea and
min-intrinsic-sizing:from-input for the sizing use case outlined
in issue #7542 (Allow <textarea> to be sized by contents). The
group discussed if this should be two properties or just one and
generally landed on needing two properties. There was a request
to have a week to discuss further so this will be on next week's
agenda.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0002.html
Present:
Rossen Atanassov
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Ian Kilpatrick
Vladimir Levin
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Tab Atkins
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Jonathan Kew
Chris Lilley
Bramus Van Damme
Lea Verou
Chair: astearns
Scribe: dael
Agenda Setting
==============
astearns: Looks like we're getting enough of a quorum
astearns: Does anyone have adjustments to the agenda? We're going to
skip item 4 in favor of having emilio on the call
chrishtr: If anyone has feedback on item 4 who is on the call it
would be helpful to take into account
iank: If we get to item 7 there's an issue that needs to be
discussed at the same time
astearns: chrishtr are you asking people to comment on the issue?
chrishtr: Yes, please review what Vlad summarized and provide
feedback. If anyone has live concern they think would be
useful please say, but most useful is feedback on issue
astearns: We'll call for anyone that wants to spend a bit of time
when we get to it
[un-minuted announcement]
Upcoming F2F
============
Rossen: We did get a few replies as of last week based on the
questions fantasai and I double asked in the private list
Rossen: Didn't get as many replies as compared to previous. Current
tally for what we asked is based on a little less than 10
responses. Suggests most likely location is going to be West
Coast with corporate hosting of Apple
Rossen: Most people want the one in Mexico that's hard to resist
based on the pictures :)
Rossen: That's where we're at today. If you have strong feelings
please reply to use either on the private channel or
directly to me. Ideally this is something we can resolve by
next week's call so Tess and company has enough time to book
rooms
fantasai: If you want to respond privately, respond to me or Rossen
jensimmons: When is the meeting?
Rossen: Week of July 17
jensimmons: Thank you
Rossen: Sooner we decide the higher chances we have that myself or
astearns will make it. Calendars are filling up for most
folks. I know for myself I need to know in advance
astearns: And getting largest number of participants able to
participate. The earlier we can get it set the better
Rossen: Let me be more decisive. As of right now feedback is West
Coast and hosted by Apple. If you have strong reasons to
outweigh this and support to sponsor please let us know. If
we don't hear anything by next call we'll decide west coast
F2F week of July 17 hosted by Apple
astearns: Alright, we'll have this decided by next week. Please send
any input to Rossen and fantasai
Scroll Animations
=================
Handling changed size/position in current frame
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8694
flackr: With view timelines we have named ranges that are related to
the position and size of their subject within their scroller
flackr: This means that if the position or size changes the named
range can change which changes animation progress and visual
output
flackr: Per spec no update if the size or position changes.
Proposing we detect when this happens. It's similar to when
we detect new timelines. It would be if it moves or changes
size and we trigger a new layout cycle
flackr: I have a spec PR to make the change. Main point is condition
I noted and that it does it after resize observer and resize
observer might change which we would want to respond to
flackr: Proposal is accept the PR that adds a change in position or
size of subject as a condition to do a layout cycle
astearns: You have people commenting on issue and PR but not calling
out changes
flackr: Discussed with iank who I think is on call
astearns: Any concerns or questions?
astearns: Objections to accept the PR?
vmpstr: What are implications to updating timeline. Can sizes
change? Asking because doing this after resize observer
means if updating can change size the size observation has
to be on next frame
flackr: Size can change
flackr: It's generally frowned upon to animate size or layout and
expect frame perfect
flackr: Trade off if we run before resize observer where we wouldn't
guarantee the timeline is correct or after
astearns: Is that enough of an answer?
vmpstr: I think that's fine. Just have an issue later on the agenda
that's similar for non-timelines
astearns: Anything else on this issue?
astearns: Proposal: We will accept this PR and close the issue
astearns: Objections?
RESOLVED: We will accept this PR and close the issue
Clarifying behavior of getCurrentTime(rangeName)
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8114
astearns: Follow up about what happens when start = end
flackr: I believe fantasai added to agenda. Clarification is how to
handle start time = end time
flackr: I've prop never return 0 for current time with assumption
dev is plugging this into an animation and if they plug - or
+ infinity they guarantee the animation is before or after
phase and that's not same as the effect they're copying
time of
fantasai: I don't have much of an opinion. If it's not 0, then what
is it? Can we resolve on what we want it to be?
flackr: It's what you said in your second option.
flackr: [reads]
<astearns> Return positive infinity for time values after the range,
and negative infinity for times coinciding with and
before.
fantasai: So negative infinity for coinciding? I don't know I
thought through this.
flackr: Yes, that is correct
fantasai: I know I suggested negative infinity, but I don't
remember why
<fantasai> and maybe I got it backwards when typing
astearns: Only difference between your options is what we do with
time values coinciding with a single point in the range
fantasai: Right, if you land on that point should it be before or
after start
flackr: I believe I compared this to a running animation with 0
duration. Recollection is your statement matched the
animation behavior
fantasai: If you think it's right, I'm fine. I just want to make sure
astearns: My question- is this just an edge case we're filling a
rational answer in for or is this something devs are
expected to handle?
flackr: My opinion this is a bit of an edge case and we're trying to
fill in value that would give the same effect as an
animation with that range
astearns: Other comments on this?
astearns: Proposal: Return positive infinity for time values after
the range, and negative infinity for times coinciding with
and before
astearns: Objections?
RESOLVED: Return positive infinity for time values after the range,
and negative infinity for times coinciding with and before
astearns: As fantasai said, seems a bit weird but this is a good...
flackr: I did paste a demo on March 10 demonstrating. So I'm not
misremembering
astearns: If you have time fantasai or anyone else please take a bit
of time considering implications in case we want to revisit
CSS Contain
===========
content-visibility: auto visibility check timing needs details
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8542#issuecomment-1515216159
astearns: Anyone on the call want to put something on the record to
help with discussion next week?
vmpstr: I'm happy to introduce the issue. Not asking for resolution
because emilio isn't here
astearns: At the beginning of call chrishtr asked for people to take
a look and speak up now or add comments
astearns: We'll come back next week
CSS Counter Styles
==================
cjk-earthly-branch and cjk-heavenly-stem
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8596
astearns: Does anyone know what needs discussing?
CSS Overflow
============
What clips scrollable overflow?
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8607
fantasai: We are trying to figure out how we're defining scrollable
overflow. clip-path seems to not clip scrollable overflow.
clip has no interop. What behavior do we want here
fantasai: smfr said clip-path should be like a mask. iank suggested
clip and clip-path should behave the same
florian: So this is not visually clipping, but clipping the effect
on scrollability
iank: Yes. And I somewhat agree with smfr as well
fantasai: Proposal: Overflow-clip clips scrollable overflow.
clip-path and clip do not clip scrollable overflow; they
just clip painting
astearns: A bit of a concern that if we define clip to have this
behavior it may not actually come to be. I don't think
browser implementors won't be all that concerned about
interop on clip
iank: webkit and blink are consistent with clip. I think Gecko is
only odd one out
astearns: Other comments?
astearns: There were results in test case. What does spec say?
fantasai: I think it's not defined for clip path
florian: overflow:clip not an objection but feeling a bit odd. If
I'm not misremembering in terms of floats poking out
overflow:clip lets them do that. So overflow:clip does clip
geometry for scrollable and not for floats. Maybe a bit
weird but I guess okay
astearns: Sounds like a candidate for a test case
astearns: Is it the case that overflow:clip is specced to say it
clips scrollable overflow?
astearns: Do we need two resolutions, one for overflow:clip and one
for clip and clip path? Or is overflow:clip handled?
florian: In the spec overflow:clip is spec to say UI is not supposed
to provide scrolling interface. At time written probably
meant for element, not its parents. Maybe needs
clarifications
astearns: Proposal 1: Explicitly define that overflow:clip does clip
scrollable overflow
astearns: According to test case we're speccing reality
chrishtr: In all browsers, right?
iank: Correct
astearns: Objections?
<chrishtr> sgtm
RESOLVED: Explicitly define that overflow:clip does clip scrollable
overflow
chrishtr: According to issue css-clip does not have interop
iank: Webkit and Blink are the same. only Gecko clips scrollable
overflow
chrishtr: On WwebKit and Blink neither clip nor clip-path effects
scrollable overflow
iank: Right. But only clip in Gecko
chrishtr: Proposal is match WwebKit and Blink?
iank: Yes
chrishtr: Makes sense
dholbert: Makes sense to me too. Digging into code to understand why
they're different but not sure. Seems reasonable
iank: Clip is such an old property I wouldn't be surprised if it's
old behavior
astearns: Other comments?
astearns: Proposal: We specify that clip and clip-path do not clip
scrollable overflow
chrishtr: What about masking? Has anyone checked that?
astearns: I'm guessing we have not
chrishtr: Pretty sure it does the same as clip-path in blink. I
think we should align them all together
astearns: Makes sense to me
dholbert: Might be good to do testing on that before we resolve
astearns: Let's resolve on clip and clip-path for now and then let's
take a look at masking. Let's have that be a separate
issue.
chrishtr: Okay
astearns: Proposal: clip and clip-path do not clip scrollable
overflow
astearns: Objections?
RESOLVED: clip and clip-path do not clip scrollable overflow
ACTION chrishtr check out if masking has the same issue as clip and
open an issue if necessary
iank: I'd be surprised if it doesn't behave correctly
astearns: But the spec may need words
CSS-UI
======
Allow <textarea> to be sized by contents
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1476706343
iank: The goal is to allow for textarea to grow number of content
and grow in inline dimension with content
iank: Previously discussed to achieve with min-intrinsic-sizing
property. Seems like a reasonable idea
iank: One way would be add 2 new values, one for textarea and one
for input
iank: you would say min-intrinsic-sizing and it would switch to
being sized based on the area
iank: Any thoughts or concerns?
astearns: Reason you are using the element names instead of
something more generic like from-content?
iank: They sort of work in different axes. textarea is in block and
inputs are intrinsic for block dimension. If someone sets a
reset it's not clear you want both so probably need individual
control
fantasai: I had the same question about why 2-axes. If we're
splitting the axes we should maybe consider axis. Is it
split on axis or on type of input?
fantasai: And then is this going to change the way auto works?
iank: What do you mean by change how auto works?
fantasai: When the input as an auto-width it currently sizes to a
magic number
<astearns> from-inline-content-size/from-block-content-size (for
those who like to type a lot)
iank: full width for textarea we haven't heard demand to grow in
inline size
iank: Is theoretically possible but I would prefer to keep. If we
did it for both axes for textarea it would be weird behavior
when they're in something like flexbox. Current magic is
simple and looks at columns
iank: Prefer to keep textarea just for block. If we split
min-intrinsic-sizing that's the other issue if we want to
add it.
vmpstr: I just wanted to ask for input if I spec
min-intrinsic-size:from-input would the input shrink below
default size?
iank: Correct. Expected webdev will put a min-width on that element
miriam: I like this. For me your argument it does one thing on
textarea and another on input seems like an argument for one
value. Seems weird to align the right value to the right
element
miriam: Why do I need to say textarea as the target and the value
rather than getting the right behavior
iank: Related to next issue which is splitting axes for
min-intrinsic-sizing. Might be better to talk about that
first. If we split that property in 2 than from-input would
only apply to one.
iank: Could have a from-content but somewhat find that more
difficult to understand. I think this is less magic. content
is an overloaded word
iank: I like the explicitness of from-input and from-textarea
astearns: I like solution of splitting min-intrinsic-size as a
solution to the reset issue
iank: I would still come back to some content would be confusing
iank: It is possible; we could have intrinsic sized text areas in
inline axis. I don't think it's desirable
astearns: That's not part of current proposal, right?
iank: Correct. Future thing to keep in mind
fantasai: I think this is workable. From author PoV I think the
original proposal we had discussed to use min- and
max-content feels more understandable. I'd prefer that if
we can
iank: I don't think we can. Flexboxes are everywhere and it would
change the auto min-size. We'd need an explicit switch for
switching the algorithm similar to what min-intrinsic-size
does for scrolling. We won't be able to shift that
fantasai: What's the case it changes behavior?
iank: A few. People use min-content/max-content on things already.
Would change any input elements with this already. Other thing
is it would change flexbox. Flexbox uses min-content size
directly and that would change
iank: I think emilio tried to implement. I don't think we can
shift it
fantasai: Make sense to put keywords on width and height? Seems like
a pretty indirect method.
iank: At the moment it's switching the algorithm we use to determine
content size. All input elements and textarea have a special
metric and this would default to the default. I think
min-intrinsic-sizing is a good place to do this since the min
size for scrollable is there also
fantasai: I think I'd like to talk this over with TabAtkins. But I
agree we need to solve the use case
iank: As long as it's not...been trying to come up with a proposal
that satisfies everyone's desire for a while. I think this is
the best so far
fantasai: min-intrinsic-sizing property is about min and not
intrinsic sizing. Or is this a new proposal? We have an
intrinsic-sizing property. Is this separate?
iank: This is the original property
fantasai: That's about how we find the min intrinsic size, but not
about something like max intrinsic size.
iank: Weird thing about inputs is they're the same thing
fantasai: Yeah, some elements don't have difference between min and
max. A div with one word has equal min and max.
iank: Input elements that's also true
fantasai: Right, because they have a fixed length intrinsic size.
fantasai: We're trying to allow elements to be resized from their
content. For a text area in block axis min and max will be
the same. Concept does exist for difference if you want it
fantasai: Would make sense if you tried to size as if they're a
regular element you get that behavior. And you can't here
because it's only giving one size.
fantasai: Probably solves use case, but I think what makes sense is
to make this behave more like a replaced element
iank: Specifically for input case you cannot get an input to wrap
multiple lines
fantasai: Yes, they're no-wrap
iank: You can't get min vs max for these elements today
fantasai: But if we wanted to do something on inline axis for
textarea there would be possible 2 sizes
iank: But no one is asking for that
fantasai: I agree. I think if we can try and get everything to fit
in that's a good directly
fantasai: I think min-intrinsic-size...what min-width:auto resolves
to is a little different from what is the intrinsic size.
fantasai: I would rather try and talk this over with TabAtkins
astearns: Can you commit to that over the next week?
fantasai: If TabAtkins is available tomorrow or Friday, yeah.
[discussion on TabAtkins availability]
astearns: iank okay with you if we put this and 8620 on the agenda
next week?
iank: Sure
astearns: Next week we'll start with content-visibility and then
this two issues
astearns: I think we're out of time. Thanks everybody for calling in.
Received on Thursday, 4 May 2023 23:03:20 UTC