- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Jan 2022 19:03:58 -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 UI
------
- There was some concern that the overall approach defined in pull
request #6537 (Define how to compute the kind of widget to use
for an element) defines things that should be defined in HTML.
This is a larger conversation that will go back to the issue and
may also want to engage with OpenUI.
CSS Values
----------
- RESOLVED: Add `first-valid` and please add an issue to bikeshed the
name once we better understand the scope (Issue #5055:
Allow an inline way to do "first value that's supported")
CSS Contain
-----------
- RESOLVED: Drop the function syntax for querying sizes, but keep the
function syntax for querying styles (Issue #6870: Spec
syntax for size queries)
CSS Flexbox
-----------
- Issue #6794 (Change content-size suggestion to min-intrinsic
instead of min-content?) needs some deep investigation of the
spec to determine the right behavior. TabAtkins and fantasai will
look into it further and add this back into the agenda when they
have a proposal.
- RESOLVED: Reject the proposed change but clarify the specification;
we invite Serifo to comment further if they have
objections to this resolution (Issue #6822: Percentage
height resolution of children of flex items with
indefinite flex basis)
Toggle proposal
---------------
- TabAtkins introduced the proposal for a toggle switch and requested
feedback and questions on github: https://github.com/tabatkins/css-toggle
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jan/0012.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins Bittner
Delan Azabani
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Daniel Holbert
Dean Jackson
Brian Kardell
Jonathan Kew
Una Kravets
Rune Lillesveen
Ting-Yu Lin
Peter Linss
Alison Maher
Eric Meyer
François Remy
Morgan Reschenberg
Florian Rivoal
Cassondra Roberts
Alan Stearns
Miriam Suzanne
Lea Verou
Zheng Xu
Regrets:
Chris Lilley
Scribe: emeyer
astearns: Any changes to agenda?
sfraser: Request to move #7 to next week.
astearns: Yes, moved.
CSS UI
======
Define how to compute the kind of widget to use for an element
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/6537
florian: I reviewed this a while back. No issue with the specifics;
issue with the overall approach.
florian: Overall, I think it's odd to have a CSS spec define every
type of HTML widget.
florian: The definition of a text field is “a one-line input that
looks like a text field”. That's almost tautological.
florian: Definitions of inputs should be over in the HTML spec. I
think we should define widgets that define like foo, those
that act like blah.
florian: If we think this is the right approach, the text content is
fine. But I don't think this is the right approach.
zcorpan: I co-authored this. I hear two things. One: the algorithm
should refactor so it doesn't repeat. Two: the definitions
are vague.
zcorpan: If the WG thinks descriptions of rendering should be in
HTML, that's fine with me.
florian: The way they look is tied to how they behave and what they
do. All these are sort of kind of replaced elements, but
they seem outside of the scope of what CSS controls, in
terms of both appearance and behavior.
florian: If we want to specify their appearance in detail and think
the specifics of that should be in CSS, I see why you want
it here.
florian: Do we expect that this would define how things would look in
not-HTML languages? That seems odd.
zcorpan: For the applicability of other languages, I see that as
hypothetical.
florian: You can style plain XML with CSS.
zcorpan: I don't see why someone would want to invent a new language
that recycles stuff from HTML.
florian: I stand by my original position, but I feel less strongly
about it.
florian: This seems like it touches on OpenUI and what they plan
to do.
astearns: Any other opinions?
astearns: Florian and Simon, do you think we can resolve on this
today, or should we pull in others?
florian: I think refactoring is good, we can at least do that. We
should also talk with Greg [Whitworth].
<bkardell> there is open agenda space in the openui call - suggest
you add it?
<bkardell> there is a call tomorrow
zcorpan: I don't think it's super urgent at this point.
florian: This has helped me progress. We'll get back to this later?
astearns: We'll take this back to the PR and the issue and see what
we can do there.
CSS Values
==========
Allow an inline way to do "first value that's supported"
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5055
TabAtkins: This is trying to address an issue that's become more
prevalent as variables have become more common.
TabAtkins: CSS lets you use new features and fall back to old ones by
writing something twice.
TabAtkins: Variables break this. We assume things are valid at parse
time, and only find out later whether or not they are.
TabAtkins: This same problem is going to come up with more things
that do things at parse time.
TabAtkins: Proposal is to allow things to sub in the first thing the
UA understands at parse time.
<dbaron> ... has to be the full value of the property
TabAtkins: This will need some clarification about how it can or
can't be nested. So we'll want to define some contextual
stuff.
TabAtkins: Overall it's an attempt to get parse-time fallback
behavior.
<fremy> huge +1 of course
lea: This would be incredibly useful. Would it be available in
descriptors as well?
TabAtkins: I don't see why not.
florian: So this is no different than writing a thing twice if you
use it without variables?
TabAtkins: Correct.
emilio: This would go away at parse time?
TabAtkins: Correct.
emilio: That seems fine.
astearns: Any concerns?
astearns: So the resolution is to add `first-of` to Values. Any
objections?
florian: Just wondering about the name of it. If people see this out
of context, will they think it's a list manipulation thing?
<lea> Yeah, as much as I like terse names, first-of() is confusing
TabAtkins: It's possible there will be misinterpretation, but at
least they'll run into confusion quickly.
florian: How about `first-valid`?
<miriam> +1 first-valid
<smfr> +1 on first-valid
TabAtkins: I like it.
fremy: I support that.
astearns: We can bikeshed the name later. Any objections to the idea?
RESOLVED: add `first-valid` and please add an issue to bikeshed the
name once we better understand the scope
CSS Nesting
===========
Syntax suggestion
-----------------
github: https://github.com/w3c/csswg-drafts/issues/4748
astearns: Are we ready to resolve on this? I don't see agreement in
the very large discussion.
TabAtkins: I'd prefer to push this off.
<fantasai> +1 to deferring
astearns: Tab, it would be great if you could summarize where we are
and what you think we should do.
TabAtkins: Will do.
CSS Contain
===========
Spec syntax for size queries
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/6870
miriam: A while back we added the `style` container query, so we
added `size`. Would we rather have size queries match media
queries? I'm happy either way.
una: I like the solution of of dropping the size function syntax like
in media queries, but requiring the style function for querying
styles.
<dbaron> I *think* (although I'm not sure) that what I wrote in the
issue was the same thing fantasai argued for on the call.
<fantasai> wfm
RESOLVED: Drop the function syntax for querying sizes, but keep the
function syntax for querying styles
CSS Flexbox
===========
Change content-size suggestion to min-intrinsic instead of
min-content?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6794
fantasai: I think I need to go back to read the flexbox specs from
the very beginning to figure out what I think should happen
here.
fantasai: I think we have to decide what behavior we want here and
how to achieve that.
fantasai: I'm not sure I'm clear on any of that.
TabAtkins: Same here. This is important and VERY difficult to reason
about correctly, and we need more time.
dgrogan: Base issue is that aspect-ratio define sizing one way and
flex defines it another
dgrogan: and they conflict when you aspect-ratio a flex item.
TabAtkins: That's what I understand. I don't know how to resolve that
yet.
dgrogan: Before we start talking about changing the spec, should I
change Chrome to match Firefox where they apply both
minimums?
TabAtkins: Wouldn't that answer the question?
TabAtkins: Because if you change to match Firefox, then the spec will
just match whatever you do.
dgrogan: Okay, let's pinch this off now.
astearns: Will remove Agenda+ and will put it back once fantasai and
tabatkins have time.
iank: Can we do this quickly? It's a major problem.
TabAtkins: That's the goal.
astearns: Let's wait on this for now.
Percentage height resolution of children of flex items with indefinite
flex basis
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6822
dgrogan: This is also an interop issue. Chrome recently switched from
WebKit to Firefox behavior, which we think is what's
specced. Sergei from Igalia has a good argument for why
WebKit might be better and should be specced.
TabAtkins: Elika says she agrees with dgrogan that we should try not
to introduce new exceptions unless there's a strong reason
and we can describe it clearly.
dgrogan: When you have a column flexbox and the item's flex basis is
content, and a child of that item has a percent height do we
resolve it in the final pass or do we make the flex item's
height indefinite?
dgrogan: The spec currently roughly says it's indefinite. Proposal
from Igalia is to make the child of an item with content
flex basis resolve its height.
Rossen: When you say this, are you talking about the measurement of
item in the last pass when you would have already computed
all of the contributions of flex items?
fantasai: And the child with the percent is a block level box.
Rossen: I'm struggling to figure out why we would resolve the percent
height, and more importantly how, if we don't do it anywhere
else.
dgrogan: The debate is around when do we resolve that height. Are we
on the same page for that?
dgrogan: The argument is, we already have a bunch of definiteness
exceptions, so why not do another?
Rossen: In the contribution pass, you are not resolving percentages.
Which will most likely give the item a height based on its
content. When you go to the last pass, if you resolve the
percentage of the block child, it will probably overflow or
underflow. So do we allow that overflow or underflow to
satisfy the percentages?
dgrogan: That's a good restatement.
dgrogan: I don't know that I can defend this.
oriol: I haven't been following this in detail. I also felt like
WebKit is doing something different than the proposal. I don't
have a strong opinion here.
iank: I believe WebKit has a bug that it's resolving during the
contribution phase. So looking at its output is a little
complicated for teasing out the intended result.
iank: I somewhat prefer the Firefox behavior currently. It's aligned
somewhat with other behaviors.
fremy: If you have the exact same scenario, but the page size is
bigger, does that mean the thing won't get shrunk?
dholbert: I think it would depend on other things, and I think
unrelated to this issue.
Rossen: It's hard to argue about later stages if the earlier stages
are inconsistent.
Rossen: I don't know if we have good progress here. This should maybe
go back to the issue. it sounds like the current spec
[carrier lost]
astearns: It sounds like we're converging against the original
proposal?
iank: I think Firefox and Blink are correct as per the spec's
definition of definiteness.
dgrogan: Correct.
<dholbert> (agreed)
astearns: Is what's in the spec at the moment sufficient or does it
need to be more clear?
dgrogan: I think there's a part of the contribution spec that needs
to be tightened up.
fantasai: I agree, we need to clarification in the spec.
RESOLVED: Reject the proposed change but clarify the specification;
we invite Serifo to comment further if they have objections
to this resolution
Toggle proposal
===============
<TabAtkins> https://tabatkins.github.io/css-toggle/
TabAtkins: There a lot of weird and inaccessible hacks to toggle
checkboxes and `details` and stuff.
TabAtkins: There are some states on an element in the page that other
elements can affect. This spec is a proposal to do that.
TabAtkins: You set up toggles and their metadata (initial value,
etc.) and you can declare certain elements see those
toggles.
TabAtkins: The toggle pseudo-class lets you select on states.
TabAtkins: The toggle-root property is consulted at the same time we
resolve animations.
TabAtkins: This resolves circularity issues entirely.
TabAtkins: We're interested in doing an experimental implementation
this year. It ties into OpenUI work.
TabAtkins: Not going to ask for acceptance resolution now, but ask
all to review the draft and open issues on Tab's
repository.
<TabAtkins> https://github.com/tabatkins/css-toggle
<tantek> +1 I like this in concept, thanks TabAtkins for drafting
this. Still reading.
<bradk> Sounds like a great idea, based on what Tab has said just now
<fremy> for me to recall: 1/ circularity is not solved if :toggle()
can display:none the "tab" element 2/ I don't like the a11y
heuristics, they are risky
<bkardell> TabAtkins: have there been updates post tpac breakouts?
TabAtkins: There have been minor updates since TPAC, nothing major.
astearns: And that's time.
[post-meeting IRC conversation]
<bkardell> can we maybe create an issue for this in the csswg repo
and link up the minutes of the two breakouts?
<Rossen> I like the toggle proposal. One point that didn't come
through for me is hoy and why this is better from a11y pov.
Perhaps you can elaborate in the spec
<TabAtkins> fremy: display:none isn't an issue - it will prevent the
element from *creating* new toggles (because we don't
resolve styles), but it won't stop updating the toggle;
that's based on element, not box.
<bkardell> I feel like there was a lot said in those that it is a
shame to lose in reading, even from members of csswg itself
<TabAtkins> bkardell_: Thank you for volunteering. ^_^
<fremy> @TabAtkins: hmmm, yeah, I will file an issue with a clearer
example, but you might be right
<bkardell> I am happy to, but it's not my proposal so I thought worth
asking.
<TabAtkins> Rossen: Yes, that needs more than five minutes to talk
about. Suffice for now to say that we've given it a *lot*
of thought, and believe that in common cases we can infer
the appropriate aria relationships automatically, and set
up the a11y tree accordingly to be helpful in the same
way as a full-fat "aria sprinkled everywhere by an
expert" solution would.
<Rossen> TabAtkins: love it
<bkardell> TabAtkins: https://github.com/w3c/csswg-drafts/issues/6991
<bkardell> let me know if I did an injustice or something - happy to
edit or remove
Received on Thursday, 27 January 2022 00:04:38 UTC