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

[CSSWG] Minutes Telecon 2022-08-24 [css-flexbox] [css-selectors] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Aug 2022 19:05:00 -0400
Message-ID: <CADhPm3tnbSUMLjGABvfE3=gG5rW6=t-5A+j_fpDnQUcMpjj=yw@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 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

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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Aug/0004.html

  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

  Lea Verou

Scribe: argyle


  <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
  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
  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
  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
  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
  iank: This is just for static pos
  bradk: Make sure it's clear in the spec


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
  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

  <fantasai> I just want to record strong +1 to plinss's comment

  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
  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
  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
  <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
  masonf: Plus one yours and put a resolution into the chat. Agree I'd
          like resolution on :open interest, then more issues for
  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
  <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
  <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
  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
  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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:20 UTC