- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Jan 2024 19:18:01 -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 Viewport ------------ - RESOLVED: Create FPWD for css-viewport-1 - RESOLVED: Publish FPWD for css-viewport-1 Media Queries ------------- - RESOLVED: Adopt picture-in-picture media query (Issue #9260: Add display-mode for document picture-in-picture) - RESOLVED: Remove requirement for the ua stylesheet rule for inverted-colors (Issue #9674: Inverted-colors media feature can cause problems on semi-transparent images) Selectors --------- - RESOLVED: No change to :has() behavior (Issue #9422: Is it intentional that :has(:is()) is different from :has()?) - RESOLVED: Close issue #5684 (What is the reasoning for ignoring default namespaces only on the subject for :is() / :where() / :not()?) with no change CSS Nesting ----------- - RESOLVED: Contextually-invalid selectors have a specificity of zero (Issue #9600: Specificity of contextually-invalid selectors) CSS Contain & Sizing -------------------- - RESOLVED: Add ScrollIntoView to the definition of relevant to the user, should also affect ancestors (Issue #9337: ScrollIntoView a descendant of element with content-visibility:auto) ===== FULL MEETING MINUTES ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jan/0009.html Present: Rachel Andrew Adam Argyle Tab Atkins-Bittner Kevin Babbitt David Baron Oriol Brufau Emilio Cobos Álvarez Yehonatan Daniv Matthieu Dubet Elika Etemad Robert Flack Daniel Holbert Jonathan Kew Vladimir Levin Chris Lilley Peter Linss Eric Meyer Alan Stearns Miriam Suzanne Bramus Van Damme Regrets: Chris Harrelson Lea Verou Chair: astearns Scribe: Frances CSS Viewport ============ Republishing Tasks Permathread ------------------------------ github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-1894132753 astearns: First on the Agenda is FPWD for css-viewport-1 Emilio: Something might be worse than doing, but we can republish it. Place for things in the spec that are linkable. astearns: Inclined to publish now and zoom stuff later. PROPOSAL: Publish FPWD for css-viewport-1 Florian: Section 3 viewport, is it light? astearns: We already published the section astearns: Any objections? astearns: None and resolved. RESOLVED: Create FPWD for css-viewport-1 RESOLVED: Publish FPWD for css-viewport-1 Media Queries ============= Add display-mode for document picture-in-picture ------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/9260 <TabAtkins> https://github.com/WICG/document-picture-in-picture TabAtkins: There is a spec for the PROPOSAL: Add display-mode for document picture-in-picture Emilio: A lot of the preexisting values for this would be reasonable. How do the values intersect such as in full screen? TabAtkins: Mutually exclusive, if not right, we can figure it out. Emilio: Not opposed. Probably file an issue in a variety of cases. TabAtkins: Reviewed by people, about 60 issues. astearns: A couple avenues such as specifying what's there in the wiki-spec and take on the issues or in the repository TabAtkins: All picture-in-picture api, displayed as pip or not? astearns: Any other comments on taking on a picture-in-picture media query? PROPOSAL: Adopt picture-in-picture media query astearns: Any objections? RESOLVED: Adopt picture-in-picture media query Inverted-colors media feature can cause problems on semi-transparent images -------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9674 astearns: Next issue is about Inverted-colors media feature Emilio: Seemed familiar, spec has ui style that manually applies a filter to an image and a picture and video and so on. Seems good but it is a problem for a bunch of images, if images with same color as text it is invisible. Agree to not inverting and react to preferences themselves. Emilio: Unfortunate for visual images, makes sense to not invert because aligns with how we treat other user preferences. <TabAtkins> +1 in general, auto-responding to the query is confusing (especially when there's a mix of behaviors between browsers, ugh) emeyer: Had to do uninverting and reinverting, browser should not be trying to guess. Authors should deal with them and not at browser level. <kbabbitt> +1 to favoring author control argyle: Chrome has tried automatic dark-mode, not to just invert, but intelligently invert. Should leave the value in the authors control, many edge cases and nesting scenarios. PROPOSAL: Remove requirement for the ua stylesheet rule for inverted-colors astearns: Any objections or comments? RESOLVED: Remove requirement for the ua stylesheet rule for inverted-colors Selectors ========= Is it intentional that :has(:is()) is different from :has()? ------------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/9422 Emilio: Feels weird to make :has() to escape the scope of the subject, fine with no change, slow path in every engine if wrong. astearns: Is there something we can put in the specification to make it more clear? Emilio: Clarifying is good TabAtkins: Behavior is what you get when combining two features. If something that can be added, put in the spec. astearns: Any other comments? PROPOSAL: No change to :has() behavior astearns: Any objections? RESOLVED: No change to :has() behavior What is the reasoning for ignoring default namespaces only on the subject for :is() / :where() / :not()? ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5684 astearns: Namespaces for :is() / :where() / :not() Emilio: Compat-wise is probably okay, Tab's answer is good but weird that nested selector list has weird parsing behavior. TabAtkins: Context if you write a selector without a namespace, with a url, will apply namespace to all selectors unless specifically overridden, even non type selector in the element name. <TabAtkins> a.foo <TabAtkins> a:is(.foo, .bar) <TabAtkins> foo|a:is(.foo, .bar) TabAtkins: Issue is if you start with a .foo and then want to have foo or a bar class, normally second selector matches same or more elements. In presence of default namespace selector, it might not. <TabAtkins> foo|a.foo => foo|a:is(.foo, .bar) TabAtkins: If it wasn't for the special case, they could get the default namespace rather than .foo namespace. Selector might not match anything. Do not apply now special namespace rule to their arguments. <TabAtkins> foo|a.foo <TabAtkins> foo|a:nth-child(n of .foo) TabAtkins: Some related issues about other spots such as nth child of the selector. Expect to match all elements, with default namespace rule, it might not match anything. TabAtkins: Alternative is if you don't want backwards incompatible, can remove default namespace rule to only use when there is a type selector. Namespaces in general are rarely used across css, could fix by removing the special rule. Emilio: What is the implementation style of the rule? dbaron: Probably well implemented for :not for the subject part of it. When you talk about a type selector, should be explicit about whether or not you're including universal selectors. TabAtkins: Default selector is a universal selector dbaron: :hover and *:hover would now be different, which is a little weird. Oriol: If using featureless element, need to use universal selector to match them. Emilio: Only on quirks mode? Oriol: For :hover, they are the same except for some cases can add universal selector to change the meaning. TabAtkins: :host and *:host might not match a featureless element. Emilio: Ignore default namespace unless global or type selector. TabAtkins: We can close the issue with no change and open another issue with changing the underlying rule entirely to be mutually exclusive with some of the other issues with the :is rule, need to be consistent and intuitive. Why do we have the rule in first place need to explain. astearns: Need to describe if backwards compatible. Emilio: Do we want it in the right most compound, why only in the right most compound? TabAtkins: The one that is selecting the element, namespace rule probably invented to restrict to the default namespace, would make slightly harder to use the selector? dbaron: Might be a function of how the selectors evolve over time, not taking combinators, and now taking them. TabAtkins: Does make sense to apply to all components. dbaron: Rule to not apply to is part after last combinator makes sense. TabAtkins: Intuition is to use :is and :where as syntax rules, such as preceding combinator, treated same as outer dbaron: When there is a default namespace, should only be applied in one place in the selector for a particular element, so if you're overriding it you don't have to override it the same way in both places. dbaron: Right now outside of :where and not inside dbaron: Also, regarding :has(), I can certainly see :has() working differently Emilio: :has is different, is doesn't match. nth is different from :where. Interesting to see where in browsers it's implemented, possible non intentional implementation. Emilio: Fine with no change, can address in another issue. Might not be specific to Firefox. We could try simplifying it. PROPOSAL: Close issue #5684 no change astearns: Can make the rule consistent, open a new issue on backwards compatibility or remove rule entirely ACTION: TabAtkins to create a new issue for removing the rule RESOLVED: Close issue #5684 with no change CSS Nesting =========== Specificity of contextually-invalid selectors --------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9600 Emilio: About what happens when nesting invalid pseudo-element. Keeps sort of being valid, reuse selector from the outside. Behavioral specificity of nesting doesn't seem defined. <TabAtkins> I have no opinion on this issue, happy to clarify/edit whatever the group wants. matthieu: Weird that specificity is taken in account. Keep invalid selector, we don't take specificity in account. Emilio: Seems fine to me, would make behavior of nesting and not nesting as consistent, makes sense. Part of the way to prevent is by sharing memory, need to make specificity not count. astearns: Defining a behavior shouldn't have too much backwards compatibility risk possibly. Emilio: Right now are consistent in reusing the specificity, other cases like :has(:has) astearns: Any other comments or questions? PROPOSAL: Specify contextually-invalid selectors via nesting Emilio: Nesting doesn't have specificity at the moment. PROPOSAL: contextually-invalid selectors have a specificity of zero Matthieu: Specific wording? Emilio: Make it behave the same as the regular selector list RESOLVED: contextually-invalid selectors have a specificity of zero CSS Contain & Sizing ==================== ScrollIntoView a descendant of element with content-visibility:auto ------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9337 Emilio: Some interoperability, need to generalize to arbitrary ancestors. ScrollIntoView should update layout to scroll into view to be visible. astearns: Change definition relevant to the user to add a condition via ScrollIntoView to be relevant. Emilio: Make all ancestors relevant as well. flackr: Might not fully fix problem, scrolling away from is also visibility:auto, other content might change Emilio: Ideally it shouldn't flackr: Scrolling may pass over other content Emilio: If scrolling to the hundredth item and scrolling into view, make hundredth item relevant and the ancestors. The siblings from 50 to 100 might not be relevant to the user and can change size. flackr: We need to be adjusting the scale-target astearns: Not an issue with the proposed resolution flackr: Instead of calculating target, we can update the target with the location. Such as when the target scrolls into view. vmpstr: Can ScollIntoView without an animation, still need the resolution. The position of the element may be locked in size-overflow, and might not approach the viewport. vmpstr: Content-visibility:auto state changes, might fire an event in those cases. flackr: Reasonable argument for accepting proposed resolution, possible other resolutions. astearns: Any other comments? PROPOSAL: ScrollIntoView a descendant of element with content-visibility:auto relevant to the user, should also affect ancestors. RESOLVED: Add ScrollIntoView to the definition of relevant to the user, should also affect ancestors
Received on Thursday, 18 January 2024 00:18:35 UTC