W3C home > Mailing lists > Public > www-style@w3.org > January 2022

[CSSWG] Minutes Telecon 2022-01-26 [css-ui-4] [css-values-4] [css-contain-3] [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Jan 2022 19:03:58 -0500
Message-ID: <CADhPm3u+s0KPWn=uQ9_RGTTcomp7qvZ=PAqv7GLN8Cy9RjWLQg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:20 UTC