- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 4 Mar 2023 14:29:47 -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.
=========================================
Motion Path
-----------
- The group was positive about the simplification proposed in FXTF
Issue #363 (The description of contain flag in ray() function).
They would like to make sure that folks who are expert in watch
design are involved and then bring the issue back when the spec
text is written.
CSS Selectors
-------------
- RESOLVED: Accept restrictions in
https://github.com/w3c/csswg-drafts/issues/8174#issuecomment-1431243750
with exception of :is and :where (Issue #8174: Add
pseudo-class to establish before-change style for
css-transitions on new elements)
CSS Overflow
------------
- RESOLVED: Adopt this feature as overflow-bikeshed [name is to be
decided later] (Issue #8361: Add method to prevent
elements from contributing to scrollable overflow)
CSS Inline
----------
- RESOLVED: Accept this behavior for baseline-source:first|last
(Issue #8214: baseline-source:first and overflow:hidden
inline-boxes)
- RESOLVED: leading-trim: normal; >> text-box-trim: none; AND
text-edge >> text-box-edge (Issue #8067: Naming Stuff)
CSS Position
------------
- On the call there was a possible solution raised for issue #8286
(Making a stickypos in a scroller also see the viewport edges)
to use overflow:clip so it's explicitly not scrollable. Initial
reaction was that that could work, but discussion will return to
github to investigate further.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Mar/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Elika Etemad
Robert Flack
Mason Freed
Daniel Holbert
Dael Jackson
Ian Kilpatrick
Peter Linss
Cassondra Roberts
Jen Simmons
Alan Stearns
Regrets:
Adam Argyle
Yehonatan Daniv
Jonathan Kew
David Leininger
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Chair: Rossen
Scribe: dael
Motion Path
============
The description of contain flag in ray() function
-------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/363
TabAtkins: Unless people agree with me, I don't expect resolution
but want eyes. Motion is in interop 2023 and have issues
TabAtkins: Problem is the ray function was added to make it easy to
put things around a circle. Wanted easy way to position
around the edge of a watch face.
TabAtkins: Have origin out to some distance. Element is along a
0-100% path. 100% is edge of the watch face but you want
to pull it in and not have the center at 100%.
TabAtkins: We had the contain flag which would shorten the ray for
that. Definition was pretty complicated and even ignoring
the math I think it's not good based on complications
TabAtkins: Have suggestion to simplify at end that would have little
change in practice, but better behavior in general.
Better animation and more predictable.
TabAtkins: If anyone has opinions would like them in thread. If I
don't hear for a while I'll add to spec
TabAtkins: Summary is previously took rectangle of element and
pulled in until it's in circle defined by what the ray
projects into. Figuring out how much to pull a square
into the circle is not trivial. The angle mattered which
made positioning weird.
TabAtkins: Now is treat element like a circle based on larger
dimension. Circle to circle make is way easier
TabAtkins: Don't need resolution right now, but want attention.
Rossen: Thoughts or feedback?
fantasai: This was supposed to also handle non-circular watches. Is
that still doing that or does it only work for circles?
TabAtkins: Should generally do it. Especially if element you're
trying to position is square should work approx same.
Rectangle will be a bit different. Old if you're
positioning rectangle to rectangle you would get right at
the edge. But that's not the original thing it was trying
to solve. Mine gives you good on circle and okay on
rectangle
fantasai: Would be good to get people that do watch stuff to take a
look. I'll look also
Rossen: Feedback here is general temperature is positive to proceed
forward. I guess that's what you're looking for.
fantasai: I think we should bring it back once we have spec text to
resolve on. People should review with examples and stuff
Selectors 4
===========
Add pseudo-class to establish before-change style for css-transitions
on new elements
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8174
[Restrictions List:
Parses, but always fail matching if not in subject
Parses, but always fail matching inside matches-any selectors like
:is(), :where(), :has(), :not().
Allowed after tree-abiding pseudo elements (::before, ::after,
::marker, ::placeholder, ::file-selector-button)
Allowed after ::part()
Allowed inside ::slotted()
Allowed inside :host()
Parse error after other pseudo elements
]
chrishtr: Allowing transition to present first frame in cases where
it was not present. Seemed like positive feedback but
discussion didn't conclude about if there should be
restrictions to make it performant enough
chrishtr: Rune did a prototype that he added a comment on. Has a
list of 8 inclusions/exclusions.
TabAtkins: Subject means the part of the selector getting styled
chrishtr: Makes sense. [reads list]. The prototype works as expected
for us. Concerns with definition?
fantasai: No concerns, but want dbaron and emilio to be happy with
definitions
flackr: I know last time we discussed I believe they both were on
and didn't have immediate concerns. I believe subject
restriction was from emilio to make it performant
flackr: Not to say we can't defer, but I believe they have looked
chrishtr: That's my recollection as well. If no other concerns today
perhaps we can resolve and then we can reopen if they do
have a concern
chrishtr: Would that be okay?
<fantasai> wfm
Rossen: Sounds okay
TabAtkins: The list of conditions is good. Only concern is
restriction on :is/:where/structural pseudos. :not makes
sense, but :is and :where in all cases seems excessive.
As noted in thread would restrict some nesting and
doesn't give you anything
TabAtkins: So long as all branches of :is/:where have the initial
pseudo class it should work. You can re-write to move the
initial out but in nesting that's not plausible
TabAtkins: If we can relax that bit I'd be happy.
chrishtr: Do you mean every branch as nesting?
TabAtkins: If every comma separated selector has the initial pseudo
it's valid just as if you put it outside the :is
fantasai: What does that have with nesting?
TabAtkins: Not technically using :is it's described as behaving
similar with regards to parent selector
fantasai: but this can be an exception
TabAtkins: No reason for exception because it's not the nesting but
that it's in every branch of the selector
<TabAtkins> .foo:is(.a:initial, .b:initial) should be valid, along
the .foo:initial:is(.a, .b) which is currently valid
fantasai: Feel like that makes it more confusing. Obvious it's valid
when it's outside and valid when inside. Saying has to be
in all 3 but not 2 gets complicated
TabAtkins: [missed] in all branches
TabAtkins: The rule is it has to be on the subject in all branches.
It's an extension of the existing rule. If it's on all
branches it can go into and is/where
fantasai: Defer to implementors. I think it's a little confusing
TabAtkins: Unhappy with behavioral differences for :is/:where when
there isn't a reason
chrishtr: Makes sense to me
<TabAtkins> but .foo:is(.a:initial, .b) would make the initial not
match
Rossen: Augment proposal to exclude is and where from the second
list item? Or all 4?
TabAtkins: :has and :not are not selecting the subject so they are
fine to exclude
TabAtkins: :is/:where are allowed if on the subject in every
argument would need to be explicit
Rossen: Proposal: accept list of restrictions in
https://github.com/w3c/csswg-drafts/issues/8174#issuecomment-1431243750
as proposed by Rune excluding :is and :where. Draw attention
to emilio and dbaron to review
Rossen: Draw attention to Rune to make sure it's implementable with
the change to :is/:where
TabAtkins: If there's implementation complexity I'm fine restricting
Rossen: Accept restrictions in
https://github.com/w3c/csswg-drafts/issues/8174#issuecomment-1431243750
with exception if :is and :where
Rossen: Objections?
RESOLVED: Accept restrictions in
https://github.com/w3c/csswg-drafts/issues/8174#issuecomment-1431243750
with exception of :is and :where
ACTION: chrishtr get feedback from dbaron emilio and Rune
CSS Overflow
============
Add method to prevent elements from contributing to scrollable overflow
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8361
<fantasai> See also leaverou's examples in
https://github.com/w3c/csswg-drafts/issues/8400
TabAtkins: Happy to take it since raised by non-WG member and
leaverou is not available
TabAtkins: Request is some way of opting an element out of
contributing to ancestor scrollable overflow. Lots of
examples of places with decorative element that happens
to overflow and element a little bit. Overflow isn't
important. Stuff in viewport is important but you trigger
scrollbars
TabAtkins: Example from leaverou is the fork me banner on GH that's
at 45 deg angle and has a little corner poke out. Another
example is animating an element into the page it's
outside the page as it animates in, triggers scrollbars,
but once it's in place no scrollbars.
TabAtkins: Forcing an element to only contribute ink overflow. More
to discuss about using it in a safe fashion, but use case
is worth addressing and should explore in overflow 4
iank: Trivial for implementation, more or less what we do for
position:fixed already. Want to make sure this doesn't effect
the content-edge contribution to scrollable overflow. I don't
think that breaks any use cases
iank: If you have element in block flow at the end the end content
edge contributes to scrollable overflow, but when you rotate
the element wouldn't. Want to make sure of that. Otherwise,
this would be great
TabAtkins: More details on the case?
iank: Maybe grid is easier to explain. The content-edge we add the
end content edge; padding after content edge; as scrollable
overflow. To do that look at where children are or look at
grid itself. Grid, see last row and column, add end padding,
and that's part of scrollable overflow
iank: If we start excluding things from the content-edge calc it
gets tricky very quickly
TabAtkins: Do we currently pay attention to things like box shadow
for that calc?
fantasai: No because ink overflow
TabAtkins: Assume similar here
fantasai: I think iank is saying there are things not descendant
boxes that are for scrollable overflow and we shouldn't
change that?
iank: Correct. When calc overflow we factor in a bunch of things
like where the padding is. Don't want to effect that
calculation
fantasai: I agree and I don't think that's requested. Need to set on
the element containing the padding. You'd like to set on
an element whose ancestor is a scrollable
iank: A bit of a nuance because could say you shouldn't include me
where the content edge is but want the distinction
fantasai: I think if we add it's a property on an element you want
to exclude that says ignore me when calc scrollable
overflow
fantasai: Might want a distinction between ignore my box but pay
attention to my contents vs ignore me and all my contents.
I can imagine a rotated box with padding where you don't
care about corners but you do want the text scrollable
fantasai: Propose 3 values, one is normal, one is ignore my box, one
is ignore me and all my descendants
TabAtkins: Makes sense
iank: Want to check with authors on more complex. It sounds fine
<flackr> Sounds reasonable. Could allow setting the not ignored
property on a descendant for some of those descendant cases
Rossen: Clarification - assuming this is true for my immediate
scrollport ancestor and all of it's ancestors? Including
initial?
TabAtkins: Yep. Ideal is you mark the element as ink overflow so
it's the same as ink overflow in all scrollers
TabAtkins: iank, hypothetical: Animating element up from bottom to
visible. I have this marked on it. Do you think okay or
would it make scrollbars?
iank: If it's out of flow positioned behaves as you expect. If it's
in flow you would still consider end content edge
TabAtkins: That sounds good. We'll have to make sure we get that
because it's a little more nuanced, but I think it's
fine. Will need to word carefully.
iank: fwiw if we can come up with a reasonable syntax this is
trivial to impl
fantasai: Name is hard. overflow-skip?
TabAtkins: We can do names in the thread
Rossen: Overall sentiment is we want to resolve on adopting the
feature and figure out name as we go. Anything else to talk
about or resolve on this?
TabAtkins: That's all
Rossen: Objections on Adopt this feature as overflow-bikeshed
RESOLVED: Adopt this feature as overflow-bikeshed
CSS Inline
==========
baseline-source:first and overflow:hidden inline-boxes
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8214
iank: baseline-source longhand has 2 values which is what we do
already. It will behave css2 baseline. We also have
baseline-source:first and last
<TabAtkins> gonna go ahead and +1 Ian's suggestion for this issue,
it sounds good
iank: The definition...currently the thing that conflicts is when
you have overflow:hidden specified. We'll snap to end margin
edge. A lot of webdev dislike this behavior. If you add
overflow:hidden to hide visual effects you lose baseline
alignment. For baseline-source:first|last it would be good to
skip that behavior and use clamping like flexbox and grid
TabAtkins: Sounds great, I like it
iank: fwiw the baseline-source:auto needs to be tightened up a
little bit to capture some nuance
Rossen: Objections?
RESOLVED: Accept this behavior for baseline-source:first|last
Naming Stuff
------------
github: https://github.com/w3c/csswg-drafts/issues/8067
fantasai: This is a long discussion about naming stuff. May come
back for more naming. A number of properties in inline
spec that are not most understandable. I think that the
person who put this on agenda wanted leading-trim and
text-edge to be taken.
fantasai: text-box-sizing and text-box-trim have been discussed for
text-edge and leading-trim respectively. Also rename
initial values to normal
fantasai: I think it makes sense and we should go in this direction.
Not sure we'll end up where because some discussion about
splitting what is text-edge into two properties.
fantasai: text-edge -> text-box-sizing, leading-trim ->
text-box-trim and initial values are normal
fantasai: Though text-box-trim could be none
<astearns> +1 to removing ‘leading’ from the list of words we use
jensimmons: I think leading-trim initial is normal and text-edge
initial is leading. Makes a lot of sense to change that
jensimmons: text-box-trim is none because won't do any extra
trimming and then you change to trim
<fantasai> text-box-sizing: normal | other stuff
<fantasai> text-box-trim: none | other stuff
fantasai: Makes more sense. Going with ^
jensimmons: Wondering a bit if text-box-sizing makes the most sense
or make sense to text-box-edge. It's really about
finding top and bottom edge. Where will you trim to.
fantasai: And we have values for top and bottom independent, right?
jensimmons: I think you can use one value and it's used for both if
both in other property or you can list them separately
jensimmons: Are you saying making that two separate properties?
fantasai: No, separate discussion about text-edge. Does 2 things
currently, one is change how we measure an inline box to
see if it fits in the line-box. Right now include text +
half-leading and text-edge lets you cut that down.
fantasai: That's per line box. Effects how text is measured in a
paragraph
fantasai: leading-trim we say if you trim start or end and what's
top of first line box or bottom of last and that drills
down through descendants. In that case we say where we
trim to and we look at text-edge. Alan (from Apple) raised
a question about if we should have a separate property to
let you control that perhaps defaults to text-edge
fantasai: I think what you're proposing is an improvement, we should
take and realize we might come back
jensimmons: Hearing what you described makes me wonder having both
properties used. Edge when you say which edge and sizing
to change calc of box height. That makes sense to me
fantasai: Makes sense
jensimmons: text-box-sizing people like because they know
box-sizing. Pointing at lines is different than saying
border-box. I don't know what that means for a first
step.
jensimmons: Rename to text-box-trim and then text-box-edge for now?
Or do we call it sizing for now?
fantasai: Let's go with what you suggested and we can come back once
we dig into other issues
jensimmons: text-box-edge or text-box-sizing to start?
fantasai: I don't know. Could go either way
Rossen: If we start with text-box-edge given it lets you control the
2 edge separately that would be better because
text-box-sizing is similar to box-sizing and that applies to
the whole box. text-box-sizing suggests both would be
effected so prefer -edge
fantasai: Makes sense. And we could split into longhands eventually.
text-box-edge-start makes more sense
fantasai: Don't know we'll need it but good we could go to longhands
<jensimmons> leading-trim: normal; >> text-box-trim: none;
AND text-edge >> text-box-edge
jensimmons: Talking about this ^
jensimmons: Potential of text-box-sizing or breaking things out later
<tantek> +1 Rossen's reasoning on naming.
fantasai: Yeah
jensimmons: sgtm
Rossen: Feedback or objections?
fantasai: Going in the right direction. Not sure it's at the finish
line, but happy to make those edits
jensimmons: sgtm. We have an impl but behind a flag. the name
changes are important to get quickly so there won't be
old tutorials with wrong names
Rossen: Not hearing objections
RESOLVED: leading-trim: normal; >> text-box-trim: none; AND
text-edge >> text-box-edge
CSS Position
============
Making a stickypos in a scroller also see the viewport edges
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8286
TabAtkins: An issue for a good while is when people use stickypos by
default it sticks to viewport. Very useful. Stays on
screen
TabAtkins: If you have a scrollable ancestor this stops happening.
Stays in scrollport but no longer sticks to viewport. If
scrollport larger than screen you can scroll sticky thing
offscreen even though intended to be always visible
TabAtkins: Request is for some mechanism to make sure a stickypos
can see viewport edges even when it's not the closest
scroller. Could go further to allow arbitrary scroll
containers, but important things are nearest scrollport
and viewport
flackr: Commented on issue, think viewport is too special case. I
don't know if we have ability to have overflow:clip in one
position. That could be workable to make this compositable
so you can observe scroller scrolling you and not the one
clipping you
TabAtkins: I don't think that solves. In a scroller that can be
scrolled vertically. You have a big table and want head
to be sticky. Box of table is partially offscreen but you
want thread to be sticky. Genuinely scrollable access is
that thing you want to pay attention past
flackr: Concern is if we special-case viewport there's still a lot
of cases where doc can't use viewport
TabAtkins: Agree. Hits on issue viewport has magic we can't
reproduce. Talked in the past about being able to mark
something as root scroller. Perhaps it's a matter of we
should do that and it interacts well here
flackr: That would help
TabAtkins: I think you were a part of those discussion in the past,
but that was years ago
flackr: It certainly stalled.
fantasai: Other proposal in the issue was make it sticky to nearest
scroller in the relevant axis. If you have only horizontal
scroll something sticky in vertical axis sticks to next
scroller up
TabAtkins: I thought use case listed in root is that or by what
flackr mentioned
flackr: I think they are same. They could ignore nearest scroller if
it doesn't impact in that axis
fantasai: I feel like it's more flexible. Would it make sense?
flackr: Tricky bit is non-scrollable direction is treated as
overflow:hidden
fantasai: So can't be a scroll container
flackr: Could make non-scroll overflow:clip so it's explicitly not
scrollable
flackr: Haven't fully thought if that works
TabAtkins: I don't think anything wrong with that. Clipping in 1
axis is weird visual stuff, but not if scrollable in
other axis
TabAtkins: That might be it
flackr: Might be good in general to say something is clipped in one
axis
TabAtkins: I want to do investigation, but that's a plausible
approach
Rossen: TabAtkins you want to do that and bring it back?
TabAtkins: Sounds good
fantasai: I wasn't expecting a resolution, but good to have progress
Rossen: Thanks everyone for connecting. Reminder- take a look at
dates and times for mid-March virtual F2F
Received on Saturday, 4 March 2023 19:30:30 UTC