[CSSWG] Minutes Fukuoka F2F 2019-09-16 Part III: Scroll Anchoring, Images with layout information, Multicol, Transforms [css-scroll-anchoring] [css-inline] [css-multicol] [css-transforms]

  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

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.


  - 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


  - 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


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

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

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

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

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


column-fill should behave similarly in paginated and continuous
  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

  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
  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
  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
  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
  smfr: Originally the notion was perspective is we're applying
        another transform for descendants, a common viewport/
  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
  smfr: Creates a stacking context, and a graphical group, it triggers

  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
  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
  smfr: Not really sure how to describe the clipping effects of
  mattwoodrow: Think we want different behavior for preserve-3D and
  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
  mattwoodrow: but the perspective origin is outside the scrolled
  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
  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
  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
  smfr: but the author could use the perspective transform function on
        the leaves to get something similar, but not sharing the same
  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
  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
  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
  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

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