- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 23 Dec 2017 10:04:38 -0500
- To: "www-style@w3.org" <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.
=========================================
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