[CSSWG] Minutes Telecon 2024-02-07 [css-overflow] [mediaqueries-5] [css-ui-4]

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


CSS Overflow
------------

  - RESOLVED: Overflowing into the gutter of a classic scrollbar
              triggers scrollable overflow, overflowing into the gutter
              of a overlay scrollbar does not trigger scrollable
              overflow (Issue #5253: Overflow into the gutter)
  - RESOLVED: Drop scrollbar-gutter: force (Issue #9815: Subgrid
              obviates the need for `scrollbar-gutter: force`)

Media Queries
-------------

  - There needs to be more use case discovery for issue #3871 (Detect
      physical keyboard (keyboard capable of shortcuts?)). On the call
      games were mentioned as a potential use case, but also concerns
      about fingerprinting and needing to tell the user so they can opt
      to add a keyboard.
  - RESOLVED: Add window-focus: active | none, bikeshed later (Issue
              #5828: active vs inactive window states)
  - RESOLVED: Add window-focus: active or none matching behavior of
              javascript in print behavior and matching (Issue #5828)

CSS UI 4
--------

  - RESOLVED: Align canonical order of outline sub-properties with
              border (Issue #7700)
  - RESOLVED: The caret animation is auto versus none (Issue #9707:
              Inteference with the caret blinking and the ability to
              animate its color)

===== FULL MEETING MINUTES ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2024Feb/0002.html

Present:
  Rossen Atanassov
  Tab Atkins-Bittner
  Kevin Babbitt
  Stephen Chenney
  Elika Etemad
  Robert Flack
  Daniel Holbert
  Brian Kardell
  Alison Maher
  ChangSeok Oh
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

Regrets:
  Rachel Andrew
  Oriol Brufau
  Yehonatan Daniv
  Chris Harrelson
  Jonathan Kew
  Cassondra Roberts
  Noam Rosenthal
  Khushal Sagar
  Bramus Van Damme
  Sebastian Zartner

Chair: Rossen

Scribe: Frances

CSS Overflow
============

Overflow into the gutter
------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5253

  Rossen: Our topic of discussion is transform-box:stroke
  Rossen: Moving to scrollbar gutter, some members are not available to
          discuss topics.
  florian: Didn't define so far overflowing into the gutter, do we
           treat as padding effectively, or an area beyond the padding
           to have an effect on overflow?
  florian: Constrained if overflowing into a scrollbar, could trigger
           overflow and would have to account for it. If overflowing
           into the gutter of a classic scrollbar, might not trigger
           overflow. Could trigger instability.
  florian: Classic scrollbars could have the same answer, if
           overflowing into classic scrollbar, if overflowing into
           overlay scrollbar. Nuance of scrollbar gutter only has the
           stable value. A value to reserve for space in overlay
           scrollbars.
  <TabAtkins> Sounds reasonable to me.
  PROPOSAL: overflowing into the gutter of a classic scrollbar triggers
            scrollable overflow, overflowing into the gutter of a
            overlay scrollbar does not trigger scrollable overflow

  flackr: Layout of the site could be affected
  florian: Will be accessible regardless, can scroll though the content
           anyways.
  flackr: Different platforms could be affected.
  florian: Not necessarily

  RESOLVED: Overflowing into the gutter of a classic scrollbar triggers
            scrollable overflow, overflowing into the gutter of a
            overlay scrollbar does not trigger scrollable overflow

Subgrid obviates the need for `scrollbar-gutter: force`
-------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9815

  florian: scrollbar-gutter: force value would be the same gutter in an
           element that doesn't scroll at all. A scroller and right
           next to the scroller a toolbar of some kind. If you have a
           scrollbar or a gutter that consumes space to the right, the
           same amount of space could visually line things up.
  * bkardell supports closing an issue / removing an ask
  <astearns> +1 to removing the value
  florian: grid and sub grid are good at aligning things to take into
           account the width, we can drop this property.
  Rossen: Any objections?
  PROPOSAL: Drop scrollbar-gutter: force

  RESOLVED: Drop scrollbar-gutter: force

Media Queries
=============

Detect physical keyboard (keyboard capable of shortcuts?)
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3871

  florian: Seems useful to have media query to see if you have a
           keyboard or not for keyboard shortcuts or a layout with
           keyboard shortcuts. What is a keyboard and what keyboards do
           we want to detect?
  florian: Onscreen keyboards, virtual keyboards, need to define with
           use cases on a variety of devices before answering the
           questions such as privacy concerns.
  bkardell: I was going to agree with smfr on the thread that
            fingerprinting/privacy were something to be aware of and
            maybe make us wary of this

  astearns: Displaying shortcuts only if there is a keyboard to
            accomplish shortcuts, could possibly be bad if we don't
            notify the user, because they might decide to plug a
            keyboard in to use the shortcuts
  flackr: Developers can already infer whether there is a keyboard or
          not, exposed through the visual viewport api only after
          interaction.
  vmpstr: There could be use cases for games showing on screen controls
          vs not when there is a keyboard attached
  florian: These are the type of questions we need to answer.

active vs inactive window states
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5828

  fantasai: We have ::selection vs ::inactive-selection, we decided to
            have a separate media query. What should it be called?
  TabAtkins: Windows state vs active and inactive for the values
  florian: Is there a tab to not focus on multiple windows?
  TabAtkins: Javascript doesn't expose additional states
  <fantasai> window-focus: active | none
  <fantasai> window-focus: active | inactive
  fantasai: Could have an alias for inactive, do not need none on top
            of it.
  florian: Could do something else
  Rossen: In overloaded, it could be confusing on the actual focus
          inside of a window for accessibility.
  <kbabbitt> Wondering which value would take effect in print media
  <fantasai> kbabbitt, good question. I'd say active
  <schenney> We already support ::selection:window-inactive and
             ::selection:window-active in Blink
  <schenney> I would drop those if we have a media query.
  <fantasai> yes

  kbabbitt: Which value would take in affect when considering such as
            none or active, in a default-ish state?
  florian: Need to have a contraster.
  fantasai: Is it a view focus or a viewport focus? Or an iframe?
  florian: It is in javascript, let's not be different in javascript.
  <TabAtkins> In JS, the state is exposed via "blur" and "focus" events
              on window
  Rossen: Any additional thoughts? No objections

  PROPOSAL: Add window-focus: active or none matching behavior of
      javascript in imprint behavior and matching

  RESOLVED: Add window-focus: active | none, bikeshed later
  RESOLVED: Add window-focus: active or none matching behavior of
            javascript in print behavior and matching

CSS Multicol
============

What is the max-content width of a muticol container with only
    column-width:<length>
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9103

  dholbert: No current browser behavior makes much sense. Firefox makes
            the most sense but could end up still overflowing.
  Rossen: Moving onto the next issue, a member is not present necessary.

CSS UI 4
========

Align canonical order of `outline` sub-properties with `border`
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7700

  florian: The outline property has 'outline-color, outline-style,
           outline-width, and there is a strange order. Should we
           follow the implementations or challenge it for more
           consistency with border? Possibly not important, but
           consistency is nice.
  fantasai: Line things up unless there is a web compat issue, it is an
            error in the spec, previously order in the grammar was not
            significant.
  <fantasai> ->
https://github.com/w3c/csswg-drafts/issues/7700#issuecomment-1440764072
  florian: Shouldn't change the spec depending on the interoperability.
  florian: Can resolve to change possibly from the issue
  dholbert: Could change in a coordinated way.
  Rossen: Any objections?
  PROPOSAL: Align canonical order of outline sub-properties with border

  RESOLVED: Align canonical order of outline sub-properties with border

Inteference with the caret blinking and the ability to animate
    its color
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9707

  florian: Using the caret-color property that is implemented is an
           animated property. Could use the wrong blinking between
           transparent and the color. Proposal is to make it possible,
           to opt to not animate the caret.
  florian: If there is not an override, we need to create a more
           reliable animation. Use various built in types of
           animations. Add none and auto.
  florian: Counter point is that sometimes the browser can do things
           that is not just thinking, if stopping the animations then
           could lose animating the caret at the same time.

  kbabbitt: Could a better property be the caret pseudo element to
            replace the blinking and a box caret, would it be more
            extensible?
  florian: This could possibly expose too much structure, most carets
           might be simple, might be used in case. Could be a dormant
           property. Make an explicit not implementing the caret in
           adding support and being able to add support. Browsers that
           do not want to yield should be able to not implement the
           caret

  <TabAtkins> I think the "people are already just completely replacing
              the caret, we likely won't make this worse" is
              reasonable, so adding this won't make things meaningfully
              worse (and is outweighed by having the native caret be
              used, which is less janky).
  <vmpstr> Tab, the blinking rate though is something that is (or can
           be) user set and so ignoring that because author said so
           seems wrong... But I agree that if authors already replacing
           the whole caret, maybe this isn't worse

  flackr: We have some pseudos to specify only a few properties.
  florian: There are some fairly limited carets that exist. Such as
           both sides of the logical locations. Not sure if a caret
           pseudo would be the right thing.
  florian: What does width mean? Multiple pieces? We would need to
           describe the structure.

  TabAtkins: We already have existent proof in manually reimplementing
             them. It could be less janky with a more correct caret.
             More people could replace the animation of a caret for the
             user of a web page.
  TabAtkins: Leans towards this being a useful thing to specify.
  florian: We need to be careful to not interfere in any way in
           accessibility.
  Schenney: The most similar pseudo would be spelling and grammar, text
            browsers render native text-decorations
  Schenney: We can outline and could put a special caret.

  PROPOSAL: The caret animation is auto versus none

  RESOLVED: The caret animation is auto versus none

Received on Thursday, 8 February 2024 23:45:43 UTC