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

[CSSWG] Minutes Telecon 2021-09-08 [css-position-3] [css-highlight-api] [css-scollbars-1] [css-color-adjust] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 8 Sep 2021 19:36:00 -0400
Message-ID: <CADhPm3uHfDH_3ZfX2erpvNOp=4Opi70HTArM531kbrYtDhCStA@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.
=========================================


TPAC Reminders
--------------

  - There are calls scheduled with i18n and a11y on 20th and 27th.
      Please tag Agenda+TPAC on issues that should be discussed during
      those calls.

CSS Positioned Layout L3
------------------------

  - Please review the updated spec text. Next week there will be a
      request for republication.
  - RESOLVED: Close no change: taking BR out of flow removes its effect
              on the surrounding content, just like every other element
              (Issue #5749: What is the behavior of an
              absolutely-positioned <br>?)

CSS Highlight API
-----------------

  - RESOLVED: Reference DOM's definition of invalidity for static
              ranges for highlight API (Issue #5497: Invalidation of
              Static Ranges)
  - RESOLVED: Republish Highlight API

CSS Scrollbars
--------------

  - RESOLVED: Retitle CSS Scrollbars to CSS Scrollbar Styling (Issue
              #6549: Improve title)
  - RESOLVED: Republish CSS Scrollbars

CSS Color Adjust
----------------

  - RESOLVED: Move css-color-adjust-1 to CR
  - If a decision isn't reached on issue #5469 (Should forced-colors
      override `border-image`?) before the CR publication it will be
      noted inline as an open issue.

CSS Sizing
----------

  - RESOLVED: Add marquee to compressible elements (Issue #6342: Add
              <marquee> to list of compressible elements)
  - Issue #6754 (Definiteness of min-height: min-content) needs some
      additional discussion off the call about what option is most
      consistent and/or doesn't have negative performance implications.

Hit Testing
-----------

  - chrishtr will take the lead on reviewing the differences between
      Gecko and Blink implementations.
  - There is still no volunteer to try and specify hit testing, but the
      group would be interested in doing so if anyone does step forward.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0003.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Dan Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Megan Gardner
  Daniel Holbert
  Sanket Joshi
  Jonathan Kew
  Ting-Yu Lin
  Peter Linss
  Morgan Reschenberg
  François Remy
  Jen Simmons
  Miriam Suzanne

Regrets:
  Chris Lilley
  Lea Verou

Scribe: fantasai
Scribe's scribe: TabAtkins

  Rossen: Any additional topics?
  smfr: Hit testing isn't specified anywhere, and CSSWG has said
        doesn't want to spec it
  smfr: but inert attribute affects hit testing, can't define clearly
  <emilio> smfr: you aware of https://github.com/whatwg/html/issues/5650 ?

TPAC Reminders
==============

  Rossen: Calls with i18n and a11y on 20th and 27th
  astearns: They will be during our regular telecons
  astearns: There's a bunch of issues tagged, but probably too many for
            a single hour each
  astearns: If people could review and tag Agenda+ TPAC as appropriate,
            would be helpful
  astearns: Note that we will not have our usual calls those weeks
  astearns: I'll post all the details to the internal list

CSS Positioned Layout L3
========================

  <astearns> https://drafts.csswg.org/css-position-3/#changes
  fantasai: I wanted to repub. We fixed a pile of errors, hopefully
            correctly.
  fantasai: We'd particularly appreciate review from Oriol and Ian.
  fantasai: So would like to update the draft.

  Rossen: Do you want to republish now, or ask for review this week?
  fantasai: I'll let Oriol make that call, I haven't reviewed his
            comments since yesterday
  <oriol> It's https://github.com/w3c/csswg-drafts/issues/6580
  oriol: I didn't review everything, but filed an issue about one part
         that's confusing
  Rossen: OK, sounds like we'll call for review this week and republish
          next week

CSS Highlight API
=================

Invalidation of Static Ranges
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4597

  <dandclark> https://dom.spec.whatwg.org/#staticrange-valid
  dandclark: Discussed structures for representing highlights
  dandclark: Author could choose live or static ranges, with different
             perf considerations each
  dandclark: Issue was originally open to discuss, given static ranges
             can become stale
  dandclark: What is an invalid static range that we should not try to
             paint?
  dandclark: Do we want to have highlight API spec point to these
             definitions in DOM spec, or do we want a different
             definition
  dandclark: ...
  dandclark: [reads criteria]

  florian: I think it's likely a good idea to point to DOM
  florian: Reason this is new is that it's first time in the platform
           that the static range is created by user and passed to UA
  florian: other uses the UA passes to user
  florian: The criteria listed are reasonable, but ...
  florian: but is sensitive to the length of the node
  sanketj: Should just follow DOM definition

  fantasai: What about the length?
  fantasai: What is the length of a node?
  sanketj: For text it's number of characters
  <cbiesinger> is that code points? code units?
  <sanketj> @cbiesinger, yes, code units
  florian: So if you have an offset bigger than length of node, one
           behavior is to treat whole thing as invalid
  florian: other behavior that we had originally was to clamp to within
           the length
  florian: Going with DOM's definition seems reasonable
  Rossen: Any objections to using DOM's definition of invalid for
          static ranges?

  RESOLVED: Reference DOM's definition of invalidity for static ranges
            for highlight API

  fantasai: Do we need to republish?
  fantasai: Last publication was 2020

  RESOLVED: Republish highlight API

CSS Scrollbars L1
=================

Improve Title
-------------
  github: https://github.com/w3c/csswg-drafts/issues/6549

  fantasai: The title is "CSS Scrollbars", but we're not actually
            generating scrollbars
  fantasai: We're styling them, so I propose renaming to "Scrollbar
            Styling"
  Rossen: That makes too much sense.
  TabAtkins: I presume no shortname change, just a title change?
  fantasai: Yes

  RESOLVED: Retitle CSS Scrollbars to CSS Scrollbar Styling

  RESOLVED: Republish

CSS Positioned Layout
=====================

What is the behavior of an absolutely-positioned <br>?
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5749

  Rossen: Seems the proposal is to close no change.
  smfr: Question is if you have a <br> and say 'position: absolute'.
        Does it trigger line breaks?
  smfr: 'position: absolute' takes it out of flow
  smfr: which probably means it shouldn't trigger a line break
  smfr: so I think Gecko has the right behavior
  smfr: Slight concern about if it's web-compatible, but if Gecko's
        shipping probably OK

  Rossen: Do we have any specific spec text defining it one way or
          another?
  smfr: I think the spec is fine, just implementers not following spec
  florian: That and fact that BR and WBR aren't properly specced fully
  florian: We've had discussions about how to represent them, but
           haven't fully resolved
  florian: but only logical behavior is if take out of flow, stop
           influencing the text round it
  Rossen: Sounds like we have consensus for breaking behavior here
  Rossen: and that seems to be spec-compliant atm
  emilio: I've never heard a compat issue with Gecko's behavior so far
  <jfkthame> nor have I, fwiw

  Rossen: proposed close issue no change to spec and encourage UAs to
          follow Gecko's lead

  RESOLVED: Close no change: taking BR out of flow removes its effect
            on the surrounding content, just like every other element

  <astearns> A testcase would be an excellent encouragement (and smfr
             just added the tag to the issue)
  emilio: Where does the WebKit behavior come from?
  smfr: It's probably very historical
  iank: BR inherits from text node, so has ...

CSS Color Adjust
================

Should forced-colors override `border-image`?
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5469#issuecomment-707918323

  TabAtkins: This is the only issue open to block us from CR
  TabAtkins: we pinged you repeatedly for the answer, and no response
  TabAtkins: So put it on the agenda.
  Rossen: Have some colleagues closer to the implementation, will tag
          them.
  fremy: wouldn't mind keeping the border image, just in case
  Rossen: hopefully close on this before the end of the week

  Rossen: horizontal review issue?
  fantasai: We only have the one issue open. Horizontal review is done.
            We want to transition to CR, once the border-image issue is
            closed.
  Rossen: Should we resolve provisionally, or resolve next week?
  TabAtkins: up to the chair :)
  Rossen: Current spec doesn't override border-image?
  TabAtkins: Current spec calls for that I believe
  TabAtkins: border-image is not on the list of properties getting
             overridden
  Rossen: That reflects current implementations. Don't see why we'd
          want to change it. Does anyone have a different opinion?
  TabAtkins: We're not trying to resolve on the open question right now.

  TabAtkins: Question is do we want to move to CR?
  Rossen: Current spec matches our expectations
  <fremy> +1 to what Rossen said; also border-image is quite rare, it's
          tough to say why it's used because it can be creative
  TabAtkins: Question is, do we want to resolve regardless of how that
             issue is resolved, or do we want to wait for that issue
             before deciding?
  Rossen: Currently we can proceed with CR. I will follow up with folks
          here today and have closing arguments in the issue by end of
          week
  Rossen: If we end up changing, let's handle it later
  tantek: Is the issue linked in the draft?
  TabAtkins: No
  Rossen: If we can't close this, put a link in there
  <tantek> perhaps in the status section
  Rossen: OK, calling for provisional CR transition resolution
  Rossen: Any last concerns to moving forward with transition?

Publication
-----------
  github: https://github.com/w3c/csswg-drafts/issues/5768

  RESOLVED: Move css-color-adjust-1 to CR

CSS Sizing
==========

Add <marquee> to list of compressible elements
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6342

  fantasai: We were told to add <marquee> to the list of compressible
            elements, wondering if there's any objection
  Rossen: Any opinions?

  RESOLVED: Add marquee to compressible elements

Definiteness of min-height: min-content
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6457

  “The original question still remains: the spec is currently implying
      that the content-based sizing keywords in the min-* properties
      don't prevent children from resolving %s against those sizes
      (even though the width/height properties themselves do). This is
      necessary behavior for the automatic minimum size (or else
      percentages would usually be unresolvable), which can be
      content-based, so it seems like it should be fine to specify that
      explicitly for all the content-based sizing keywords. But given
      that these keywords aren't otherwise representing definite sizes,
      do we actually want to?”
  TabAtkins: Original question of issue is still open
  TabAtkins: For reasons of usability, we had to rule that 'min-size:
             auto' does not prevent percentages on your children from
             resolving
  TabAtkins: even though technically the size of parent might be
             dependent on size of contents
  TabAtkins: because if not, percentages would hardly ever resolve in
             flex or grid
  TabAtkins: But we have also the min-content and max-content keywords
  TabAtkins: Do we make these also not block percentage resolution on
             children?
  TabAtkins: Or do we want to hold the line, and have these
             content-based keywords block percentage resolution
  TabAtkins: just like they do in the not-min sizing properties (width/
             height/etc.)
  TabAtkins: Not necessarily need to resolve now, but wanted to bring
             up the question

  iank: I'd want to discuss with David
  dholbert: I think given how treated as 'auto' right now, there might
            be web-compat demand for them to have same definiteness
            properties.
  fantasai: Given they're "treated as auto" and not commonly used,
            there's not much incentive for authors to use them right
            now, especially in a min-size property; feels unlikely that
            there's compat risk
  Rossen: Any concrete use cases?
  TabAtkins: no, this is a question of consistency
  TabAtkins: what kind of divergence do we want here
  TabAtkins: we need an answer for the spec, but having use cases

  dholbert: For non-definite case
  dholbert: consider a deeply-nested flexbox case
  dholbert: Want content-based minimum
  dholbert: but don't want performance complications
  dholbert: so switch from auto to min-content
  dholbert: That said, browser could also maybe detect the lack of
            percentages inside the element
  dholbert: and not run the second layout pass
  dholbert: Can't think of another justification for not being definite
  jfkthame: Agree
  Rossen: The deeply nested elements can be made context aware and
          resolve % only in the cases of having both % and min-content
  Rossen: I think the performance problem stated here is more of a
          speculation
  Rossen: less a concrete concern
  Rossen: My preference would be to keep it consistent
  fantasai: Consistency works both ways
  fantasai: These keywords in 'height' cause it to be indefinite
  fantasai: So do we want to be consistent with that? or with
            'min-height: auto'?

  Rossen: Where do we go from here?
  fantasai: Tab and I are happy for people to think about it. We just
            wanted to bring it up and explain on the call.

Hit Testing
===========

  Rossen: We don't have it specified anywhere, but acknowledge that it
          exists
  Rossen: and smfr points out that the inert attribute is under-defined
          as a result
  <smfr> https://github.com/whatwg/html/issues/5650
  smfr: This is the a WHATWG issue that discussion is in
  smfr: The inert attribute in HTML is intended to make an element
        unresponsive to user interaction and also hidden from a11y
  smfr: One of the intended uses is, in combination with dialog,
  smfr: ....
  smfr: behaves as though has inert attribute, not interactive
  smfr: Gecko and Chrome have initial implementations of this attribute
  smfr: which differ in how they prevent interaction
  smfr: Chrome has gone with a more DOM-based approach, kinda like
        disabled form control
  smfr: Emilio's approach in Gecko is different, more like
        'pointer-elements: none'
  smfr: These have different behaviors wrt z-index, if you stack
        elements, what happens when you click on it?
  smfr: also [...]
  smfr: Also, can a non-inert tree have an inert tree (???)
  smfr: Trying to resolve differences between Gecko and Blink's
        interpretations
  smfr: Emilio believes not specified well enough for any browser to
        ship it
  smfr: There are some WPT, but not exhaustive
  emilio: In particular, Blink's implementation also have some event
          retargeting going on
  emilio: Implementing it in either existing or new CSS primitives
          would be great
  emilio: but question of hit testing is not defined

  florian: Earlier you stated that we decided we didn't want to specify
           it
  florian: I think our conclusion was more that it's a giant topic and
           nobody is taking it up, rather than it's out of scope for us
  florian: We could do it, but nobody is signing up
  smfr: Hit testing is the inverse of painting, so should be able to
        specify it
  smfr: Also elementFromPoint is in CSSOM-view, which involves hit
        testing
  florian: So maybe need to bite the bullet and find someone to do it

  chrishtr: Which spec would it go into?
  florian: We had an earlier discussion that the property
           'pointer-events' could go into css-ui
  florian: as long as just a switch, why not
  florian: but scope of defining all of hit testing is probably too much
  florian: so probably want a standalone spec
  chrishtr: Also painting is also not in an awesome spec location
            either, in CSS2 right?
  florian: Yes, we want a standalone spec for that also
  florian: Then as new specs tweak it, can refer to that. But need a
           foundation document
  chrishtr: So new spec for painting, and also hit testing
  chrishtr: I've been sad about state of painting also
  florian: So, now that we've increased the scope :) Still looking for
           a volunteer to do it
  chrishtr: I'll try to find someone
  Rossen: Sounds good

  Rossen: Anything specific, smfr?
  smfr: Would like to solve this issue before we have a hit testing
        spec, because that will take years, but we need to implement
  chrishtr: Alice (??) was the one who implemented, and wanted to try
            to ship, but then discussions with Gecko ...
  chrishtr: I will volunteer to go back and reread the blink-dev thread
  chrishtr: and then respond with an update
  chrishtr: I think we're quite close to having this in all three
            browsers, which would be nice to achieve
  Rossen: So, a lot of volunteering from Chris, which is great.
          Hopefully issue will make progress, and maybe we'll even work
          on it.

  Rossen: Assuming nothing else on this topic, and we did everything on
          the agenda
  Rossen: let's close
  tantek: Did we get the funding we needed for infrastructure?
  <TabAtkins> nope, not yet
  Rossen: I haven't heard anything. Anyone else?
Received on Wednesday, 8 September 2021 23:36:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 8 September 2021 23:36:42 UTC