- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:36:47 -0400
- 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 Highlight API
-----------------
- RESOLVED: Add the highlightFromPoint() API to CSS.highlights or
DocumentOrShadowRoot (Issue #7513: Approaches for
dispatching highlight pointer events)
- RESOLVED: Properties that don't apply on highlight pseudos are
ignored (Issue #7591: Highlight pseudos and
non-applicable properties)
- RESOLVED: For the highlight pseudos on the root element, all of the
font settings are taken from the element (Issue #7591)
CSS Contain
-----------
- RESOLVED: Republish css-contain-1 as a Recommendation with the 3
changes marked as proposed changes
CSS Images
----------
- RESOLVED: Accept to start work on @image and draft it into
css-images-5 (Issue #6807: @image rule for manipulating
images)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/31
Present:
Rachel Andrew, Google
Jake Archibald, Google
Adam Argyle, Google
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Google
Tantek Çelik, Mozilla
Daniel Clark, Microsoft
Emilio Cobos Álvarez, Mozilla
Jon Davis, Apple
Karl Dubost, Apple
Kevin Ellis, Google
Elika Etemad, Invited Expert
Robert Flack, Google
Megan Gardner, Apple
Daniel Holbert, Mozilla
Ian Kilpatrick, Google
Chris Lilley, W3C
Alison Maher, Microsoft
Cameron McCormick, Apple
Eric Meyer, Igalia
Tess O'Connor, Apple
Kazumasa Okabe
Olli Pettay, Mozilla
Manuel Rego, Igalia
François Remy, Invited Expert
Morgan Reschenberg, Mozilla
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Dominik Röttsches, Google
Peter Rushforth, Natural Resources Canada
Khushal Sagar, Google
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Scribe: heycam
CSS Highlight API
=================
Approaches for dispatching highlight pointer events
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7513
dandclark: Problem we're trying to solve is making custom highlights
interactive
dandclark: For scenarios like custom spell check, annotation popups
over words
dandclark: A few months ago I came to the WG with a proposal for
adding eventing for highlights
dandclark: When there's a pointer event, a highlight, we get a first
crack at it
dandclark: dispatch events at highlights in priority order
dandclark: if none preventDefault() it, we give it to the normal DOM
element
dandclark: Goal here would be to allow non-coordinating highlight
libraries to do reasonable things
dandclark: If you have say a spell check library, and a annotation
library running, stopping propagation of an event would
avoid two popups at once
dandclark: Normal event propagation would allow this coordination
without the 2 libraries knowing about each other
dandclark: however this is somewhat complicated, there was a simpler
competing proposal
dandclark: Providing "highlightsFromPoint", put a click event on the
body, when there's a click pass the coordinates into this
function
dandclark: some discussion for coming up with schemes where the
events could then be dispatched in a manual way to
highlights
dandclark: Discussed in the issue, not a great way for
non-coordinated libraries to coordinate an event loop
dandclark: That said, I think it's maybe worth pursuing this as a MVP
API
dandclark: seems like a useful addition to the platform
dandclark: If in practice there turns out to be issues with
non-coordinating highlight libraries working together, we
then go back to pursue highlighting events in addition to
that
dandclark: CSS.highlights.highlightFromPoint()
dandclark: some issues with shadow DOM
dandclark: First let's get some feedback from the group. is this
worth it as an initial step?
<TabAtkins> Seems useful to me. The coordination issue still needs to
be addressed, but I don't think that blocks this as a
useful ability. I like the API discussed.
<flackr> +1 MVP of highlights from points seems useful even if we add
events
TabAtkins: Seems useful to me. agree the coordination issue needs to
be resolved, but that shouldn't block this useful primitive
TabAtkins: if this unblocks general abilities, I still think it's
worthwhile
TabAtkins: I like the API shape in the proposal
smaug: I agree this is probably good enough for now
smaug: might need to think about shadow DOM for now, but we can tweak
the proposal for that
dandclark: Seem to have agreement on adding this
dandclark: Would be good to dig into the shadow DOM issue
dandclark: Does it go on DocumentOrShadowRoot?
<dbaron> (My initial reaction is that DocumentOrShadowRoot is a good
location because then it lives next to elementFromPoint,
which it is similar to.)
Rossen: Let's resolve on adding the API, if we still have time at the
end of this slot, we can come back to this issue
RESOLVED: Add the highlightFromPoint() API to CSS.highlights or
DocumentOrShadowRoot
CSS Contain
===========
Publish css-contain-1
---------------------
https://lists.w3.org/Archives/Member/w3c-css-wg/2022JulSep/0192.html
florian: Two years ago we published a REC of css-contain-1
florian: since then we've made some editorial tweaks
florian: 3 candidate changes
florian: If you remember the process 2020, we can make normative
changes in a rec through a process of annotating them as
editorial in the rec, then if they're editorial we can
republish without permission
florian: and use that to highlight things we want to change, without
changing them yet
florian: We have a 3rd change in an ED for a while
florian: Status of the spec is good. no open issues
florian: DoC all are resolved or deferred
<florian> no open issues:
https://github.com/w3c/csswg-drafts/labels/css-contain-1
Changes section: https://drafts.csswg.org/css-contain-1/#2020-12-22-changes
DoC: https://drafts.csswg.org/css-contain-1/issues-2022-rec
Implementation report:
https://drafts.csswg.org/css-contain-1/implementation-report-2022-09
florian: I wrote an implementation report for each of these 3 changes
florian: we have exhaustive tests, passing in at least 2 browsers,
sometimes in 3
florian: I think we should republish this rec, mark these 3 changes
as proposed changes, which will trigger AC review
florian: then we can ask the Director (or his delegates) to get to an
actual REC while the patent reviews etc. are going,
horizontal review, etc.
florian: These are minute changes, so I don't think anything will
come up
florian: Asking for WG approval to republish css-contain-1 as a Rec
with these 3 changes highlighted in it as proposed changes
florian: There is a level 2 of css-contain, and I have checked that
they are in sync
RESOLVED: Republish css-contain-1 as a Recommendation with the 3
changes marked as proposed changes
CSS Highlight API Continued
===========================
Highlight pseudos and non-applicable properties
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7591
fantasai: Look at the example in the issue
fantasai: it's showing a ::highlight with a text-shadow with an
offset expressed as 1em
fantasai: there's a parent selection pseudo with a font-size:69px,
and the originating element has a font-size: 42px
fantasai: font-size does not apply to ::selection, so the actual font
is going to be 42px
fantasai: The question is, when we're computing the value of 1em, are
we using the font-size assigned to the selection even
though it doesn't apply, and cannot apply, or do we ignore
that font-size and use the value from the originating
element?
fantasai: Implementations do various things. E.g. Blink uses the
initial value, which is 16px
fantasai: The question is what do we want to do?
fantasai: Using the actual font-size would give the most expected
results from the author perspective
dandclark: I agree with that
dandclark: definitely seems the most intuitive thing here, i.e. the
font-size of the originating element
dandclark: anything else seems strange to me
emilio: We have precedent for this
emilio: things like ::placeholder already ignore a bunch of
properties, and they do so by ignoring the declarations
emilio: so as if the font-size declaration wasn't there
emilio: I think that's what's being proposed here, and I think that's
reasonable
fantasai: Proposed resolution is we use the actual, effective
font-size (and font-family, etc.) here
emilio: Can we word it as declarations of not supported properties
are ignored instead?
fantasai: It inherits from the parent selection
emilio: That's trickier then
fantasai: We can say both things
emilio: I think that's weird
emilio: I'd rather keep it simple and ignore the declarations
astearns: If we ignore the declarations, and just do the normal
inheritance, even though the value is ignored, don't we get
what we want?
fantasai: You get the initial font-size
emilio: Or the root element's font-size
emilio: Weird to add another source of inputs here
Rossen: If we don't do that what makes most sense?
Rossen: on one hand we have the default 16px
Rossen: that seems less useful
astearns: Don't understand why we get the initial font-size
astearns: the pseudo is on an element that has a font-size
fantasai: But it doesn't inherit from that element
fantasai: ::highlight inherits from the parent element's selection
fantasai: we rewired highlight inheritance like this
Rossen: The initial font-size, is that because you simply end up with
the root size?
fantasai: Yes
dbaron: I was just thinking about the desired behavior here
dbaron: If you have a selection with text-shadow that's got a 1em in
it, and that selection crosses elements with different font
sizes, do you actually expect that the shadow has a different
offset or spread as the selection crosses those elements?
fantasai: Maybe, maybe not
fantasai: depends on what you were aiming for with the effect
fantasai: I think having it be consistent across them is not
unreasonable
Rossen: What do we do for outline?
fantasai: That doesn't inherit
dbaron: One of the other factors here is that a principle about
selection styling is that you shouldn't get different results
depending on where the selection starts
dbaron: so if your selection starts further up ancestor, which has a
different font-size, versus a narrow selection scoped to a
descendant with a different font size, those descendants
shouldn't render differently
fantasai: I think both proposals follow that principle
JakeA: Is currentColor an issue here? for the same reason?
fantasai: currentColor inherits as its own keyword, and resolves on
each element
fantasai: for highlights it has some special behavior
fantasai: I think maybe it's just on the color property? it doesn't
look as its parent, it looks at its originating element
fantasai: from the user's PoV this is arguably what you want
fantasai: to Jake's point, if we model this on the same way color /
currentColor works...
fantasai: color inherits from the parent selection, not the
originating element
fantasai: currentColor on all other properties than color, looks at
color
fantasai: normally color:currentColor is like inherit, but for
highlights it takes the originating element's color
fantasai: so if you have a highlight where you're only doing say
underlining, it gives you a way to "use the original color"
fantasai: rather than parent's color
Rossen: So for em resolution
Rossen: seems like we could have the same behavior
heycam: If you set font-size:inherit...
heycam: analog is, you're using the currentColor keyword on a
property other than color, is the analogy is for having em
values in some other property
heycam: if you used em values in the font-size property, that's more
of an analog to using currentColor in color property
JakeA: When you talk about the originating element of the highlight
JakeA: what happens in the case where the highlight spans multiple
elements?
fantasai: multiple pieces of highlight, each has an originating
element
fantasai: if we consider dbaron's comment, making font relative
values always resolve against the initial values seems to
be most consistent with the principle
Rossen: I'd argue from a user PoV that makes no sense
Rossen: [something about highlight sizes]
fantasai: The size of the highlight doesn't change
dbaron: I tend to be in favor of what Elika just proposed
<fantasai> proposal was that, since having consistent resolution from
1em is not unreasonable in many cases, and is already
implemented in Blink, then we should resolve on that
dbaron: The alternative seems like it would be hard to implement
dbaron: and I don't think we've heard any good use cases for the
alternative, i.e. do people really have demands for em
offsetted text-shadow that varies on elements
miriam: Would it be closer to author intent to use root ems instead
of browser default?
emilio: That's the behavior you get when you ignore declarations
fantasai: I think the spec is a bit unclear on that
fantasai: so whatever we decide here is how we'll clarify it
Rossen: Hearing consensus forming around Elika's proposal, with using
root ems instead of the initial value of font-size
Rossen: any other proposals?
dandclark: Should this be more general than font-size?
dandclark: Lots of other properties that don't apply to highlights
fantasai: We're applying it to all font properties, taken from the
root
fantasai: all of the declarations on pseudos that are defined not to
apply are ignored
fantasai: Proposed resolution: declarations on highlight pseudos
defined as not applied are ignored, and font properties are
all taken from the root element
RESOLVED: Properties that don't apply on highlight pseudos are ignored
fantasai: I think we say that for the ::selection on the root element
(and therefore inheriting down into other highlights), all
of the font settings are taken from the root element
RESOLVED: For the highlight pseudos on the root element, all of the
font settings are taken from the element
CSS Images
==========
@image rule for manipulating images
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6807
TabAtkins: This is a request for feedback and possible WD, precised
details are being discussed on the thread
TabAtkins: This is a request for a way to manipulate images directly
in CSS
TabAtkins: Right now you can do a handful of things directly in CSS
TabAtkins: certain repetitions with background properties
TabAtkins: but anything more complex, running a filter on it,
opacity, etc. your only choice is to use a separate image,
or to put it on a declarative element and then apply CSS
properties to that element
TabAtkins: This is trying to split the difference, and allow existing
existing effects (transforms, filters), directly in a CSS
image
TabAtkins: rough approach is an @image rule, which provides a double
dashed name
TabAtkins: A bunch of descriptors, one which takes a src image, then
others which are copies of other CSS properties that do
useful things
TabAtkins: Currently only supporting things you can already do to
elements
TabAtkins: once defined, you could use this image in CSS
TabAtkins: image(--foo)
heycam: Alternative approach is to slam all of these filtering and
transforms into the image() function itself
heycam: if you need to re-use that, put it all into a custom property
heycam: have you thought about that?
TabAtkins: I don't believe there's a great reason to go one way or
the other
TabAtkins: back in the day, using it in an image() function you'd
need to repeat it
TabAtkins: but with variables it's not a huge deal now
TabAtkins: Some bits of functionality like image layering have been
discussed, but more widely as pulling in SVG's filter
capabilities via nested at rules
TabAtkins: having them be consistent in approach would be nice
TabAtkins: but now that I bring that up, it could still be done using
CSS functions
TabAtkins: it would be a matter of what we find more convenient to
do, or more natural
TabAtkins: don't think there's a huge way to go one way or the other
dbaron: Could you talk briefly about how sizing of these images works?
dbaron: Looks like there's some sizing related properties in there
dbaron: transforms and filters which might have sizing implementations
TabAtkins: You have a width/height property
TabAtkins: that's the natural width/height of the produced image
TabAtkins: scaling etc. would be purely visual effects
TabAtkins: It would scale it within the bounds of the width/height
that's already been provided
JakeA: For blurring a low quality image as a placeholder
JakeA: that's difficult with filters now, because it blurs the edge
as well
JakeA: Here you want to recognize the edge and not blur the
transparency into it
JakeA: so it works a bit more like backdrop-filter
andreubotella: Could you use such an @image rule in the src property?
andreubotella: If you already have declared an image, then you want
to apply some further transformations to that?
andreubotella: And for the current properties, it seems like you
could apply a set of properties to multiple images
TabAtkins: The exact answer to that depends on what we want to define
TabAtkins: being able to put a generated image in as the source of a
new generated image is reasonable
TabAtkins: whether that gets rasterized then transformed, as if it's
an independent image, or these transformations are
additively appended to the list of existing
transformations in some intelligent fashion? no opinion
TabAtkins: both have pros/cons. simplicity on one side,
understand-ability
TabAtkins: avoiding rasterization effects
TabAtkins: both seems potentially reasonable
TabAtkins: can discuss those
andreubotella: Thinking also maybe not having it rasterized, that
might limit the properties we could add to @image rules
TabAtkins: I think everything we've discussed so far in the thread is
compatible with just holding it as a scene graph
ydaniv: Might be some advantage to have this rasterized beforehand
ydaniv: if you're just setting the properties outside the at rule,
you could have them animated
ydaniv: then if you want to do further animations on the element,
then have the browser apply all of these at the same time
every frame, could be heavy for the browser to handle
ydaniv: so maybe this could be some sort of performance boost
ydaniv: another thing that might be way off, if you're thinking about
syntax, having this for replaced images, object manipulation,
that could be useful
ydaniv: so not just for background-image, <image> values, but use the
same manipulations on replaced elements like straight on an
<img> element
TabAtkins: Right now you can take any replaced element and put
properties on it
TabAtkins: but you want to be able to run these on the underlying
image itself, and still be displayed in the bounds of the
image element? so apply a rotate to the source image?
ydaniv: I want to optimize for having the src already rasterized,
then if I'm rotating the image outside, then the browser
doesn't have to handle rasterizing every frame
ydaniv: what you're saying is another use case which is also valuable
dbaron: Andreu's comment made me think about another set of questions
about the ordering of these operations
dbaron: In CSS, a bunch of these things are properties where the
order that they apply in is defined by our processing model
dbaron: The relative ordering we apply opacity, filter, transform,
etc. on a single element is defined by CSS's processing model
dbaron: One thought is that re being able to nest the output of one
of these as the source of another, that's probably quite
useful, since sometimes you want to apply these things in a
different order than how CSS's processing model works
TabAtkins: Or the same descriptor multiple times in different fashions
dbaron: Maybe falling back to that processing model isn't the right
thing here? for this rule, the graphical operations maybe
shouldn't be order independent?
dbaron: so the order of the descriptors matters
TabAtkins: If you have them in an order, that implies you should be
able to repeat: rotate, blur, rotate
TabAtkins: first, object model issues
TabAtkins: also, that would run into our forward compat fallback
ability
TabAtkins: where you can say something twice and ignore the first,
unsupported value
TabAtkins: but I like the way you are thinking
TabAtkins: having this order be controllable is probably a great idea
emilio: That kind of issue disappears if you add the operations in
the image() function
TabAtkins: Yes, it removes the fact that ordering and repetition is a
problem
TabAtkins: now support is an all or nothing for the entire graph
TabAtkins: On the other hand, if an image transform isn't supported,
and you are trying to rely upon it, you probably do want
the whole thing to fail
TabAtkins: so that is an argument in favor of a function
heycam: I realized that there might be a semantic difference between
image() and the at rule
heycam: Each of those are a different image
heycam: Is there any situation where having the image defined in the
at-rule lets you have a single place where you can do image
manipulations, where with image() you'd need to apply the
transform to all uses of the image() function
heycam: It's probably not an issue, I don't think they can express
different things
TabAtkins: Being able to say that one in an at-rule there's an
efficiency arg to be made there
TabAtkins: how to animate an at rule is an open question
TabAtkins: how to animate a function is already a reasonably solved
problem
TabAtkins: match up lists, animate individual parameters
TabAtkins: does the WG feel this is OK, or objections to the approach
in general?
fantasai: My main concern is prioritization wrt other things we're
doing
fantasai: other than that doesn't seem terrible
Rossen: From a use case approach, it's fine
fantasai: Definitely needs a lot more work
Rossen: That's like most other work we take on
fantasai: This is not a small task
Rossen: Assuming Lea and others will be contributing to this?
TabAtkins: I'm shepherding this
Rossen: Acknowledge this adds more work to the group, but I'm hearing
support for the use case and approach
Rossen: so I'm personally OK with this
TabAtkins: Do we want this added to images 5, or is it larger enough
to be split out?
fantasai: What else is in images 5?
Rossen: Almost nothing
fantasai: Current images is images-4. images-5 is just an ED, don't
think there's anything even in it
TabAtkins: Just want to know if it should be merged into the totality
of the images spec
RESOLVED: Accept @image and add it to css-images-5
Received on Tuesday, 25 October 2022 22:37:30 UTC