[CSSWG] Minutes Extended Telecon 2023-03-15 [css-view-transitions]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

View Transitions

  - RESOLVED: If an element if fragmented into more than one element,
              it does not participate in View Transitions (plus note
              that we want to do such things in the future) (Issue
              #8339: Capturing fragmented elements)
  - RESOLVED: If an element is involved in a transition, the
              `view-transition-name` constraints are enforced during
              the transition (Issue #8548: Define the constraints
              which must be satisfied by a named element during the
  - RESOLVED: Conditions are checked per-frame; transition is skipped
              if other constraints are broken (Issue #8548)
  - RESOLVED: The view transition fills the viewport and captures
              clicks (Issue #8278: UA CSS should size
              ::view-transition to 0x0)
  - RESOLVED: Target pointer events to the document element (Issue
              #7797: User input should be ignored when rendering is
  - RESOLVED: User agent can limit rasterization for performance
              limitations, but must size the element as if it was
              fully rasterized (Issue #8561: Define behavior when
              capturing image for a large element)
  - RESOLVED: Rasterization must cover at least the visible area of
              the viewport (Issue #8561)
  - Further discussion is required to determine how to handle painting
      overflow in issue #8561. There needs to be a bit more
      understanding of both author expectations and fingerprinting


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

  Rachel Andrew
  Jake Archibald
  Rossen Atanassov
  Tab Atkins
  David Baron
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Mason Freed
  Paul Grenier
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  Vladimir Levin
  Rune Lillesveen
  Chris Lilley
  Eric Meyer
  Cassondra Roberts
  Khushal Sagar
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Chair: astearns & rossen

Scribe: emeyer

View Transitions

Capturing fragmented elements
  github: https://github.com/w3c/csswg-drafts/issues/8339

  JakeA: When an element is captured as part of a transition, we
         ignore all the transforms and then figure out what transforms
         we need to apply to place it correctly
  JakeA: so if the transition is a 90 deg rotation, you get a rotating
  JakeA: The columns case is particularly interesting because you can
         apply transitions across fragments, which transitions each
         fragment individually
  JakeA: That's not compatible with the View Transitions model, which
         we want to be a single image and single transform
  JakeA: It's unclear to us if View Transitions are desirable in
         fragmented cases
  JakeA: Prior art indicated fragmented elements should be treated as
         if joined flush
  JakeA: We looked at Firefox's implementation; it seems to capture
         the union of the fragments before a transition is applied
  TabAtkins: That's per-spec
  JakeA: Good to know Firefox is doing the right thing
  khush: I was confused between what old specs said and what Firefox
  TabAtkins: The capturing of dimensions is spec-compliant; other
             things may not be
  JakeA: Trying to figure out View Transitions in this case
  JakeA: Option 1: You Are Not Allowed; the captured element must not
         fragment, which means you skip to the end of the transition
  JakeA: Is a constraint broken when an element fragment, or if an
         element ever can fragment
  JakeA: Previous resolutions have been that if a constraint can be
         broken, then the treatment is as if it has been broken
  JakeA: If you've given a name a none-none value, should it prevent
         an element from being fragmented?
  JakeA: Option 2: View Transition only applies to the first fragment;
         doesn't seem useful, but could be done
  JakeA: Option 3: Take a bit from the element() function and remove
         any transform from the element, figure out union of fragment
         quads, reapply transform to each fragment and capture image
         with that transform baked in
  JakeA: Not sure if that's useful, but it's a non-failing treatment
  JakeA: We're stuck here

  vmpstr: One of the constraints we have is that the element has a
          box, so we don't check if the element can lose its box; we
          only care whether it has a box
  vmpstr: I prefer option 1, because as you said this adds a lot of
          complexity to both model and implementation
  vmpstr: I don't think there are compelling use cases to transition a
          fragmented element
  vmpstr: You could work around by putting a box around the fragmented
  <khush> +1 to Vlad's comment.
  <dbaron> +1 to not doing something complex if there aren't actual
           use cases for it. (I think that most strongly says "not
           Option 3".)

  TabAtkins: I also think Option 1 is probably the right idea
  TabAtkins: None of the options are great, but I don't think there is
             a good way to do it
  TabAtkins: I think making thing with view transitions
             not-fragmentable makes sense
  <florian> q+ to disagree with making non fragmentable
  <astearns> also disagree with making things non-fragmentable

  fantasai: The problem is a people will apply this to a lot of
            elements and if you force things to be not-fragmentable
            they'll break in print
  fantasai: I would just not go down this path; the problem here is
            the combination of fragmentation and transforms
  fantasai: if you capture the bounding box and say this is a the view
            transition snapshot, that's okay
  dbaron: We seem to be focused on Tab's variant of Jake's option 1,
          not the original option 1
  astearns: I think we're agree Tab's variant is Right Out
  <khush> I'd be ok with that. Ignore the element if it fragments.
  <TabAtkins> It feels a little unpredictable, but I think I'm okay
              with the "just don't VT if it's fragmenting"
  fantasai: We could not transition when fragmented, or take the
            bounding box and transition the whole thing, which will
            interact weirdly with transforms
  fantasai: but would let you do simple transitions like translations
            or fades

  astearns: I'm fine with not transitioning view-fragmented things,
            but I'm concerned this is like other things we've punted
            for being too complicated and then never got back to
  astearns: We already have the option to apply a view transition to
            multiple elements, so we could treat fragmented elements
            as if they created separate view transitions
  JakeA: The difficulty there is how you'd address each fragment with
         CSS, and what do you do if the number of fragments changes
  astearns: I wouldn't expect being able to address each fragment
            directly, until we have fragment pseudos (which we have
            talked about)
  astearns: As in regular view transitions, if you have an element
            that appears in one state but not the other, it doesn't

  florian: I agree with dbaron and fantasi
  florian: Another concern: a user agent that's interactive but
           paginates is not common today, but there are things like
           e-readers that could do that, and we don't want a model
           incompatible with that
  florian: It's hard to make a union of things that don't share the
           same coordinate space, like columns
  TabAtkins: That union of non-oriented coordinate spaces is why
             element() stitches them together
  TabAtkins: line-box-clamp could intersect with this; it's at least
  TabAtkins: I think option 2, transitioning the first fragment, is
             the best choice
  TabAtkins: I think it's better to get some of the element rather
             than none of the element during a transition
  astearns: If we fragment the first box, we'll find out if people
            want other fragments to transition
  JakeA: Different transitions names for different fragments would be
         a nice way to address that

  jensimmons: +1 to actually solving this and taking it seriously
  jensimmons: I can see a future where simple and elegant transitions
              make it so web sites use a lot of transitions to go
              between pages and even sites
  <chrishtr> +1 to solving both
  jensimmons: We also need to figure out overflow fragments to solve
              the Regions use case, and make ihs and view transitions
              work together
  <fantasai> "using overflow fragments to solve the regions use case"
  JakeA: I would worry that because we don't know how the regions
         thing will work, we might pick a solution today that clashes
  * florian is in total agreement with Jen. I'd like to live in that

  khush: As an implementor, if we ignore a fragmented element, the
         fallback is you get a crossfade rather than a nice animation
  khush: I think I prefer we either ignore the element if it's
         fragmented, or we use the first fragment, I'd be okay with
  khush: Doing a union like element() does, we could try, but I really
         want to see how that pans out

  fantasai: If we take option 2 and go back to Alan's idea, we could
            apply the same transition to all the fragments that is
            being applied to the first fragment
  fantasai: In the future, we might be able to address each fragment
            individually, through something like :nth-fragment
  fantasai: I think Alan's proposal is the best going forward, but
            it's not the easiest to implement
  fantasai: We could start with first-fragment use, and leave the door
            open to individual-fragment later
  khush: I think the problem is the View Transition API has a way to
         address fragments individually
  fantasai: The selector would select all of them
  JakeA: We could ask for the developer to give view transition names
         to each fragment, and we could ignore in the meantime
  fantasai: The whole element has a name, and we could use

  vmpstr: Would that mean the pseudo representing these elements is
          itself fragmented?
  fantasai: I'm not sure of the distinction
  vmpstr: So the new selector would select both, but they would be
          their own fragments?
  JakeA: My understanding is if you give a name to an element, we'll
         operate on the first fragment, but we can use :nth-fragment
         to address fragments?
  fantasai: You can transition an <article> element, and then
            transition that element
  fantasai: Each fragment gets snapshotted
  JakeA: So what happens if you give an individual fragment a view
         transition name?
  fantasai: I suppose you could do that
  astearns: I like the idea of individually transitioning fragments,
            but don't know if it's useful to do before we have
            fragment pseudos
  astearns: That seems like the path forward
  astearns: Not transitioning fragmented elements is a way of saying
            we'll address this in the future, but don't want to have a
            suboptimal solution now
  <flackr> I think the ideal would be if you have an element that has
           n fragments transition to another element with n fragments
           it pairs them up?
  JakeA: I like it
  astearns: Any arguments that it would be better to transition the
            first fragment, rather than none?
  <JakeA> +1
  <khush> sounds good
  astearns: Proposed resolution is that if an element if fragmented
            into more than one element, it does not participate in
            View Transitions

  RESOLVED: If an element if fragmented into more than one element, it
            does not participate in View Transitions (plus note that
            we want to do such things in the future)

Define the constraints which must be satisfied by a named element
    during the transition
  github: https://github.com/w3c/csswg-drafts/issues/8548

  <JakeA> A view-transition-name value that isn't none gives an
          element stacking context, grouping element, backdrop root,
          similar to non-1 opacity, as view transitions need these
  JakeA: If you give an element a transition name that isn't none, it
         acts as if opacity is not 1
  JakeA: Name is only checked during transition, but because the new
         view is live, we need to check constraints per frame
  JakeA: If constraints are not satisfied mid-transition, element is
         dropped from the rest of the transition
  JakeA: If an element isn't rendered during setup, it's ignored
  JakeA: If an element becomes fragmented during transition, it's
  JakeA: How do we check these conditions?
  JakeA: Option 1: we assert extra conditions, then check to see if
         the view transition name is not none
  JakeA: If a name ever becomes none, element is dropped
  JakeA: Option 2: We assert these all individually, regardless of name

  flackr: Option 3, if an element is undergoing view transition, it is
          subject to the constraints
  <khush> I'd be ok with that.
  JakeA: We can't enforce rendering and we wouldn't enforce fragmenting
  <vmpstr> +1
  flackr: Right, we could continue to enforce name-based constraints
  TabAtkins: My preference as well

  fantasai: That makes sense; other thought I had was if the name
            changes at all, I wouldn't be surprised if the transition
            is suddenly dropped
  JakeA: We avoided that because it means we can't deal with elements
         that suddenly gain a transition name
  fantasai: I'm not saying you'd start a new transition, I'm saying if
            someone messes with names, it should be dropped
  JakeA: If a paragraph isn't in a transition and halfway through JS
         gives it a name, should it be ignored?
  JakeA: If we deal with every element changed names, then you have to
         check every frame

  astearns: It sounds like Option 2, except names are kept throughout
            the transition and so need to be checked?
  JakeA: I think people like flackr's option
  JakeA: I'm happy with that
  <khush> +1
  fantasai: Wouldn't you also be enforcing that it's not fragmented?
  JakeA: We would skip the transition in that case
  fantasai: What if a thing becomes fragmented partway through? Would
            you just ignore that?
  JakeA: The new views are live and updated per frame
  JakeA: If an element becomes not-renderable…
  fantasai: I get it
  astearns: Option3
  <JakeA> If an element is involved in a transition, the
          `view-transition-name` constraints are enforced during the
  <JakeA> It's skipped if other constraints are broken
  <JakeA> (eg rendering and now fragmenting)

  RESOLVED: If an element is involved in a transition, the
            `view-transition-name` constraints are enforced during the
  RESOLVED: Conditions are checked per-frame; transition is skipped if
            other constraints are broken

UA CSS should size ::view-transition to 0x0
  github: https://github.com/w3c/csswg-drafts/issues/8278

  <JakeA> https://github.com/w3c/csswg-drafts/issues/8278#issuecomment-1460153943
  JakeA: Trying to decide default styles for the main pseudo-element
  JakeA: It currently fills the snapshot root
  JakeA: Use case one: rootless transitions
  JakeA: By default we give a name of root, but authors could change
         it to none
  JakeA: Now when the transition runs, only components will be
         involved, but you can see the document beneath
  JakeA: This is like a scoped transition, but it's not quite a scoped
  JakeA: I feel like this is rare and it will be more rare when we
         ship scoped transitions
  JakeA: Use case two: animating a view transition container and
         expecting it to move everything inside
  JakeA: Use case three: If you move your root view away, you might
         want to create a background for the rest of the area
  JakeA: Use case four: transitioning relative to the viewport
  JakeA: We always go from top left, but in custom cases you might do
         something different
  JakeA: I've done transitions to the center or bottom of the viewport
  JakeA: So, the question is, what styles to give this by default.
  JakeA: Option 1. It fills the viewport, which is great in all but
         the rootless use case
  JakeA: Option 2. we do pointer-event: none to the transition and
         pointer-event: auto to the parts of the transition, so you
         can click the real DOM
  JakeA: This is great except in cases where you fill in an opaque
         background; clicks will go through it
  JakeA: Option 3: Make the transition element 0x0 in the top left,
         which breaks the ability to fill in the background
  JakeA: Also break cases where you're trying to position relative to
         places other than top left
  JakeA: This feels like making the common things hard
  JakeA: I think we're in favor of option 1

  TabAtkins: I agree, I think option 1 is the right idea and is least
             restrictive, also fails in a way that's safer than the
             other options
  flackr: I'm good with 1 or 3; 2 could override authors setting
          pointer-event on child elements
  flackr: We should add as few enforced UA styles as possible

  fantasai: Conclusion seems fine; have slight concern that
            positioning default is top left, rather than being
            writing-mode dependent
  khush: That's correct, spec says to place but doesn't say how to
  JakeA: I understand the writing mode concerns, but this should
         result in the same effect in the default case
  fantasai: Should look into whether there are things that compute
  astearns: We should have a separate issue about writing mode being
  khush: We did have that, but then made it relative to the center of
         the containing block
  khush: I'll reopen that issue so we can get things into the spec
  astearns: Sounds like we're converging on option 1
  <khush> +1 to this proposal

  RESOLVED: The view transition fills the viewport and captures clicks

User input should be ignored when rendering is suppressed
  github: https://github.com/w3c/csswg-drafts/issues/7797

  <JakeA> https://github.com/w3c/csswg-drafts/issues/7797#issuecomment-1469931231
  JakeA: During a transition, elements involved are hidden from the DOM
  JakeA: That usually means every element is hidden, because the root
         element has a transition name
  JakeA: Clicks during a transition will almost always hit the pseudo
         and fall to the document root
  JakeA: Authors could change this by changing the root's transition
         name to none
  JakeA: Question is: what do we do with clicks while promises haven't
         settled and the transition is frozen?
  JakeA: Similar case: if you block the event loop using a while loop,
         it will block rendering
  JakeA: If a user clicks anywhere, those events are queuing up
  JakeA: Once the freeze is thawed, the events and hit tests and such
         are resolved then, which may resolve hits against things that
  JakeA: We can't do a full event block, but we could take from
         tasksources and then resolve when the transition starts
  JakeA: Deadlocks are still possible in this option, which may also
         conflict with scoped transitions
  JakeA: We don't want to block all input events while scoped
         transition is happening
  JakeA: Option 2: we apply all events to the document element
  JakeA: In that case, a click may hit the document element whereas if
         we'd queued it, it might have hit a more specific element

  <khush> +1 for option 2.
  Rossen: I want to make sure we're sticking to CSS
  TabAtkins: +1 for option 2, which seems a little safer; also I hate
             when things resolve against DOM I wasn't expecting; also
             makes things more predictable

  flackr: I think a common case is that by the time you'd dispatch the
          events in option 1, the elements will be where they should be
  flackr: Worried that we're seen cases transitions to move small
          pieces of sub-documents
  flackr: I strongly prefer option 1
  khush: If we decide to buffer until rendering is done, the first
         question is do we dispatch before or after creating the
  khush: Why not just give it to the document?
  JakeA: I think flackr's point is that if you have a pseudo-element
         is in a certain place, option 2 raises the chances of a thing
         not being where it was when the click was made
  khush: So this is for the case of rootless transitions?
  JakeA: This is all about rootless transitions
  flackr: If I start a transition on mousedown, as long as my pseudo
          is pointer-events: none, I can still get that click
  flackr: I also feel like you have a halting issue regardless, since
          there's no requirement a transition ever finish
  JakeA: Should have clarified that this deadlocks are already limited
         to four seconds
  flackr: So this isn't new, it's just we could make them more likely
  flackr: If a developer doesn't finish setting up for a view
          transition, there will be problems
  chrishtr: With option 2, if the dev starts a transition but then
            does nothing and we wait four seconds, if the user clicks
            in that 4s window, is the click lost?
  JakeA: Yeah, in option 2, the click won't work
  chrishtr: So the default UA behaviors are suppressed
  flackr: In option 1, we wait for the transition to fail to start,
          the events are processed after the transition is canceled
  chrishtr: Could we do an option 3 where user events are still
            processed and applied to the original target?

  khush: Option 1 is very hard to reason about with scoped
         transitions, which is why I'm advocating option 2
  khush: The easiest thing is to dispatch an event at the root of the
  <vmpstr> +1
  flackr: An event targeted at the document provides XY coordinates,
  khush: Yes

  Rossen: We seem to be sliding to option 2; flackr, you were the main
          proponent of 1
  flackr: I like that option 2 supports scoped transitions better
  flackr: I think it's okay
  Rossen: Any other opinions or objections to resolved on option 2?
  <JakeA> Target pointer events to the document element
  <JakeA> This is what will happen during the transition in most cases
          anyway, except in the edge case mentioned above, where the
          root's view-transition-name is set to none, and the clicks
          don't hit the pseudos. In that case, click may hit the
          document element, where they would hit a more specific
          element during the transition.
  <flackr> Or to the root of the transition for future compat with
           scoped transitions!

  RESOLVED: Target pointer events to the document element

Define behavior when capturing image for a large element
  github: https://github.com/w3c/csswg-drafts/issues/8561

  JakeA: When we capture the content of an old view, we don't know how
         it might be animated yet
  JakeA: Part of the element might be out of view, and could come in
         view as part of the transition
  JakeA: Some elements are very large and we can't feasibly capture
         all of it
  JakeA: Image transitioning the body element
  JakeA: Proposal is, we'll base the dimensions of the transition
         group on the element, but say that browsers don't have to
         capture every pixel, while suggesting they capture beyond the
  JakeA: If possible/performant to do so
  JakeA: Are we okay to handwave like that, so we let UAs act as they
         see best?
  JakeA: Further, what should the natural width and height of the in-
         and out-states be when a browser chooses not to capture every
  JakeA: Also, should those things be script-visible?

  TabAtkins: I think we should require at least the visible area and
             some amount outside is good, maybe with a minimum
             explicit margin like 50% beyond
  TabAtkins: We should expose the size of the thing being captured
  fantasai: +1 to Tab, plus the size should be the size it actually
            is, even if there isn't painting inside the entire range
  <flackr> +1
  fantasai: We should require or very strongly recommend capturing
            beyond the viewport as well, probably +1 viewport in each
            direction as the minimum range to capture
  JakeA: So if there's a case with many elements layered on top of
         each other, they're all in the viewport; if device can't
         handle all that, should we just skip the transition?
  JakeA: I think that's a good general case, that if a UA doesn't feel
         it can handle a given transition, it should skip the

  khush: +1 to fantasai, which is kind of what I was implementing
         anyway, so I'm okay with the spec recommending taking the
         root as a barometer for how much to expand beyond the visible
  khush: The spec says the natural size of the image is equal to what
         you capture and everything around it is transparent
  khush: object view box exposes how much the UA decided to paint
  fantasai: I don't think you should use object view box to set this,
            even if you use the same computation internally
  khush: So the computed value is meant to be ink-overflow-rectangle

  chrishtr: We would just not raster things we can't put into memory,
            so developers can't observe anything about this behavior
  fantasai: Exactly
  <flackr> +1
  JakeA: We can say the exposed value doesn't say anything about
  vmpstr: I think the object view box is the problem, because we need
          to make it the same as ink overflow, but if that's infinite\
  flackr: It's the same as if you hadn't rendered everything
  khush: In the spec it says to paint everything in the ink overflow
  khush: We pretend an image is the size of the ink overflow rect
  chrishtr: A dev wouldn't know whether we painted the whole thing or
            not, only the user can tell

  khush: Base case where the UA can raster the whole thing, and
         element has drop shadow, so ink overflow is bigger than
         object box
  khush: UA should compute a view box it applies to the element such
         that when you render this, the boxes should coincide at the
         same origin
  khush: If the UA hasn't painted the whole thing, and the dev messes
         with the object view box, the effect is the same as if the
         whole thing was painted
  khush: My question is, to implement this, can we not let devs change
         object view box?
  khush: When they read it, we can give the the value the spec wants;
         also the device specs wouldn't be exposed?
  fantasai: What is the ink overflow rectangle of something that has a
            box shadow?
  chrishtr: There's spec language about this
  fantasai: Do we want to expose this?

  khush: You could call getcomputedstyle and don't see anything, which
         would make implementation easier
  fantasai: That seems better, and if the dev wants to manipulate they
            don't have to know about the internals
  chrishtr: We could take this and whether we should add a new
            !important to a new rule
  fantasai: I think we agree the rasterization is not exposed to devs
            but the returned values are spec-consistent
  chrishtr: Agreed
  JakeA: I think we generally agreed the spec should suggest an
         overflow amount, was it one viewport in each direction?
  JakeA: Also in out-of-memory cases the transition is skipped
  TabAtkins: We don't usually specify memory problem recovery because
             it can show up whenever
  <TabAtkins> Exception is if OOM actually causes a security issue. In
              all other cases OOM behavior is explicitly undefined.

  <fantasai> proposal: UA can limit rasterization for perf
             limitations, but must size the element as if it was fully
  <fantasai> proposal: rasterization should cover at least the visible
             area of the viewport + one viewport in each direction
  <fantasai> proposal: if the UA cannot performantly perform the view
             transition (for any reason) it must skip the transition
  fantasai: I think we have three proposed resolutions
  fantasai: One (see above)
  fantasai: Two look one viewport in each direction for overflow
  fantasai: Three is the error fallback is to skip the transition
  fantasai: And that you never do half a transition, you either do all
            or none
  khush: One viewport in each direction should be a recommendation
         rather than a requirement
  khush: Only requirement is that what's visible must be captured
  <fantasai> proposal: UA can limit rasterization for perf
             limitations, but must size the element as if it was fully
  <fantasai> proposal: if the UA cannot performantly perform the view
             transition (for any reason) it must skip the transition
  <fantasai> proposal: rasterization should cover at least the visible
             area of the viewport + one viewport in each direction

  RESOLVED: User agent can limit rasterization for performance
            limitations, but must size the element as if it was fully

  <bkardell> I missed some stuff here but what does #1 mean in terms
             of jake's 'body of the whatwg html spec' case?
  <fantasai> it means that the pseudo representing the snapshot is the
             true height of the html spec, but only part of it is
  <fantasai> the rest of it is transparent
  <bkardell> so if the spec were still loading (because it can take
             like a whole minute in chrome if you have a low end
             device and slow connection) it would be 'whwatever it is
             right now'?
  <fantasai> yes
  <JakeA> proposal: Must: rasterization should cover at least the
          visible area of the viewport Should: + one viewport in each
  <JakeA> proposal: Must: rasterization should cover at least the
          visible area of the viewport
  <JakeA> proposal: Must: rasterization covers at least the visible
          area of the viewport

  RESOLVED: rasterization must cover at least the visible area of the

  JakeA: We need to consider the directions and how much overflow
         SHOULD be captured async
  flackr: Skipping the transition is dev-visible so we're exposing
          device capabilities
  fantasai: You can limit rasterization but if you're getting to the
            point you can't even transition what's on-screen, you
            should skip the whole thing
  flackr: We could not paint the transition but still run it so the
          dev knows it happened
  bkardell: You're saying skipping the transition is dev-visible but
            is it? Because a device can just not support that or
            animations can be turned off with prefers-reduced-motion
  JakeA: We've decided those can be exposed, but giving away GPU
         memory is a fingerprint
  bkardell: So, are saying you could do something like try a _small_
            transition and then kind of scale them up until it fails
            and then fingerprint with that? I see.
  khush: Is it safer to say that this should silently fail by not
         painting things?
  khush: We can already hit this with filters and blurs and such and
         that's silent in Chrome
  JakeA: I think we have to go back and come up with a plan here
  Rossen: So we'll have to postpone this resolution

Received on Sunday, 19 March 2023 15:09:10 UTC