- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Jun 2023 19:27:40 -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.
=========================================
Anchor Positioning
------------------
- RESOLVED: FPWD of css-anchor-positioning (Issue #8929: Request
for FPWD)
CSS Grid
--------
- RESOLVED: Go with the content-box (option 2) (Issue #7661:
Application of grid-positioning properties to static
position of grid children is inconsistent)
View Transitions
----------------
- RESOLVED: Move mix-blend-mode behavior into the UA opacity
animation (Issue #8924: Should mix-blend-mode be a part
of the UA opacity animation?)
- RESOLVED: Accept the new behavior, put it in View Transitions 2
(Issue #8888: Hold paint of old Document until new
Document draws a frame)
Counter Styles
--------------
- RESOLVED: Work with i18nWG to republish Ready-Made Counter Styles
as a W3C Registry allowing CSSWG and/or i18nWG to
update; update Counter Styles to require everything in
the Registry (Issue #8636: Should "Ready-made Counter
Styles" be supported by UA?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jun/0002.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Megan Gardner
Paul Grenier
Chris Harrelson
Brian Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Vladimir Levin
Peter Linss
Alison Maher
Vitor Roriz
Noam Rosenthal
Khushal Sagar
Jen Simmons
Miriam Suzanne
Bramus Van Damme
Regrets:
Rachel Andrew
Daniel Holbert
David Leininger
Chris Lilley
Lea Verou
Sebastian Zartner
Chair: Rossen
Scribe: emilio
Scribe's scribe: fantasai & TabAtkins
Anchor Positioning
==================
Request for FPWD
----------------
github: https://github.com/w3c/csswg-drafts/issues/8929
TabAtkins: We talked about anchor positioning from a while back
TabAtkins: spec is pretty mature, our experimental impl is looking
pretty good
TabAtkins: definitely still work to be done
TabAtkins: both in terms of making things well defined and features
TabAtkins: but we'd like to implement in the relatively near future
TabAtkins: if there's questions I'm happy to answer
TabAtkins: otherwise I think people are familiar with the stuff
florian: I agree from maturity it makes sense for FPWD maybe even
more
florian: Curious about other implementors
florian: at least about making sure they are not against this
approach
TabAtkins: WebKit has been at least reading it
jensimmons: It's been something we've tried to look at and discuss
jensimmons: not sure how deep engineers have looked at it
jensimmons: we've been pretty busy
jensimmons: there's been some feedback about the spec not being
quite ready for shipping
florian: but not push back about being in the wrong direction right?
Rossen: Not talking about shipping yet
jensimmons: It'd be great to have more time for review before folks
ship it
<florian> +1
emilio: I want to say the same. I agree it's a problem that would be
useful to solve
emilio: I'm not sure about the general direction of defining things,
e.g. .... CB
emilio: I don't think it's objectionable to publish
emilio: I agree with jensimmons it would be good to have time to
review and prototype
emilio: I don't think there is any blocker, this is terribly wrong
kind of thing on our side
emilio: so I would support FPWD
jensimmons: It's on the roadmap for Chrome to ship in August
jensimmons: that's really soon
jensimmons: would be better to have more time to review and
participate in shaping the feature
Rossen: Seems folks are happy for fpwd and we want to make sure we
don't ship prematurely
fantasai: What I hear is chrome was FPWD because it's shipping in
August and they think there's only minor stuff
TabAtkins: That's not what I said
fantasai: But it's on your roadmap to ship?
fantasai: What I'm hearing from jen and emilio is that they'd like
time to review and probably have significant feedback
fantasai: and some non-minor things might need changing
<jensimmons> I should correct myself, it's on Chrome's roadmap for
117, going to beta in August, and ship in early
September. https://chromestatus.com/roadmap
fantasai: I don't object to FPWD, it's probably past time for FPWD,
I think we have agreement on this being worth solving and
going in the right general direction
fantasai: so I hear full support for FPWD but uncomfortableness
about shipping in two months
<TabAtkins> (I actually thought we'd already done FPWD some time
ago, and was surprised that we hadn't.)
Rossen: I'm hearing that FPWD is not objected
Rossen: and mostly supported
Rossen: I'd like to take a call for objections and resolve that
Rossen: I'm wanting to hear from Tab if there's anything else he
want's to put on the record about implementation or shipping
/ testing / whatever
Rossen: but let's not relate the two and hold off on one based on
the other
RESOLVED: FPWD of css-anchor-positioning
Rossen: Tab do you want to correct some of the record about the
shipping status?
TabAtkins: We're open with our shipping status, we're planning on
shipping on 117 _if there are no major changes_, so
that's why we want FPWD and review
fantasai: Sounds like you want to functionally get to CR within the
next month or two?
fantasai: Have you requested all of the horizontal reviews and so on?
TabAtkins: No, haven't yet because spec still needs some changes
fantasai: But you want horizontal reviews within a month or two
which are very busy
TabAtkins: This is mostly extending abspos positioning
TabAtkins: we mostly need implementation review from other
implementors
TabAtkins: to make sure that the features are covered and we don't
rely on details of our impl
jensimmons: CSSWG usually goes to FPWD and have enough time for
reviewing from a variety of groups and experts
jensimmons: and this seems very fast specially at a time where folks
might go on vacation
jensimmons: I get chrome is in the position to write a spec and
ship, but this feels very fast
<tantek> +1 jensimmons — this feels unusual for the "normal" CSSWG
workmode
<jensimmons> I'm not assuming bad intent.
<jensimmons> I'm asking for time for everyone else to participate.
As we normally do.
Rossen: Let's stop this here, we have a resolution for FPWD
<florian> +1 to Jen
<TabAtkins> bare minimum of ~2 months, that's not "a few weeks" by
any definition of "few"
<tantek> Thanks TabAtkins
<emilio> +1 to having more time, for reviewing anchor-positioning
fwiw
CSS Grid
========
Application of grid-positioning properties to static position of grid
children is inconsistent
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7661
<fantasai> summary ->
https://github.com/w3c/csswg-drafts/issues/7661#issuecomment-1587880994
iank: Restating previous conversations. Two options: always use
content-box, or always use grid-positioning properties
iank: Two weeks ago people were asking for use cases
iank: I don't think anybody came back with use cases for always
using grid-positioning
iank: Me and Tab have a preference for content-box, fantasai has a
preference for using the properties
fantasai: We have agreement on if the grid properties are auto then
we use the content-box
iank: That might be more complicated because of how those work
iank: because those insert additional lines for the purposes of
abspos
iank: so would like to keep that separate
Rossen: So we want to go with option (2), which is always use
content-box (option (1) is off the table)
iank: I'd like to propose going for (2), I don't think there are use
cases for (3)
<chrishtr> +1 to option 2 (content box)
emilio: Echo slight support for going for the content box
emilio: Seems there's no use-cases for grid, seems determining the
static position form grid properties can be a rabbit hole of
interop not worth getting into
emilio: If always using the content box works, then good
Rossen: Quick question: also supportive of option (2) though. If you
want an annotation on the box that sits on top of everything
else like a semi-transparent number
Rossen: Let's say you want to number your grid cells
Rossen: is my assumption correct that if you want to achieve the
same effect you'd have to say which line you're positioning
to in the grid and then use that as your left and top?
iank: Right you need to make the grid the containing block yeah, and
set top: 0 left: 0
Rossen: What about auto placement? Where would that end up?
iank: You can't (today) setting auto placement on an abspos, you'd
need to wrap it in a grid item
Rossen: Can we make that the default behavior?
iank: We don't invoke auto placement for out of flows
iank: you need to be explicit to pick up the grid area
Rossen: Ok in that case I'm good with option 2 as well
RESOLVED: Go with the content-box (option 2)
iank: Final note: we'll do this change behind a kill-switch in case
people rely on the weird behavior, can come back to the group
if the change goes wrong
View Transitions
================
scribe: TabAtkins
Should mix-blend-mode be a part of the ua opacity animation?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8924
vmpstr: In the UA stylesheet, we add an animation, a cross-fade that
changes opacity of new and old pseudos
vmpstr: We also added mix-blend-mode:plus-lighter
vmpstr: This way if you have the same content on both sides it
doesn't look like it fades in the middle
vmpstr: We found since devs can customize this, if they change it to
anything but cross-fade they're surprised by the
plus-lighter behavior
vmpstr: So proposal is to bundle the plus-lighter to be part of the
animation
vmpstr: A separate set of keyframes that animates from plus-lighter
to plus-lighter
vmpstr: And put that in the UA stylesheet, so when devs change the
animation, they'll get rid of the mix-blend-mode
automatically
vmpstr: Also right now mix-blend-mode is marked as not animatable,
but as I understand it this is an oversight, so we need to
change this to discretely animatable
<dbaron> +1 to the proposed changes; I think all 3 properties in
https://drafts.fxtf.org/compositing/ should be Animation
type: discrete rather than Animatable: no.
khush: There's a few syntax options about where to put it in
keyframes
khush: From an impl perspective, we also add isolation to the
image-pair elements to get the cross-fade right
khush: If you have an isolated node and something below has a
non-normal blend mode, you have to do an off-screen
compositing.
khush: That's a lot of rendering work to do if it's not necessary
khush: We convinced ourselves that keeping the isolation is fine; if
you remove the mix-blend-mode it goes back to a fast
rendering path
khush: So wanted to run this past the group
emilio: I guess the isolation isn't particularly side-effect-ful
because things are already stacking contexts
emilio: But still probably less confusing to authors if we mix it
with the opacity animation?
khush: We just couldn't figure out a CSS way to tie the ancestor's
isolation to the child's animation
emilio: Not sure I follow
khush: By default you have isolation on ancestor and
mix-blend-mode+opacity on the child
khush: If author is overriding the opacity animation, we wanna get
rid of mix-blend-mode and isolation both
khush: We can easily get rid of mix-blend-mode, but not sure how to
get rid of the isolation too
emilio: I see. If there's not a great way to do it, it's probably
not a big deal.
khush: Right, we can optimize it out if there's no mix-blend-mode
emilio: I suppose if someone writes their own thing they might get
confused, but if devtools shows the right thing it's
probably okay
fantasai: Should we be creating two different sets of keyframes? Or
one set?
vmpstr: I think one set makes sense so we're not creating too many
UA keyframes
fantasai: So we have a proposed resolution?
vmpstr: Proposed res is to move the mix-blend-mode behavior into the
opacity transition
Rossen: Objections?
RESOLVED: Move mix-blend-mode behavior into the UA opacity animation
fantasai: This depends on the propertiess being discretely
animatable; they are, but we changed the format of the
animatable line in propdef
fantasai: "No" used to mean "discretely"; later we changed it to say
"discrete" and "no" really meant no.
fantasai: Tab and I went thru CSSWG and fixed everything, but missed
FXTF.
fantasai: So all of the fxtf drafts need fixing and repubbing
fantasai: But many have had changes and no active editor, so that's
hard
Rossen: This sounds like a big topic on its own, should track as
separate issue
<TabAtkins> (I suggest we move into csswg as we repub them, but we
should open an issue for it.)
<dbaron> can we at least resolve to fix the fxtf EDs per the
previous edits?
<fantasai> I don't think you actually need a resolution, we already
agreed to make those changes
vmpstr: Can I confirm that mix-blend-mode *is* meant to be
animatable?
TabAtkins: Yes, absolutely
dbaron: Can we at least resolve to fix the FXTF EDs?
TabAtkins: Shouldn't need another, we already have a resolution to
fix this stuff
dbaron: And potentially houdini, tho I'm not sure they have
properties
dbaron: and maybe also css-houdini-drafts if there are any
properties in them
Rossen: Let's just make a tracking issue for this
<TabAtkins> I'd take it on but I'm gonna be too busy the next week
and a half before vacation
<fantasai> -> https://github.com/w3c/fxtf-drafts/issues/521
Hold paint of old Document until new Document draws a frame
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8888
khush: Exploring cross-document view transitions
khush: When navigating from page A to B, there's a period of time
where B is still producing its first frame
khush: the browser has to decide what to paint in the tab before this
khush: Few options. 1) clear the tab to show white, might make sense
if it's cross-origin
khush: 2) leave page A's pixels until B paints something
khush: 3) If you have cached B, show that until B paints real pixels
khush: With view transitions, if going from A to B you need A's
pixels in the tab until B is ready, to run the animation
khush: otherwise you get a flicker during the transition
khush: in chrome, we show cached rendering of B if it's available,
otherwise leaves A around.
khush: Safari always leaves A around
khush: We want to standardize on leaving A's pixels until B draws a
frame
khush: So two parts, first get a resolution here, second where to
actually spec this. HTML and CSS neither actually define this
behavior.
TabAtkins: I think HTML is probably the best place for it - it
covers nav and timing and such, better than what CSS has.
fantasai: I think the opposite - specifying in View Transitions, at
least for now, is probably a good idea
fantasai: We don't care particularly what the browser does when View
Transitions aren't active
fantasai: but when there *is* a View Transition, for it to make
sense it has to hold the old paint
fantasai: So it's a request of *this spec and feature*
fantasai: If at some point we need to spec what happens when there
isn't a View Transition, maybe it can move to HTML or
somewhere else
emilio: So the diff is...
emilio: Clarifying that with the first you mean the page is still
interactive?
khush: Until the browser switches to showing the live B document,
all browsers keep it non-interactive
khush: Diff is in most cases if you're going from A to B you only
have A's rendering to show
khush: but if you're going back, from B->A, then forward again, you
might have B's cached rendering. Chrome currently shows that
when going forward from A->B
emilio: When you are flipping display?
khush: There are cases where pages do something in pageShow, it's
timing-sensitive
khush: If the bfcache restore takes more than a single frame you get
flicker - show B, then show A, then see animation
emilio: Okay so if pageShow takes more than a frame to arrive...
khush: Right, it wasn't uncommon to see pages accidentally run into
this
emilio: I have the feeling HTML might be the better place to put this
khush: I think it's clear on the behavior, just not where it is
khush: Happy to put it in View Transitions right now and move it to
HTML in the future when it's more mature
noamr: For View Transitions 2 and MPA stuff, lots will move into
HTML or monkeypatch HTML due to nav interaction, so this will
be part of that
Rossen: Okay so sounds like it'll move to HTML later
fantasai: Sounds like we want it in VT for now and move it later
Rossen: Ok, so any objections on putting this behavior into View
Transitions 2?
RESOLVED: Accept the new behavior, put it in View Transitions 2
Counter Styles
==============
scribe: fantasai
Should "Ready-made Counter Styles" be supported by UA?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8636
vitorroriz: When we were implementing counter styles on webkit side,
I saw this list maintained for Ready-made Counter Styles
for different languages
vitorroriz: but this was not intended to be supported by browsers
vitorroriz: so I wanted to understand why
jensimmons: Proposal is to take this stylesheet and put it into the
UA stylesheet for browsers
jensimmons: so that all these styles are supported by browsers out
of the box
jensimmons: for all the languages equally, so devs don't have to
copy-paste
<emilio> FWIW I think Gecko ships at least an early version of this?
https://searchfox.org/mozilla-central/rev/fb55a4ee44a9a95d099aa806ca494eb988252ded/layout/style/res/counterstyles.css
TabAtkins: I have no objections to in or out
TabAtkins: we agreed to move out at the time partially because we
didn't want to show favoritism that we happened to have
listed
TabAtkins: so restricted to list in CSS2
TabAtkins: but list has been enhanced substantially by i18nWG over
last 8 years
TabAtkins: so as long as implementers are fine with it, I'm OK too
TabAtkins: dbaron did point out that some of these changes could
have web-compat impacts
TabAtkins: I reviewed the changes, given intended use cases and the
practical use cases ppl use these for
TabAtkins: I suspect web-compat for such changes are going to be
minimal
TabAtkins: I think this is going to be low chance of compat
TabAtkins: and if author disagrees with what we do, they can
override; spec allows this
TabAtkins: just need to make sure that whatever we do, it's still
easily editable by i18nwg
TabAtkins: There was some discussion about putting UA styles in HTML
stylesheet, but that would create a lot of friction for
updates, so don't recommend
<dbaron> I'd note that the UA styles here are for all document
languages rather than just for HTML, and I *think* such UA
styles don't go in the HTML spec...
<fantasai> +1 dbaron
jensimmons: I think one issue that will come up, e.g. making content
for WWDC, one of the examples I used made
upper-serbo-croatian
jensimmons: term was used in the past, but in this day and age,
would be better to use a different term...
jensimmons: but there's going to be some touchy political issues
around naming these things
jensimmons: if in CSS, then we'd have to add aliases or something
jensimmons: so some homework for CSSWG over the years
<tantek> +1 jensimmons I saw chatter about that example as well
jensimmons: but feels important to do, to include all languages of
the world not just those in CSS2
<TabAtkins> yeah, so long as we don't drop anything, just add
aliases, it should always be fine
emilio: For the case Jen mentioned, keep old name around and add new
if needed
emilio: want to point out, Gecko ships an early version of this
emilio: I tend to think that we should really support this in the
browser, don't care where they live
fantasai: I don't think the right thing is to fold into Counter
Styles 3, that's focused on the mechanism of counter
styles and we want this to go to Rec
fantasai: But this could be a document, maybe a Registry which is
new and allows easy updates, and commission CSSWG and
i18nWG to add new things to it, make it a joint
publications
<bkardell> registry is interesting
<florian> [that makes sense to me]
fantasai: And counter styles can require including everything in the
registry
fantasai: Just putting them in the same doc makes things harder to
update
jensimmons: Benefit is better compat
jensimmons: We don't really have interop between browsers for this
jensimmons: expecting that browsers will regularly ship all of them
will help authors in that way
TabAtkins: I propose we take fantasai's idea, take into registry
jointly published by CSSWG and i18nWG
TabAtkins: and have Counter Styles require everything in the registry
Rossen: Any objections to that?
RESOLVED: Work with i18nWG to republish Ready-Made Counter Styles as
a W3C Registry allowing CSSWG and/or i18nWG to update;
update Counter Styles to require everything in the Registry
Received on Wednesday, 14 June 2023 23:28:15 UTC