- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Aug 2022 19:05:00 -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.
=========================================
CSS Flexbox
-----------
- RESOLVED: Ignore the effect of align-content properties on
absolutely positioned elements in flex (Issue #7596:
align-content: stretch for abspos children of flex
containers should align with browser behavior)
- RESOLVED: Open an issue on justify-content (Issue #7596)
CSS Selectors
-------------
- RESOLVED: Start work on an `:open` pseudo class, which matches
things that are in an "open" state. We need to define
that state carefully, with a general conceptual
definition that can be used by HTML for the specifics
per-element. (Issue #7319: Add :open or :top-layer pseudo
class)
CSS Contain
-----------
- There wasn't agreement on issue #7413 (Should style() queries allow
!important flag?) though there were no strong feelings either.
Discussion will continue on github to reach a resolution.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Aug/0004.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins
David Baron
Mike Bremford
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Jon Davis
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Vladimir Levin
Chris Lilley
Peter Linss
Alison Maher
Florian Rivoal
Khushal Sagar
Miriam Suzanne
Alan Stearns
Bramus Van Damme
Regrets:
Lea Verou
Scribe: argyle
TPAC
====
<astearns> https://wiki.csswg.org/planning/tpac-2022
astearns: Please go update the wiki with your availability
astearns: Will have the bare outline done by EOW, then we can move
things around based on when folks wants to discuss what
astearns: Any other items of feedback people want to bring up?
astearns: Please do liberally mark issues for feedback so we can fill
up the agenda
CSS Flexbox
===========
align-content: stretch for abspos children of flex containers should
align with browser behavior
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7596
astearns: first is flexbox align-content
astearns: Is this something that you want to introduce Ryan?
rreno: The specific scenario is flexbox, when your computing the
static position of absolutely positioned children of flex
containers
rreno: The problem is, the spec for alignment defers to flexbox in
this scenario, and flex specifies that when the container has
negative available size, like an absolute positioned child
that's larger than the container
rreno: When that's the case, supposed to fallback to flex start, but
no browsers do that
rreno: My proposal is align the spec to what the proposal is doing,
ignoring alignment content, but the browsers are. Let's align
spec text with what the browsers are doing
rreno: It's essentially the default based on how browsers are
currently operating
astearns: Any other opinions on making this change?
TabAtkins: From fantasai and I's opinion, we approve of this change
dholbert: firefox does actually honor align-content for abspos flex
children
dholbert: in most cases
dholbert: This resolution we make us start ignoring it. This would be
a behavior change for firefox. I'm ok with it.
dholbert: Specifically for this align-content for abspos flex children
fantasai: Wanted to confirm we keep grid and flexbox aligned on this
point
fantasai: so they ideally they both grid and flex behave the same
with regards to this property
iank: I'm a little bit confused, ryan, previously you wanted to keep
respecting, like change webkit to match gecko, now that's not
the case?
rreno: We would like to change webkit to match geckko, however, I was
also trying to match the spec when implementing this...
rreno: none of the browsers do the fallback to flex start
rreno: My proposal was to remove that back to flex-start
rreno: We're currently shipping webkit, we can rollout a patch I
have. Did that answer the question?
iank: Yeah, just not sure we're exactly...maybe if we had a proposed
resolution that would clarify
iank: Tab you were saying we should ignore both justify and
align-content, is that correct?
TabAtkins: Ignoring the content properties for abspos children
iank: I think we're talking about 2 separate things here
rreno: fwiw, my proposal was a scoped change. Maybe a new topic for
another time
iank: Do we just want to consider dropping align-content behavior,
that would mean chromium and webkit stays the same, and firefox
does the change
dholbert: That's fine with me
astearns: Tab, does the scoped proposal make sense? or you want to
remove all of the scenarios?
TabAtkins: I'm fine with doing this in stages, don't have to do all
at once
fantasai: All browsers honor justify content of abs children, and 2
of them are ignoring align-content, firefox is honoring it
fantasai: In grid, all browsers are ignoring both of them
iank: That's correct. extra context: I've added a use counter in
chrome to see what the impact would be of dropping
justify-content
iank: in flex, to see if that had substantial behavior change. we can
deal with that later if you like
astearns: A proposed resolution could be: ignore the effect of
align-content properties on abspos element in flex and
grid. open a new issue on whether or not we make the same
change to justify-content
astearns: Is there anyone who wants to argue against that?
dholbert: Not against it, clarifying this is only scoped to flex. No
proposed change for gird
astearns: Is it clear in the spec? that align-content should be
ignored in grid
dholbert: I think so
iank: This sort of flex behavior comes from the older logic of how to
determine static pos in flex. assume you're the only flex item
and positioning yourself and if your not a flex item. grid came
along and didn't have that logic. for some history
astearns: Proposed resolution: ignore the effect of align-content
properties on abspos element in flex
astearns: we do need to open a new issue on justify-content
astearns: hearing no objections, we're resolved
RESOLVED: ignore the effect of align-content properties on absolutely
positioned elements in flex
RESOLVED: open an issue on justify-content
astearns: So who's going to open a new issue. Can I ask you iank?
iank: Sure, I can do that
<bradk> If the positioned thing is display:flex, then align-content
still applies to its children though, right?
astearns: brad had a question in the chat
iank: aw yes, this is for abspos for determining the static pos
bradk: Make sure, talking about how the align-content on the parent
of the abs items effects the abspos items, but if the abs
positioned items is flex, it still applies to their children
right?
iank: This is just for static pos
bradk: Make sure it's clear in the spec
Selectors
=========
Add :open or :top-layer pseudo class
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7319
masonf: We have discussed this before, in June, initially proposed as
a top layer pseudo class. we need something like this for the
popup api
masonf: General conclusion in open ui and reading issues in css, we'd
prefer to do something like :open
masonf: Like a selector that matches things open. both modals and
dialogs included
masonf: dialogs (both modal and non modal), details elements, popup
api, possibly select
masonf: Agenda on open ui today to discuss for a different pseudo
class for select
masonf: general consensus and hoping to hear resolution on an open
pseudo class
astearns: Queue up if you have questions
<TabAtkins> +1
<bramus> +1 for `:open`
<chris> +1 for :open
fantasai: May not have fully followed it, say its a details element
that's open, this would match open?
masonf: Correct
masonf: even though it's not in the top layer, the :open class is
unrelated
masonf: This is no longer a top-layer only thing
fantasai: Is it going to match things like form controls while open?
masonf: That's debatable. There was discussion on select whether or
not we should allow it to be visible as a thing
masonf: Some platforms done provide a calendar picker
fantasai: I like the idea of :open, useful in a number of cases,
hesitant to add it due to ambiguous points. We need a
definition that covers all the current and future elements,
so we have a consistent story for what open means
fantasai: A clear definition where any person can look at an html
element they have a clear idea of whether it can be open or
not
<fantasai> I just want to record strong +1 to plinss's comment
https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1193026841
ntim: If you put the open attr on dialog, it will visually appear
open because of the user agent stylesheet, but on the dom side
it wont be considered open, what should we match for that case?
masonf: In what sense wont it be open? it will be visible
ntim: It won't be tracked as open but will be visible. If you
dialog.setAttribute('open', true) as opposed to
dialog.showModal()
masonf: Difference will be whether or not events are fired?
ntim: attr will confused the browser because, especially, if you put
:open and then .showModal(), or weird combinations, you end up
in a broken state
ntim: dom doesn't consider just setting the open attribute to be
having the dialog open. The UA will use the open attribute.
Maybe one thing we could do is
ntim: Make the pseudo class match the dom state and change the UA to
use the new pseudo class.
ntim: and make the pseudo match the dom state. so you don't have
confusion between visually open and ..
masonf: There is an open issue for dialog. Open attribute behaves
weirdly in various cases
masonf: This proposal you make could be good tho
masonf: but I'd like to propose a working definition for open, for
things that can visually open and close, and when they are
open it matches :open
ntim: I think if you want to define a def for dialog, we need to
resolve which definition of open we want to take first
masonf: that's what I'm proposing, open things match :open
ntim: Like visually open, via show or attribute change?
masonf: The current dialog behavior is funny, but I think, if you add
the open attribute to a dialog, it becomes visible, I expect
the pseudo class to match
plinss: First I'm generally in favor of an open pseudo, I agree with
fantasai that we need a clear definition, like in the HTML
spec. this thing is in the modal state, how it gets in and
out of the state. I don't think we should have in the CSS
spec, that this is openish
plinss: needs a hard definition.
plinss: My other bigger concern is, coming from TAG perspective, we
have a problem of managing this kind of state
plinss: This isn't well defined on web platform, this is a mess
plinss: There's areas where things are controlled with an attribute,
a property, and with CSS Toggle spec we can open with a CSS
property
plinss: If css can do that, we can get into circularity issues
plinss: We need to take a step back and make sure it all plays nicely
together
<fantasai> +1
TabAtkins: We shouldn't have circularity here
plinss: One of the things I understand for toggles, offered defined
elements, something like details with open with a toggle,
should that represent this pseudo class?
TabAtkins: That's entirely author controlled
<dbaron> The :open pseudo-class should reflect something that is open
according to the markup language and its api.
plinss: Now I have an independent method for opening and closing
things. One or more of these may interact well the others
plinss: If an author is building a custom element, they should be
able to use a similar method the platform has
plinss: so if an author is building a custom element with open/close,
they should have a way to interact with this. If we say
toggle's is the way to do that, we need to know how it should
all work
astearns: Can we postpone this to a future call and have a separate
discussion about
TabAtkins: The design of it will be about getting to his concern more
directly, which I believe will resolve concerns here
TabAtkins: The issues you're bringing up has been true for CSS's
lifetime, it can do something that triggers off something
that's emulate-able by hand
TabAtkins: nothing new about :open that makes it weirder than
anything else
fantasai: Depends on how you define it
TabAtkins: Secondly, looping toggle()'s, only circularity if it's a
pure CSS loop
TabAtkins: If toggle()'s can hook up to something that can reflect
:open, it would be dependent on toggle() state, that is
intentionally not controllable by css.
astearns: The toggle() state is driven by js and user interaction
astearns: I'd like to close this off for now, and go back to the queue
astearns: but, I'd like to constrain this so we can get to a
resolution or choose not to
astearns: just about whether we start work on an :open pseudo
<masonf> Proposed resolution: add `:open` as a pseudo class, which
matches things that are in an "open" state. We need to
define that state carefully.
astearns: Lots of things to elaborate on that can be separate issues,
I want to drill down to objections to starting work, not
figuring out details
emilio: Was going to say something about what mason said, about the
pseudo class, I don't think we should use the attribute for
this. It's a separate issue and I'm happy to punt on this.
Don't need to discuss the rest. But I think that :open should
be based on the UA-internal state that happens from
openDialog.
masonf: Plus one yours and put a resolution into the chat. Agree I'd
like resolution on :open interest, then more issues for
precision
masonf: Regards to :modal, something similar to that would be great
today. needs a careful definition too
masonf: There is no :modal definition in the HTML spec
ntim: There is one
masonf: But it's missing :fullscreen definitions, etc
masonf: There's a definition of a modal dialog, but not :modal
dbaron: Was going to support the idea that if we agree to do this,
and say that we need formal definitions of what :open is,
where markup defines what it is to be open, so the html spec
would have those defs, this would address some of peters
other concerns, based on suggestions mason gave, dialog and
details and maybe select, and so on
dbaron: I'm thinking then, through the process of writing those def
formally, you avoid the circularity issues of a more vague
definition
<masonf> +1 dbaron, well said
bkardell: I don't object to us starting to define the pseudo class, I
do agree with david that the act of defining it can deal
with a lot of this
bkardell: State doesn't necessarily mean the same thing all the time
bkardell: We have controls that are unchanging, they're immutable in
their, that have particular meaning
bkardell: there's other things, where plinss was detailing, something
like summary/details, where perhaps it's not always shown
with a control nature, sometimes you want it open,
sometimes you want it closed
bkardell: They're matters of display, they're in the domain of css
bkardell: I favor us having a wider discussion and careful
articulation of that
bkardell: and how it all plays together
bkardell: I think that's important to make good progress
fantasai: :modal was more straight forward, I think we can come up
with a conceptual def of :open, and have the HTML spec
define it, don't think HTML spec should only define it
fantasai: We want the html spec as it evolves, and other languages,
to be able to easily and clearly understand what it should
match when its :open
fantasai: I don't think we have a clear idea of what that means yet,
and has intent to add something like this until we have a
proposal, where everyone agrees not he delineation where we
can extrapolate clearly without arbitrary decisions because
it's not a clear def that cuts through all the open or not
open items
fantasai: I'm not opposed to working on it, I would be opposed to
adding it to the spec right now, until some of these
questions are answered enough where we can make a fairly
clear argument for each element whether it's open or close.
<masonf> +1 to fantasai's point that we need a conceptual definition.
At least at the same level of detail as we have for :modal.
fantasai: Can try to draw the line, and then use that to extrapolate.
but I don't want to add something so fuzzy that we end up
making decisions that are inconsistent over time cuz we can
come up with something clear enough
<masonf> Proposed resolution: add `:open` as a pseudo class, which
matches things that are in an "open" state. We need to
define that state carefully, with a general conceptual
definition that can be used by HTML for the specifics
per-element.
<TabAtkins> I fundamentally don't understand where this is coming
from. We proposed the elements it would match. There's an
open question about if any <input>s should, which can be
quickly argued and answered in the thread.
astearns: Are you ok working on that resolution? in this issue? until
the point at which fantasai and the rest of the group agree
it's ready to go into the spec?
masonf: We agree with my proposed resolution?
astearns: Makes sense to me
astearns: Anyone want to make changes to the proposed resolution?
fantasai: Say work on defining an :open instead of just add it
astearns: Start work on an :open pseudo class, in the issue
<masonf> Proposed resolution: start work on an `:open` as a pseudo
class, which matches things that are in an "open" state. We
need to define that state carefully, with a general
conceptual definition that can be used by HTML for the
specifics per-element.
astearns: any other amendments to the proposed resolution?
<chrishtr> + to this resolution
<masonf> Proposed resolution: start work on an `:open` pseudo class,
which matches things that are in an "open" state. We need to
define that state carefully, with a general conceptual
definition that can be used by HTML for the specifics
per-element.
astearns any objections?
<tantek> +1
astearns: alright we're resolved to start work on an :open pseudo
RESOLVED: Start work on an `:open` pseudo class, which matches things
that are in an "open" state. We need to define that state
carefully, with a general conceptual definition that can be
used by HTML for the specifics per-element.
astearns: Thank you mason
masonf: Thank you
astearns: Anything else on this issue today?
CSS Contain 3
=============
Should style() queries allow !important flag?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7413
astearns: Who's gonna take this one?
florian: The syntax for style container queries, lets you specify a
property declaration representing the computed value, and
grammar wise, a prop declaration can include !important. but
that has no effect on the computed value
florian: question is, should we ban writing !Important or should be
keep it even though it has no effect?
fantasai: I think we should disallow this because it represents a
computed value, it has no concept of where it exists in the
cascade
fantasai: I don't feel the same about @supports rules which have a
similar syntax, in that case, you're asking is this syntax
supported and then it's fine to have !important be part of
that. but if add another !something later, it'd return null
emilio: I think I disagree with fantasai because even though it does
represent the computed value, what you write is a specified
value. You can query color: blue, and it's computed then
compared, but
emilio: it's a specified value right
florian: I don't feel strongly, seems to me it's easier if we can
copy/paste declarations from where they define and test
them, to test. That might drag a !important along the way.
If we allow it in @supports, could support it here as well.
But I don't feel strongly
miriam: Was thinking about resolving variables, custom properties in
a query, but they won bring along !important. never mind, I'm
fine either way
florian: If you're using actual css var, you're right, but if you're
using server side processor that has something similar to
variables, it might
miriam: That's true
astearns: We are out of time, is anyone else convinced by the copy
paste argument to not make a change to the spec?
astearns: or should we continue discussion in the issue?
astearns: Not going to get resolution to this, we will continue in
the issue. Bring it back to the agenda once we have clarity
Received on Wednesday, 24 August 2022 23:05:42 UTC