- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 8 Feb 2024 18:45:09 -0500
- 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.
=========================================
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