W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes TPAC/Vancouver 2022-09-15 Part I: CSS Highlight API, CSS Contain, CSS Images [css-highlight-api] [css-contain] [css-images]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:36:47 -0400
Message-ID: <CADhPm3sv+5-sw07faUFYJigMHjWsEgJFY_UZ4zrjKFTz8bSaGQ@mail.gmail.com>
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


Agenda: https://github.com/w3c/csswg-drafts/projects/31

  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
  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

  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
  dandclark: some discussion for coming up with schemes where the
             events could then be dispatched in a manual way to
  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
  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
  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
  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
  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

CSS Contain

Publish css-contain-1

  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:
    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:

  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
  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

  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
  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
  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
  fantasai: multiple pieces of highlight, each has an originating

  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
  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
  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
  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,
  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
  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
  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
  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
  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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC