[CSSWG] Minutes Telecon 2022-01-19 Part I [mediaqueries] [css-ui] [fullscreen] [css-conditional] [css-selectors] [css-text]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Media Queries 3
---------------

  - RESOLVED: Publish a Proposed Correction for MQ3, along with any
              necessary antecedents as determined by florian/chris/
              fantasai (Issue #6962: REC update)

CSS UI
------

  - RESOLVED: Put an issue in the draft saying we'd like to remove
              (Issue #6788: 'input-security' considered harmful)

Fullscreen
----------

  - RESOLVED: Set visibility:hidden [typo: this should be
              visibility:visible] on modal dialogs (Issue #6939: How
              does top-layer interact with ancestors)
  - New issues will be opened to resolve the modal pseudo-class and
      reparenting issues raised as a part of issue #6939

Conditional & Selectors
-----------------------

  - RESOLVED: Close no-change (Issue #3936: How should selector
              supports test react to partially-implemented selectors?)

CSS Text
--------

  - RESOLVED: hyphenate-character is shippable; we'll add it to the
              Snapshot 2022 list of exceptions (Issue #6887: Is
              hyphenate-character stable enough to ship?)

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/29

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins Bittner
  Delan Azabani
  David Baron
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  Vladimir Levin
  Rune Lillesveen
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Morgan Reschenberg
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Scribe: TabAtkins

Media Queries 3
===============

REC update
----------
  github: https://github.com/w3c/csswg-drafts/issues/6962

  florian: Elika suggests we might want an update since it's been a
           while
  florian: We haven't touched it since 2012
  florian: Presumably we thought 4 and 5 would be done
  florian: Also haven't rebuilt it since then, since it's on the old
           preprocessor
  florian: Some edits went into source, some went into output
  florian: I synced them, and deleted the source since nobody uses it
           anymore
  florian: And made a few markup fixes
  florian: Also errata. Most are editorial
  florian: One was later overturned, but we didn't remove it from errata
  florian: One was normative, so I've included it as a candidate
           correction
  florian: I think we're ready to publish.
  florian: But if the group agrees I'd rather have it as a proposed
           correction rather than candidate correction
  chris: Don't think you can do that
  chris: A proposed correction must have the same text as a candidate
         correction
  florian: hm, you might be right, but I think we could do two pubs in
           a five minute span
  chris: True there's no minimum review period
  chris: Think it's an abuse of process, but it's not disallowed
  astearns: So we could do candidate corr, let the AC know...
  florian: Letting the AC know is the *proposed* correction thing
  astearns: So you're suggesting do a candidate correction now, and do
            a proposed correction sometime later?
  florian: I propose doing it immediately after since we gain nothing
           from a delay, but we can wait a bit if necessary
  chris: You can do a proposed correction and ask the director and see
         what happens, but it might take more time
  florian: We don't need to ask the director, these are non-normative
           until they're folded in
  [missing some process discussion]
  TabAtkins: Propose we resolve to publish a Proposed Correction, along
             with any necessary antecedents?
  <chris> https://www.w3.org/Guide/transitions?profile=REC&rec=substantive

  RESOLVED: Publish a Proposed Correction for MQ3, along with any
            necessary antecedents as determined by florian/chris/
            fantasai

  florian: Maybe a followup, maybe implied
  florian: Once this is done we should clear the errata
  chris: You automatically start with a new blank errata whenever you
         publish a doc

CSS UI
======

'input-security' considered harmful
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6788

  florian: I disagreed with just one of his statements, not all
  florian: In UI4 we introduced 'input-security: auto | none'
  florian: 'auto' does nothing by default, but on password fields (and
            other host-defined "sensitive" things) it obscures the text
            via *** or whatever
  florian: 'none' turns that off
  florian: Mats says this is a useful feature, but shouldn't be under
           the author's control, needing them to use JS on things.
  florian: UAs are also much more likely to get a11y right on things
           like this.
  dholbert: Also Edge already does this by default with a little button
            on password fields

  scribe: fantasai

  astearns: Anyone implemented the CSS value?
  TabAtkins: WebKit did, Chrome inherited it pre-fork
  TabAtkins: Not ok to drop without a replacement
  TabAtkins: Maybe mark as deprecated and that we will remove, once
             HTML spec is updated to require
  TabAtkins: No mandatory UI, but required functionality
  smfr: I don't have much of an opinion.
  smfr: If we need it internally we can keep it internally, don't have
        a strong opinion
  florian: Can we not have the dependency on HTML?
  TabAtkins: The functionality is useful
  TabAtkins: Optimal place is not in CSS, but if we don't have the
             functionality otherwise should leave it in
  florian: I'm saying we drop it from CSS now, and encourage browsers
           to do the right thing
  florian: rather than not removing it now
  TabAtkins: That falls into the failure mode that's likely, which is
             that we remove it and nothing happens to HTML
  TabAtkins: and I think this is useful enough for users that we
             shouldn't encourage nothing
  <oriol> Firefox also has a UA button to show text (like Edge) behind
          pref: layout.forms.input-type-show-password-button.enabled
  florian: Chrome has it?
  TabAtkins: yeah
  florian: Edge has it?
  dholbert: Firefox also has it on Nightly
  florian: So seems like the scenario of not having it is unlikely
  Rossen: Talking about the property?
  florian: The behavior of being able to reveal the password
  TabAtkins: We don't have it in Chrome
  ??: We disabled in Chrome because of compat issues

  astearns: Issue in HTML spec?
  <jensimmons> Issue at HTML: https://github.com/whatwg/html/issues/7293
  astearns: That issue mentions something I'm concerned about, which is
            the HTML spec might need a CSS definition in order to say
            "here's what happens"
  astearns: with this attribute or UI
  florian: OK, maybe let's go back to what Tab suggests
  florian: Resolve, we would like to remove this, would like it to be
           in HTML
  astearns: So adding an issue to draft, we'd like to remove please
            don't implement?
  dholbert: My concern is that if we leave it, HTML spec might point at
            CSS for how to do it, and then JS can set in buggy ways
  astearns: Note would say we'd like to remove, please don't implement
            property, and HTML should define in a way that doesn't
            depend on CSS
  florian: Tess is arguing for what we are saying to not do
  astearns: Which is we should make it an issue and get Tess's input
  Tim_Nguyen: Issue on our side was that inputs tend to have buttons
              for e.g. password autocomplete, and would need UI that
              wouldn't interfere

  astearns: Sounds like we're not going to resolve any spec edits
            today, but let's add an issue to the draft saying we'd like
            to remove this
  astearns: Proposed resolution is to put our recommendation into an
            issue in the draft, and come back to it later when we can
            get more discussion on it
  astearns: Objections?

  RESOLVED: Put an issue in the draft saying we'd like to remove

Fullscreen
==========

scribes: TabAtkins & fantasai

How does top-layer interact with ancestors
------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6939

  smfr: top-layer is used by <dialog>, ::backdrop, etc
  smfr: They generate new stacking contexts, escape ancestor opacity,
        other graphical effects
  smfr: 'visibility' is a bit different
  smfr: It's inherited; as specced, a visibility:hidden ancestor will
        hide a dialog
  [simon was dropped]
  smfr: Tab responded with a confusing comment
  TabAtkins: ...
  smfr: He said top-layer things are reparented in the box tree
  smfr: so that doesn't affect inheritance
  smfr: I think people might be confused about that effect with
        visibility
  smfr: Maybe UA stylesheet should put visibility:visible on the dialog?
  ntim: Worth noting - display:none on the ancestor propagates to the
        top-layer element

  emilio: Unsure to what extent display and visibility work together
  emilio: was going to suggest Simon's UA stylesheet tweak to make it
          work
  TabAtkins: That seems fine to me. I don't see a particular issue to
             set 'visibility' in the UA stylesheet
  TabAtkins: I think it is surprising that a dialog would stay hidden
             if the ancestor is hidden
  emilio: Seems like a special case, yeah. But other than that, no
          strong feeling.
  TabAtkins: I guess 2 resolutions
  TabAtkins: a) Top-layer elements are essentially reparented in the
             box tree, so visual effects from containers don't apply,
             but inheritance applies as normal
  TabAtkins: b) We add rule to UA stylesheet that dialog is visibility:
             visible
  emilio: I'm not super convinced we should add it
  emilio: could argue the same for a ton of other properties
  emilio: but not strong, so won't object
  astearns: What other properties?
  emilio: Everything that inherits, like pointer-events
  emilio: Anything that inherits thru could potentially be weird
  astearns: And we're only talking about setting visibility and not
            display
  TabAtkins: display is consistent with what I said because it can't be
             reparented in the box tree, because it's not in the box
             tree
  astearns: So first proposal from tab is top-layer elements are
            reparented in the box tree, and point out that inheritance
            isn't affected by that
  smfr: The "etc" in the spec text needs clarification
  TabAtkins: Agree, can do that

  emilio: Related to 'display' issue, something came up recently while
          triaging
  emilio: Blink will create a box if the dialog is a child of the
          replaced element
  TabAtkins: I probably agree with you, decided on that in my comment
             too quickly. Because affects box generation, dialog
             shouldn't display at all
  astearns: So any more discussion on the "reparenting in box tree"
            portion?
  smfr: do we need to be that specific?
  TabAtkins: You asked a bunch of questions, need to have consistent
             answers
  TabAtkins: and having this conceptual model gives us consistent
             answers
  ntim: I think stacking context/containing block dfns are enough to
        cover those cases
  TabAtkins: Possibly
  TabAtkins: I can review and see if that's enough
  astearns: So why don't we not take that resolution for now, and you
            can review

  astearns: Okay so the etc
  ntim: pointer-events
  TabAtkins: It's an inherited property, so will just inherit. Unless
             we want to do a reset in the UA stylesheet
  astearns: Do we need to resolve on resetting visibility?
  TabAtkins: OK, let's do that
  astearns: Proposed to have UA stylesheet reset visibility for
            dialog ... what about other top-level elements?
  TabAtkins: Can't for other elements, can be arbitrary elements
  TabAtkins: so can only do for dialog
  astearns: OK, so proposed is that UA stylesheet sets 'visibility' on
            dialog
  smfr: When they are in the modal state
  fantasai: I believe there's a :modal pseudo-class in HTML
  ntim: We have a pseudo-class, but internal, not exposed in CSS
  iank: I wrote that internal class
  iank: Wording is there, but not actually in the HTML spec
  astearns: Anything else we can use to select?
  TabAtkins: Reasons we don't want to go into, are they blockers to
             putting in HTML spec or historical?
  iank: There was pushback to adding as an actual pseudo-class
  iank: HTML spec didn't want to define pseudo-classes itself
  TabAtkins: put it in Selectors
  ntim: UA stylesheet, should have a statement about it

  smfr: Comment about ::backdrop
  smfr: Current behavior, if have visibility:hidden ancestor on dialog
  smfr: Is that dialog is hidden but backdrop shows up
  smfr: because backdrop not affected by inherted visibility, that's
        not great
  TabAtkins: Right, because ::backdrop inherits from the root
  emilio: I thought it didn't inherit, which causes problems with
          system properties
  rune: ...
  <iank> https://html.spec.whatwg.org/#phrasing-content-3 and scroll up
  <iank> "The dialog element, when its is modal flag is true, is
         expected to act as if it had a user-agent-level style sheet
         rule setting the following properties:"
  emilio: Which is something we may want to consider fixing
  TabAtkins: That can be done in today's CSS by setting 'all: initial'
             in the ::backdrop stylesheet
  TabAtkins: so explainable in current CSS
  emilio: Is it though?
  emilio: All doesn't reset custom properties
  emilio: We have an agenda item about selection, e.g. new ::selection
          model not inheriting from original element which causes other
          issues
  iank: Quoted the prose from HTML
  TabAtkins: HTML spec says "pretend there's a pseudo-class, and apply
             these properties"
  TabAtkins: let's just define the pseudo-class
  iank: Pushback was exposing the internal pseudo-class to web
        developers

  astearns: Is there a concern about exposing to web devs?
  emilio: I think Gecko was the first to implement via internal
          pseudo-class
  emilio: Everyone converged on that model
  emilio: I think at first there was some resistance to expose a
          pseudo-class because not how some browsers work
  emilio: but at this point, given we have interop in that sense, all
          browsers have internal pseudo-class
  emilio: maybe makes sense to expose it
  iank: Agree it makes sense, but think we'll still get pushback from
        WHATWG
  iank: Another thing that could be internal class but isn't
  TabAtkins: We don't have to invoke WHATWG, we just put it in Selectors
  TabAtkins: As long as browsers want that, not a jurisdictional problem
  emilio: ...
  TabAtkins: To change the styling of a dialog based on whether it's
             open in a modal style or not, if UA wants to do it don't
             see why authors wouldn't want to do it
  ntim: I don't see much use case for it
  ntim: Unlikely that someone will call showModal() and show() on the
        same dialog

  astearns: I suggest we separate out whether properly-defined pseudo
            into own issue
  astearns: but whether or not we do that, we should define certain
            things for dialog using existing internal pseudo-class
  astearns: So have some changes mentioning that you set visibility and
            perhaps pointer-events
  astearns: using same handwavy definition that HTML currently has
  astearns: and separately figure out whether we need an exposed real
            pseudo-class to put into Selectors
  astearns: Does that sound reasonable?
  TabAtkins: OK, opening issue
  astearns: So can we resolve to set visibility using internal
            pseudo-class?
  astearns: Anyone want to continue discussing? Anyone have an
            objection?
  [continued silence]

  RESOLVED: Set visibility:hidden on modal dialogs

  astearns: Any other property to resolve now, or continue discussing
            in the issue?
  ntim: Pointer-events maybe?
  ntim: Idk if it should be auto or all ...
  astearns: In interest of time, let's punt to issue
  astearns: and find out what the value should be and figure out any
            other properties that should be set in this way
  astearns: Done with this issue for today
  astearns: bit about box-tree reparenting, should that be a separate
            issue so don't lose track of it?
  (new issue for :modal-dialog https://github.com/w3c/csswg-drafts/issues/6965)
  astearns: OK, we'll keep this issue just about properties to set in
            UA stylesheet
  astearns: separate issue on modal pseudo-class
  astearns: and separate issue on reparenting

Conditional & Selectors
=======================

How should selector supports test react to partially-implemented
    selectors?
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3936

  fantasai: So it's about how supports() should work for
            "partially-implemented" selectors (only implemented in some
            contexts)
  fantasai: And if we need a separate supports*() function to
            differentiate them.
  TabAtkins: :has() pseudo-class, was suggested could be implemented
             just in .querySelector and not in CSS
  TabAtkins: Question about whether @supports/.supports() return true
             for support in that case
  TabAtkins: Conclusion was that only true if supported in CSS
  TabAtkins: and can tell if .querySelector supports by whether or not
             it throws
  TabAtkins: So shouldn't need additional work
  astearns: So anyone interested in keeping the issue open, or okay
            with closing?
  astearns: Objections to closing?
  astearns: I trust if Amelia disagrees we'll hear about it

  proposed: .supports/@supports checks for support in CSS, use
            .querySelector throwing to check for support there, close
            no change

  RESOLVED: Close no-change

CSS Text
========

Is hyphenate-character stable enough to ship?
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6887

  jfkthame: Question in the title
  jfkthame: webkit and blink have this, but -webkit- prefixed
  astearns: And Firefox has this unprefixed?
  jfkthame: Yes, behind a nightly flag
  jfkthame: So question is whether we can ship it unflagged
  fantasai: I think so. I don't remember there being any issues against
            this particular property for the many years it's been around
  florian: Agree. You noted there might need to be extensions later to
           be smart about some details, but they can be put on top of
           the current value set

  astearns: What's state of the spec?
  florian: WD, this is level 4
  astearns: So we resolve this is okay to publish, and add this to the
            snapshot list of things that are shippable ahead of process
  astearns: objections?

  RESOLVED: hyphenate-character is shippable; we'll add it to the
            Snapshot 2022 list of exceptions

  fantasai: Do we want to resolve to publish a Draft Note 2022 with
            this change?
  astearns: I think we should publish as needed, yes.
  chris: Seems much better to publish as we have updates, yes
  astearns: So proposed resolution is we publish a Draft Note for 2022
  <fantasai> (Now that we have a Draft Note)
  chris: Since /TR/CSS goes to the snapshot, why don't we publish a
         Note series with "css" as the shortname, so every time it's
         not the first draft, but just an update?
  fantasai: I didn't like this; I think it's useful to have snapshots
            on a yearly basis
  fantasai: Just walking back thru publish history isn't the same
  chris: If you follow history right now, it'll say "css 2022 has been
         published once", and you can't go back to 2021 from there
  fantasai: I think your point is valid but it is true for all leveled/
            versioned things
  fantasai: That's an issue for the templates
  astearns: So no resolution, we'll break

  <break>

Received on Thursday, 20 January 2022 10:44:20 UTC