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

[CSSWG] Minutes Telecon 2022-06-22 [css-color-4] [css-images-4] [css-contain] [css-pseudo] [fullscreen]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Jun 2022 19:27:35 -0400
Message-ID: <CADhPm3uX0nYCn6KdtgBcDLzUwFV4J=9K+X2W5uZjvX0iCFLszg@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.

Summer F2F

  - RESOLVED: CSSWG F2F in NYC Aug 1-3, further details incoming on
      private list
      - Please RSVP as soon as possible if planning on attending in
          person or virtually in order to get logistics confirmed:

Color 4

  - RESOLVED: Republish Color 4 and 5 (Issue #7393: CSS Color 4 to
              Candidate Recommendation)
  - RESOLVED: Color 4 to CR when timing permits (Issue #7393)

Images 4

  - A resolution for republishing will be called next week so that
      people have time to review the changes (Issue #7043: Long overdue
      for republishing)

CSS Contain

  - RESOLVED: Initial value is `none` (Issue #7066: Revisit decision to
              make style the default container type)
  - RESOLVED: All elements are style containers by default (Issue #7066)

CSS Pseudo

  - RESOLVED: Go with Delan's option 2 [For ::highlight pseudos, we
              redefine the "inherited value" of 'color' at the root, so
              instead of being the initial value (as normal) it is
              currentColor]. (Issue #6774: Defaulting ‘color’ in :root


  - RESOLVED: Fullscreen elements should inert the stuff behind them,
              and match :modal (Issue #7311: Should :fullscreen be a
              modal state?)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0014.html

  Adam Argyle
  Rossen Atanassov
  Tab Atkins Bittner
  Delan Azabani
  David Baron
  Mike Bremford
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Mason Freed
  Megan Gardner
  Brian Kardell
  Jonathan Kew
  Vladimir Levin
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Eric Meyer
  François Remy
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou
  Sebastian Zartner

Daniel Holbert

Scribe: TabAtkins

Summer F2F

  Rossen: We've tallied the summer f2f results
  Rossen: Decided to hold as much of an f2f as possible in person
  Rossen: For those who can make their way to NYC
  Rossen: For everyone else, we'll make sure we have proper virtual
          facilities for participation
  Rossen: Picked timing and place based on allowing other participants
          to allow TAG f2f, as well as having a geo location that's
          okay for global participation
  <astearns> This will also allow us to test out substantial virtual
             participation pre-TPAC
  Rossen: No one's going to be perfectly satisfied unless they're
          already in east coast time zone
  Rossen: Putting it earlier would be hard for lack to warning for
          travel and location
  Rossen: So fyi to everyone
  Rossen: Also wanted to give a chance to talk about hosting

  <jensimmons> Aug 4-6 are the proposed dates
  TabAtkins: 4-6 wasn't the dates proposed, 1-3 was
  jensimmons: Rossen sent 4-6 in the email
  Rossen: Oh I got confused, was looking at July
  <TabAtkins> DATES ARE AUGUST 1-3
  TabAtkins: Plan is to rent a loft in Tribeca with excellent
             ventilation, able to host 20 ppl in common spaces
  TabAtkins: Need confirmation on dates and location in order to
             confirm the venue

  lea: Is this an fyi on date/location or are we still deciding?
  Rossen: This is the current proposal. If you have a hosting proposal
          elsewhere we can consider...
  florian: There's not much time to hesitate
  fantasai: I have all the logistics ready, all I need is absolute
  TabAtkins: I have about a day and a half to cancel the reservation if
             we go elsewhere
  Rossen: Okay so this is time-sensitive. If anyone has another
          proposal this is when to surface it, otherwise I'm calling
          for resolution
  fremy: Do you know how many people will make it in person vs remotely?
  Rossen: Looks like more than a dozen people from confirmations
  lea: Note that speculative survey responses are different from actual
  fantasai: We're very time-sensitive, can we do a survey on this call?
            we need to make a call on this particular venue

  STRAW POLL: (1) will attend in person in NYC Aug 1-3 (2) will not
      attend in person
  <astearns> 1
  <smfr> 2
  <faceless> 2 - dateclash, sorry
  <lea> 2
  <jensimmons> 1
  <jfkthame> 2
  <chris> 2
  <dandclark> 2
  <Rossen> 1
  <vmpstr> 2
  <emilio> 1
  <futhark> 2
  <TabAtkins> 1
  <florian> 1, probably
  <fremy> 2
  <fantasai> 1
  <plinss> 1, tentative
  <bramus> 1
  <argyle> 1 tentative
  <miriam> 1, tentative
  <emeyer> 2 (most likely)
  <bradk> Virtual for me
  <dbaron> likely 2, though remote chance of 1 if I hear more details
           about ventilation etc. in venue
  <delan> 2
  <TabAtkins> (8 attendees on call, with 3 tentative attendees)
  <fremy> sounds like a good enough group to me
  Rossen: So that answers the participation question, and this'll be as
          hybrid as we can make
  <jensimmons> Like dbaron I'd love to hear details about ventilation.
               (Link to Airbnb venue would be one way to do so. I'm
               presuming it has windows that open.) It'd be good to
               agree about masking policy as well.
  <astearns> I suggest we start with TPAC plans for vaccination
             requirements, inside masking, etc.
  Rossen: This looks like a reasonable number. Final call for
  <TabAtkins> https://wiki.csswg.org/planning/nyc-2022 for details
  <TabAtkins> https://www.airbnb.com/rooms/53428467?source_impression_id=p3_1655914572_%2BSlp4jp%2FDP%2B%2B8OJl

  RESOLVED: CSSWG f2f in NYC Aug 1-3, further details incoming on
            private list

  fantasai: Tab just linked to wiki page, plz register asap to
            participant list so we can get logistics together
  fantasai: Let us know dietary restrictions so we can make sure
            everyone has food
  fantasai: Allergies but also dislikes are fine
  <fantasai> (please distinguish which!)
  <fantasai> (and level of allergy)
  <castastrophe> late logging onto IRC but I'm a 1 for attending as well

Color 4

CSS Color 4 to Candidate Recommendation
  github: https://github.com/w3c/csswg-drafts/issues/7393

  Rossen: Looks like you wanted to ask for additional resolutions?
  chris: Last week we made some Color 4 and 5 resolutions
  chris: I wanted to request a new WD
  chris: Not many changes from a couple months ago, but want an
         up-to-date WD
  chris: Takes at least a week for CR
  Rossen: So repubbing Color 4 and 5, what changes?
  chris: Some changes we agreed on last week; Color 5 punted
         color-contrast() to Color 6
  Rossen: Objections to republishing?

  RESOLVED: Republish Color 4 and 5

  chris: Color 4 has good test results and is being implemented, we
         should get CR quick
  Rossen: Anyone need more time to look over test results?
  Rossen: In order to move Color 4 to CR? If not we can resolve today
  Rossen: Objections for Color 4 CR?

  RESOLVED: Color 4 to CR when timing permits

  <chrishtr> Congratulations!

Images 4

Long overdue for republishing
  github: https://github.com/w3c/csswg-drafts/issues/7043

  chris: We just resolved to ship something in Images 4 and the spec
         hasn't been updated in 5 years, come on
  TabAtkins: Chris, you're married to one of the editors
  fantasai: Need to evaluate the changes list, which I can do and we
            can revisit next week?
  chris: I've updated the changes list
  fantasai: Okay I'll review. I'm okay with provisional resolution to
  Rossen: Let's do it next week when there's been review. Taking the
          resolution isn't hard.

Republishing Tasks Permathread
  github: https://github.com/w3c/csswg-drafts/issues/6900

  chris: That was color 4 and 5

CSS Contain

Revisit decision to make style the default container type
  github: https://github.com/w3c/csswg-drafts/issues/7066

  miriam: There's been more discussion. I left a summary, well, longer
          than that, at the end of the thread. No responses since.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/7066#issuecomment-1158184820
  miriam: So same question as last time - last time we talked about it
          it split into several questions.
  miriam: 1) Do we need style queries? I think we do, I argued for it.
  miriam: 2) If we have them, should every container be a style
          container by default. I think answer is yes for authors,
          question is perf.
  miriam: In convo with emilio it seems the perf issues are less (maybe
          not none) if the impl first matches selectors then looks for
  miriam: If you're going the other way and matching containers first,
          and everything's a container, you don't get much filtering.
  miriam: Those perf issues are only for people using broad container
          queries (not using name, etc) and broad selectors.
          Multiplying those together means lots of searching
  miriam: I don't know how bad that perf hit would be, so hard for me
          to judge on that.
  miriam: Proposal moving forward is [missed]
  miriam: If we start now with an initial value of none, browsers can
          release size queries, and I think that's the right syntax
  miriam: Other question: people will set container types in various
          places, also names
  miriam: Suggestion was to set type in another longhand. But that
          doesn't work for names.
  miriam: I think the general solution is an additive cascade. No
          specific solution, need general solution here.

  Rossen: Any further comments?
  <astearns> read the comment and support the suggested resolution
  futhark: I'm supportive, I said so on her writeup
  futhark: Positive to the proposed resolutions
  futhark: Important thing now for chrome and safari is to end up with
           the initial value of `none`, will let us ship CQs without
           having to worry about whether everything's a style container
  futhark: We're exploring style queries; right now it doesn't sound
           that bad to have them as default

  fantasai: I'm in favor of miriam's points
  Rossen: Miriam could you summarize?
  miriam: First resolution, initial value is `none`
  Rossen: Objections?
  <chrishtr> +1 to Miriam's proposed resolution.
  <SebastianZartner> +1 from me, too

  RESOLVED: Initial value is `none`

  miriam: Since style queries are in the spec, probably need a
          resolution for every element being a style container by
          default. We'll spec that out and adjust as needed as impls
          start showing up.
  fantasai: Resolution is that every element *is* a style container,
            regardless of `container-type`.
  emilio: Still skeptical about this.
  emilio: Gecko's CQs are like Blink's. It's a little more annoying to
          have every element be a style container.
  fantasai: Argument is a lot of people will do that anyway because
            it's useful to query, so you'll take that hit on a lot of
            pages anyway.
  fantasai: That's our expectation.
  emilio: I don't know if my expectation matches, but you know more
          about CSS authors. Okay with that for now, guess I don't

  RESOLVED: All elements are style containers by default

  <SebastianZartner> Congrats Miriam!
  <bramus> Nice!
  <fantasai> Side question, should 'none' be 'normal' now since
             everything's a style container?

CSS Pseudo

Defaulting ‘color’ in :root highlights
  github: https://github.com/w3c/csswg-drafts/issues/6774

  <delan> https://github.com/w3c/csswg-drafts/issues/6774#issuecomment-1083055006
  delan: For highlight pseudos, setting color:currentColor means the
         color doesn't change when you highlight with that pseudo,
         compared to the original color underneath
  delan: Editors agreed this is what should happen if color hasn't been
         set anywhere for a highlight
  delan: I think the way this is achieved isn't actually specified. My
         best interp of Cascade is that we don't actually do that, and
         the spec says the default color of a highlight pseudo becomes
  delan: Three steps
  delan: First, when you have an inherited property (all props are
         inherited for highlights), they do the defaulting by way of
         "inherited value"
  delan: Second, inherited value is value from parent, unless you're at
         root, in which case it's initial value
  delan: Third, initial value of color property is CanvasText
  delan: Which is generally black (in light mode)

  delan: So this raises the question of how to fix it
  delan: Which step we add an exception for affects what happens when
         you use initial/inherit/unset
  delan: One option is to say that for highlights, the initial value
         isn't CanvasText, it's currentColor
  delan: Here if you set color to initial/inherit/unset, they'll become
  delan: Second option is for highlights, the inherited value isn't the
         initial value at root, but instead currentColor
  delan: So when you set color to inherit/unset you get currentColor,
         but initial means canvastext
  delan: I like this the best
  delan: Third option is to change defaulting for highlight pseudos and
         say that for root highlights, you don't inherit, we just set
         the value.
  delan: So all the keywords would become canvastext
  delan: Not sure my understanding is correct, but it's how I see
         things. What should we do?

  fantasai: That was a great explanation of a complicated issue
  fantasai: I think either first or second makes sense to me
  fantasai: If no one has a reason to do something different your pref
            makes sense to me. I suspect your pref is the easiest to
  delan: I think all three are possible to implement. I preferred 2
         over 1 because in option 2 you can say color:initial and get
         black, and I feel like that intuitively makes sense.

  emilio: Doesn't 2 change the - fix the weirdness around currentColor
          in highlights?
  emilio: If we change how it inherits doesn't it fix all the
          shenanigans about what currentColor means in highlights?
  emilio: Or is this orthogonal
  delan: I don't think it does
  delan: Are you talking about where we have the exception for
         currentColor where it means this special thing for highlights?
  emilio: yes
  delan: Then no, this actually relies on that.
  delan: Unless we don't literally use the word "currentColor" in our
         fix and just say that it "keeps the same color"
  delan: But as worded it relies on that currentColor behavior
  emilio: More generally, currentColor refers to the computed value of
          the color property, how can you inherit it?
  emilio: In impls the color property is special bc you don't want to
          resolve currentColor by walking all the way to the root
  emilio: and currentColor disappears at computed value time, before
  emilio: But if this is just an impl detail, eh, this just makes color
          more special, but given previous things we're past that point

  Rossen: So hearing some gravity towards options 1 and 2, particular 2
          as delan's fave. Is this something we can resolve on?
  delan: Restating option 2: For ::highlight pseudos, we redefine the
         "inherited value" of 'color' at the root, so instead of being
         the initial value (as normal) it is currentColor.
  <fantasai> currentColor does not disappear at computed value time...
             that's one of the important things about it
  Rossen: Objections?

  RESOLVED: Go with Delan's option 2.

  <fantasai> WFM

CSS Backgrounds

The shape of box-shadow should be a circle for a box with
    border-radius:50% and big spread
  github: https://github.com/w3c/csswg-drafts/issues/7103

  [looking for Oriol on the call]
  fantasai: Let's push to next week


Should :fullscreen be a modal state?
  github: https://github.com/w3c/csswg-drafts/issues/7311

  chrishtr: We introduced :modal, which brought to our attention that
            Chrome impl of FullScreen makes it modal (stuff behind is
            inert) but other impls don't do that
  chrishtr: Think we should resolve on whether fullscreen is modal,
            which both affects inert and whether :modal applies to it
  chrishtr: Don't have a strong opinion on how we go

  ntim: I think it makes sense to make the stuff behind fullscreen inert
  ntim: But not sure webdevs would expect :modal pseudoclass tomatch in
        this case
  <TabAtkins> Aka *my exact argument for why we should have named it
  emilio: Unsure what webkit does for fullscreen
  ntim: webkit's impl is old but if we redid it I'd make it inert
  emilio: In firefox you can interact with stuff behind it; you can set
          pointer-events:none and then interact with the page
  ntim: I don't have strong opinion, but it seems unexpected that you
        can do that
  emilio: I don't particularly mind either way, was just pointing out
          that you can, unless you do the chromium thing of making the
          underlying page inert

  fantasai: This is less of a style question. I think the inertness is
            less significant
  fantasai: Think we need to understand if there are use-cases for
            being not inert
  fantasai: Unsure we're equipped to resolve on this during this call
  fantasai: probably need info from people authoring fullscreen stuff
            and see if it's necessary to fullscreen something that
            doesn't take up the whole screen
  ntim: This issue aside, it seems unexpected either way for :modal to
        apply to fullscreen elements, regardless of whether stuff
        behind is inert
  ntim: :modal comes from modal dialogs
  fantasai: They might not, but we decided it means things with modal
            qualities. Fullscreen might not be first in mind, but if it
            has those qualities it should match
  <flackr> +1
  <masonf> +1

  flackr: If the content behind wasn't inert it would be in tab order
          as well, which could be confusing if you could tab out of the
          fullscreen element
  emilio: fair
  jensimmons: This raises a11y memories, if visually a fullscreen
              element covers everything, so assumption is the stuff
              behind isn't accessible, having it not be inert could
              make it different for people using other a11y tools
  jensimmons: I'm wondering what the use-cases would be for making the
              contents behind a fullscreen *not* inert
  jensimmons: Maybe there should be a way to toggle it off, but default
              should be for inert
  fantasai: I buy that
  <bkardell> agree
  <masonf> +1
  Rossen: strong agree
  <bramus> +1
  <chrishtr> Agree on inert making sense given these arguments
  <SebastianZartner> +1 for what jensimmons said.
  emilio: fair point. Then :modal should apply to fullscreen.
  <florian> +1 to Jen

  fantasai: Right, so decision is whether it's inert, and whether
            :modal applies is a consequence
  masonf: Strong agree with points, think fullscreen should inert the
          rest of the page

  masonf: Do we include special provisions for fullscreen escaping that
          inertness, like dialogs have?
  masonf: Like if you inert the entire page the fullscreen shouldn't be
          inert, need provisions for that
  ntim: That's what fullscreen does
  masonf: Sure just want to make sure it's captured

  Rossen: additional thoughts or objections?
  plinss: In context of dialogs there's clear spec in html of what puts
          the dialog into a modal state
  plinss: in my mind that is what puts into a :modal pseudoclass
  plinss: Think it's important to not just catch things that are
  emilio: Yeah fullscreen spec should define the modalness
  plinss: So as long as it's defined that fullscreen puts it into this
          state just like dialog, unsure that we should just auto-apply
          it because it resembles modalness
  Rossen: So if I understand, fullscreen elements *are* modal from html
          behavior like dialogs, and rely on same behavior. Is that
  plinss: I'm saying :modal shouldn't apply unless something is
          *defined as* "being modal", not just because it's kinda
          modal-ish in some respects. HTML is very clear about modal,
          need to respect that.
  plinss: So if fullscreen uses that same definition it's fine.
  <ntim> https://html.spec.whatwg.org/multipage/interactive-elements.html#is-modal
  <SebastianZartner> Maybe we can at least resolve on fullscreen
                     elements making the reset inert.
  masonf: +1 to that
  masonf: Note that HTML doesn't define "being modal", it defines how a
          dialog becomes modal. But that can probably be pulled out
          into a proper definition.

  RESOLVED: Fullscreen elements should inert the stuff behind them, and
            match :modal
Received on Wednesday, 22 June 2022 23:28:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 June 2022 23:28:17 UTC