W3C home > Mailing lists > Public > www-style@w3.org > December 2017

[CSSWG] Minutes TPAC F2F 2017-11-07 Part V: choosing the root scroller, unexpected flex/grid auto min sizes, dups in font-variation-settings, filters trapping fixedpos, spec meta-info, WebAnim to CSSWG repo [filter-effects][css-sizing][css-fonts][css-device-adapt][css-snapshot]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 23 Dec 2017 10:04:38 -0500
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <027305e7-65d6-2e2e-c270-1479b1ef69ab@inkedblade.net>

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


Moving Web Animations into CSSWG
--------------------------------

   - RESOLVED: Move WebAnim to the CSSWG repo.

Filter Effects
--------------

   - RESOLVED: follow the existing resolution, add a quirk for filters
               on the root element to not trap fixpos

rootScroller
------------

   - There was pushback on creating an API to choose the primary scroller,
     but interest in solving the use cases. Discussion to move to WICG.

Device Adaptation / Viewports
-----------------------------

   - RESOLVED: Add David Bokan as editor to the Viewport spec

CSS Sizing
----------

   - fantasai introduced a possible solution for the “min-content
     contribution of scrollable autosize descendant of a flex/grid item
     unexpectedly forces overlarge min-size on flex/grid item” problem;
     further discussion deferred to later
     https://github.com/w3c/csswg-drafts/issues/1865

CSS Fonts
---------

   - RESOLVED: For both font-variation-settings and
               font-feature-settings, the computed value is a map (and
               thus specified dupes are removed)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda

Scribe: TabAtkins

Moving WebAnim into CSSWG
=========================

   Rossen: The WA spec is pretty active, relatively speaking, but
           issues don't seem to get attention from the WG. I think this
           is a straightforward request.
   Rossen: We can separately talk about whether to do something with
           the rest of the specs.
   fantasai: Fine if we can get history preservation.
   TabAtkins: Right, so let plinss do it.

   RESOLVED: Move WebAnim to the CSSWG repo.

Filter Effects
==============
   scribe: fantasai

Filters should establish containing blocks for abspos and fixpos
----------------------------------------------------------------
   github: https://github.com/w3c/fxtf-drafts/issues/11

   TabAtkins: Filters are morally equivalent to opacity (or vice versa)
              and opacity establishes a cb, so what's wrong?
   ericwilligers: People were using extensions to apply a filter to the
                  whole page, and they didn't want things to rearrange
   TabAtkins: Ah, it would break fixpos in that case.
   <smfr> TabAtkins, opacity creates stacking context, not containing
          block
   <TabAtkins> ahhhh
   TabAtkins: Right, I was thinking of stacking context; I don't have a
              strong opinion on cb
   <dbaron> Perhaps it's worth reading the background in
            https://www.w3.org/2015/02/10-fx-minutes.html#item02 on the
            previous time this was resolved?

   TabAtkins: So my position is just: opacity is a filter, we need a
              very good reason to make filter and opacity work
              differently in any regard.
   TabAtkins: In the linked details, roc gives an explanation for why
              opacity is different. It commutes with the clipping
              operation, whatever that means.
   TabAtkins: That doesn't apply to other filters.
   TabAtkins: That's a reason for opacity to work different from other
              filters.
   TabAtkins: That is a reason for filters to make a containing block
              'cuz awkward where not for opacity.
   TabAtkins: Can special case root element to have filters apply to
              canvas
   TabAtkins: since that's the compat issue
   TabAtkins: and maybe also body.
   * fantasai hates body special cases
   TabAtkins: Root has filter, fixedpos, and filters keep cb, then
              fixedpos is not fixedpos, it's abspos
   <dbaron> blur then clip is different from clip then blur
   TabAtkins: Filters create a containing block for fixedpos
   TabAtkins: turn them into abspos
   TabAtkins: opacity doesn't have this problem much, so doesn't need
              to do this.

   <myles> We are worried about web compat
   <Rossen> +1 to myles
   TabAtkins: Are you worried about more than just filter on body?
   myles: Yes.
   TabAtkins: You get weird results, as dbaron points out.
   TabAtkins: Blur followed by clip is very different than clip then
              blur.
   TabAtkins: fixedpos figuring out what that means is weird.
   TabAtkins: What do you do now?
   myles: I don't know.
   <smfr> we’re kinda broken
   <smfr> :)
   <smfr> not sure if bugs or fundamental problems with implementation
   <dbaron> I think Gecko has been shipping this for a while
   <dbaron> we did get a small number of bug reports when we shipped
            it, I think
   <dbaron> although at least some of them were due to bugs in what we
            initially shipped

   Rossen: Fixed, everyone expects to behave a certain way.
   Rossen: If you have a filter on an element you expect an effect.
   Rossen: Want to trap abspos things so they filter applies to them as
           well
   Rossen: but for fixed, not so much.
   TabAtkins: Should fixedpos be blurred or not blurred?
   Rossen: Should not be.
   TabAtkins: OK, that's an entirely different solution.
   Tien-Ren: Does that mean fixedpos escapes stacking context?
   Tien-Ren: including Opacity and CSS Mask stacking context?
   Tien-Ren: Does it still follow z-index stacking order?
   Rossen: Of course.
   TabAtkins: We already have these same cases addressed.
   TabAtkins: So we should change everything in lockstep.

   fantasai: The reason we did this for transforms is we need to find
             the staticpos
   fantasai: But for filters, nothing's moving...
   TabAtkins: Sure can - displacement filter
   fantasai: You can have a fixpos in a scroll container, it escapes
             the container unless there's special trapping behavior
             there. Why would filters be different from that?
   TabAtkins: But then can't apply the filter.
   fantasai: That seems reasonable.
   TabAtkins: But it's different from other things.
   fantasai: I'm not really convinced that any of these should trap
             fixedpos...
   TabAtkins: Yeah but that's what ppl implemented so now we're stuck
              with it.

   Rossen: So proposed resolution is apply both containing block for
           and abspos on filters as well as stacking context
   Rossen: Now that we've caught up, the proposed resolution is to make
           filters apply a cb to abspos and fixpos
   Rossen: Second is potentially add a quirk for the root containing
           block to not trap fixpos
   Rossen: and other is add a quirk for root containing block, where
           fixed positions remain fixed rather than turning into abspos
   Rossen: can take in order or together.
   TabAtkins: Think we need to take them together.
   Rossen: So Filters establish stacking context as well as containing
           block for any positioned descendants except when they are
           apply to the root element, in which case they affect
           everything
   <dbaron> fwiw, the group already resolved to do this, it just never
            got edited into the spec...

   Tien-Ren: Do we have to do this on body or just root?
   fantasai: Please not on body, it's so terrible.
   TabAtkins: Depends on web-compat.
   Tien-Ren: [describes some horrible thing that happens with
             style-stealing from body]
   TabAtkins: Yes, I would prefer root only if possible.
   Rossen: dbaron kindly reminds us that we resolved on all of this and
           we just need to edit.
   <smfr> this quirk is going to complicate the “rootScroller” proposal
   <TabAtkins> not more than the existing versions of the quirk...
   <TabAtkins> proposed: follow the existing resolution, add a quirk
               for filters on the root element to not trap fixpos

   RESOLVED: follow the existing resolution, add a quirk for filters on
             the root element to not trap fixpos

rootScroller
============
   Scribe: TabAtkins

   bokan: Proposal based on feedback from internal Google teams
   bokan: Problem to solve is that the document element is special in
          many case
   bokan: Particularly the url bar on mobile
   bokan: You get overscroll-glow on the root element only (on android)
          or elastic (on ios)
   bokan: On ios if you tap the url bar, the root is scrolled to its top
   bokan: But authors might want to compose their app in multiple
          views: a stream with multiple items where each animates in
          nicely
   bokan: Each stream is a separate scroller, only one displayed at a
          time.
   bokan: But now you lose those nice effects, like scrolling it hides
          the url bar
   bokan: Same with AMP pages

   bokan: So proposal is a simple API with some difficult implementation
   bokan: You specify which element is the "special" scroller. Starts
          as the root element
   bokan: When you animate to a view, you designate that as the root.
   bokan: Looking to gage interest from other vendors.
   bokan: I have this impl'd in a flag in chrome.
   bokan: This is unrelated to viewport stuff.
   bokan: Not as concerned about API shape; willing to explore
          alternatives as long as we solve the problem.

   TabAtkins: I remember some interesting questions about what displays
              if the element isn't screen-filling...
   bokan: We currently spec that it only applies if the element fills
          the viewport.
   myles: How to do that?
   bokan: width/height: 100%. Just needs to be the same size as the ICB.
   bokan: There was some interesting in having, say, a header element
          that sits alongside it.
   TabAtkins: [discussion about how it's bad to overlap the scroller]

   myles: Some real complexity here. We have at least 3 codepaths for
          scrollers, and the root scroller has a fair amount of
          machinery associated with it including tiling, hardware
          layers, and inter-process layer hosting. Hooking this up for
          an arbitrary scroller would be very difficult for us.
   myles: Hooking this to an arbitrary scroller is mechanically
          difficult.
   myles: So I hesitate to support this yet.

   gregwhitworth: We haven't received author interest about this yet.
   bokan: Today you can hack around this - teams at Google will pull
          things in and out of the document element. But this is hard
          to do well and interoperably, you can get scrollbar flashes,
          etc.
   bokan: And you have to keep track of scroll positions yourself;
          scrollbar flashing is unavoidable, everyone does it.

   myles: So objection is that when the height of the root scroller
          changes the scrollbar moves?
   bokan: So say you have a stream loaded in the doc element, and you
          expand one of the items.
   bokan: Today you hide all the content, and insert the expanded
          stuff. That causes the scrollbars to flash.
   bokan: Some are bugs or inconsistencies, some are just general
          issues.
   myles: I guess browsers control that scrollbar - if your goal is to
          not flash the scrollbar, maybe we can solve that more
          directly, without the complexity of arbitrary scrollers
          becoming root.
   TabAtkins: So it sounds like you might support the use-case, if not
              the API.
   myles: We're all for being able to remove and replace stuff from the
          DOM hierarchy, and do it in a non-jarring way.
   TabAtkins: Yeah, that's our use-case then.
   myles: Right, then we support that.
   TabAtkins: So you'd support a wicg to solve that problem?
   myles: Sure.

CSS Viewport
============

   Rossen: A while back, we had a resolution to work on a spec that
           describes the viewport
   Rossen: We want to explain/define all the different things like
           zooming, pinch-zooming, content-zooming, all the zooms.
   Rossen: More recently, the separation between visual and layout
           viewport, what applies to what.
   Rossen: What units are we returning OM results from...
   Rossen: Today we have non-interop behavior where Edge returns one
           set of results, in a mix between viewport and layout units.
   Rossen: Chrome does only layout viewport units, I think.
   Rossen: And Safari is trying to align with this.
   Rossen: So the work we have planned that is supposed to be split
           between myself, Peter, and Florian, hasn't had much traction.
   Rossen: There are a lot of specs starting to come about that need to
           reference the viewports.
   Rossen: David graciously agreed to start writing spec text
   Rossen: So the proposal is to add David as an editor to Viewport and
           start writing spec text.
   Rossen: smfr said he's thumbs up

   RESOLVED: Add David Bokan as editor to the Viewport spec

   <jensimmons> what’s the URL for the Viewport Spec?

Intrinsic sizing and containers for grid/flex sizing
====================================================
   github: https://github.com/w3c/csswg-drafts/issues/1865

   fantasai: We discussed yesterday this problem of, in flex and grid
             we have implied minimum size, and people put stuff in
             there with scrollbars, expecting that to handle overflow,
             but because we're looking for min-content size *including*
             overflow, stuff gets too big and it's awkward.
   fantasai: Not obvious how to fix it, because it's a deep descendant.
   fantasai: We opened an issue to find better ways here.

   fantasai: Proposal is that grid/flex items that have non-visible
             overflow ignore their content for the purpose of
             calculating their min-content contribution
   fantasai: In both axes
   fantasai: And block boxes do the same thing in the inline axis.
   fantasai: Excluding the block axis because it's awkward and
             difficult to compute a min-content that's different
             from the max-content.
   fantasai: dbaron brought up the point that you might want to
             consider overflow:hidden different from scroll, because
             it's sometimes used just for bfc, nothing to do with
             clipping. That's probably only relevant for blocks.
   fantasai: For authors that want the min-content size to handle the
             sizing, they can explicitly use "min-height: min-content";
             and if they want some other minimum > 0 can specify that.
   fantasai: I think this will give more intuitive behavior; people
             won't be as confused when their items get much wider than
             expected
   fantasai: And for the people who do need to have this old behavior,
             they can just use min-content keyword.

   TabAtkins: I'm confused - I thought this was about *descendants* of
              flex/grid items.
   fantasai: Right, but those descendants might be flex/grids again.
   fantasai: So a block with auto-size and scroller in the inline axis,
             and the flexbox container says "how much space does my
             content want?" and the block says "THIIIIIIIIIIIS wide"
             and the flexbox gets huge.
   fantasai: So if the block reports that it's 2ems wide (just
             padding), the flex container can say "2ems here for this
             scroll container, 3ems for that word", and then becomes
             3ems wide, and the extra stuff will scroll as intended.
   fantasai: So the intrinsic size of a scroll container is dictated by
             its contents. The fact that it has a scrollbar is
             irrelevant to its contribution; but in practice, you put a
             scrollbar on it, you're *okay with* it shrinking, so it
             should be able to shrink below the min-content size.
   <fantasai> (and if you don't want to, you can set min-width:
              min-content)

   dbaron: Trying to see how specific it is to grid/flex
   fantasai: Currently not specific. It would effect a float or
             table-cell that contains an element with overflow:scroll,
             *if* that float's size is dictated by the size of the
             overflow element.
   dbaron: I suspect we can't change the float/table behavior, we're
           probably stuck with this.
   TabAtkins: So just min-width/height:auto, then.
   gregwhitworth: We resolved about something similar on tables
                  yesterday.
   fantasai: The cases affected by this proposal would be where author
             sets overflow:auto/scroll, but nothing ever scrolls
             because the box is always big enough to fit its contents.
             This seems weird:
   fantasai: where the overflow-controlled box is the one dictating the
             size of the container, such that it never ends up needing
             to overflow. Seems kinda odd.
   fantasai: Usually when you set 'overflow', your size is dictated
             by something else, such that you might have overflow.

   TabAtkins: I think this needs more thought and compat analysis
              before I'm comfortable with this.
   fantasai: Should be able to do it for flexbox and grid, at least,
             which would solve a lot.
   fantasai: Currently we say if you have overflow:non-visible your
             automatic min-size is zero, but your min-content
             contribution is not zero.
   fantasai: So I think it's safe to say your min-content contribution
             is also 0.
   TabAtkins: I'd still want some thinking time about this, even for
              the limited case.

   <fantasai> Rossen, testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5495

CSS Fonts
=========

getComputed value for font-variation-settings
---------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1959

   gregwhitworth: You can duplicate values in font-variation-settings;
                  set axis "x" over and over again.
   gregwhitworth: When you ask for computed value, should you get the
                  dupes?
   gregwhitworth: Or get the simplified version.
   gregwhitworth: Currently Chrome and Edge return what the author
                  wrote.
   TabAtkins: I think Safari makes sense. It should be a map.
   eae: And it would simplify our implementation.

   dbaron: Is this the same as font-feature-settings?
   myles: In our impl, yes. And it makes sense to keep them in lockstep.
   myles: If there is a script calling gCS() and parse that value, it's
          more likely to get it right with deduped values too.
   gregwhitworth: So barring testcases, resolution is to have it be
                  deduped for font-variation-settings
   dbaron: We should resolve for both, and come back if testing says
           it's a bad idea.

   RESOLVED: For both font-variation-settings and
             font-feature-settings, the computed value is a map (and
             thus specified dupes are removed)

CSS Snapshot
============
   Scribe: fantasai

Copy document conventions (and conformance?) from 2.1
------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1867

   TabAtkins: Definition of what a propdef block means is in 2.1
   TabAtkins: I would like to move it to someplace better
   TabAtkins: snapshot's probably the best place for that.
   TabAtkins: Problem is definition of propdef tables is probably
              normative.
   TabAtkins: Snapshot was decided to be non-normative awhile back
   TabAtkins: which as other consequences such as the ton of
              conformance boilerplate that we have to put in every one
              of our specs.
   Chris: We could ship that spec to other spec like Values and Units
   Chris: Or we can make it non-normative
   Chris: so let's do that.
   Florian: You can do that in a Note?
   Chris: Reading prodpef tables isn't really a conformance thing.
   fantasai: But the other bits of boilerplate are.
   Chris: Then, we'll publish the snapshot as a WD, and the a year
          later when the new snapshot is a WD, turn it into a note.
   flackr: You'll deal with that?
   Chris: Yeah.
Received on Saturday, 23 December 2017 15:05:23 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 23 December 2017 15:05:23 UTC