- 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