- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 Mar 2019 22:27:29 +0300
- 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)
Transforms
----------
- 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.
===== FULL MINUTES BELOW ======
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
opacity
chrishtr: and problems of not applying atomically
chrishtr: while also supporting stacking context without visual
effects
chrishtr: or stacking contexts that should be able to with more
clever code support in compositing systems
chrishtr: ...
<AmeliaBR> The proposal:
https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html
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
corners
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
effect
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
table
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
differences
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
list
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
concept
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
thing
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
limitation
dino: We do have example of backdrop filters and opacity on the
ancestor
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
filter?
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
video
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
proposal
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,
right?
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
example
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
block
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:
https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty
<AmeliaBR> New section (plus other edits):
https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html#BackdropFilterProperty
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
clarification
Markus: Also defines order of operations wrt opacity, wasn't defined
before
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
Safari
[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
Transforms
==========
3D Transform Interop
--------------------
github: https://github.com/w3c/csswg-drafts/issues/1950
<AmeliaBR> Current spec:
https://drafts.csswg.org/css-transforms-2/#grouping-property-values
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
implement.
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
definition
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
block
mattwoodrow: I think if we changed ? to use the ?
mattwoodrow: Then we could be clear about when we're supposed to
flatten
<mattwoodrow>
https://drafts.csswg.org/css-transforms-2/#accumulated-3d-transformation-matrix-computation
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:
https://docs.google.com/document/d/1FIQW9qVPbZxn0pifFOXWWK0-7fXrjlSeYeZN7wHmIHo
... archived at
https://lists.w3.org/Archives/Public/www-archive/2019Mar/att-0001/01-part
<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
interest?
[scheduling]
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