- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 9 Dec 2022 15:28:31 -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 Fonts
---------
- RESOLVED: Use set explicitly, reset implicitly and cascade
implicitly terms (Issue #7832: Should `font-palette` be
reset by the `font` shorthand?)
- RESOLVED: Put font-palette in the cascaded independently category
(Issue #7832)
- RESOLVED: Explicitly enumerate all properties which are cascaded
independently that start with font- (Issue #7832)
Scroll Anchoring
----------------
- Discussion on issue #4264 (Explicit anchoring) will return to
github to discuss further if there's a desire to keep improving
the algorithm or if a preference should be introduced because
the algorithm is pretty much complete.
CSS Display
-----------
- RESOLVED: Merge this PR (Pull request #8095: Define root element
(as a term, and its display type))
CSS Images
----------
- RESOLVED: Revert the definition of crisp edges to allow for more
advanced algorithms (Issue #6038: Is "image-rendering:
crisp-edges" still worthwhile to keep separate?)
Selectors
---------
- RESOLVED: Make :has unforgiving (Issue #7676: The forgiving nature
of :has breaks jQuery when used with a complex :has
selector)
- RESOLVED: Limit forgiving behavior to :is and :where and remove it
everywhere else (Issue #7676)
CSS Contain
-----------
- RESOLVED: Match intersection observer behavior for this definition
(Issue #5641: Spec is unclear about whether 0-sized
boxes can be "relevant to the user" (since they have
zero intersection area))
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Dec/0003.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Jonathan Kew
Chris Lilley
Peter Linss
Ben Mathwig
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Sebastian Zartner
Regrets:
Bramus Van Damme
Chair: astearns
Scribe: flackr
CSS Fonts
=========
Should `font-palette` be reset by the `font` shorthand?
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7832
jfkthame: When implementing font palette for gecko, I noticed in
blink and webkit the font shorthand doesn't reset
font-palette to the initial. This could just be a bug, but
I wonder if it would be preferable
jfkthame: font palette seems to be a bit different in that it may be
set on the root, and devs may be surprised when the font
short-hand loses that setting
chris: Agree it's surprising. The only reason the spec doesn't do
this was because it's recent.
chris: This one should not have been in the implicitly reset
chris: We should use set explicitly, reset implicitly, and cascade
independently
chris: it's common to set on the root, it makes sense
RESOLVED: Use set explicitly, reset implicitly and cascade
implicitly terms
RESOLVED: Put font-palette in the cascaded independently category
fantasai: Every property that's not part of the shorthand be
cascaded independently. It would be helpful to have a note
for the properties that begin with font- to consider them
explicitly
astearns: Are there any properties beside font-palette and
font-synthesis in this category?
chris: Don't think so, might happen
RESOLVED: Explicitly enumerate all properties which are cascaded
independently that start with font-
Scroll Anchoring
================
Explicit anchoring
------------------
github: https://github.com/w3c/csswg-drafts/issues/4264
SebastianZ: Explicit anchoring came up many times. We currently have
some overflow anchoring that you can opt out of, but
there is no way to choose explicit anchoring or set
elements to be preferred explicitly.
SebastianZ: The idea that came up several times is to add a new
keyword to the overflow-anchor property, indicates the
element is preferred in the anchoring node selection
algorithm step 2
SebastianZ: I suggest prefer keyword, name open to bikeshedding
emilio: There are 2 interleaved things. Your proposal is about
making a note about somehow being preferred. The other thing
mentioned is about force enabling anchoring. Right now
there's a bunch of heuristics
emilio: Do we want to restrict this to the former thing or also
discuss enforcement
SebastianZ: Discuss both
emilio: The prefers stuff may be a bit tricky when you have
conflicting elements. Should the preference be a number to
help with this, what elements should be excluded?
emilio: Is an element completely in view preferred?
astearns: The details of how this property or index value effects
the heuristics would have to be precisely specified
astearns: I'm wary of another index value to fight over priority
fantasai: If you set prefer on it, maybe you filter the list of
candidates to the preferred list, and then fall back to
the non-preferred list
astearns: Would anyone argue against allowing authors input to the
algorithm
flackr: I think that we're still fairly naive in the anchoring
algorithm, and introducing a preference and having ways that
we expect that preference to work now might prevent us from
making improvements to the overall anchor selection
flackr: so that might be a reason to not have 'prefer' added now
SebastianZ: Just to emphasize. Regarding providing an index, my
suggestion was just to give the algorithm a hint to
choose the element but not to enforce anchoring
explicitly
SebastianZ: Not having indices, just preference for some elements
over others
smfr: The use case in the first comment, is about making sure
content inside the main content of the page is what's
preferred. This sounds like something that's set on an
ancestor of a node that's important. There's a lot of
hierarchy logic that needs to be defined.
smfr: e.g. is there something in the ancestor chain preferred, this
seems pretty complicated
<fantasai> smfr++
<fantasai> The idea of being able to e.g. set something on <main>
makes a lot of sense to me
astearns: I suggest that we take the discussion back to the issue,
not opposed to having a simple preference but we have to
work through it and also happy with the idea of trying to
improve the algorithm we have without this first and
adding it in a later level
astearns: or at a point where we feel the algorithm is as good as we
will make it and we need preference to improve
astearns: Let's take the discussion back to the issue
CSS Display
===========
Define root element (as a term, and its display type)
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/8095
<fantasai> https://github.com/w3c/csswg-drafts/pull/8095/files
fantasai: There's various things about root element that are
under-defined. The PR introduces the term root element,
clarifies the principal doc always establishes an
independent block, ??. It also defines the ICB establishes
a block formatting context
fantasai: This is a new concept. For the most part, browser behave
as if it is a BFC. The only thing I found different was
the firefox couldn't float the root box
fantasai: The other differences are some honor float or don't
TabAtkins: The text of the PR looks good
TabAtkins: It looks like this should be appropriate to apply to
things in the top layer as well, do you have an opinion?
fantasai: Makes sense, as a separate PR
TabAtkins: Agree, still need to pull out to a separate thing
dbaron: Anything weird with blocks doing things differently in block
axis vs inline axis that would mix things up with grid or
flex on the root?
fantasai: It all seems to behave as expected, percentages resolve
against ICB since ICB is definite
astearns: Assume there should be some wpt tests
fantasai: Yes, tests not there yet
astearns: Add tests-needed once we accept
astearns: Any other comments?
RESOLVED: Merge this PR
fantasai: Do we want to make float compute to none?
astearns: Is there an issue?
fantasai: No, in various discussions related to PR
astearns: Ian Kilpatrick is not on call but believe his opinion was
that it should not compute to none
astearns: I believe it's only gecko that does?
fantasai: Yes, and one or two of the print impls
<dbaron> I remember there being spec text about this at some point...
smfr: webkit does not (according to issue)
astearns: Let's merge this and later on decide whether to do
something special for floats
CSS Images
==========
Is "image-rendering: crisp-edges" still worthwhile to keep separate?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6038
TabAtkins: fantasai pointed out this needs a resolution. I took it
on editors discretion, dholbert agreed on this.
image-rendering controls how images are upscaled /
downscaled has a combination of value that vaguely try to
keep things pixelated
TabAtkins: pixelated, crisp-edges and nearest edges
TabAtkins: We ended up deciding that pixelated allowed slightly
blurred edges. There was also nearest which could result
in slightly different sizes because of grid mismatches
TabAtkins: and nearest edges allowed for higher quality resampling.
Nobody bit and implemented so I propose merging
crisp-edges and nearest-neighbor
TabAtkins: I removed crisp-edges and defined it to be equivalent to
nearest-neighbor which keeps edges crisp even if resized
a little
chris: I think this is right thing to do, the intent was for
crisp-edges to do nearest neighbor
fantasai: I don't like this change, because crisp-edges to me
suggests you get crisp looking edges rather than jagged
edges on diagonal lines
fantasai: There's lots of art for which this isn't appropriate. I.e.
you want something upscaled in a way to maintain edge
boundaries
fantasai: I can see a reason to want nearest neighbor but think this
should just be called nearest neighbor since that's what
you're requesting
TabAtkins: The edges are exceedingly crisp, jaggedness was present
in original image
fantasai: I feel the name doesn't imply make this roughly pixelated
fantasai: I think we could do better
astearns: Is crisp edges something we have to support for web compat?
TabAtkins: moz has it prefixed, maybe still, not sure about other
impls
smfr: I think browser want to map crisp edges to pixelated because
that's easier, but maybe now with machine learning algorithms
we'd have better ways to upscale line art and keep the door
open to use these options
<fantasai> +1 crisp-edges seems to me like it would be appropriate
for line art
TabAtkins: I'm fine either way, can define to be flexible or not
TabAtkins: If we leave it open, do we leave nearest neighbor as an
explicit algorithm, or have a value that's something like
nearest neighbor
fantasai: I think for most people they'd be happy with pixelated
which does almost this
<fantasai> with better handling of non-integer multiples
TabAtkins: I suspect so as well
TabAtkins: Proposal is that we partially revert, keep the merging of
crisp edges and nearest neighbor, default to nearest
neighbor but allow impls to use better algorithms
fantasai: I think the text before did this more nicely
TabAtkins: Problem was it referenced nearest neighbor algo
fantasai: We can put that as a definition in the property and
reference from two values
TabAtkins: Agreed
fantasai: I'm happy with crisp edges with original definition
RESOLVED: Revert the definition of crisp edges to allow for more
advanced algorithms
Selectors
=========
The forgiving nature of :has breaks jQuery when used with a complex
:has selector
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1332429146
TabAtkins: Since jquery defines :has for internal usage, when you
use it in jquery's lib, it tries to evaluate the selector
natively. If it throws an error then it goes back and
runs custom parser recognizing jquery specific things
like what used to be a jquery specific :has
TabAtkins: this means putting :has with a jquery specific selector
would definitely invoke the jquery parser and get jquery
specific behavior
TabAtkins: but since we made :has forgiving, if you have a jquery
selector inside of :has we drop the jquery specific
selector breaking pages depending on previous behavior
TabAtkins: Couple of proposals. My proposal is to take up fantasai /
dbaron proposal to remove forgivingness from :has and
everything but the :where and :is pseudoclasses
TabAtkins: This will make jquery selectors invalid and fallback to
jquery logic
TabAtkins: and means the list of things which are forgiving is short
and easy to understand
fantasai: :not was made not forgiving intentionally due to strange
behavior when you start dropping selectors
<emilio> +1
astearns: any concerns with making :has unforgiving?
lea: I think it's confusing to have :not not be forgiving and :where
and :is forgiving
lea: There has been a proposal to make forgiving selector list
invalid if every selector in list is invalid
lea: I think this works better regardless of jquery issues
lea: It does have downsides, e.g. ?? would change the meaning of the
selector but that's fixed by putting everything inside the :is
lea: I'd be more in favor of this than having some forgiving and
others not
astearns: This could be a separate issue, to continue to extend
unforgivingness
emilio: I find this a bit confusing rather than having :is and
:where being forgiving all the time
emilio: Browsers may not support some things and then your whole
selector gets dropped
emilio: I guess you could gate based on number of items, but this
breaks the point of making it forgiving
fantasai: There are good reasons to make forgivingness not apply to
:not, shouldn't go back on this
fantasai: I support restricting to :is and :where, it's really
simple, and because we do it this way you can control
whether something is forgiving or not by wrapping in :is
or :where
fantasai: I think it gives the author more power to control fallback
behavior and is easier to learn
<emilio> +1
fantasai: I feel this is easier than having behavior vary
<fantasai> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1332429146
fantasai: My recommendation is take the recommendation TabAtkins
proposed ^
fantasai: We can take up invalidity of a single invalid selector
inside :is() as a separate item to think about
TabAtkins: Agree with emilio. I feel strongly we should not make
forgivingness predicated on all being invalid or not. It
complicates the feature in non-obvious non-predictable
ways
TabAtkins: They might think something's reasonable but use something
that didn't exist. It doesn't seem great to have these
gotchas.
astearns: Let's try to resolve on specific behavior for :has
astearns: Proposed resolution is to make has unforgiving, any
objections?
RESOLVED: Make :has unforgiving
fantasai: Can we get a resolution to make everything other than :is
and :where unforgiving, e.g. nth-child and nth-last-child
<TabAtkins> +1 to limiting forgivingness to is/where
astearns: Anyone want to argue for keeping forgiving behavior in any
other pseudo?
RESOLVED: Limit forgiving behavior to :is and :where and remove it
everywhere else
astearns: We can discuss limiting it for those in a separate issue
CSS Contain
===========
Spec is unclear about whether 0-sized boxes can be "relevant to the
user" (since they have zero intersection area)
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5641#issuecomment-1250159004
TabAtkins: Problem is if you have a 0-sized box, it's not clear in
several conditions whether it's relevant to the user on
screen, next to screen, etc
TabAtkins: have to be careful whatever we do doesn't influence
positive area boxes
TabAtkins: The definition in the thread is if a box is 0 area we
treat it as if it's epsilon size in the 0-axis and
calculate intersection as normal
TabAtkins: This means if it's inside the viewport it's intersecting.
If it's next to, it also does so. But if it has positive
area but is adjacent it will remain not intersecting
TabAtkins: Specifically, if the element has 0 area it's on screen if
it's in the inclusive range of the viewport's bounds
TabAtkins: If this sounds reasonable, we can add this
emilio: Intersection observer has this idea of adjacent intersection
which handles this, any reason we can't use this?
TabAtkins: Not aware of details of this
<emilio> https://w3c.github.io/IntersectionObserver/#update-intersection-observations-algo
<emilio> > Let isIntersecting be true if targetRect and rootBounds
intersect or are edge-adjacent, even if the intersection
has zero area (because rootBounds or targetRect have zero
area).
smfr: A 0-sized box can be made and have a visual impact by having
an outline or box outset. These may have painted ink overflow
astearns: My understanding is we don't want to count ink overflow
astearns: We aren't including box shadows for example
smfr: Something visible on the screen may be interesting to use even
if it has 0 size
astearns: Proposal is we would only count adjacent boxes for 0 size
TabAtkins: My definition was carefully crafted to do a minimal
change but aligning with intersection observer is a good
idea and have no strong opinions on specific so prefer to
align with what IO does
astearns: This would catch those things which smfr mentioned and
also things which don't have ink overflow
TabAtkins: Not necessarily, ink overflow can be larger than 1px but
that's not included by intersection observer either
smfr: Just wanted to make sure we don't discount things that are 0x0
RESOLVED: Match intersection observer behavior for this definition
<astearns> thanks to flackr for scribing!
<fantasai> +1
Received on Friday, 9 December 2022 20:29:12 UTC