- 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