W3C home > Mailing lists > Public > www-style@w3.org > March 2019

[CSSWG] Minutes San Francisco F2F 2019-02-25 Part II: Filter Effects, Transforms [filter-effects] [css-transforms]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 Mar 2019 22:27:29 +0300
Message-ID: <CADhPm3u5_Dgym4oejn4o4U=F0FpUBQkTRZGy6LxE92dQd24g+A@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.

Filter Effects

  - RESOLVED: Add the proposal [for background root] with an issue
              [that there isn't yet consensus on this approach] noted
              in the spec (FXTF Issue #53: Backdrop filters should not
              use BackgroundImage)


  - Issue #1950 (transform-style: flat should not create stacking
      context, and 3D context grouping) is part of a group of issues
      needing better definition of 3D styles. A breakout session will
      be created to cover this topic.


Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: fantasai

Filter Effects

Backdrop filters should not use BackgroundImage
  github: https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-451599995
  Proposal: https://docs.google.com/document/d/1D302HscLmYW-WE2u5DpYSB9RwLau9nfpockl_wmKWRA/edit
  Archived: https://lists.w3.org/Archives/Public/www-archive/2019Mar/0000.html

  chrishtr: Backdrop filters was discussed last year at F2Fs and at
            tpac, and the concerns raised were all about efficient
            implementability and clear semantics
  chrishtr: In particular cases having to do with what happens if
            there are filters above backdrop filter element
  chrishtr: Did a bunch of research on explicit examples
  chrishtr: looking for undesired behaviors
  chrishtr: Also researched use cases that are considered important
  chrishtr: Number of uses cases involving transforms, for example,
            the folks at Apple, smfr et al. mentioned wanting to use
            transforms to rotate something inside an overlay of a
            video element
  chrishtr: So don't want backdrop filter to stop at the transform
  chrishtr: New proposal that avoids strange behavior of filters and
  chrishtr: and problems of not applying atomically
  chrishtr: while also supporting stacking context without visual
  chrishtr: or stacking contexts that should be able to with more
            clever code support in compositing systems
  chrishtr: ...
  <AmeliaBR> The proposal:

  chrishtr: Backdrop filter root would only be applied for elements
            with filters, opacity
  chrishtr: and masks and clip path and mix-blend-mode
  chrishtr: and in our proposal a border-radius clip
  chrishtr: got general positive feedback from experts form MSFT
  chrishtr: and also some feedback from Markus from Mozilla
  chrishtr: Markus raised some concerns, Mason and I were
            whiteboarding to solve
  chrishtr: Feedback was browsers have a lot of complexity around how
            containing blocks and DOM parentage don't agree
  chrishtr: Browsers in effect have to push clips, particularly
            background corner clips, and apply them non-topically
  chrishtr: Can have undesired bleeding and fringes around rounded
  chrishtr: We thought it through and agreed that's the case, and
            agree that it shouldn't be necessary to require backdrop
            root for rounded corner clips
  chrishtr: Second concern was that current spec proposal, there's an
            action at a distance going on
  chrishtr: If you put background filter on an element, the background
            filter root implied by that element becomes a containing
            block for all of its descendants
  fantasai: Including fixedpos items?
  chrishtr: Yes
  fantasai: That seems really extreme

  smfr: That's the same as filters?
  chrishtr: That has to do with excessive difficulty of compositing
  chrishtr: Under same rationale under proposal
  chrishtr: This creates situation where a descendant can change
            behavior of the parent
  fantasai: Hang on, what?
  chrishtr: Let's suppose you have an element with opacity on it, and
            then you have a descendant with a backdrop filter
  chrishtr: Element with the opacity is the backdrop filter root on
            that other element
  chrishtr: Under this proposal, the backdrop filter root becomes a
            containing block for all descendants
  chrishtr: That means presence of a property on a descendant has side
            effect of making some ancestor that has opacity on it
            become a containing block
  fantasai: That's really bad
  chrishtr: This avoids the complexity of the problems of mismatch
            between containing block and dom order
  chrishtr: Because the content underneath the backdrop filter root
            that paints before the backdrop filter element is stuff
            that needs to be drawn into an image behind the element
  chrishtr: That's the point of the feature
  chrishtr: We concluded that Markus is right that we don't need this
            so we can remove it from the spec proposal

  AmeliaBR: You've obsoleted my question by removing this
  AmeliaBR: What are you replacing it with?
  chrishtr: There will still be a backdrop root
  chrishtr: Everything here except the border radius would be a
            backdrop root?
  AmeliaBR: Are these all things that create a containing block?
  chrishtr: No, opacity doesn't create a containing block
  chrishtr: In certain situations you'll be able to see a fringing
  chrishtr: Way opacity is implemented, browsers commute with clip
  chrishtr: we push the clips down below the opacity
  chrishtr: multiple clips that can occur
  chrishtr: can even have multiple mask textures happening
  chrishtr: These clips are not necessarily atomic. Opacity is atomic
            but others aren't
  chrishtr: You might see certain effects at the corners
  chrishtr: We have no choice but to push down the clip because of
            opacity vs clip
  chrishtr: because clip is applied before the blur filter, some of
            the colors of pixels that were outside the clip will no
            longer appear in the output

  AmeliaBR: My general comment is that I don't like having yet another
            category of properties that cause a special behavior
  AmeliaBR: We already have stacking contexts and containing blocks
            and isolation and certain properties affect one but not
            the other
  AmeliaBR: If anyone wants to make a table which properties trigger
            which behaviors?
  dbaron: I did that!
  dbaron: My table came with tests, and I filed a bunch of bugs with it
  dbaron: Some of the bugs are just described at the bottom of the
  dbaron: not necessarily all filed...
  <dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
  <dbaron> (and the above table is actually a *test* and will produce
           different results in different browsers)
  chrishtr: Table was great!
  AmeliaBR: If we can make sense to synchronize one of the existing
            definitions, would be great
  AmeliaBR: Otherwise need to be really clear with authors why
  AmeliaBR: With transform-style and 3D, authors got really annoyed
            when some browsers triggered flattening on opacity and
            others didn't
  chrishtr: Things that trigger flatting are almost the same as this
  AmeliaBR: If we can sync the lists that'd be very helpful
  chrishtr: Transforms spec has a lot of compat restrictions. Open
            question of can we move the Web to that model without
            breaking things.
  chrishtr: Could have a common name for this
  chrishtr: new concept
  chrishtr: When mix-blend-mode was specified, the final decision was
            to make it only to the containing stacking context
  chrishtr: I think that was chosen because it doesn't introduce a new
  chrishtr: but there's been rightly some concern that this make the
            feature not as expressive as it could be
  chrishtr: Apple engineers had this position
  chrishtr: So we could maybe even change mix-blend-mode to match this
            and make it better than today
  astearns: So you are concerned about introducing notion of
            background root?
  AmeliaBR: Just concerned that it's similar but slightly different
            from other concerns
  AmeliaBR: If we can sync them, that would be great.
  chrishtr: Wrt your comment about isolation, yeah, isolation: isolate
            creates a stacking context, not a containing block. Maybe
            a different thing could do that.
  christr: Another thing is that contain: layout does almost the same
  christr: It creates stacking context, containing block, etc. Maybe
           that property suffices

  smfr: ...
  smfr: Backdrop was always intended to be everything under the
        element all the way up to the root
  smfr: There are some issues with ancestors, but I think that's what
        the author wants.
  dino: It also means they don't have to tweak their content to do
        what they want to do
  dino: It's not difficult in our impl
  dino: We do need to fix up to define edge cases like ...
  dino: It's a shame that it's inefficient in some engines. It's not
        in ours.
  dino: Want to build on what smfr says. Backdrop this way will
        require authors to change how their content works.
  dino: We definitely have bugs in the webkit implementation that we
        should fix
  chrishtr: I can't say I really agree with that.
  chrishtr: This is just something that developers can know about. We
            can describe succinctly
  TabAtkins: We've had examples of things being double-filtered or
             otherwise being weird.
  TabAtkins: Safaris' definition is just "whatever CoreGraphics does"
  TabAtkins: That's not well-enough defined. We don't even know what
             it does.
  smfr: I volunteer Dean to write that up.

  Markus: I mostly agree with Chris.
  Markus: I think Safari's current behavior is confusing and hard to
          define what should be the outcome with opacity effects.
  Markus: I don't agree that authors will have to change their content
  Markus: I think usually there will not be filters on the ancestor of
          the element with the backdrop filter
  Markus: Have yet to see a case where Google's proposal imposes a
  dino: We do have example of backdrop filters and opacity on the
  dino: Every video on iOS does this.
  dino: The play button on videos fades in and out
  dino: It works fine
  dino: If we implement this new backdrop root, then have to fix that.
  Markus: So opacity is on a different element than the backdrop
  dino: Yes
  dino: Controls might have things that you don't want backdrop
        filters on, such as subtitles.
  dino: With video and controls, have complicated structure under the
  dino: Sometimes things have backdrop filter, some don't; some things
        fade in/out, others don't.
  dino: To Google's credit, they figured out how to do this, but it is
        a change.

  dino: I agree that we haven't specced it well enough.
  dino: I volunteer smfr to write it up
  dino: It's up to us to define exactly what we've implemented.
  dino: Will cause us to understand our bugs and fix them too
  dino: And we can better analyze what Google has come up with so far
  dino: Wrt efficiency, actually on mobile devices implementing it
        Apple's way might be more efficient based on the way mobile
        GPUs work.
  dino: Also we thought about how WebKit would implement Google
  dino: Would have to clear away whatever's under the elemnet
  dino: [gives an example]
  astearns: ...
  dino: Don't want to block work on the proposal. It's up to Apple to
        provide more info and counter-proposals.
  dino: We object in the sense that we don't think it's the right
        thing to do, but not in the sense that we will fight you on
        the beaches.

  astearns: We have a resolution on having backdrop-filter in general,
  chrishtr: We need a resolution to put this into the draft.
  dino: The core difference in the proposal is adding
        backdrop-proposal. The core difference is where do you take
        the backdrop from.
  chrishtr: In terms of web compat, this should be quite compatible.
            We did research finding no examples; didn't find the iOS
  chrishtr: Also Safari's implementation is prefixed. Edge's is not,
            but that will be Blinkified
  chrishtr: With all that we propose to resolve on this?
  astearns: So proposal is to add the backdrop-root proposal to the
            draft minus the rounded corners
  chrishtr: and minus the part about backdrop-root causing containing
  fantasai: What are we doing?
  chrishtr: We have a backdrop-filter property in the spec, we are
            adding concept of backdrop root

  <AmeliaBR> Current spec definition:
  <AmeliaBR> New section (plus other edits):

  chrishtr: What I'd like to resolve on is that we define a backdrop
            root to be according to the thing on the screen minus the
            part about rounded corners and minus the part about
            backdrop-filter creating a containing block
  chrishtr: When a backdrop-filter is present, it means that you draw
            all content underneath its containing backdrop root into
            an image buffer and the filters apply to that
  chrishtr: and it's drawn underneath the backdrop filter element
            clipped to its rounded border rect
  chrishtr: That clarification about rounded border rect is also a
  Markus: Also defines order of operations wrt opacity, wasn't defined
  astearns: So by putting this into the draft, that becomes the place
            we discuss whether this is how we do it or whether there's
            an alternative proposal
  dino: Add an issue describing this
  hober: We're OK adding it to the spec provided there's an issue
         noted in the spec describing that there is no consensus on
         having such a property
  astearns: So we're not waiting on Apple to have an explanation of
            CoreGraphics, but here's our current proposal and an issue
            saying it's still under discussion to maybe make more like
  [discussion of how to make an issue note in the spec]
  fantasai: We file issues in the tracker generally, but also
            sometimes we mark it in the spec, possibly with a link to
            a github issue, to warn the reader about the existing
            discussion, disagreement, etc.
  astearns: Any objections to adding to spec with issue marker?

  RESOLVED: Add the proposal with an issue noted in the spec


3D Transform Interop
  github: https://github.com/w3c/csswg-drafts/issues/1950

  <AmeliaBR> Current spec:
  mattwoodrow: The current ED is pretty unclear and seems to not be
               backwards-compatible with the Web. We're seeing lots of
               bugs in Firefox and it's unclear what we're supposed to
  mattwoodrow: Wanted to clear up what we want to do, get
               implementations and spec to match
  mattwoodrow: Especially transform-style: 3d
  astearns: I see a list of issues in the agenda
  mattwoodrow: 4-5 are those cover transform-style
  smfr: I think all those issues could be duped to a single issue.
        They're pretty vague
  mattwoodrow: Targeting individual pieces

  smfr: I can summarize state of problems
  smfr: You mentioned speccing webkit behavior. But Webkit behavior is
        not very definite.
  smfr: WebKit tries to follow spirit of current spec
  smfr: The main issue is that transform-style: flat creates stacking
        context, but the draft also says that 'overflow: not visible'
        also triggers transform-style: flat
  smfr: Which implies that non-visible overflow creates a stacking
        context which would be nice but we can't do that
  dbaron: But at this time 'transform-style: flat' doesn't create a
          stacking context in any implementation
  smfr: There's no implementation that has a consistent model for how
        this all should work
  smfr: So I tried to introduce an auto value to help solve this issue

  AmeliaBR: Background root triggers list, could maybe be adopted as a
            list of what triggers auto to turn into flat?
  smfr: Transforms spec has a list of "grouping properties"...
        "graphical grouping properties" should have a master list in a
        spec somewhere
  smfr: Should agree across the specs
  smfr: 3D transforms and backdrop-filter
  <smfr> https://drafts.csswg.org/css-transforms-2/#grouping-property-values
  dbaron: When I brought this issue up last year agreed we should have
          a consistent term
  dbaron: Just variation on whether also becomes a containing block
          that traps fixedpos
  <dbaron> We also need... an above CSS-level-2 spec that can define
           base terms for this stuff!

  AmeliaBR: Still in the spec that SVG elements have special behavior
            in that 2D transforms on SVG elements don't cause stacking
            and some other things even though they do on CSS boxes
  AmeliaBR: That's important in SVG because transforms are the main
            way to do "layout" in SVG, but does complicate the
  smfr: I thought every element in SVG was a stacking context, did
        that change when z-index was added?
  AmeliaBR: Yes. Hard to get ppl to implement z-index for that reason
  AmeliaBR: Do have a definition for it somewhere.
  smfr: Stacking context introduces a lot of complexity everywhere.
        Having also in SVG scares me.

  mattwoodrow: Separate issue to raise about the draft
  mattwoodrow: Current spec for transform-style says to look for
               containing block [missed]
  mattwoodrow: Decided to flatten and switch transform-style to flat
  mattwoodrow: But can have a stacking context that's not a containing
  mattwoodrow: I think if we changed ? to use the ?
  mattwoodrow: Then we could be clear about when we're supposed to

  chris: We've slightly moved past that, but this is why SVG resisted
         adding z-index for many years
  chris: The model with painting in SVG was simpler, didn't add
         stacking contexts.
  chris: Adding z-index brings two models into SVG. Worth doing, but a
         lot of work.
  astearns: Need to resolve that we don't create a stacking context
            but decide what we do instead?
  smfr: So we have a resolution for this issue but not an actual fix
  astearns: Anyone have an idea of what we should do?
  mattwoodrow: TienYan Chan from Google who used to work on this but
               unfortunately doesn't anymore. Had a long explainer of
               these problems with a proposed solution for four
               different things
  <astearns> explainer:
    ... archived at
  <dbaron> https://github.com/w3c/csswg-drafts/issues/1944

  chrishtr: This was discussed at a breakout session at TPAC 2017, was
            clear that more work was needed. Some cases we couldn't
            explain still
  chrishtr: afaik this explainer document is the closest we got to
            figuring out what to do
  astearns: Maybe another breakout session this week?
  chrishtr: It's 12 pages, so would need to reread it to remember what
            it says
  chrishtr: It does seem there's room on the agenda. Is there enough
  astearns: So breakout session tomorrow afternoon. If anything on the
            agenda then that would be problematic, lmk so I can
            shuffle things around
  smfr: Tess can cover dark mode
  * hober can study up on it between now and then
  dbaron: Mozilla is next door, so if can't get a room here can get a
          room there.
  * dbaron would kinda like to be around for dark mode as well

<br type=lunch>
Received on Tuesday, 26 March 2019 19:28:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2019 19:28:21 UTC