- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 16 Aug 2021 18:10:43 -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.
=========================================
CSS Contain 2
-------------
- RESOLVED: Conceptually play (invisibly and muted) any media
playback for things that are skipped due to
content-visibility, skipping any events unless queried
(as for animations) (Issue #6468: Pause media playback in
iframes hidden by content-visibility:hidden)
CSS Overflow
------------
- RESOLVED: Adding a note describing the behavior to the css-overflow
spec (Issue #5733: Should transformation affect the
scroll direction via touchpads/touchscreens?)
- The use case in issue #5670 (proposal: scroll-index (priority)) is
a good one to solve, but the proposed solution didn't seem
correct. Discussion will continue in the github issue to find a
better solution.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/19
CSS Contain 2
=============
Scribe: fantasai
Scribe's scribe: TabAtkins
Pause media playback in iframes hidden by content-visibility:hidden
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6468
chrishtr: Web developer raised use case of wanting to automatically
pause videos, media
chrishtr: In situation where media happens to be in iframe, page
can't really access it, because usually cross-origin
chrishtr: atm can only do that by coordinating with each provider of
video
chrishtr: Perhaps platform can make that possible
chrishtr: Suggestion was content-visibility to control that
chrishtr: content-visibility is meant as a performance tool, and this
is about reducing unnecessary use of CPU
chrishtr: so ...
chrishtr: so seems that media under content-visibility be
automatically paused
chrishtr: Final point is, as I understand, for web-compat a lot of
sites expect video, especially with audio, when not visible
for other reasons
chrishtr: e.g. off screen or detached from the DOM
chrishtr: But since content-visibility is new, probably not compat
worry
TabAtkins: I'm surprised at how many things still allow video to play
TabAtkins: This seems like a good idea
astearns: I'm not sure I'd look for content-visibility as a way to
make cross-origin video stop playing
florian: In that direction not obvious
florian: but in other direction, would you expect a video with
content-visibility to play?
flackr: display:none might have similar effect
flackr: might also unload frame...
<TabAtkins> It does unload the frame
Rossen: Display:none is a big hammer
emilio: Idea is to also do this for same-origin stuff?
emilio: ...
emilio: Is there a ?? on if you remove element from the DOM, then it
doesn't stop playing, then you add content-visibility and
then remove from DOM it's paused, that's weird
emilio: Doesn't pausing media change styles?
emilio: causes :pause to apply ...
emilio: maybe not a huge deal if under subtree, but also weird
emilio: Overall, I think removing video from DOM should pause
emilio: Seems weird that content-visibility is the only thing that
does this
chrishtr: Yes, it would be all media
chrishtr: Issue says iframes, but would also apply to same-origin
video within the document
chrishtr: with regards to relative timing, seems similar to detaching
video after user presses pause button
chrishtr: Same thing, rendered as visible under content-visibility
chrishtr: Third point was about how styling changes when it's paused
chrishtr: I think yes, those styles would conceptually apply, just
like all boxes within content-visibility subtree
chrishtr: but UA is allowed to not render within that, for
performances reasons
emilio: Does content-visibility currently change styles under its
sub-tree?
emilio: I guess it pauses animations, which is something
flackr: It pauses animations in a way that is not very
developer-visible
flackr: the timer keeps going
flackr: For this video, could maybe not change state to pause, but
would not continue playing
Rossen: Is that how we have it specced?
Rossen: content-visibility is currently defined as behaving like
'display: none' on contents
Rossen: [quotes spec]
<Rossen> https://drafts.csswg.org/css-contain/#content-visibility
Rossen: display:none does not exhibit the behavior you just described
for animations
flackr: That's a misleading statement, interaction should not
continue ..
astearns: That note is about accessibility, but it's not clear what
that note is hooked to
<dholbert> https://drafts.csswg.org/css-contain-2/#valdef-content-visibility-hidden
emilio: But this isn't what the OP filed the issue about
Rossen: You get to some part of the video, or would you start from
the beginning?
astearns: The idea is it will pause, and then resume after visible
astearns: Detaching would restart the video which is not good
chrishtr: Pausing video seems simpler to implement
chrishtr: already way to pause videos in UAs
<flackr> content-visibility animation pausing was spec'd by
https://github.com/w3c/csswg-drafts/commit/82fc7ddb1abf9ce0c3f616cbd91a0f1d2069a215
chrishtr: With regards to styles, can leave styles uncomputed
emilio: Why not for animations?
Rossen: display:none will stop animations entirely
Rossen: but with regards to animations, it's different than what I'm
hearing about video that's described by ??
Rossen: In case of animations, supposed to pretend they're running,
but not actually run and use up CPU
Rossen: When you return, get to more advanced stage
Rossen: video ...
Rossen: saying 2 are the same is not right
Rossen: If we want this behavior for video or media
Rossen: differentiate clearly so people would know what to expect
chrishtr: Leaving video playing but not using CPU to do texture stuff
is problem, because still have audio
chrishtr: otherwise UA would have to keep audio stream running, but
not the video stream
Rossen: You can pause, and then take them forward, by the delta
Rossen: as if the video was playing
fantasai: What Rossen said - if you wanted animations and videos to
be consistent, you'd need to advance the timer on it even
when it's not playing
fantasai: I think it would be good to treat them the same
astearns: And if you did that, you would *not* set pause on the video
fantasai: Right
flackr: Because content-visibility:auto hides things as scrolled out
of view
flackr: ...
flackr: this is why we had this behavior for animations
emilio: Pausing a video not only changes styles, but also triggers JS
events
emilio: Really a problem when style change triggers a bunch of JS
handlers
emilio: ...
chrishtr: For animations, we did decide that although video is
conceptually advancing in time, it doesn't fire events
chrishtr: since that goes against perf goals
chrishtr: Could potentially just not fire the events
flackr: Concern was audio, could also conceptually mute the audio
astearns: That would meet the perf goal, but I wonder
astearns: I get annoyed when I scroll Twitter just slightly enough,
but want to keep hearing it
TabAtkins: I have exactly opposite problem with Youtube videos open
in a tweet where they *don't* stop playing when I scroll
away
chrishtr: Could conceptually allow the video to continue, but mute
it, and get all the performance advantages
chrishtr: solve use case of pausing the videos some other way
florian: Conceptually playing doesn't mean actually playing, can just
move the timer and not do work
florian: but for use cases where authors do want to pause
florian: could send an event
florian: and then video can react to that state
florian: same thing could apply to animations, things applying to
canvas, etc.
florian: all things trying to be on the same timer
chrishtr: I think you're referring to an event where you can identify
when you are skipped?
chrishtr: Discussed on and off. There are use cases for it, like
avoiding work in scripts
chrishtr: A video, for example, inside cross-origin iframe could
pause when skipped
chrishtr: Similar use case from gmail, cross-origin iframes, would
like to be able to stop themselves when they are noticed
they are skipped
chrishtr: don't want to poll server to ask for more when not visible
Rossen: Appears we're drifting off the main task of pausing the video
Rossen: rather than aligning behavior with scrolling and animations
Rossen: user request we have as well, people want to pause video when
scrolling away
Rossen: At least the current described behavior for
content-visibility:hidden doesn't quite align with that
Rossen: so behavior that advances animations and advances stuff, are
we talking about a different behavior here
Rossen: A pause-media? could be helpful
Rossen: Allows two behaviors co-exist
Rossen: or have users control one or the other
Rossen: One moved ahead and other paused, etc.
Rossen: 2 different behaviors, let's discuss them separately
Rossen: Define what pausing looks like and then figure out how they
can co-exist
Rossen: They weren't asking for that
chrishtr: That's what person was asking for, however ...
astearns: Fits more with existing behavior of content-visibility, to
conceptually run it
astearns: So should do that
astearns: and then discuss use case of pausing
chrishtr: Talked to developer
chrishtr: Didn't want to keep playing video, audio is annoying
chrishtr: and also didn't want to take up bandwidth
chrishtr: Easiest way was to kill it off
chrishtr: I do think that performance and muting things won't solve
everything but will help
emilio: Other question is pausing, does it fire events, does it not
fire events
emilio: Media has a bunch of crazy things going on
fantasai: Should we resolve on the timer continuing while it's
actually paused?
astearns: Proposed to treat video similar to animations in
content-visibility, is conceptually muted, will return with
intervening time skipped
astearns: Any objections?
flackr: Don't object, but that's not identical to animations
flackr: not ticking animations is what user would have seen if
animation continued to tick
flackr: but muting audio is a bit different from ...
flackr: but given that content-visibility is a performance
optimization I'm not objecting
Rossen: With this behavior, are there any events?
chrishtr: No events will fire, it's not observable
chrishtr: Querying the element might trigger events or something,
kinda like animations
Rossen: So observability will be aligned with that of CSS animations
as well
chrishtr: Yes
chrishtr: observability to script same, observability to user a bit
different because muted
astearns: Note Twitter right now stops the video when scrolling out
of view
dholbert: Twitter version that matched Alan's expectation means they
can't use content-visibility?
dholbert: if want to still have audio play while off-screen
astearns: You just don't use content-visibility in that case
dholbert: Yes, but Twitter might want to use content-visibility ...
TabAtkins: The benefits of content-visibility are precisely that the
browser can stop committing resources to things, rather
than keeping videos around multiple times
<Rossen> content-visibility: hidden pause;
dholbert: I feel like I've heard from our media team that we already
stop streaming video in background tabs, there's
optimizations that can be made there
dholbert: maybe can do that here too
smfr: Websites like youtube and ??
smfr: are manipulating through script
smfr: If no notification to video that it's being paused, will still
run all that stuff
smfr: which is a waste
smfr: Are we resolving for skipped content (also affects
content-visibility:auto) or only content-visibility:hidden
chrishtr: Proposal is to apply to all skipped content
smfr: Are we trying to avoid detectability of when content becomes
skipped or unskipped?
chrishtr: The events that determine whether skipped, can also consider
chrishtr: Raised issue of ? video
chrishtr: or youtube video automatically pause themselves when they
notice that they are skipped
chrishtr: in order to raise the other use case in the discussion
fantasai: With regards to the idea that muting the audio isn't
entirely consistent
fantasai: it kinda is if the audio is part of the visibility of the
element
fantasai: which is true in an audio environment
fantasai: so don't think it's entirely inconsistent
fantasai: Not sure if this is the mechanism we want to use to allow
videos to be paused
fantasai: Might want to do it more explicitly, rather than building
it into this
fantasai: because depending on the use-case you might want it to
still play
<smfr> +1 for more explicit control. You don’t want Command-F to
start videos making noise
florian: The idea is reasonable, especially with event that allows
you to customize behavior
florian: maybe can then combine with API to pause an entire subtree
florian: but comment from smfr got me wondering, if you just think
about things being skipped or not being off-screen, whole
thing we discussed is reasonable
florian: but if things are unskipped
florian: Suppose you search for word 'play', then they all start
playing with video
florian: not a great user experience
florian: Can no longer be skipped due to things other than being
off-screen, maybe isn't great
flackr: If you scrolled something into view, would start playing
flackr: but because most search results off-screen
flackr: we'd resolve their style to figure out whether they match the
search, but they're still off-screen and will continue to be
skipped
chrishtr: Would be able to see the track time, but not playing
smfr: What if UA makes all content unskipped when finding in
content-visibility:auto
chrishtr: Spec says that [...]
chrishtr: it will only become unskipped when scrolled into view
smfr: per-element granularity?
chrishtr: Every element that becomes unskipped
smfr: Confused about the granularity of skipping
smfr: Suppose container with auto
smfr: inside it each element becomes skipped or not individually?
chrishtr: Granularity is content-visibility:auto element
astearns: This seems to be more generally, could you read through
spec and open an issue if it's a problem?
smfr: ok
<TabAtkins> (There's text in
https://drafts.csswg.org/css-contain-2/#using-cv-auto
with rough guidance about this exact issue.)
astearns: Back to media playback, any other comments before we try
for a resolution?
[silence]
<Rossen> Behavior of media is similar to that of animations inside
content-visibility:hidden
RESOLVED: Conceptually play (invisibly and muted) any media playback
for things that are skipped due to content-visibility,
skipping any events unless queried (as for animations)
<br duration=10m>
CSS Overflow
============
scribe: emilio
Should transformation affect the scroll direction of
touchpads/touchscreens?
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5733
fantasai: The question is what happens to various ways of scrolling
when you have a transform
fantasai: On firefox the wheel follows logical directions
fantasai: while touchpad uses physical directions
fantasai: Other UAs do different stuff
fantasai: This is not defined, do we want to specify this?
TabAtkins: Given the complexity of what transforms can do to an
element I doubt that we can provide strict rules
TabAtkins: but guidance sounds good
<fantasai> +1
TabAtkins: Flipping an element and scrolling with the trackpad should
probably scroll visually
smfr: I'd prefer not defining this strictly, we rely on UIKit and
doing something different is probably very hard
florian: If you manipulate a touchscreen there's a clear expectation,
but mousewheel is different. Should guidance for direct
manipulation sounds worth it but trackpads are harder
<chris> yeah users have two, conflicting, ways that touchpads and
mice should work and each user hates one of them
Rossen: Seems there's agreement to add guidance, would this go to
overflow?
florian: Yeah, we talking about a note?
Rossen: Yeah
florian: Fine by me
RESOLVED: Adding a note describing the behavior to the css-overflow
spec
scroll-index
------------
github: https://github.com/w3c/csswg-drafts/issues/5670
florian: Not my issue but I wanted to give it some attention
florian: The use case is something we see on lots of websites, with a
top banner that disappears but reappears if you scroll up
again
florian: This author is thinking of this in terms of nested scrollers
florian: where your top banner is in a scroller outside the inner one
florian: We always prioritize the inner scroller
florian: but the author was proposing to prioritize the outer
scroller, and only when that is exhausted scroll the inner
one
florian: No strong opinion, there could be some parallels with
overscroll-behavior
florian: just wanted to bring some attention to the issue
TabAtkins: I find the use case good to address because lots of sites
do this badly
TabAtkins: but I think this approach is not the way to go
TabAtkins: First, this doesn't do what lots of sites do which is
having a minified banner
TabAtkins: Second, it seems very easy to screw up a page if you only
test on desktop
TabAtkins: The current behavior is safer for that
TabAtkins: So I think the problem is good, the solution is bad
TabAtkins: We probably want another way to do this
flackr: I was going to point pretty much the same
flackr: You only want to do this scroll priority inversion for the
topmost scroller
flackr: If you have nested ones then scrolling the header is probably
not what the user intended
flackr: so it seems a bit of a problematic solution
<argyle> agree with robert and tab
Rossen: Sounds like the use case is well recognized, but the proposed
solution is not
Rossen: I suggest to go back to the issue to discuss the solution
florian: So the issue was proposing the solution, you're proposing to
repurpose it right?
Rossen: Sure
florian: Sounds good
Rossen: Yeah, it seems like we should explore a good solution for
this problem
Republishing Fonts 4/5
======================
github: https://github.com/w3c/csswg-drafts/issues/6462
chris: we discussed this already and have a resolution so I'm puzzled
astearns: it seems the tag didn't get taken off
Received on Monday, 16 August 2021 22:11:23 UTC