- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 3 Jun 2022 06:12:55 -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.
=========================================
CSSOM View
----------
- RESOLVED: Rename .isVisible to .isHidden and flipping default value
(Issue #7317: Rename Element.isVisible to
Element.isHidden?)
CSS Color
---------
- The group agreed with the spirit of the proposed approach for
issues 7302 (Resolving color-mix() / color-contrast()) & 6168
(What should the behavior of the CSS Color 5 color functions be
when passed currentcolor as <color>). Once the spec text is
clarified the group will resolve on the changes and then discuss
issue #7310 (Are these features ready to ship?)
Scroll Animations
-----------------
- RESOLVED: Close this with no change (Issue #7296: Support setting
start and end time on scroll timeline)
- RESOLVED: Remove phase from the animation timeline IDL and remove
the before and after timeline-phases (Issue #7240:
Rethinking timeline-phase)
- The proposal for issue #7044 (Entry/Exit Transitions for View
Timeline effects) is going in the right direction, but still
would be awkward for multiple animations. A separate call will be
set up for interested individuals to discuss further and come up
with a more refined proposal.
CSS Contain
-----------
- RESOLVED: Disallow 'not' as a container name (Issue #7203:
<container-name> in @container ambiguities)
- RESOLVED: 'none', 'not', 'and', and 'or' would be disallowed. Only
a single name allowed in @container rule (Issue #7203)
CSS Text Decor
--------------
- The proposed behavior for issue #7251 (Composition of inset
shadows) is to composite the text, stroke, and decoration and
then shadow it for both types of shadow. However, people are
still struggling to visualize the results of that decision so
more examples will be added to the issue in order to continue
discussion next week.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0000.html
Present:
Joey Arhar
Rossen Atanassov
David Baron
Tantek Çelik
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Vladimir Levin
Chris Lilley
Alison Maher
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Regrets:
Jonathan Kew
Cameron McCormick
Florian Rivoal
Scribe: dael
Summer F2F?
===========
Rossen: It is 4:02 in Seattle so let's get going
Rossen: As always, first question is are there any extra agenda items
or changes?
fantasai: I started a survey thread about a summer F2F
fantasai: I we can get people's thoughts we can try and decide soon
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022AprJun/0080.html
Rossen: Awesome topic. Is this on the private list?
fantasai: Yes, private list
Rossen: Thank you. I see it. This is awesome.
Rossen: I encourage everyone to take the survey. Ideally by next week
we can have preliminary results and can have a initial yes or
no next week
Rossen: Anything else for the agenda?
<chris> For item 2, there has actually been more discussion on
https://github.com/w3c/csswg-drafts/issues/6168
CSSOM View
==========
Rename Element.isVisible to Element.isHidden?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7317
joeyarhar: Proposal is to rename .isVisible to .isHidden
joeyarhar: Got some feedback that isVisible is more about if it's
painted but this is about DOM and style so we thought
isHidden would make more sense
joeyarhar: That's pretty much it
<TabAtkins> I'm fine with the name either way, both seem reasonable
to me.
joeyarhar: The return value would be flipped since visible and hidden
are opposite
Rossen: Default for hidden is false?
joeyarhar: Yes, isHidden would return false because is not hidden
Rossen: Seems straightforward proposal
Rossen: Since we settled on isVisible previously, isHidden seems best
choice. There is one proposal in the issue about naming
isCssHidden but that goes against some of our naming schema
Rossen: Additional thoughts? Suggestions?
Rossen: Objections to Rename isVisible to isHidden and flipping
default value?
RESOLVED: Rename .isVisible to .isHidden and flipping default value
fantasai: Should we ask authors for feedback?
Rossen: We can. In what way?
<TabAtkins> Yeah, not that we should block the change one way or the
other, just might be useful to vibe-check the direction
of the name
fantasai: Ask authors in group or posters on twitter. We got no
feedback from WG so seems like no opinion
vmpstr: Also worth pointing out isVisible is not used so fine to
change
fantasai: Fine to change, just nobody here seems to have expressed an
opinion
<astearns> prior art (from linked issue) for 'visible'
https://github.com/w3c/csswg-drafts/issues/6850#issuecomment-1011388347
chris: I think it's a better name. If something is hidden tells you
truer information. If not hidden it depends on how big page
is. Doesn't make incorrect promise.
Rossen: Agree stronger promise
<dholbert> +1 to what Chris said
Rossen: To fantasai point if we want someone to run a survey that
would be great
jensimmons: I posted a tweet
<jensimmons> I posted this tweet:
https://twitter.com/jensimmons/status/1532137408418004994
jensimmons: A bit late to hear from my usual audience but maybe over
next day or so. We can decide now and reverse later
<chrishtr> I recommend making a decision now and we can update it if
we hear other evidence
Rossen: There's a well articulated reason to change. If we hear
anything to the opposite we can reverse.
<fantasai> wfm
Rossen: Thank you
CSS Color
=========
Resolving color-mix() / color-contrast()
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7302
<chris> People should also have
https://github.com/w3c/csswg-drafts/issues/6168
open as they cover basically the same thing
chris: 7302 is about resolving color-mix and color-contrast. Have
spec text but didn't say how to resolve
chris: Have another issue, 6168, that talks about same thing. I'll
copy discussion to both
chris: Suggested wording, emilio said it's slightly wrong and I
agree. There is proposed wording in color 5
chris: lea did a little codepen that impl color-mix so you can see
how it works and get calc
chris: Useful to see what's happening, particularly when currentColor
involved.
chris: If we can agree here I'll put this in the spec
chris: Color-mix has to inherit in as the whole thing
jensimmons: codepen URL? I don't see it in the issue
<chris> https://codepen.io/svgeesus/pen/QWQrQqr
chris: It's in the other issue; discussion is happening in both
<fantasai> +1 to computing currentColor components to themselves
<fantasai> even if that requires maintaining notations through
inheritance
chris: I put in concrete wording. emilio pointed out it's a bit
wrong, but other then that do people like the wording?
chris: smfr or jensimmons do you know what Sam is thinking?
smfr: Not sure I do. Can you give proposed wording comment?
chris: Dropping a link
<chris> https://drafts.csswg.org/css-color-5/#resolving-color-values
chris: emilio didn't like the section being called resolving color
values and I asked him about that. Didn't hear back yet.
That's what it's named in color 4
fantasai: Call it computing color values?
chris: Resolving makes it sound used. This is both computed and used
value
fantasai: I don't know what to do. It's fine then.
chris: It's different if currentColor is involved. In WK this is at
parse time and WK doesn't do currentColor because it didn't
know what to do. I suspect WK will need to change
fantasai: If I understand intention, it's that you compute the
winning color and that becomes computed. If currentColor is
used you compute individual values but don't resolve until
used value time
fantasai: That makes sense. Not exactly what you wrote but if that's
what you're going for good
fantasai: You wrote another sentence about resolving the used value
to compute...confusing.
chris: That is intent. used is the winning color for contrast and the
mix value for mix
fantasai: used is always a color. computed is not always for
currentColor
chris: Yes.
chris: Other thing is emilio opened an issue a while ago that if we
resolve another bug happy to ship. Bug closed today so I take
as happy to ship from Moz. Want to know if WK is happy to ship
too
chris: Both browsers you have to run with flag enabled to get right
result so all tests flag
smfr: I think with WPT it runs with flags enabled
jensimmons: I think it enables for chrome and firefox but not safari
smfr: May want to fix currentColor before shipping on by default
chris: But sounds near-term thing on what spec should say?
fantasai: Seems like we should fix up spec to say what we want
shipped and once that's ready we say go ahead
Rossen: Do you want to go back and do that and let us know once ready
chris: Have to assume that's done to cover item 3 on agenda
Rossen: We can resolve to accept text that is not quite correct.
Let's consider the request once more next week and we can go
from there
chris: Okay
Scroll Animations
=================
Support setting start and end time on scroll timeline
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7296
flackr: This is just a minor one. When create scroll timeline it
always animates over full scroll range
flackr: Has been desire for devs to say animation runs one scroll
offset to another. Unclear if use cases are better solved
with new timelines. That's the counterargument to adding
flackr: Prop could be punt for now and add later
fantasai: I was on queue to basically say that I drafted it up
because it would make sense but asked what would be better
here then using view timeline. Can add later once there's
better use cases
smfr: When you said a new timeline are you implied there's a generic
feature
Rossen: Said view timeline
smfr: Okay. Should this be a generic feature to allow you to trim
ends of animation generally or is it specific to scroll
fantasai: Don't have generically because some timelines don't have an
end
flackr: There is end-delay prop of animations that if applied to
scroll linked allows you to trim end
fantasai: document-timeline doesn't have an end you can trim for
example
Rossen: smfr does that answer your question?
smfr: Not sure. This sounds like range mapping to me which may be a
generic that web animations should support. I don't know enough
to say if that's a sensible ask
flackr: I would say we don't have enough detail about what the ask
would be here
fantasai: My prop is we close no change. If people come back with a
use case that's a scroll timeline that's not to element
position we can come back and add it
Rossen: Prop: Close this with no change
Rossen: Objections?
RESOLVED: Close this with no change
Rethinking timeline-phase
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/7240
flackr: Somehow phase was added to animation timeline. I suspect was
for original scroll animations. Is in TR of web animations.
No browser exposes this phase. Before and after were only for
scroll timelines
flackr: As a general simplifications I prop we remove phase from
interface and remove before and after phases. I think we can
use times in scroll timeline that go beyond beginning or end
and that achieves the same effect
<fantasai> wfm
Rossen: Any ideas? Additional comments?
Rossen: I see IRC support from fantasai
flackr: Prop: Remove phase from the animation timeline IDL and remove
the before and after timeline-phases
Rossen: Objections?
RESOLVED: Remove phase from the animation timeline IDL and remove the
before and after timeline-phases
ViewTimelineOptions dictionary should accept subject
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7157
fantasai: I think this was a copy/paste error where I forgot to
switch source to subject. I don't think need to discuss
unless someone thinks it's correct
Entry/Exit Transitions for View Timeline effects
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7044
flackr: With view timeline needed to support use case of entry and
exit animations that original view timeline attribute didn't
cover
flackr: A bunch of discussion in issue about adding phase concepts
and various discussions
flackr: I prop simplified alternative to just express range of view
timeline in terms of when starts and ends relative to
element's visibility. That allows you to express from
element's entry, exit, and previous cover and contain values.
Can map cover and contain to longhands
<fantasai> https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1115297671
flackr: May 2nd comment has proposal
<fantasai> view-timeline-range: [start|end]? <percentage>
[start|end]? <percentage>?
fantasai: I think suggested tweaks are a good idea. I like the
direction. Might not be enough. One think that's awkward is
if you want to define an animation that has a particular
behavior during entry, different when visible, and third
when exiting
fantasai: Fade in, pulse, and fade out. Can't do that unless allow
binding multiple view timelines on a single element.
Becomes ergonomically a problem. Would like to expose a
single timeline with phases where can attach set of
keyframes even if not sure length of it
fantasai: That would allow more logical ties of parts of animation
together including possibly expanding to user defined
things in the future. other types of timelines might have
phases in the future
fantasai: I think it's going in a good direction, but more things to
explore
flackr: Covering the first point, I think that spec a list of view
timeline ranges wouldn't be that ergonomically awkward.
Reason I'm concerned with setting multiple phases is that
those phases can be overlapping. Can have element that's
large enough that it enters at same time as exits. That gets
complicated to spec what should happen
fantasai: Yeah. That's something we need to think about. Had a
definition where once element fill screen it's considered
to be no longer in entry phase and now is in contain phase
until starts to exit
fantasai: That said, you could define phases in a way that they
overlap and if attaching keyframes how does that work
fantasai: I think they are questions we should explore. Proposal
earlier attaches to different animations and would cascade
as animations. I think weird if a large number of people
will want separate phases for entry and exit and each
person needing 3 timelines and reference them is a lot of
unnecessary work. We should create those timelines.
<miriam> +1 fantasai
fantasai: If we decide separate timelines is right we should create 3
timelines that are named this way.
flackr: Create a shorthand to make it easy to attach a timeline to a
range
fantasai: Alternative is concept of phases in timeline which is same
as multi timeline but it's the same as having a single
timeline and attach phases to that timeline. Conceptually
you still have 1 timeline which make sense since it's this
one element moving through screen
flackr: Also examples of an animation that runs on enter and exit
phase. Unclear on what that's supposed to do. Same animation
start to finish on enter and exit?
fantasai: If that's how you spec, yeah? If want way to reverse
animations easily could make that syntax
flackr: I think they should be separate animations. Otherwise it adds
complexity
fantasai: If we add timelines for other things we're likely to way to
have concept of phases or have ability for author to create
custom phases and assign frames to names sections. Might be
useful in future for other types. I don't think will stay
as this one complex thing that's only for view timelines.
Haven't thought a lot about which but seems useful
flackr: I can see the appeal to that. Probably limited subset to that
feature that is just spec phase an animation runs during
flackr: A bit worried about overlapping phase and could be confusing
when enter means something different depending on sie of
scroller. Need more experimentation
fantasai: Yeah. And more thinking. I don't think ready to resolve.
Maybe a separate call to explore and brainstorm instead of
just try and resolve
fantasai: Prop: Arrange a side call for anyone interested in view
timeline entry/exit to brainstorm and get ideas to aim for
something more concrete
fantasai: If people are interested I can try and set something up
<ydaniv> +1
Rossen: Okay
Rossen: Is there anything else we want to do here and now?
fantasai: Don't think so
flackr: Pushing until call is fine. I added to agenda because not a
lot of commenting on the issue
Rossen: Let's do that
CSS Contain
===========
<container-name> in @container ambiguities
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7203
miriam: The way we have container-name at the start of an @container
rule can be confused currently with keyword not
<fantasai> +1 to disallowing not
<TabAtkins> +1 to disallow "not"
miriam: @container might start with either container-name or not.
First part is to disallow 'not' as a container name
<jensimmons> +1 seems obvious to me
Rossen: I see support
Rossen: Should be straightforward. Other opinions? Or objections?
RESOLVED: Disallow 'not' as a container name
miriam: Next part is a question. Not clear if you can query multiple
names in an @container rule and what happens if you did. and
or or condition?
miriam: Container can have multiple names. You can say if you use
multiple names you need both or all. Or say this or that. Or
disallow multiple names
miriam: Sort of use cases of any of the above. And all can be handled
by other naming conventions. no clear reason to go one way or
another
miriam: Most obvious to me if we allow multiple names is they're all
required
fantasai: I think legit use cases for AND and OR so logical thing to
do is apply bool syntax here. Might not want to do that
because that's adding a lot. I suggest only 1 container
name, disallow not, and, and or. Consider in the future if
we want a more powerful syntax
Rossen: Reserve the bool names for now, only allow 1 container name,
and that gives us future extensibility for bool and multi
naming
miriam: Makes sense to me
fantasai: miriam you mentioned about disallowing none?
miriam: So none can't be the name of a container. none as a container
name just removes container names. I don't think need to
explicitly disallow, but could clarify that
fantasai: Makes a difference as to if rule is invalidated. I lean
toward invalidating it
miriam: 'none', 'not', 'and', and 'or' would be disallowed. Only a
single name allowed in @container rule
Rossen: Sounds like a good summary. Opinions or objections?
RESOLVED: 'none', 'not', 'and', and 'or' would be disallowed. Only a
single name allowed in @container rule
Revisit decision to make style the default container-type
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7066
fantasai: Is emilio on?
fantasai: We should skip
CSS Text Decor
==============
Composition of inset shadows
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7251
fantasai: After the call last week jensimmons and I chatted about
what is reasonable behavior and how does it relate to
decorations and stroke
fantasai: She gave a bunch of examples. Author expectation is text
including stroke is composite together and shadowed for
outset. Same should be for inset
fantasai: So you're taking text and dropping or lifting above paper.
Doing same for inset as outset makes this cleaner.
fantasai: That's my proposal. If we want variety in future we can do
something to allow for it, but this seems like a good
default
jensimmons: Clarifying. When I was reading back our conversation I
can see many authors might want shadow between stroke and
center part of letter. I don't know. If definitely easier
to impl with everything shadowed that's sort of
compelling reason to do it
jensimmons: If I could have anything what authors would want is
opportunity to do both. Could be great graphic design.
Does seem like authors might want shadow between stroke
<astearns> fwiw I have some details from Adobe’s design tools, but
inset-shadow is not a built-in feature in any of them. Its
something you have to do on your own (so pretty much any
combination is possible)
fantasai: My take away is while authors might want both when you have
stroke text and stroke text decor and drop shadow that ends
up being [missed]. In most cases with no stroke we want to
make sure that works and in that case you want to composite
together
smfr: We don't allow authors to control compositing for inset box
shadow. Maybe start with one impl and if we get authors
requests for more control we can do in future
fantasai: I think right answer is composite text, decor, and stroke
together an shadow as one unit
Rossen: What can we resolve on?
fantasai: Prop: Composite the text, stroke, and decoration and then
shadow it for both types of shadow
fantasai: I think that's because when you have no stroke then you
want to composite and that's more common than stroking text
jensimmons: Agree without stroke everything composites together and
then shadow
Rossen: Additional comments on this?
smfr: Still want to see pretty pictures to show us how this should
look
Rossen: Examples would be great
fantasai: I have a test case showing how it should not work
fantasai: I took text and put strike-through and then shadow that and
if you shadow the strike-through's shadow is darker. Looks
bad
Rossen: Ready to resolve?
Rossen: Proposal: Composite the text, stroke, and decoration and then
shadow it for both types of shadow
Rossen: Or smfr do you want examples first?
smfr: Without stroke okay but would like pictures. With stroke I
think inset shadow needs to be between fill and stroke
fantasai: Problem is because it's between fill and stroke so you have
to fold the stroke into that sandwich
smfr: Text stroke doesn't apply to decorations?
<astearns> +1 to smfr adding inset shadow between fill and stroke
fantasai: Can't remember. I think text stroke...I can't remember
fantasai: In any case stroke on text is between text and
strike-through. So if shadow text decoration with text you
have to also shadow stroke because it's in between
smfr: Still hard to visualize
smfr: astearns I don't suppose you could drive adobe tools to create
options
astearns: I could play with Illustrator. Got feedback from Dirk and
illustrator lets you do all the options
Rossen: Let's allow those examples to take place and then come back
to resolve. There's lack of clear expectations without
illustration and I'm sensing hesitancy
astearns: Could someone summarize the bits and pieces would like in
example? fill, stroke, decoration, inside shadows, outside
shadows?
fantasai: Line-through makes it fun
smfr: I think inset shadows and line-through combo is most interesting
Rossen: We're 3 minutes over. astearns do you have what you need?
astearns: Yeah, I can do something for next week
Rossen: Fantastic, thank you. We'll discuss again next week
Rossen: We're now 4 minutes over. Thanks for sticking a little longer
Rossen: Please fill out the survey on the private list
Rossen: Thank you and have a good week
Received on Friday, 3 June 2022 10:13:35 UTC