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

[CSSWG] Minutes Telecon 2022-05-18 [cssom-view] [css-fonts] [css-pseudo] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 May 2022 18:30:39 -0400
Message-ID: <CADhPm3vTvv+Rht5wTpmLFTCdT8Oo8K-eo-KbqYaHaD+NwFokGA@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.


  - RESOLVED: Remove checkInert from IsVisibleOptions (Issue #7274:
              isVisible inert option)

CSS Fonts

  - There were some concerns about the proposed new keyword for
      font-display (Issue #7271: Add a font-display keyword to
      eliminate @font-face FOIT & layout shifts) encouraging authors
      toward behavior that is bad for users. Discussion will go back to
      github to discuss further the intent to assist authors in making
      a decision they're already trying to make and how to balance that
      against the concerns.

CSS Pseudo

  - RESOLVED: forced-color-adjust doesn't do anything on highlight
              pseudos, and highlight pseudos take their forced color
              state from the originating element (Issue #7264:
              Highlight pseudos and forced-color-adjust)


  - RESOLVED: Issue of topmost modal dialog to be addressed with a
              pseudo-class (name TBD) (Issue #7258: Should :active
              apply to dialogs?)
  - RESOLVED: Add :-webkit-autofill in an appendix of selectors 4
              (Issue #7257: List of -webkit- legacy aliases)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0006.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Xiaocheng Hu
  Jonathan Kew
  Vladimir Levin
  Peter Linss
  Ben Mathwig
  Tim Nguyen
  Alan Stearns
  Miriam Suzanne

  Delan Azabani
  Chris Lilley
  Lea Verou

Scribe: dbaron


isVisible inert option
  github: https://github.com/w3c/csswg-drafts/issues/7274

  vmpstr: We have recently added an isVisible function to Element. It
          takes a dictionary of additional options. One of those
          options was about inert-ness.
  vmpstr: Mozilla indicated that checking for inertness was a strange
          thing to correlate with visibility. So we'd like to remove
          this dictionary option, at least for now.
  vmpstr: It's easier to add it later if people actually want this than
          to remove.

  Rossen: I'm assuming this is relatively safe at this point?
  vmpstr: I'm not aware of implementations.
  Rossen: Did you consider oriol's question?
  vmpstr: ... with aria-hidden? Rereading it now.
  vmpstr: It's a good question, but we'd like to begin by shipping
          isVisible as a somewhat non-controversial set of options...
          questions such as these can be raised to add additional
          dictionary options if there are developers who want to check
          these things.

  Rossen: Any objections to dropping dictionary for now?
  <chrishtr> +1 to removing
  vmpstr: Just dropping the inert-ness member from the dictionary.

  RESOLVED: Remove checkInert from IsVisibleOptions

  Rossen: And hopefully oriol will get back to us if he has something
          to raise.

CSS Fonts

Add a font-display keyword to eliminate @font-face FOIT & layout shifts
  github: https://github.com/w3c/csswg-drafts/issues/7271

  xiaochengh: I propose adding a new keyword to font-display descriptor
              so it's critical and blocks load event of stylesheet.
  xiaochengh: The purpose is to eliminate flash of invisible/unstyled
              text or layout shift caused by web fonts.
  xiaochengh: There are many ways to mitigate flash or layout shift,
              but either complicated to use or have other issues.
  xiaochengh: This one keyword proposal can hopefully solve this.

  Rossen: I see a conversation back and forth between Jonathan and
          Laurence on the issue. Jonathan is raising some points -- not
          sure they've been answered, especially his first point about
          what is truly critical.

  chrishtr: Regarding critical -- there are examples in issue of font
            use cases that would be considered critical. This isn't a
            question about why they'd be served from a 3d party domain
            if they were critical. If you want your site to be fast
            you'd ideally serve from same domain, but many sites use 3d
            party font service to serve fonts, which allows 3d party
            font service to update fonts over time.
  chrishtr: xiaochengh is proposing that critical fonts should be
            loaded only if they're truly critical. Hope that font
            providers could have query parameter so that their
            stylesheet could say it's render blocking.

  Rossen: Jonathan...?
  jfkthame: Don't have anything specific to add... was trying to
            understand goals and how it would work. I have a little
            reluctance to complicate font-display ... already fairly
            complex that few people understand. But I haven't tried to
            think through implementation issues.
  jfkthame: ... of the new critical value.
  jfkthame: Other question is how this relates to font loading api. Are
            these use cases where authors should be using font loading
            api to more closely control what is happening? Not sure...

  fantasai: My concern is that it prevents the page from showing text.
            I understand that intent is that authors not use it for
            most of the text, but I think authors might use it for
            that. We normally don't make it easier to prevent the page
            from loading for long periods of time, perhaps forever.
  xiaochengh: Problem is developers are already trying to block render
              of page with various hacks. One example is to add empty
              external stylesheet that blocks rendering so font can
              load. Other is add display:none or visibility:hidden and
              remove when font is loaded. Since developers are already
              trying to do it, we can provide a better way.
  <chrishtr> also, style sheets and scripts already block rendering,
             potentially indefinitely.
  <chrishtr> this attribute also indicates intent directly, and allows
             the UA to ignore it after a timeout
  fantasai: I think technique of using visibility:Hidden and then
            visible is the developer very clearly saying that it's not
            to be rendered until font loads. Very clear they want
  xiaochengh: not just making element invisible... making entire page
  Rossen: This is use-case specific. People can do it in a more
          targeted way.
  fantasai: My concern is that someone will be like "Oh, my wedding
            invitation *has* to be loaded in this font because it looks
            ugly otherwise, so I definitely consider this a critical
            font" and then the reader of the invitation, on a different
            connection, ends up never able to read the page

  astearns: I think I agree with fantasai that the current hacks might
            be sufficient for this. But I got on queue because of
            concern with how this works only with render-blocking style
            sheets. I worry about adding something that will work in
            some cases but not in others. We'd have to specify what
            this does, if anything, if the style sheet is not render
            blocking. And I'm worried about adding something that has
            that works and doesn't work
  astearns: characteristic.
  xiaochengh: The intention is to make it render-blocking but after the
              document has already started there's no way to block
              render, so to keep things simple I'm just making it block
              load of style sheet.

  emilio: Similar to that... this would imply the font should load
          unconditionally and fully -- don't have unicode-range (
          presumably ignored) -- my other question isn't this more
          similar to how background images block the load event of the
          page but not of the style sheet. Doesn't achieve the
          rendering blocking that you want... but maybe it does?
          Background image loads get started before layout rather than
          during layout like fonts.

  plinss: I agree with fantasai. I hear the argument that authors do
          this so we should make it easy. That argument falls down when
          authors are doing something bad -- we have no obligation to
          do that. We should teach authors how to do fallbacks,
          progressive rendering ,etc.
  <fantasai> +1 to "don't optimize for making the bad things easy"
  chrishtr: plinss, I don't think there is a good way to do it right
            now. Only way to do it causes flashing on load. size-adjust
            was added but ??. This is a clean solution to this natural
  plinss: We have to weight harms between flashing and blank content.
          Look for other alternative rather than blocking?
  Rossen: Not sure how this isn't creating flashing as well while
          you're waiting.
  chrishtr: Shows white.. shouldn't consider that a flash of unstyled
  fantasai: We already have the block keyword that shows white.
  chrishtr: The existing keyword shows white only for the text, not the
  ?: ... and there's layout shift.
  plinss: I'd say both preferable to blank page.
  chrishtr: I think use cases for either.
  plinss: Authors don't always consider all the factors
  plinss: Doesn't mean we should make it easier... think it will lead
          to more abuse.
  <fantasai> If we're adding a keyword for this, it needs to be
             something really obnoxious and obvious, like

  Rossen: I'm hearing a good bit of feedback. So I think we should take
          this back to the issue and accumulate a little more consensus
          there before we bring it back for a resolution. Also given
          how many people missing today.
  Rossen: Anything else you wanted to highlight today, xiaochengh?
  xiaochengh: The intention is not to help authors do bad things... let
              me outline this another way. We're trying to help authors
              make a tradeoff more easily... tradeoff between page
              stability and responsiveness. No easy way to go to one
              end of the tradeoff.
  Rossen: We'd like to move it back to the issues.
  <astearns> I don't think this is necessarily a bad thing, but I am
             not convinced there is no current way to achieve an
             appropriate result
  fantasai: My understanding is that the proposal is to add a keyword
            that blocks the page rendering *literally forever* if the
            font doesn't load. If it's still not loading 30 seconds
            later because the font isn't loading, that's a problem for
            the user.
  plinss: I think the concern is that authors will unknowingly use this
          badly and wind up doing bad things by accident.
  <tantek> +1 fantasai, plinss this makes it too easy for authors to do
           *harmful* things to users
  <florian> +1 to not liking this, for the reasons said by fantasai and
  <emilio> one could make a case that the same can effectively already
           happen for any stylesheet tho
  <chrishtr> Fantasai: this is not new, style sheets can and do already
             block rendering. I do think the spec for this should say
             the UA should provide a timeout.
  <emilio> (I guess that's what chrishtr just said)
  <fantasai> emilio, yeah, and it's obnoxious when I try to load a page
             and it gives me a blank forever even though I know the
             text is loaded

CSS Pseudo

Highlight pseudos and forced-color-adjust
  github: https://github.com/w3c/csswg-drafts/issues/7264

  dandclark: Question about how forced-color-adjust:
             preserve-parent-color should work with highlight
  dandclark: This interaction is potentially problematic.
  dandclark: Prerequisite: consider whether forced-color-adjust should
             be allowed in highlight pseudos.
  dandclark: The spec gives a list of properties. Currently not allowed
  fantasai: I think the idea of having it not apply and just applying
            the forced-color-adjust effect of the originating element
            makes sense to me.
  fantasai: I think that was mentioned in the post as a way to deal
            with this.
  dandclark: I think that's a good outcome... seems simplest.

  dandclark: For all other color based properties the highlights are
             sort of an independent cascade. But I think it makes sense
             here. Seems odd that the originating element would take
             forced colors and the highlights not.
  dandclark: If the originating element has
             forced-color-adjust:preserve-parent-color, what does that
             mean for highlight pseudos that are active over that
             originating element?
  fantasai: Effect is that the color property is able to inherit from
            the parent the actual color of the parent... and that
            doesn't really impact the highlight pseudos ... which
            doesn't matter for highlight pseudos where the currentColor
            keyword comes from the previous layer. So the keyword
            wouldn't have an effect.
  dandclark: So then try to resolve that forced-color-adjust doesn't do
             anything on highlight pseudos, and that highlight pseudos
             take forced color state of originating element

  Rossen: Proposed resolution: forced-color-adjust doesn't do anything
          on highlight pseudos, and highlight pseudos take their forced
          color state from the originating element
  <dandclark> +1 to the whole thing. I think it's good to have that

  RESOLVED: forced-color-adjust doesn't do anything on highlight
            pseudos, and highlight pseudos take their forced color
            state from the originating element


Should :active apply to dialogs?
  github: https://github.com/w3c/csswg-drafts/issues/7258

  plinss: The sense is that there can be multiple modal dialogs and
          only one is active. Should have a pseudo class for it. I
          propose we re-use the :active pseudo class, though what
          pseudo used is not that important.
  plinss: There was a lot of pushback against using :active. I accept
          it could be problematic... many people seem to think :active
          means the mouse is down, but I think it means the thing is

  emilio: I was going to echo that... :active applies to all elements
          when you press the mouse, regardless of whether they're
          activatible. So I think it would be very confusing to use it
          for this. Especially because it would trigger when you click
          something in a dialog, because :active applies to the whole
          chain of things.
  emilio: I don't know that the pseudo is that useful -- can't think of
          cases where you want different styling for the topmost modal
          dialog from other modal dialogs.
  Rossen: Is the point you're making that an active modal dialog must
          always be the topmost one, and ... ?
  emilio: I think reusing :active would be a mistake because it already
          applies to <dialog>, and that I don't think there's a lot of
          use cases for styling the active (i.e., topmost) dialog
          versus styling a modal dialog that is not the topmost one.
  emilio: We need to do that internally for inertness, but that's just
          to control inertness of the topmost thing.
  plinss: If you have nested dialogs, I can see wanting to
          differentiate them visually. They may not necessarily be on
          top of each other or obviously obscuring each other. I think
          there's a valid use case for it.
  emilio: Fair. I guess I think it's something the backdrop usually
          takes care of.
  plinss: Depends on what effect backdrop has and whether it's obvious.

  ntim: I'm also against using :active for this. If you're really
        targeting the dialog ??? ... that would make it incompatible.
  ntim: :active has a historical meaning, so I'm against doing that.
  ntim: I also don't see a lot of use cases. But my main pushback was
        using :active.
  ntim: Personally regarding use cases, since modal dialogs are
        triggered using javascript, you can control which class you put
        on the topmost one. I don't see a real gain from adding
  plinss: You could make that argument about almost every pseudo-class.
          Let me push back on :active meaning the mouse is down -- I
          don't think that was original intent. I think it was a
          mistake -- not sure if it's one we can fix.
  ntim: Let's say you have a button inside a dialog, and you're
        pressing that button. Unexpected that :active would apply,
        given that :active propagates to parent elements.
  plinss: It would already be active if the button is clickable
  emilio: not if the dialog isn't modal

  emilio: If I understand correctly, this would make a pseudo for the
          topmost modal dialog. Would be confusing for that pseudo to
          apply to non-modal dialogs.
  <Rossen> +1 to emilio and :active interop being bad
  emilio: Put on queue to say that :active interop is pretty bad. This
          would make it a lot more confusing.

  fantasai: I agree we can't use :active given how it's been
            reinterpreted by implemented. Was never intended to be
            "while I'm clicking on this element".
  fantasai: I can see there might be use cases for having a
            pseudo-element for the topmost modal. Wish we could use the
            word active for it, maybe :active-modal or similar.

  Rossen: I'd like to break the solution into validating the use case
          and coming up with a solution, and then the bikeshedding.
  Rossen: Would like to validate the use case first.
  chrishtr: To the point about developers don't need it because they
            control the dialogs... it's still convenient because it's
            very simple to just have to style the front-most dialog and
            not have to use script to polyfill the same thing.
  Rossen: Sounds like there's more validation to the use case... name
          of the pseudo TBD.
  Rossen: Would prefer to take bikeshedding back to the github issue.

  <tantek> I would like to get input from the OpenUI folks on this
  <tantek> I didn't see any in https://github.com/w3c/csswg-drafts/issues/7258

  ntim: If you have a UI that does stacking multiple dialogs... it's
        not a great UI. This sort of encourages it in some way. I guess
        the role of CSS isn't how to say how to build UIs.
  plinss: I agree stacking modal dialogs is a bad pattern... though
          maybe modal dialogs are a bad pattern to begin with. If we're
          going to do them we should do them well.
  plinss: ... goes against my earlier advice about allowing authors to
          do bad things, but arguably modal dialogs in general are a
          bad idea. If we're going to do them, though, let's do them
  tantek: I'm looking at issue and leaning towards plinss opinion as
          well. But haven't considered motivating use cases.
  tantek: I think OpenUI folks should comment... may have more context
          of uses cases that would need this pseudo class... or they've
          considered it and decided they don't need it.
  Rossen: I think the decision of styling the active modal dialog
          through a pseudo-class is seemingly obvious decision even if
          we invalidate the use case later.
  Rossen: I'd like to record a decision here....

  ntim: Looking at top layer generally, maybe use case is targeting
        topmost thing in top layer rather than active modal dialog.
        Look at it from different perspectives as well.
  ntim: How does this fit with other things that use the top layer --
        full screen api, popup api.
  ntim: How does this pseudo fit with this stuff... and should it be
        more generic to these things?
  ntim: so maybe openUI input would be good.
  plinss: Happy to get openUIs input, but would like to take a
          resolution to have a pseudo-class.
  <chrishtr> +1 to resolving to add a pseudoclass now. :modal-active ?
  <astearns> hears :tdb
  Rossen: Proposed resolution that issue of topmost modal dialog to be
          addressed with a pseudo-class (name TBD).

  RESOLVED: Issue of topmost modal dialog to be addressed with a
            pseudo-class (name TBD)

List of -webkit- legacy aliases
  github: https://github.com/w3c/csswg-drafts/issues/7257

  fantasai: We have a bunch of :-webkit- pseudo classes and things that
            we may need to add to selectors spec. ??? has come up.
            Questions are (1) do we define this in selectors 4 spec
            (2) other aliases to add or (3) do we incorporate these
            into definitions of each pseudo, or do we put them in an
            appendix at the end.
  ntim: Isn't there a web compatibility spec that defines a lot of CSS
  fantasai: Yes, and the editors prefer that we'd define them in the
            relevant specs.
  <ntim> https://compat.spec.whatwg.org/
  florian: That spec is meant as a stopgap for things not spec'd in
           their native space.
  florian: In general: preferably get rid of them. If we can't, spec
           them. Appendix is a good way to spec without encouraging
  Rossen: Main question was should webkit prefixed things go in
          selector 4 spec.
  fantasai: Sounds like add as appendix to selectors 4. Do we add
            :-webkit-autofill specifically? Are there others?

  RESOLVED: Add :-webkit-autofill in an appendix of selectors 4

  <tantek> I know we're over time, but I'm not seeing a reason to
           duplicate the list from the compat spec
  <fantasai> tantek, compat doesn't have a list of selectors
  <fantasai> and also, they'd prefer we move things here
  <fantasai> iirc
  <tantek> thanks fantasai
Received on Wednesday, 18 May 2022 22:31:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 18 May 2022 22:31:20 UTC