- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 4 Oct 2019 18:51:40 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Scroll Anchoring
----------------
- Firefox is proposing to change the scroll anchoring behavior to
never apply any adjustment for scroll anchoring if you are
processing a scroll event listener for that node in order to
prevent the current loops that cause either high CPU usage or
pages to freeze. Chrome believes they looked into that and
rejected it, but will figure out why it was rejected in order to
further the issue. (Issue #4239: Should not apply anchoring
adjustments from scroll event handlers)
- RESOLVED: An anchor node can be any box except non-atomic inline
boxes (Issue #4247: Can an anchor node be an inline
block)
Images with layout information
------------------------------
- There was a lot of interest in the group for solving how images
can give layout information in order to appear inline with text
easily (Issue #4116). Knowing the group is interested myles will
continue to design a proposal.
Multicol
--------
- RESOLVED: Revert the change made in #3224, and add spec issues to
define this (Issue #4036: column-fill should behave more
similarly in paginated and continuous contexts)
- RESOLVED: Republish the wd of css-multicol
Transforms
----------
- smfr talked through his research on current use of 3D transforms,
proposal for changes, and the potential web compat implications
of making changes.
- The current ED has you always in a 3D rendering context, but smfr
proposes to move to you only establish a 3D rendering context
when you use the magic properties.
- There was interest in specifying that the root must have
perspective and preserve-3D to establish a 3D context, but there
needs to be more research about potential breakage before that's
resolved upon. chrishtr will do that research.
- RESOLVED: Add a new "pseudo-stacking context" definition and use
it to define how backface-visibility works (Issue #918:
Preserve-3D + backface visibility semantics need to be
clarified)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda
Scribe: myles
Scroll Anchoring
================
Should not apply anchoring adjustments from scroll event handlers
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4239
emilio: The spec specifics a few situations where if a given style
change happens, you don't apply any scrolling adjustments in
the container. This is done to avoid manual sticky effects.
This is done to prevent them to breaking.
emilio: Even with this heuristic, we have still found either broken
pages that for example, once you scroll to the bottom you
can't scroll back up, or they do things that in the regular
cases you want scroll anchoring to apply, or pages that get
burn a bunch of CPU in infinite scroll event listeners
because scrolling triggers more scrolling listeners. This is
possible in both chrome and firefox.
emilio: What I did to fix it is to never apply any adjustment for
scroll anchoring if you are processing a scroll event
listener for that node.
emilio: When you fire the scroll event listener, you remember the
target of the event, and if the element matches, you don't
re-fire
emilio: This is mainly to prevent bad scroll events. I'm just
interested in feedback from implementors
<missed>: Chrome implementors are in agreement
emilio: Steve Kobes is no longer working on this
eae: No one is working on it now
chrishtr: What about it are you interested in?
emilio: Scroll anchoring restores positions so the offset relative
to the scroller is preserved. There are cases where that's
undesirable, or breaks if the page is doing stuff like
scroll effects. So if you change a static position thing to
be below, the anchor node goes up, and then you need another
scroll event, and the page realizes that the thing is no
longer sticking to the viewport, etc.
emilio: Chrome fixed this by, when changing from in-flow to
out-of-flow, don't do the scroll adjustment.
eae: Yes, that's how it works today.
emilio: Even with this heuristic, pages burn CPU by firing infinite
scroll events, which is not great. Pages that get locked up
on scrolling if you get to the bottom.
emilio: Those cases are not easy to identify generically, because a
particular style change happened. The style didn't change,
it's a case that scrolling wants to fix. The only thing
that's happening is a scroll event listener. Instead of
Chrome's heuristics, it would be simpler to not adjust
scroll offsets if you're doing scroll anchoring if it's
happening during a scroll event listener
eae: We tried that and rejected it, but I don't remember why. Our
current behavior is the one that worked the best in the best
number of cases.
chrishtr: If something dirties layout that changes scroll offset in
a scroll event listener... you want that readback to not
take into account anchoring?
emilio: Yes.
eae: That sounds reasonable. If we can't figure out why we can't do
that, we should try it again and see if it's workable
chrishtr: Is the code doing this loop synchronously?
emilio: I know pages in Chrome that burn CPU because the scroll
offset keeps changing
emilio: It changes back and forth, and triggers two scroll events
eae: We try to detect that and short-circuit if we go back and forth
more than a few times, but it may not always work.
atotic: If you have feedback, that would be great, because we're
using a heuristic now
chrishtr: If layout is dirtied and synchronously read back in the
same handler .... what does reading it back have to do
with ....
emilio: While the page is measuring something, so if you insert
something, measure it, then remove it, that measurement
triggers a scroll offset update. If you measure again, you'd
get the opposite scroll offset update. That needs to update
the scroll offset
chrishtr: Are you proposing that forced layouts don't do this?
emilio: I'm proposing that Scroll offsets don't do anchoring
smfr: Is the time that scroll anchoring is applied defined in terms
of HTML5 event loop.
emilio: No. This is an issue. Mostly for this heuristic, if we can
remove it, we don't need that, but the main issue is that
it's undefined when this calculation occurs. We are aware of
this.
emilio: Scroll anchoring runs after updating styles but before
updating layout.
emilio: In order to have the tree in the state you want it to, you
have to run it every layout
smfr: Scrolls triggered by scroll anchoring fire scroll events?
emilio: Yes
smfr: that's necessary?
emilio: Yes
chrishtr: What you're proposing is worth investigating. Chrome can
invest engineers to page back in our history here.
eae: If you're implementing now, we should resolve this
astearns: Do we need a resolution? Should we change the spec?
emilio: These heuristics are still implemented in Chrome and
Firefox. I want to remove them in Firefox.
emilio: I don't see any reason to remove them now.
chrishtr: We need more investigation.
dbaron: You talked about, in a certain case, not doing scroll
anchoring. Are there are reasons to record but defer the
adjustment until later?
dbaron: I haven't thought about it that much. It feels like not
doing it sometimes runs the risk of dropping something that
you might have wanted
emilio: That may be another approach. And then we can move it to the
"update the rendering steps" in HTML5
emilio: The main reason case where you don't want scroll anchoring
adjustments is when you're reacting to scroll events yourself
atotic: Part of the problem in Chrome is that, by the time we're in
layout, we don't know which handler caused it. If you can
make it work in Firefox, maybe it's possible in Chrome. But
we don't have anyone working on it
emilio: Yeah, but you can set a flag....
atotic: We'd have to pass the flag around....
emilio: Yeah, it's possible
smfr: High level comment about spec: The spec is unusual because it
describes a behavior which is making up for the fact that web
developers often make mistakes and cause scroll jank. With
specs like this, we need to be careful. We risk a scenario
where some UAs implement this, papering over the bad stuff,
and authors may only test in UAs that implemented it. In other
UAs which haven't implemented in it, there's a lot more scroll
jank than the other UAs. This spec increases the disparity
between user agents. We need to be careful not to make too
many of these in the future
astearns: There are lots of CSS features which are improving the
rendering of a page. If a browser doesn't implement that
feature, that browser will look worse.
smfr: It's invisible to authors. The browser just fixes up content.
It's easy for authors to create scroll-jank if they don't test
in chrome
iank: There is precedence. Text autosizing behavior is automatic.
astearns: Can we move on?
Can an anchor node be an inline block
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4247
emilio: A bit of the issues we've found with the spec, the spec uses
terms, and the terms don't map to the implementation that
wrote the spec. The spec says "the anchor is either a block
box or text" but what blink does is "well any thing that is
not an inline or an anonymous block can be an anchor"
emilio: That is not great. I think we've reached agreement with
Steve about better terms for the spec. The spec needs some
love.
emilio: I'm happy to help out to refine the spec.
emilio: Proposal: Changing the definition of anchor node to be every
box but inline boxes and fragmentainers, which are the only
things that fragment across <missed>
emilio: This is what Blink does.
astearns: Any concerns?
iank: There's some discussion on the github issue?
oriol: Instead of explicitly specifying the inlines, can we use
atomic inline from the display specification? We can use
terms from that spec for future additions to the spec?
emilio: So right now, the definition is accurate. That term from the
other spec sounds better.
emilio: Proposal: An anchor node can be every box except a
non-atomic inline box
RESOLVED: An anchor node can be any box except non-atomic inline
boxes
<bkardell> non-atomic inline boxes must not be anchor nodes?
<bkardell> maybe?
JLReq met last week
===================
astearns: There's going to be a breakout session on Wednesday to
talk about JLReq updates
nat: Japan Language Requirements. We're working on an errata and gap
analysis that will add new tests so we can more deliberately
affect standards for Japanese typography including those on the
web. 10-11 Wednesday, called Evolving the JLReq. Will be
talking about what we are currently doing and what we will be
doing in the future.
TabAtkins: Majid pointed out that Waterloo is available for a summer
meeting (instead of New York).
Rossen: Near Toronto
TabAtkins: 1 hour drive
Rossen: Thanks for the offer.
Images with layout information
==============================
Scribe: emilio
GitHub: https://github.com/w3c/csswg-drafts/issues/4116
smfr: I'd like to build up the understanding of how they should work
incrementally. I have some data from real sites that will
inform our discussion.
astearns: Projection?
smfr: yes
myles: I'd like to present a problem and no suggestions about how to
solve it, but I hope to leave with a sense of whether we're
interested in solving it
myles: There are images that need to be positioned similarly to text
myles: like a math formula with a tall integral sign where most of
the formula should be aligned to the baseline but the
presence of the integral sign the whole image will sit on the
baseline
myles: so the formula won't align with the text
myles: It'd be cool if the math formula could say "my baseline is in
the middle of the image", and layout could align it correctly
<fantasai> if we're talking about things like gaiji, which is inline
images that should have a baseline and stuff... there was
some proposal to add a property to specify a baseline
table
<fantasai> we didn't spec it out because it wasn't a high priority
<fantasai> but it's certainly possible to do
myles: Similarly with the apple pay logo and similar, because of the
descender of the y
myles: A similar case is for symbols like the play button in the ios
music app, which is not fully horizontally centered, but
visually centered
myles: It's a triangle, so if you mathematically center it
horizontally it would look wrong
myles: so the layout moves it slightly horizontally
myles: Same for gaiji, which are cjk chars which are not in unicode
and people use them using images
myles: since they're images they behave wrong
myles: Three of the examples show the need for horizontal baselines,
the other is a vertical baseline
<tantek> There's another fairly common use-case of this, images used
for decorative first/initial letters
myles: There are various ways to do this, one option is using it on
the image formats and such to provide the information
myles: Another option is to add a css property
myles: Mac has these system assets that contain this information
myles: Another option would be to provide a css function that takes
a name to these system assets, and returns the information
myles: so at least we could use it for system assets
myles: I wanted to get an indication of whether this is a problem
worth solving, and if it is what's the solution could look
like
TabAtkins: Chrome is fine with that, we have taken a look to the
image formats to provide x-height and baseline
nmccully: A single baseline is fine, but multiple baselines may be
needed for multiple writing systems
tantek: I agree this is worth solving. Another use case is a
decorative image for the first-letter which has decorations
and borders and such
tantek: We have a similar feature / challenge in css-ui with the
cursor property
tantek: Cursor has a hotspot. May be something that we could reuse
somehow
TabAtkins: Cursors are usually set once, but in this case you need
the same information every time you set the image
tantek: I think cursors can also have the same issue. Having the
info in the image would be great, but maybe both
TabAtkins: Both is fine
<fantasai> agree its similar, but hotspot is different from
alignment; first is a point in x y space, second is
position independently in each axis
<fremy> @myles: if you want more details about the CUR format
wrapper which can contain a PNG image and specify a hotspot:
https://en.wikipedia.org/wiki/ICO_(file_format)#Icon_resource_structure
<tantek> FYI CSS UI cursors with optional hotspot x y that can
override any built-in hotspot: https://www.w3.org/TR/css-ui-3/#cursor
stantonm: We have a similar use case for @font-face / images and
cjk, where adding a baseline to the font-face rule would
be useful
myles: Can you link me to it?
stantonm: We also have a use case to get rid of these images and use
the font, so we wanted to use @font-face with the images,
and for that the baseline would be great, but for the
symbols it may not make sense
<stantonm> creating @font-face from an CJK image (gaiji) -
https://github.com/w3c/csswg-drafts/issues/4013
stantonm: Another thing we wanted to see if we can treat images more
like a bitmap, to invert in dark mode
myles: mix-blend-mode?
stantonm: I haven't looked into impl that much
heycam: I wanted to express general agreement on the problem being
worth solving
heycam: have run into this with svg
heycam: I think modifying image formats would be useful, though I'm
concerned for compat if we run into a situation with
image-orientation
heycam: where we start reacting to image metadata and breaking pages
myles: We still need some css integrations to define how these are
read or what not
heycam: Using vertical writing mode to getting centering and
alignment seems a bit odd
krit: File formats seems nice, but there are formats which we may
not be able to modify
krit: So we may want a css-only solution as well
chrishtr: What formats have this already, any examples?
myles: Nope, 0
myles: The ui image in iOS apps have this, but it's not a file format
chrishtr: So in an iOS app you create an image and set this and use
it in your layout?
myles: Yes
chrishtr: I'm curious about how feasible is it to modify the formats
myles: People think it's a good idea so I'll try and come back if
fail
fremy: We may not need to change formats, the cursor format is a
small wrapper file with some metadata. May be able to use a
similar wrapper-format
chrishtr: You're proposing a new format?
fremy: Windows cursors do exist already, and include the hotspot. It
already has the hotspot, but we don't want exactly that
fremy: so we may want that instead
fremy: as changing formats is going to be a pain
myles: Only interested in jpeg and png really, and those do have
optional tags
myles: but yeah, first thing to try is changing those, second the
wrapper format, third css-only solution
<myles> optional tags inside their existing formats
<nmccully> Adobe's SING glyph format was one way to make an image
with font metrics:
https://web.archive.org/web/20080627183635/http://www.adobe.com/devnet/opentype/gdk/topic.html
<fantasai> myles, I think we need to make sure whatever we do can
handle multiple baselines
<fantasai> e.g. alphabetic vs ideographic vs central vs mathematical
bkardell: We need to specify what do we do with these values, and
people thought that a css solution would also be valuable
too
bkardell: so it seems like we'd get into a situation where there are
multiple sources of truth
myles: image-orientation was like that until not long ago
bkardell: Right, also aspect-ratio and such
bkardell: Do you think a property of that sort would be valuable?
myles: I think the way I'd approach is the
underline-{offset,thickness} where there is an auto value,
then from-font (which would look and the image), then <length>
chrishtr: We discussed something similar about mathml not long ago
right?
myles: I think the mathml proposal was to identify the baseline out
of specific elements inside the formula
myles: but that doesn't work for non-formula use-cases like the ones
I've provided
chrishtr: That makes sense
cbiesinger: Could potentially work for svg
myles: Yeah, true
chrishtr: drott mentioned that fonts can be the wrapper format
chrishtr: That may be a lot of overhead
myles: I think making icon fonts is an anti-pattern
drott: There are some ergonomic issues with them
drott: but my point is that we don't need a new wrapper format, you
could wrap an image in a font file
myles: I'd prefer a new format, there's tons of unrelated stuff that
you'd need to create a valid font
<skk> when image is wrapped in font, is it easy to change font? In
e-book, we sometimes change font, but image(gaiji) doesn't
change.
Multicol
========
column-fill should behave similarly in paginated and continuous
contexts
---------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/4036
rachelandrew: This is an edit made in #3224 (since the last wd)
rachelandrew: dbaron opened this, issue has a bunch of discussion
rachelandrew: I think it was left reverting the resolution in #3224,
but then we need to resolve what column-fill: auto and
height: auto works
rachelandrew: so we need to decide
rachelandrew: I wanted to sort this so I can publish another wd, and
I wouldn't like to publish something that we may revert
iank: Can you describe what happens right now?
rachelandrew: If we're on a continuous context we only look at
column-fill: auto in ???, and there were interop issues
rachelandrew: Chrome is doing the new behavior, which is actually
the old one that was commented out on the spec
rachelandrew: dbaron has a nice table on that issue
rachelandrew: the second table
rachelandrew: I think if we print from the browser the behavior
should be the same
dbaron: yeah, I think we shouldn't get in that situation, because
we'd balance the columns separately because we're printing
dbaron: I think at least the last fragment in paginated mode should
behave the same as the only fragment
dbaron: I suggested a fix, but florian didn't agree because it was
not what print formatters do
dbaron: so I suggested going in the other direction
dbaron: I think mstensho was fine with this if we have a clearer
definition of what each combination does
dbaron: it'd take me a bit
astearns: So reverting would get us to a better place to improve
upon right?
dbaron: I think so if WebKit are fine with changing this
iank: Reverting this leaves less more stuff unspecified right?
rachelandrew: Yeah, that's right, but we shouldn't publish something
that we might revert
iank: Can we mark it at risk or such?
astearns: It's more of a note "we think this is wrong but we haven't
figured out the implications of changing it"
iank: That seems fine for a WD
astearns: But if we know it's flat wrong it may not be useful
iank: But is it wrong for sure?
dbaron: I think the inconsistency is pretty wrong
iank: mstensho didn't agree looks like
dbaron: I don't think he disagreed
dbaron: To be clear the thing mstensho is complaining about is that
`height: auto; column-fill: auto` if we revert this change
dbaron: That combination is already not-defined when you're printing
dbaron: so there's an existing spec gap that needs to be filled
dbaron: but I don't think it's too hard since there is existing
behavior (though we may not like it)
florian: I think consistency between printing and formatters is
important, so it is consistency between a browser on
continuous contexts and printing
florian: so we should revert to find a solution that doesn't break
any of both
astearns: iank had objections?
iank: I think reverting is fine
astearns: proposed resolution is reverting the change and leave
issues in the draft to define this
rachelandrew: yeah
iank: may be useful to link to the reverted change
<dbaron> It looks like what Gecko does for the auto height is just
to assume one column.
RESOLVED: Revert the change made in #3224, and add spec issues to
define this
RESOLVED: Republish the wd of css-multicol
Transforms
==========
Scribe: heycam
3D Transforms
-------------
smfr: Thinking about 3D transforms
smfr: I want to make sure any changes to the spec don't have
unreasonable web compat impacts
smfr: so I wanted to understand how people use 3D transforms on the
web, I did a poll
smfr: Analyzed these sites that are using real 3D
smfr: not as many sites as I expected
smfr: I've noted the structured
smfr: the set of properties on the node that's doing 3D stuff
smfr: properties on the node, the child, the grandchild, etc.
smfr: Generally web sites are putting perspective on the root of the
3D stuff
smfr: not preserve-3D on the root, mostly just perspective
smfr: Then they put preserve-3D in the child, sometimes with
transform
smfr: Sometimes they have a no-op element. Not no transform related
styles on it
smfr: Sometimes they'll have some intermediate elements, e.g. 3 noop
divs, then transform/preserve-3D under that
smfr: Sometimes they put just the transform on the leaf nodes.
Sometimes preserve-3D and transform on the leaf nodes
smfr: Something that came out of this is that there are a few sites
that have these no-op divs that cause bugs in Gecko
smfr: Gecko treats an element in the ancestor chain that doesn't
have transform related properties as something that triggers
flattening
smfr: It's causing problems on a few sites
<TabAtkins> It broke my demo, I recall.
florian: Are there sties that rely on this happening?
smfr: Did not see any
smfr: People combine overflow-scroll and 3D for parallax effects
smfr: Might have to make some exceptions for overflow-scroll
smfr: This is how people are using 3D transforms.. most important
thing is that no-op divs should not cause flattening
smfr: Next I want to build up the 3D model from scratch
smfr: I've realized there are some problems with the current ED
smfr: We'll end up with a combination of that's in the current ED
and the previous WD
[shows transforms-buildup.html]
smfr: Let's started with a simple case. This is a 3D transformed
element, in isolation
smfr: Nothing else that is 3D-ish in this content
smfr: The best behavior for this is that the 3D transform here acts
as a painting effect
smfr: It'll be squished by the transform, but painted in the
regular z-order
smfr: no intersection with its container or anything else
smfr: Next question is what happens if there are 2 siblings that are
transforms
smfr: Think the right answer is that they should act as a painting
effect, they should not intersect
smfr: I think that's the Gecko model, and maybe Blink, but not
WebKit. Willing to change WebKit here
chrishtr: Nothing has the preserve3D here?
smfr: Right, we're still in "painting" transforms
astearns: Is this something the current ED is saying something
different about?
smfr: The current ED is written with the notion that you're always
in a 3D rendering context, and doing flattening
smfr: It uses the analogy of CSS stacking contexts and flattening
smfr: I think a better model is that you only establish a 3D
rendering context when you use the magic properties
smfr: otherwise you paint in the regular z-order
smfr: Now let's change the example to put perspective on the
container
smfr: Originally the notion was perspective is we're applying
another transform for descendants, a common viewport/
perspective
smfr: Looking at the way content is using perspective, think it
makes sense to establish a 3D rendering context
smfr: The 2 siblings would start intersecting with each other
chrishtr: Not a behavior any browser has now?
mattwoodrow: WebKit will intersect them (though even without
perspective right now)
chrishtr: The perspective proposal is unrelated to current
intersecting behavior of WebKit?
smfr: Yes
smfr: When an author says perspective, they're opting in to 3D
stuff, and expecting descendants to depth sort
chrishtr: And currently, in Gecko and Chrome, they don't intersect
but the perspective does adjust the transform
mattwoodrow: Right
mattwoodrow: Did you have examples on your spreadsheet of examples
where Gecko/Blink are broken?
smfr: Most sites had more complex hierarchies
smfr: nobody had just perspective and transformed children
smfr: So, hard to say
smfr: Going back to the example, next set of questions is about the
preserve-3D behavior
smfr: I think the right thing for preserve-3D is to establish or
extend a 3D rendering context
smfr: So in this case, if you put a preserve3D wrapper around the
child -- leaf doesn't have the preserve 3D -- ...
chrishtr: So 2 transformed elements in a single context are sorted
with respect to each other
krit: This example would render the same in all browsers now?
smfr: Not sure that Gecko will do intersection between the two
krit: The proposal is if you have perspective set to a value, you'll
establish a 3D rendering context?
smfr: Yes
chrishtr: Suppose you have an element with perspective. and a child
with no transforms. then a grandchild ---
smfr: We'll come to that
smfr: Web site data showed that no-op divs should not flatten
smfr: Some interesting cases then, things like opacity that trigger
flattening
smfr: Creates a stacking context, and a graphical group, it triggers
flattening
mattwoodrow: My biggest concern with the no-op thing is it's hard to
describe what the behavior is
mattwoodrow: The spec wording for how to decide how to establish a
new one or to participate in an "ancestor"
smfr: Think that should be written in terms of stacking context
ancestors
smfr: WebKit's implementation is based on paint order, not
containing block order
smfr: I think there are some cases where these properties should
trigger a containing block for ease of implementation
smfr: but effectively we certainly work in painting order
mattwoodrow: There are things like overflow:scroll
mattwoodrow: anything that has a clip
chrishtr: Setting aside overflow:scroll, do you think this opacity
would need to establish a containing block?
smfr: No?
smfr: Another interesting case. Things that trigger stacking
contexts but which aren't grouping effects
smfr: For example z-index
smfr: that doesn't create a graphical group, but stacking contexts
are effectively graphical groups, so it should flatten as well
smfr: It's no-op-ish
smfr: so I think in the model it has to flatten
smfr: Then there's the other interesting one, what if you have
overflow:scroll -- doesn't create a stacking context. People
take advantage of this not flattening to create parallax
effects
smfr: Not really sure how to describe the clipping effects of
overflow
mattwoodrow: Think we want different behavior for preserve-3D and
perspective
mattwoodrow: for preserve-3D we probably want to flatten. But the
perspective subset we could do relatively easily
chrishtr: Can we go through a quick example of doing parallax with
this model?
mattwoodrow: Currently in Gecko, the clip is applied on the outside
of the perspective
mattwoodrow: the perspective gets multiplied into the transformed
elements
mattwoodrow: but the perspective origin is outside the scrolled
element
mattwoodrow: The clip is not in the middle of the transform chain
chrishtr: As long as we can preserve parallax scrolling....
mattwoodrow: Spec text could say to look up the DOM to find a
preserve3D element, but stop walking if you find
overflow:scroll
chrishtr: I think you would want this to be a containing block and
stacking context as well
chrishtr: It's neither of those 2 things by default
mattwoodrow: Right
smfr: When it has preserve3D around somehow?
chrishtr: Walk up the tree, if it's got preserve3D around an
overflow:scroll, ...
mattwoodrow: Not suggesting overflow:scroll should be a stacking
context, but the inner preserve-3D would create a new
3D rendering context
[some discussion about preserve-3D on the overflow:scroll element
resulting in the computed style being transform-style:flat]
astearns: Sounds like there were some existing sites that expected
no-op divs ... is there a difference between no-op divs and
those that have an explicit flattening property?
smfr: no-op divs don't flatten
mattwoodrow: I think it's easier to specify if they do flatten
astearns: But not what authors expect?
chrishtr: Maybe
smfr: None of these examples totally broke. But you could see the
perspective looked different on some elements
chrishtr: Definitely think aligning browser behavior is going to
break some content
chrishtr: Should minimize that, but come up with a model that we're
sure is well defined
smfr: That flattening was the most obvious breakage if we followed
the Gecko model straight away
smfr: I think the last piece is the discussion around how
preserve-3D behaves ...
smfr: On #1950, Tab lists four different behaviors
smfr: Don't fully understand if they're the same except for whether
preserve-3D is on the parent or the child
chrishtr: Q1 is, do the children 3D sort before they flatten
<TabAtkins> Q2: do the children sort with the rest of the 3D scene
their parent is in, or do they flatten into the parent
and then (flat) parent lives in the scene?
chrishtr: and these behaviors are the 2 core ones we control with
preserve-3D or perspective
chrishtr: That's your whole point? how do they behave default and
how do the properties affect this?
TabAtkins: Yes
TabAtkins: All 4 combinations seem reasonable, don't know if you
want to expose them all
TabAtkins: Case 1 is fully 3D, everything is operating in the same
graph
TabAtkins: Case 2 is you run the children's 3D scene, flatten it,
the parent does the 3D scene
TabAtkins: #3 is the weird one. Each child does an independent 3D
thing in the parent's plane, but they could overlap with
other things
TabAtkins: 4, double flat is simple
<dbaron> One other thought (related to discussions a few minutes
back) is that you were talking about walking up the DOM
tree, but I'm not sure if you wanted to walk up the DOM
tree or the containing block chain.
smfr: Doing all of these with combinations of properties, with the
behavior I described, except if perspective establishes a 3D
rendering context, authors would not be able to have the
transform effects of perspective without also the intersection
effect
smfr: but the author could use the perspective transform function on
the leaves to get something similar, but not sharing the same
origin
chrishtr: I think that first part of the sentence is a good reason
why perspective should not imply preserve-3D
smfr: So valid to have shared perspective, but siblings not
intersecting, which is contrary to my first point
smfr: ok, so we're back to perspective not making a context
smfr: Question is how many of these sites would break
chrishtr: Then there's the question of resolving the intermediate
divs
chrishtr: how we'd spec and implement the corner cases
chrishtr: If those intermediate divs would in some cases be
transmitting up the preserve-3D as opposed to flattening
smfr: Unless we're willing to go to the Gecko model of always
flattening
smfr: Still think that's the most web incompatible change
chrishtr: If it was web compatible would it be objectionable to you?
smfr: No
chrishtr: Certainly the easiest to reason about in the spec
chrishtr: We should do some homework tonight on why these sites are
broken in Firefox, see if it's due to this issue or
something else
mattwoodrow: I can do that
chrishtr: And whether it's easy to fix them
smfr: If we say that the root must have perspective and preserve-3D
to establish a 3D context, I did not capture data about
whether there are multiple transformed siblings
chrishtr: The intersecting thing?
smfr: Yeah
smfr: No authors are using preserve-3D on the element with perspetive
chrishtr: You would've observed a rendering difference
smfr: These don't have multiple siblings, so wouldn't necessarily
see that
chrishtr: Nobody's done any httparchive searches
chrishtr: would be good to find more to sanity check
smfr: The stripe stuff is genuine content, most others are old demos
chrishtr: Anecdotally, not sure how common this kind of content is
chrishtr: I will volunteer to do an httparchive search tonight
florian: I think the lack of interop is indeed causing a lack of
sites using it
florian: I did retire a site that used to use 3D
Preserve-3D + backface visibility semantics need to be clarified
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/918
mattwoodrow: Current spec says that backface-visibility only applies
to the element it's on, not descendants
mattwoodrow: doesn't say it would create any plane or layer, which
Gecko faithfully implements
mattwoodrow: Other engines create a plane for all descendants but
not positioned descendants
mattwoodrow: which is not something there's any precedent for, seems
a bit crazy. Would prefer backface-visibility create a
stacking context
smfr: I think in WebKit it does create a stacking context, not a
containing block
mattwoodrow: Maybe it is that it doesn't create a containing block
chrishtr: Definitely doesn't create a stacking context
smfr: I'd be scared to change the behavior of backface-visibility...
mattwoodrow: So try to find a description of what it actually does.
Affects itself and non-positioned descendants?
chrishtr: Self painting layers reset the backface visibility thing
mattwoodrow: Don't know how to describe it for the spec
chrishtr: Similar to the set of things dbaron found that caused
"painting as if positioned"
<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
chroshtr: In CSS 2.1, positioned elements paint later than regular
elements
chroshtr: anything that has an effect-y thing on it
chroshtr: This is exactly what is on self painting layers
chroshtr: so we could define it that way
florian: Where else did we run into this?
chrishtr: Might have been another case yes
chrishtr: but the thing about the paint order is one that's not
specified properly, is that right?
mattwoodrow: Most of the specs that create stacking context say
that. But they mean create a stacking context and sort
it with positioned descendants
chrishtr: overflow:hidden, backface-visibility, SVG elements and
other atomically replaced elements, ...
chrishtr: CSS clip probably
chrishtr: and the rest of them do create stacking contexts
chrishtr: We should define this, get interop on the table in
dbaron's test, then use it for the backface-visibility
definition
dbaron: I don't think there's a whole lot in there that's not
creating a stacking context
dbaron: CSS clip only applies to things that are positioned
chrishtr: But in terms of the "painting as if positioned"
chrishtr: I think overflow:clip is the most common
dbaron: Have we added that yet?
chrishtr: I mean overflow:hidden and scroll
chrishtr: On the issue in which this table resides, I mention
there's a silly quirk in Chrome and probably WebKit, not
triggering self painting in some bizarre corner cases of
scrolling
smfr: WK does not create self painting layers for overflow:hidden
dbaron: I don't think Gecko sorts overflow:hidden on to positioned
descendants list
mattwoodrow: Don't think so
mattwoodrow: overflow:hidden isn't a stacking context, can
interleave things inside and outside, so can't go in
the positioned descendants list
smfr: So is everything on the list make stacking context?
mattwoodrow: Yes
chrishtr: overflow:hidden does not create a self painting layer (in
Blink)
chrishtr: If there's overflow:scroll but is in effect like
overflow:hidden since there's nothing to scroll, then we
skip it
chrishtr: That's something we could change in Chrome
chrishtr: In any case, is this a good way to spec it?
mattwoodrow: Yes, I agree the CSS 2.1 spec describes floats [...]
<dbaron> I think Gecko calls this "pseudo-stacking context"
RESOLVED: Add a new "pseudo-stacking context" definition and use it
to define how backface-visibility works
dbaron: Some of this would be easier if there's a spec to put this
old CSS 2.1 text to evolve it
dbaron: maybe a central painting spec
-- break until 4pm --
Received on Friday, 4 October 2019 22:52:34 UTC