- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Jan 2024 18:23:08 -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 Compositing
---------------
- RESOLVED: Make lighter defined the way plus-lighter is now defined,
pending checking some additional tests that might show
differences (FXTF Issue #448: 'lighter' vs 'plus-lighter')
CSS Conditional
---------------
- RESOLVED: Adopt keyword based feature queries, with names to be
bikeshedded later, with the expectation that we will use
them less than 2x per year and test and message their
addition carefully (Issue #3559: Testing support of
properties and values with partial implementations)
- RESOLVED: Add a keyword for alignment on blocks, with the specific
name TBD (Issue #3559)
CSS View Transitions
--------------------
- RESOLVED: 'auto' means push or replace that's not browser UI, or
traverse with any user involvement, excluding any reloads
(Issue #8783: Define navigation descriptor for
@view-transition)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jan/0006.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Kevin Babbitt
David Baron
Andreu Botella
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Peter Linss
Eric Meyer
Florian Rivoal
Vitor Roriz
Noam Rosenthal
Khushal Sagar
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Chair: Rossen
Scribe: flackr
CSS Typed OM
============
Rossen: 2 topics haven't gotten attention in houdini and fxtf, let's
decide what to do
Make CSSUnitValue use unrestricted double
-----------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/1089
fantasai: Can we make progress without Tab?
bkardell: Tab had a proposed resolution
<Rossen> linked resolution proposal:
https://github.com/w3c/csswg-drafts/issues/8114#issuecomment-1458935503
Rossen: [summarizes linked proposal]
bkardell: TabAtkins believes this is fine for cssom because we have
the needed types
emilio: Plain css values in the computed space are not allowed to be
+/- infinity so it's a bit weird
emilio: You usually need a calc to have an infinity and it gets
simplified to a large number when computed, so it might be a
bit inconsistent
emilio: Has anyone looked into this?
Rossen: Tab has, and thinks it's okay
emilio: If you assign an infinite value to a style map with a
specified value, what does it turn into? is it implicitly
wrapped in a calc?
emilio: It's fine, but perhaps a bit odd that you'd get a calc back
Rossen: This is the discussion we need to have, let's wait for
TabAtkins to push this forward since there are concerns
emilio: Sounds good
CSS Compositing
===============
'lighter' vs 'plus-lighter'
---------------------------
github: https://github.com/w3c/fxtf-drafts/issues/446
dbaron: The compositing spec has a list of blend modes, one is
lighter, one is plus-lighter. The only difference between
them is that lighter does not clamp the color values to the
[0, 1] range. It allows the output color to be greater than
1. It's the only compositing operator that does this.
dbaron: I.e. only one that can take two colors in [0, 1] range and
produce values outside of this range.
dbaron: It's not clear if this is detectable?
dbaron: In theory there's some color space things that might be able
to test this
dbaron: It would be useful to have people aware of the color stuff
weigh in on what is the right thing here
dbaron: There's some weigh in but it would be useful to have clear
opinion
dbaron: My inclination is lighter and plus-lighter should be the same
dbaron: Lighter should be what plus-lighter is
florian: And get rid of plus-lighter?
dbaron: Not sure it would be compatible with existing content to do so
bkardell: On the issue, I saw that checking the 3 impls they're using
the spec formula for plus-lighter, though may need testing
using other color space options...
dbaron: Maybe we should tentatively resolve to make them the same
unless there's a reason not to
bkardell: If impls are the same seems like a good idea
dbaron: They're only the same in so far as I've tested so far
Rossen: Should we accept the proposal - make them the same?
<dbaron> Proposed resolution: make lighter defined the way
plus-lighter is now defined, pending checking some
additional tests that might show differences
RESOLVED: Make lighter defined the way plus-lighter is now defined,
pending checking some additional tests that might show
differences
CSS Conditional
===============
Testing support of properties and values with partial implementations
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3559
dbaron: One of the design goals of @supports is we don't want to
require impls to maintain large sets of data about what is
supported that's separate from the code which supports the
thing
dbaron: In the past doing this tends to result in them getting out
of sync
dbaron: so we originally defined it in terms of property syntax being
accepted, and is in sync with a certain definition of whether
features are supported
dbaron: @supports has not been very effective for certain types of
interactions, e.g. a property that was once only supported on
flexbox being supported elsewhere
dbaron: People have wanted a syntax for these sorts of interactions
in a general way. There's no proposal for a general syntax
that satisfies the original design constraint
dbaron: The proposal I put in the issue, is that we don't try to
solve this generally, but add a solution that we use in rare
cases where we feel it's important with one-off keywords
dbaron: I propose calling this a feature function where we add a
keyword for a particular interaction
dbaron: The idea is we'll use this rarely, e.g. 1 per year is okay, 1
per month is probably too much
dbaron: I'd like feedback on the general idea, we can bikeshed names
florian: One of the other reasons for original design constraint is
not just that they might eventually get out of sync but
could initially be out of sync if the detection is done
independently
florian: you might do one and forget to do the other
florian: This problem remains with the alternate proposal, as you
might forget to add the detector
dbaron: I agree this is a concern, this is part of the reason we want
to do it rarely and have process / tests to make sure we
don't forget
emilio: I agree with the concern, but having an escape hatch for this
makes sense.
emilio: The thing florian mentioned has also happened in reverse
accidentally, e.g. shipping & selector before nesting
support??
emilio: having this general one-off escape hatch makes sense
oriol: I'm not a big fan, these features when they're used will
assumed to be false initially and become true and authors will
stop checking them. But it's something we'll add to the
platform and will need to keep these checks even though
they're sort of obsolete after a while
oriol: This is an ongoing cost needing to keep around
rachelandrew: I quite like this. In an ideal world we'd have a more
general thing, but this doesn't come up often. This
feels like a pragmatic solution to an edge case that
comes up once in a while.
rachelandrew: This gets developers what they need / are asking for.
rachelandrew: It's also easy to explain to devs
<bramus> +1 to what rachelandrew said there.
bkardell: It feels pragmatic and easy enough to explain if it's like
what dbaron said where we have maybe 1/year. I feel like
this is the max. If more, this feels like it's not a good
solution and we need to find the more general way
bkardell: I'd really like to find the general solution as this is
only a part of the issue
bkardell: People want to detect all manner of things
bkardell: e.g. you should be able to do custom media queries
SebastianZ: When we introduce such keywords we should also make clear
these features need to ship together with the keywords,
clearly stated in the spec
florian: I think it's interesting bkardell mentioned media queries,
this might be the generic solution to not solve it directly,
but detect the behavior of the feature
florian: We could make all sorts of changes that might need to be
tested, and could be exposed through a JS media query
florian: There might be a commonly used library which exposes a set
of features needed
florian: I am concerned about the ability to become out of sync and
start of sync, not objecting though
<iank> fwiw libraries already use JS tests then add classes on html
element to say if a particular feature "works"
<bkardell> if some of those are _very_ common then a solution like
this could still work - so I don't think they are mutually
exclusive where we know there is a specific/popular one
like this necessarily
noamr: Custom media queries doesn't add much relative to performing
the test and putting a class or data attribute on the root
element
noamr: In general if your test is some JS which deals with the
document, maybe the whole feature belongs in userspace
noamr: The user defines it in their own way and doesn't seem to be a
web platform feature
bkardell: I don't think they're mutually exclusive ideas
bkardell: I think we should add a mechanism where people can do this
in author space and we can decide to add the occasional
extremely common one
dbaron: Responding to using data from what authors are doing, we
would be doing the addition too late and it would be out of
sync. I see this for cases where we know ahead of time that
it's going to be a big deal
<florian> +1 to dbaron
<bkardell> ok
Rossen: I'm hearing general support with some concerns with how many
we'll have, any other comments/concerns?
fantasai: A common pattern is property X adds to display type Y, we
should have a consistent pattern for representing these
cases to avoid each being slightly diff when introduced
chrishtr: The proposed resolution is dbaron's latest comment, right?
<fantasai> https://github.com/w3c/csswg-drafts/issues/3559#issuecomment-1868169502
chrishtr: Adding a custom keyword specific to quirk? assuming so, do
we know of any case we can put in the spec as a first
example?
dbaron: I think the first example would be support for alignment
property on blocks, as this is a thing we're talking about
doing soon that has this concern
chrishtr: How about we add this to the resolution with candidate
wording?
fantasai: I think we should have 2 resolutions, one for keyword based
resolution and one for align on block
fantasai: For align on blocks, I want to make sure we have a
consistent pattern
<chrishtr> @supports (align-content-block-flow)
dbaron: I'd like to make these two resolutions and have further
discussion to bikeshed the names
<fantasai> align-content-on-block
dholbert: One question, this proposal lets authors opt in to using
css alignment on blocks, but I don't know if it fixes some
site that sets * { align-content: center; } and that
suddenly starts applying to everything
dholbert: Do we have a similar proposal to address this?
dholbert: it seems like we may need both in order for these sorts of
changes to be shippable
<iank> fwiw we've blocked rolling out align-content:center due to
some compat issues with large existing sites.
dbaron: I agree it doesn't address this problem, we need to find out
whether this will be a problem
SebastianZ: I also had a proposal for custom support queries. I'll
create a separate issue for this for discussion. I don't
want to derail though
Rossen: dbaron can you summarize resolution?
Proposed resolution: To adopt keyword based feature queries with
names to be bikeshedded later.
Rossen: One of the main concerns was how we keep this to a small
number, do we want to capture this in the resolution?
iank: FWIW, it'll be clear when this adds value vs not. These will
only have value for a couple of years. What most devs use is
modernized library which have queries for e.g. old grid vs
new grid
iank: I suspect we can address this on a case by case basis
iank: currently for us we blocked align-content on blocks due to
breaking some sites
iank: I'm okay with general idea. we'll hear from web devs when this
will make their lives easier but we shouldn't add this for
every sub feature we roll out
Rossen: I propose let's keep a low number and see if we can agree
on this
florian: I think there's enough people concerned that we won't be
tempted to do this too often
Rossen: Is 2 the right number?
<dbaron> Proposed resolution: adopt keyword based feature queries,
with names to be bikeshedded later, with the expectation
that we will use them rarely and test and message their
addition carefully
RESOLVED: adopt keyword based feature queries, with names to be
bikeshedded later, with the expectation that we will use
them less than 2x per year and test and message their
addition carefully
RESOLVED: Add a keyword for alignment on blocks, with the specific
name TBD
Rossen: SebastianZ please go ahead and open the issue you mentioned
and we can open an issue for names
dbaron: Separate issue?
Rossen: If it's going to turn into a thing it will be helpful
dbaron: Sure
CSS View Transitions
====================
Define navigation descriptor for @view-transition
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8783
noamr: We resolved on having a view transition rule with a navigation
descriptor having values of auto and none for cross document
view transitions
noamr: We said in the future we'd resolve on what auto means and
whether it's the right name
noamr: Let's figure this out
noamr: We think any navigation except reload should be considered
auto and automatically trigger a VT
noamr: We want to be a bit more aligned with the navigation API.
Navigations that are not cancel-able should not trigger an
auto VT
noamr: This mainly includes browser UI navigations, e.g. typing a URL
in URL bar
noamr: The idea is to align more with this, and say auto means any
navigation that is not browser initiated and any navigation
that is a traverse navigation (e.g. back/forward)
noamr: An outlier to both is reloads, we resolved before they
shouldn't be automatically a VT, but reloading via JS can be
canceled with the navigation API
noamr: The proposal is to call this auto, to include any traverse
navigation, any push/replace navigation that is not browser UI
initiated, and to discuss whether programmatic reloads should
be included, probably not
fantasai: I think saying you can cancel it via JS is not the right
way to do this. We want this to work for people not writing
JS. By default we can allow for reloads (programmatic or
user initiated), but it should be an option
fantasai: We don't know if the author wants to have something reload
more invisibly rather than trigger a transition
fantasai: e.g. navigating from one catalog page to another might look
like a page swipe but reload shouldn't. auto shouldn't
include these cases and the author should request it
explicitly
noamr: Programmatic reloads are JS to begin with. We don't know what
people use them for. You probably wanted a reload pattern in
your application or because you reach a certain state want to
force a reload
noamr: The idea of hanging off of what can be cancelled via JS kind
of made sense for navigations initiated from JS
fantasai: The person writing the JS might not be the same person
writing the CSS
fantasai: The person designing the transitions needs to be able to
design this independently
noamr: Do people have views about excluding browser UI initiated
navigations?
fantasai: This seems vague, there's a lot. Does this include back/
forward?
noamr: No, anything except traverse
noamr: e.g. bookmarks, typing in url bar, extensions etc
fantasai: What is traverse? for clarity
noamr: Traverse is going back/forward in history or clicking
something through the history list
Rossen: What about meta tag refresh?
noamr: That would be a reload, or a replace if it goes to a different
url
noamr: So that's equivalent to a programmatic replace so it wouldn't
be considered browser ui
noamr: It would have a VT
Rossen: So on every refresh in fantasai's example you'd be flipping
pages
noamr: Yes, because it's like a regular replace navigation
fantasai: So to summarize, you want to introduce a keyword that says
every navigation initiated by the user or the page except a
reload of the page, or a browser UI navigation that is not
a history traversal
noamr: The keyword means any navigation that is not browser UI plus
any browser UI traverse (i.e. including links, back/forward,
forms, meta redirect)
khush: This keyword called user involvement, is an existing thing in
the spec we're leaning on. Script, activation behavior and
browser UI
khush: Script is like using history api or navigation api
khush: Activation behavior is where <a> activation triggers navigation
khush: Browser UI is interaction with browser UX to trigger navigation
khush: The desire here to align with the nav API is that it's a bit
weird to trigger a VT from a navigation you can't observe via
script
khush: in that we haven't exposed it to script normally
khush: Also you can't customize it via JS, so there will be problems
with not being able to customize it
khush: So I have concerns with only being able to customize it via css
khush: html has 4 keywords, push, replace, reload and traverse
khush: If navigation type is push or replace, and user involvement is
not browser UI
khush: One class of navigations is your type is push/replace and
involvement is not browser UI, i.e. script or activation
behavior, this is included
khush: For traverse, the html spec has a special carveout because
authors often want to include these. For this it should be
allowed even if browser UI was involved
khush: The fact that you can observe it helps customize
<khush> In summary, auto would match: Any traverse navigation. Any
push or replace navigation whose user involvement is not
browser UI.
Rossen: Does this satisfy concerns / questions?
fantasai: Yes, and last category is reload.
fantasai: I think we should exclude reload in all modes
noamr: Resolution would be auto means push or replace that's not
browser UI, or traverse with any user involvement, excluding
any reloads
<fantasai> flackr++
RESOLVED: auto means push or replace that's not browser UI, or
traverse with any user involvement, excluding any reloads
Received on Thursday, 11 January 2024 23:23:44 UTC