W3C home > Mailing lists > Public > www-style@w3.org > February 2021

[CSSWG] Minutes Telecon 2021-02-17 [css-selectors] [css-page] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Feb 2021 19:02:11 -0500
Message-ID: <CADhPm3vQVTod4_70DwmU7CwVq+w43H2MBPHnJtw8862wZ53rpg@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.


  - The group didn't agree on if the heuristic description for
      :focus-visible should be updated to detail interactions with the
      Shadow DOM (Issue #4893: :focus-visible and Shadow DOM). If it
      is updated, it wasn't clear if the guidance should be to bubble
      :focus-visible to the host or not.
  - Part of the conversation around issue #5885 (:focus-visible
      matches on initial programmatic focus) was about where the
      browser should be drawing a focus ring which is a discussion
      that should be held with the WHATWG. The discussion in the issue
      will be focused back to the pseudo class itself and if it's
      specified correctly.

CSS Page

  - RESOLVED: The stuff inside @page or @margin rule are descriptors
              but act like properties for behavior and cascade (Issue
              #5970: Should page descriptors support `!important`?)
  - Issue #5970 still needs a resolution on how variables will be
      handled. The proposal on the call was for them to be accepted
      and to inherit from the root. There were concerns about
      inheriting from the root causing issues when interacting with
      media queries so discussion will continue on the github.

CSS Contain

  - The group was unsure if they should allow container queries to
      propagate (Issue #5913: :root/body viewport propagation and
      containment). There will be an effort to check current usage to
      verify that there's no risk of breakage if it's disallowed.
      Discussion will continue on github to see if there's a way to
      allow propagation without running into a circularity problem.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Feb/0010.html

  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Oriol Brufau
  Emilio Cobos
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Sankit Joshi
  Jonathon Kew
  Vladimir Levin
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  Myles Maxfield
  Tess O'Connor
  Manuel Rego Casasnovas
  François Remy
  Cassondra Roberts
  Devin Rousso
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

  Rachel Andrew
  Tantek Çelik
  Brian Kardell
  Morgan Reschenberg
  Greg Whitworth

Scribe: dael


:focus-visible and Shadow DOM
  github: https://github.com/w3c/csswg-drafts/issues/5893

  rego: Both our selectors topics are about :focus-visible. This is
        about what happens when you have shadow DOM
  rego: focus pseudo element matches when you have focus in a shadow
        tree so matches in shadow-host. Wondering if :focus-visible
        should match.
  rego: Special thing is WK has wk-direct-focus pseudo class
  rego: People use it in UA stylesheet to avoid outline when you focus
        in the shadow tree.
  rego: In chromium in this case if you focus the input in the shadow
        tree you get the focus indicator. I believe :focus-visible is
        about avoiding people removing the outline with focus
  rego: Tricky part is in theory you shouldn't be able to know if an
        element is shadow host. Thanks to that you could check if it
        is a shadow host. There are other cases where you can do that.
        shadow host only matches in some cases. Need to think about it
  rego: With WK solution you can inspect if it's in shadow host
        because you can focus it and check if there's an outline shown.
  rego: It's a trick.

  florian: Question on indirect level. Asking if we should show
           :focus-visible in this case, but :focus-visible isn't
           defined when it shows. There's heuristics, but it says it
           should match when focus indicator is shown. Are you trying
           to spec more detail on when browser shows?
  rego: It would be adding one more item on the heuristic list to
        allow this case. One could be browsers don't show focus
        indicator in shadow host when there's an element in shadow
        tree with focus. It would be add a heuristic since current
        impl follow the heuristic. It's non-normative, but adding one
        more heuristic

  Rossen: Back to shadow root topic. I was re-reading thread in issue.
          Appears topic is discussed but not solved.
  Rossen: If I hear you, you're saying there are other precedents
          which would allow shadow root detection. If this is a fact
          we shouldn't necessarily add things to make it easier and
          more obvious to detect
  Rossen: Where is the current thinking on that?
  rego: When you focus an element you're not sure if it will match
        :focus-visible. When you focus inside shadow tree if shadow
        host doesn't match maybe you have it for a reason because user
        did a different way to focus.
  rego: There's another open issue on how that makes shadow host
  Rossen: Right. I think Alice's last comment summarizes it well. "By
          design :focus-visible is not guaranteed to match when an
          element is focused, so at best it would be a way to
          heuristically detect that something maybe-probably has a
          shadow root. Compared with the user harm from authors
          disabling focus styling, which is the problem :focus-visible
          is intended to solve, detecting that something might have a
          shadow root seems like it's at the opposite extreme of the
          priority of constituencies."
  Rossen: This doesn't seem to have the answer. I see your comment
          pointed to another issue. Seems up in the air
  rego: I agree with Alice. I think Alice would be fine not matching
        :focus-visible in shadow root. emilio might have something to
  emilio: I agree with Alice but for a different reason. Don't agree
          we're only probabilistically exposing. Given spec heuristics
          you can force :focus-visible to show. If we want
          :focus-visible to be used it needs to not match shadow host
          or not match from UA rules. Don't know if we have precedence
          for UA rules
  emilio: WK is only one that implements and they have special pseudo
          class for UA stylesheet. I think either column-focus or
          :focus-visible should do the right thing or they shouldn't
          match. Right is if you use from UA stylesheet it shouldn't
          show on shadow host ancestors
  <rego> Chromium also implements the :focus propagation on
         delegateFocus:true, that's why you get 2 outlines in Chromium

  Rossen: Catching up on IRC chat.
  Rossen: emilio, the overall take away is you agree with problem of
          exposing awareness of shadow host, though for a slightly
          different reason?
  emilio: Yeah. think it's solvable if we have special case to not
          propagate. I don't know if we want to go that route
  emilio: And we would still expose via getComputedStyle so I don't
          feel too strong. Either do what rego and Alice propose or
          making :focus-visible do right thing from UA stylesheet are

  Rossen: What is the ask here, rego?
  Rossen: Asking for resolution with the proposed behavior you
          summarized in opening comment?
  rego: One option could be resolve we don't want :focus-visible to
        match shadow host. Maybe we should explore alternative from
        emilio in the issue
  Rossen: For me that would be preferred path. I don't feel like
          conversation with Alice is resolved. emilio you can expand
          your proposal further
  emilio: Can do
  <Rossen> thanks emilio

  fantasai: My understanding is definition of this pseudo class is it
            will match when UA is doing something to style a focusable
            element as focused and will not match otherwise. If UI
            default focus was a dotted outline around everything if
            the author replicated that they should get same behavior
            as UA would give. All heuristics after example are
            suggestions of things UA should think about when they
            match :focus-visible in general
  fantasai: Meaning any UA in any case...we can improve the heuristics
            but they're not normative. Normative is if you style as
            :focus you match as :focus-visible. We can do whatever we
            want with heuristics but they're informative. We can't put
            heuristics that won't match actual definition of most
  fantasai: I'm not sure what we're trying to do here. What's required
            is clear and this is just helpful hints when designing a
  emilio: When you focus an element inside a shadow tree a lot of
          state in the page reflects that. focus pseudo class and
          others. Issue is, for regular elements like DOM APIs, app
          dev returns shadow host. That doesn't change if real active
          element is there. Doesn't change what it is. Issue here is
          should we do same with css pseudo classes
  emilio: I agree it could go either way. But it doesn't change if
          inner element should match :focus-visible. If we spec it
          should bubble up and target dom apis all browsers should do
  florian: Then are we saying it should style around the shadow host?
  emilio: In order for bubble up to work you need to match is a
          special in your sheets. UA sheets match in all shadow scopes.
  fantasai: Point of :focus-visible was for UA to not have magic
            pseudo class that does something different
  emilio: Right, this should apply to all re-targeting like
          column-focus. Not magic like how it's not magic if you
          target inside the tree
  florian: Does UA draw focus line around shadow root
  emilio: Should not
  florian: Then :focus-visible should not. It's what :focus-visible is
  <rego> about the heuristics, despite they're not normative, all
         implementations are following them, so they help to ensure
         interop on :focus-visible implementations
  emilio: Right, but if you think in terms of built in control like
          date. You have inner element you focus. Date is little
          editable fields for day, month, year. Inner focused is
          editable inside shadow root. In that case you want
          :focus-visible to bubble so you get outline around text
  emilio: Maybe add a way for shadow host to opt in. By default we
          shouldn't match
  Rossen: Don't feel we're ready to resolve. I suggest back to the
          issue and bring it back when we're ready
  rego: Agree
  rego: We should keep discussion on issue

:focus-visible matches on initial programmatic focus
  github: https://github.com/w3c/csswg-drafts/issues/5885

  rego: This is about if :focus-visible should match after
        programmatic focus. Current heuristics, though not normative,
        talk about if active element matches then next element will
        match. Spec didn't mention anything about if there's no active
  rego: Proposal is to change a bit so instead of saying it's the
        active element, you have to check last user interaction. ANd
        if none you match :focus-visible. But if someone clicked a
        button and there was blur you wouldn't match because first was
        not a mouse
  emilio: What interactions count and which don't? That's an issue. I
          think current heuristic is fine. It's a problem on mac
          because mac doesn't focus a bunch when you click on it. A
          lot of programs when you click and then move focus the
          heuristics say button wasn't focused so new thing shouldn't
  emilio: On mac since element isn't focusable by mouse you hit this
          issue. Good thing to come up with something that works.
          Generally agree with proposal, but which interactions count
          and which don't? I want the definition to be clear
  emilio: Does an interaction a second ago prevent programmatic focus
          from matching?

  florian: Confused. Are we trying to define when a UA shows a focus
           ring? If not, why defining when :focus-visible shows?
  rego: Everyone is following heuristics. If we have clear heuristics
        then it's better
  florian: They're supposed to be heuristics about when they show
           focus ring and :focus-visible matches.
  emilio: True
  florian: So we're talking about the combo, not getting out of sync
  emilio: Right
  emilio: I'm okay with the proposal. I just want whatever this
          interaction means to be clarified
  florian: Wondering if right spec and place. I think CSS spec has
           what it needs. We match browser focus ring and the pseudo
           class. When the browser shows focus feels more like HTML.
           Should we move them and call them normative?
  emilio: It's an option. Fine with that
  florian: If discussing state of doc and state of UI it's not a very
           css-y topic
  fantasai: This text is just an example. It's not normative
  florian: If you want normative it belongs in HTML, right?
  Rossen: What are we doing with this?
  rego: Keep going on the issue and see if we should move this
  florian: Just before we wrap up, my impression is even though called
           heuristics we're trying to harmonize browsers about when
           they show/don't show focus ring
  Rossen: And make it more detectable
  florian: We have detectable. We have the pseudo class that matches
           browser behavior. If we want to define browser we should
           have that in html
  Rossen: I think right next step are add any pseudo class discussions
          in the topic and rego will continue working with html group
          to see if there's additional behavior to define there

CSS Page

Should page descriptors support `!important`?
  github: https://github.com/w3c/csswg-drafts/issues/5970

  emilio: I noticed when reviewing patches for page descriptors the
          whole thing is a mess in all browsers.
  emilio: @page maybe is only one with keyframes. It's messy. Spec is
          confused about what's a descriptor. Can we define what
          cascade features work on @page and which do not?
  fantasai: I don't think keyframes cascade in same way. They have
            properties but I don't think they participate
  fantasai: For @page rules they are supposed to cascade. Spec was
            written before variables so doesn't take that into
            account. Seems useful for those to work.
  fantasai: They're all descriptors. They should behavior like regular
            properties including supporting !important. They cascade
            as properties with their own selectors and obey origin so
            no reason not to support
  fantasai: Useful to support variables, should inherit from root and
            that's new
  TabAtkins: Agree
  fantasai: Main thing I'm concerned about is there are descriptors
            that apply which are not regular properties. Not like you
            can just say just like an element, there's special stuff.
            But they should behave like properties, just not allowed
            in normal elements
  emilio: Way all browsers implement as far as I can tell is making
          page descriptors css properties. Means blink and webkit
          accept size in regular style blocks which is bad. So we
          should probably define these descriptors to be like css
          properties but that they can't be parsed in style blocks. I

  Rossen: Sounds like we are in agreement. What's the proposed
  fantasai: 2 resolutions. 1) The stuff inside @page or @margin rule
            are descriptors but behave like properties for behavior
            and cascade
  fantasai: 2) Variables are also accepted and they inherit from root
  fantasai: root to @page
  emilio: Precedent for that? backdrop doesn't
  TabAtkins: backdrop is just a pseudo element
  emilio: Similarities. Custom properties work in ::backdrop. Page
          being over root...I guess same for tables
  fantasai: Useful because then you get the fonts and such
  TabAtkins: Colors especially
  TabAtkins: backdrops quickly, they're on particular elements
  emilio: Don't inherit from them
  TabAtkins: Okay. That's an exception
  emilio: Inherit from root has another issue
  emilio: Relative to font size and relativeness. Fine with this, but
          not how browsers behave. Browsers and some print UAs take
          @page into account for MQ. This introduces a cycle
  emilio: Totally fine because I think we shouldn't take them into
          account. Maybe we can resolve they support properties for
          now and maybe move inherit from root to another issue

  faceless2: I wanted to say pages inherit from root works well for
             counter. No other way to do it. To my mind it's right way
             to do it
  emilio: Fine with that, but people want @page size to influence MQ
          which sounds gnarly
  TabAtkins: True
  TabAtkins: Leave variable open and resolve on rest?
  Rossen: Yeah
  Rossen: The stuff inside @page or @margin rule are descriptors but
          act like properties for behavior and cascade

  RESOLVED: The stuff inside @page or @margin rule are descriptors but
            act like properties for behavior and cascade

  Rossen: And we'll discuss more intention for variables and bring it

CSS Contain

:root/body viewport propagation and containment
  github: https://github.com/w3c/csswg-drafts/issues/5913

  rune: Encountered this looking at container queries
  rune: We propagate the writing mode from body to root including
        affecting used value for root element. Causes circularity if
        we don't say if we have containment on html don't prop to
        viewport. Wondering if it makes sense
  rune: Mostly thought about writing mode, but other properties too
  florian: Interesting problem. What's the solution other than making
           contain not apply?
  rune: Make contain not propagate to viewport
  Rossen: Wasn't that way more impactful on compat?
  florian: Not necessarily since existing content doesn't contain on
           body or root
  <fantasai> why would someone want to put containment on body anyway
  hober: There is because sites exist over time and worked on by
         different dev. Current maintainer might want the new shiny
         thing and not realize site depends on viewport propagation.
         They add this and cause a freaky action at a distance bug
         where other things stop working. How do you figure that out?
  florian: I don't want to break propagate. Doesn't seem as action at
           a distance. Containment at root isn't meant as neutral. So
           not worried about action at a distance. But some of the
           propagation is probably there because they're useful. I
           don't think containment on root or body is useful so not
           apply seems fine
  rune: Fine with that. Want to get rid of circularity.
  <fantasai> for the record, propagation from root to viewport is
             necessary and useful; and propagation from body is just a
             hack we had to introduce for compat
  <fantasai> I also agree with Florian that making containment just
             not apply is fine, I can't think any reason why it would
             be useful

  jensimmons: Agree with hober. I've already seen people teaching that
              best way to use container queries is to apply on root.
              May theoretically make no sense to use, but people will
              be confused by where to put containment. It's attractive
              to put on root
  florian: Confused as to why, but I believe they do
  <leaverou> That's so bizarre. Isn't that basically like a MQ?
  jensimmons: If it's impossible to do something with a sensible
              default it becomes an exercise to teach webdev to not do
              something stupid. I would lean toward can we make it not
              terrible by default? The webdev are already saying just
              put it on the root and it'll work

  miriam: I haven't seen people talking about just apply to root, but
          reason you might want to is for face that container queries
          resolve against actual font size and MQ resolve against
          external font size. That's one place where might be useful
          on the root even though MQ do most of it.
  iank: My personal opinion is not too worried about stopping
        propagation. From my memory we added propagating as a
        convenience or a compat issue that people put writing mode on
        body and we didn't want to switching to orthogonal and back.
        This cleans it up
  iank: From what I've seen webdev will but it on the root and the
        body. Seems like an edge case.
  iank: I think what rune and florian propose sounds well reasoned
  <miriam> +1 resolve container against root

  florian: Two things. Containment and container query. I think if we
           set container query so if there's no container it resolves
           against root then no need to contain root. If you container
           query without container you resolve against top level and
           no need to apply containment to body. Would that be weird?
  Rossen: I was on queue to highlight there's a ton of compat in the
          history. Especially the tail end of body or html which are
          used for setting up viewport. I don't think we should
          minimize potential compat impact. As hober pointed out
          someone could adjust styles and not realize they're
          affecting lots of stuff
  Rossen: At the same time I'm hearing there are potentially use cases
          to have containment on body or html. Whatever the use cases
          are we have to understand and figure out if we need to
          support them and figure out what's the appropriate behavior
          for backwards propagation. Maybe a middle ground to support
          backwards compat while allowing containment

  florian: jensimmons I want to check if I understand. What I thought
           you said is there are people who want to do container
           queries in general and some of the time it'll be in a grid
           and sometimes it's not in anything and in those cases they
           don't want a MQ for non-contained cases and they set the
           query on the root
  florian: If that's what you're saying I think we can work off the
           root to answer query. But did I miss?
  jensimmons: Both. People will set on the root because used to have
              to set it somewhere. They're going to be lazy and stick
              it where they want
  florian: Queries or just containment?
  jensimmons: While using container queries. Will they combine it with
              a switch in writing modes, maybe. If it's really hard it
              might we worth the extra effort, but don't assume it's
              an edge case
  florian: Making container queries on anything makes sense. If you
           need containment to get container queries makes sense to
           have containment. If you container query for anything it
           could work
  jensimmons: They're going to stick a design system container where
              they want. Sometimes in flow, sometimes deep in dom.
              They won't re-write the code depending on the context
  florian: Under that pattern makes sense to allow and the containment
           part applied to root does nothing. Query when not contained
           asks the root. Don't have to break cycles, just go all the
           way up
  jensimmons: Maybe. not sure
  <fantasai> +1 florian
  <miriam> +1 florian
  florian: Need to see if it works, but general approach makes sense

  iank: Not sure it works, florian. Need to think. You can
        set...specially setting html element and you can set
        properties which means will mismatch from viewport size I
  iank: So you'll have logical mismatch
  florian: max-width on html element?
  iank: Yeah, or set a direct width. I forget exactly what applies,
        but you'll have a mismatch between html element and viewport
  rune: If you spec containment on root html element such that
        container queries should work on html element we'll instead
        use viewport?
  florian: Yes, but iank has a point too
  iank: Yeah, I think if the choice is matching...you can set width on
        html element. If decision is making that resolve against
        viewport vs fixing containment I'm not wild about containing
        queries being special to one html element and having it match
        against viewport in one case

  florian: I need to think. I feel like there's a shortcut but the one
           I mentioned earlier is wrong
  florian: I'd like to try and find a way out of this that doesn't
           require breaking backwards propagation of things
  fantasai: I don't have problem breaking propagation from body. It
            shouldn't have existed.
  fantasai: If we want to break propagation from body, just do it
  myles: Not unreasonable, but this is wrong time to make that kind of
         big change
  iank: This is only breaking if we have containment applied on body.
        This isn't a big change. If people are worried about compat,
        I'm not, but we can add a use counter
  myles: I think jensimmons made a compelling argument that it will
         not be uncommon
  iank: I think it's uncommon at the moment. I agree it could become
        common and you're opting in
  florian: If you add a component with container queries and not
           paying attention to where and you don't check Arabic, only
           English, you broke Arabic
  Rossen: iank are you offering to collect some data?
  iank: I think I might offer rune to collect data. I also think this
        will only break vertical writing mode pages

  Rossen: We're at top of the hour. How about the following? If we can
          get data, great. jensimmons I'd ask you to dig out some of
          these examples of devs or designers talking about htis on
          root that would be helpful
  jensimmons: It's in random convos and slack channels. It's not blog
              posts. It's the first hot take. Just set it on the root.
              We can teach them not to do it, but if that's the first
              take there's something attractive. It's a sign it's not
              edge case
  florian: I think we should make it work, just aim for least breaky
  Rossen: It will come to a compromise so let's make sure it's the
          right one
  Rossen: We're a bit over, thanks for staying. That was great
Received on Thursday, 18 February 2021 00:02:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 February 2021 00:02:53 UTC