- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 18 Feb 2020 19:21:37 -0500
- 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.
=========================================
CSSOM View
----------
- RESOLVED: Over the border area, doesn't scroll the content area
(Issue #4680: How does scrolling relate to mouseWheel
event propagation?)
- RESOLVED: The scroll behavior propagates through the containing
block chain (Issue #4680)
- RESOLVED: Add these rules [above resolutions] to cssom-view, add
smfr as editor (Issue #4680)
- Note: None of these resolutions affect DOM event propagation.
CSS Motion
----------
- RESOLVED: Make an optional keyword with just the two values, and
default to even-odd or "lookup depending on context"
(Issue #3468)
- RESOLVED: All of the offset-path values allow a coordinate box,
treated the same as today's basic shape (FXTF Issue
#369: Definition of containing-box for ray())
- RESOLVED: Move Shane to former editors, add TabAtkins as a current
editor
CSS Fonts (Continued)
---------------------
- TabAtkins introduced the re-write of the 'optional' keyword for
font-display (Issue #4108: font-display: optional without
relayout). The goal for the re-write was to clarify spec text to
the end behavior is "make the user's experience smooth even if
they don't get pretty fonts".
- The new definition would prevent jank, but it allows
implementations to pause first load in order to try and get
resources. Since WebKit prioritizes first load, this would lead
to authors never getting their fonts when using 'optional'.
Several people believed this would lead to the keyword never
being used.
- Time ran out before consensus could be reached so discussion will
continue on GitHub.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Scribe: fantasai
Scribe's Scribe: heycam
CSSOM View
==========
How does scrolling relate to mouseWheel event propagation?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4680
smfr: Running into some issues with how nesting scrolling works, and
differences between browsers
[display fragments into weird pieces]
smfr: Example showing when the events are received
<bkardell> https://codepen.io/smfr/pen/RwNvVPj
<smfr> https://codepen.io/smfr/full/rQZqxo
smfr: First question is, if your pointer is over the border of the
element
smfr: and you initiate scrolling
smfr: do you scroll that element's overflow region?
smfr: In WebKit, yes
smfr: In Firefox, answer is yes
smfr: In Chrome, answer is no
smfr: My pointer over the border of the element, I scroll the main
page in Chrome
smfr: Difference #1
smfr: Other interesting thing about Chrome, notice the element is
still receiving wheel events
smfr: even though I'm not scrolling it
smfr: so disconnect between when an element receives scroll events
and when it actually gets scrolled
smfr: I think it's reasonable that browsers may have assumed that
users only want to scroll when the mouse is actually in the
content
<bkardell> what about :hover - does it work on the border?
<fantasai> bkardell, yes
smfr: Things also get interesting when you start nesting scrollers
smfr: Now, same thing, parent scroller here-
smfr: it has two descendant elements, but those elements are
absolutely-positioned, and the scroller is not their
containing block
smfr: When I scroll the left abspos, it's a DOM descendant of the
big scroller, and the big scroller receives wheel events
because of DOM propagation
smfr: but when I reach the end of the little scroller, the big
scroller does not scroll
smfr: in WebKit and Chrome
smfr: but in Firefox, the big scroller scrolls after I reach the end
of the little scroller
dbaron: That seems wrong to me
dbaron: I would expect it to scroll the ancestor only if ...
smfr: Seems that scroll propagation should follow containing block
containment
dbaron: I'm not sure
dbaron: If you have something with overflow: scroll
dbaron: I'll invent the term "containing block child", to describe
it more as a tree for this discussion
dbaron: An element with overflow:scroll might have containing block
children that move when it scrolls, and containing block
children that don't move when it scrolls?
dbaron: or do they all move when it scrolls?
smfr: I think they all move when it scrolls
fantasai: I think that's true since I don't know how you'd fix the
viewport to any scroll port other than that element's
dbaron: Concerned about sticky
dbaron: or abspos
dbaron: Maybe containing-block-ness is right
dbaron: I would expect scrolling to propagate the scrolling up to
the next thing that would cause the thing where your mouse
is to move
smfr: I think that makes sense
dbaron: This might be something Mats has an opinion about
emilio: Following regular box order is more similar to what the
events do
smfr: Problem with that is that it's easy to construct content where
you might mask scroll ... end up scrolling something unrelated
on the page just because it happens to be in the DOM parentage
dbaron: With DOM events you also have the ability to look at what
the event target is
fantasai: Do we want to resolve the question about borders first?
Seems simper.
smfr: Which do people prefer?
dbaron: I was surprised when you showed me what Firefox does
heycam: The border should move if I'm hovering over it and try to
scroll
iank: I think that's why we have this behavior
AmeliaBR: From the DOM perspective, seems reasonable that event
going to element should cause it to scroll
AmeliaBR: Maybe from user perspective preferred behavior is different
AmeliaBR: But if doing it that way, maybe give script some
affordances to figure out what's happening
AmeliaBR: because right now would have to evaluate the coords
against layout and stuff
AmeliaBR: I think it's weird to have the default behavior that we
cannot recreate with script, if you want to do something
else in response to wheel events
iank: Subtracting borders from the rectangle, lots of libraries for
these types of calculations
fantasai: I don't think it's that weird from a user perspective for
it to scroll
fantasai: For a similar reason, if hovering over the scrollbar, it
scrolled
fantasai: the scrollbar doesn't move
fantasai: The thumb does but the scrollbar itself doesn't
fantasai: I'm not convinced from a user perspective it's that
terrible for the element's contents to scroll when hovered
over the border
smfr: If you were interacting through touch rather than pointer
would you have the same opinion
smfr: with touch users have an expectation that the thing under the
finger moves
smfr: I think it's less obvious then that you want to scroll the
content rather than everything else
fantasai: It's less obvious, but unless the border was absolutely
huge, I probably wouldn't be surprised or notice
astearns: Not hearing much consensus
smfr: I would prefer you only scroll over the scrollable part of the
content, within the padding box
astearns: I think it's a little weird to scroll when your cursor is
over the right border, which is outside the scrollbar
itself, but top / left / bottom seems fine to me. So I'm
mixed.
iank: From our perspective, I don't have full back story, but I'm
guessing that someone did this for a good reason at some point
smfr: I think you inherited it from WebKit
iank: We've changed a lot of stuff in this area
astearns: Thought webkit does scroll over the border area and Blink
does not
iank: Right, I expect somebody intentionally made the change
smfr: Not sure we need to resolve now, but one thing I would like
maybe to resolve on is that there isn't a simple relationship
between an element receiving a wheel event and scrolling
happening in that element
smfr: both because of the border issue and also the containing block
issue
astearns: We could resolve on that, but then without the
particulars, not sure what use that resolution is
smfr: Maybe that's not something to resolve on, but something to use
as basis for future discussions
iank: Sounded like smfr you preferred our behavior?
iank: Sounded like dbaron and heycam, you also did?
heycam: I think so. I don't feel super strongly about it
astearns: OK, then let's try to resolve that when the cursor is over
the border area, mousewheel events will not scroll the
content area. Anyone object?
fantasai: I don't feel strongly about it
RESOLVED: Over the border area, doesn't scroll the content area
astearns: Second part
astearns: has the border case and also the content area case
iank: ...
smfr: I've seen some odd behaviors where sometimes scrolling over
the border of an abspos child causes its parent that's not in
the containing block chain to scroll....
bkardell: Should any child, if you're on the border, you're
technically inside
bkardell: You're on the border, does it scroll the parent?
iank: I can try and rationalize what potentially happens
iank: Wheel events get delivered even when the element isn't
scrolling, to the element directly under the pointer, and they
bubble up
iank: You can create applications which don't necessarily scroll,
but they do intercept wheel events
iank: Following that logic, makes sense to still deliver wheel
events on the border box
smfr: I think so
smfr: Nothing I've said is about propagating wheel events. They
should follow normal DOM propagation and hit-testing rules
iank: So your concern is mainly around abspos
smfr: My concern was that when user interaction with mouse wheel
events triggers scrolling, disassociated with DOM wheel
events, and different between browsers
smfr: Would like it to be more specified
smfr: User interface aspect of when/how scrolls propagate, somewhat
independent of event propagation
iank: So concern is where the actual scroll propagates to and when
smfr: I think there's nothing to change about how wheel events
change, nothing to do there.
astearns: So proposed resolution would be that actual scrolling
behavior only propagates through the DOM tree if the
pointer is over the content area of the scroller, is that
correct?
<AmeliaBR> astearns version makes the most sense to me. The event
propagates, but the scroll container checks the mouse
position before actually scrolling or propagating further.
smfr: I think it has to be described in terms of containing block
smfr: Assuming dbaron considers gecko behavior a bug, with ... once
you reach the end of the ...
smfr: One thing that does not happen, you don't do a deep hit test,
and find some ancestor because it happens to be under the
mouse cursor, but covered by something else
smfr: You find the most descendant scroller, then ancestors scroll
depending on whether in the ancestor containing block chain
smfr: For example, my testcase has the righthand element, which is
not scrollable
smfr: If my mouse is over this half of it, scrolling will scroll the
page.
<AmeliaBR> But what happens if the element that gets the event
*isn't* a decedent of the scroller that is behind it…
...
smfr: webkit has bugs because some parts uses containing block
chain, and some parts uses DOM ancestry, and when they don't
match you get bugs
astearns: Summarize proposed resolution?
smfr: Scroll propagation between nested overflow: scroll propagates
through containing block chain
<fantasai> https://www.w3.org/TR/css-display-3/#containing-block-chain
iank: Potential nasties
iank: Scrolling the left box, and cursor for brief amount of time is
over the big scroller
iank: and we currently don't scroll that, if that makes sense
smfr: Talking about latching, decide which element is scrolling at
the beginning
smfr: Not scrolling other things even though mouse has moved
smfr: Next gesture, choose the thing to scroll again
iank: Right
smfr: So that's another thing that's completely unspecified, and
maybe there should be some words in the spec about it
astearns: So proposed resolution is that scroll behavior propagates
through the containing block chain
iank: I think that's fine, I think that's what our current impl does
astearns: Concerns from other implementers?
astearns: Alright, now objections? Anyone want to object?
RESOLVED: Scroll behavior propagates through the containing block
chain
ACTION smfr File open issue against latching behavior
-> https://github.com/w3c/csswg-drafts/issues/4696
smfr: Does this go into cssom-view or what?
heycam: Seems like most relevant spec
emilio: Maybe css-overflow?
fantasai: overflow doesn't do anything with events. cssom view has
some scrolling stuff, some scroll apis
fantasai: don't know what extent it really fits in with either, but
would go with CSSOM since it's talking about DOM stuff
astearns: OK, we'll put in cssom-view. Which doesn't have an editor.
astearns: smfr can I add you as editor?
RESOLVED: Add these rules to cssom-view, add smfr as editor
heycam: Another question, which element's pointer-events values do
we look at to decide if it's going to scroll or not?
heycam: especially wrt looking at ancestors to see what to scroll
smfr: I think we evaluate pointer-events when we do the hit testing,
so only when finding the element to scroll
smfr: unsure about abspos and stuff
astearns: Good question, maybe open an issue?
* heycam nods
astearns: Anything more on scrolling today?
smfr: That's all I have
astearns: Thanks for calling in
astearns: Let's go through Motion issues, because we have Amelia on
the line
CSS Motion
==========
Scribe: myles
Decide on final approach for merging all uses of shapes
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3468
AmeliaBR: For the various properties that use shape(), some only
care about the outline of the shape. Others care about the
actual fill area of the shape
AmeliaBR: So for motion-path, you only care about the outline, but
for clip-path, you care about which parts are inside and
outside. This is an issue when you have polygons or paths
with criss-crossing lines and inside/outside isn't so clear
AmeliaBR: Enter fill-rule. even-odd and nonzero.
AmeliaBR: It was originally defined as polygon(keyword, ...)
AmeliaBR: path() was defined in motion-path, and didn't include the
keyword
AmeliaBR: Things get complicated with <path> because this had 2
separate properties for the fill rule. Filling vs what's
the effect when it's in a clip-path.
AmeliaBR: How do we deal with this conflict between having a keyword
as part of the shape function vs having a separate
property which doesn't make sense for <clipPath>?
AmeliaBR: I came up with a couple options. The one that seemed to
have people most support is that the keyword within the
shape function includes "auto" as the default, and the
default would look up the other SVG properties. But if you
set the value otherwise, it would override the old SVG
properties and we maybe eventually deprecate the SVG
properties.
AmeliaBR: If you specify a fill-rule keyword in motion-path, it's
ignored, but that's not a problem. The only place where
it's a problem with <shape> where it gets filled. We're
specifying where if you set a fill rule in the function,
it overrules the fill-rule property.
AmeliaBR: The default behavior is defined in all other cases to
match the current behavior.
heycam: I like that. I'm not sure we need an explicit "auto" as
opposed to just its absence.
TabAtkins: We do, for ... some case. There is a case related to
<path>
TabAtkins: If path() takes a keyword, where the winding rule is
determined by context, you need to be able to say "go
grab from the other property explicitly"
heycam: This is a component of one value, and it's optional, can we
just use its optionality?
<fantasai> +1 to heycam
AmeliaBR: So the auto behavior is the "no keyword specified" behavior
TabAtkins: That would work. It just runs into my dislike of having
omitted values being unwritable
heycam: There are a lot of properties that have optional keywords
fantasai: <lists them>
TabAtkins: Most of them are booleans, but when more than one value -
I get tetchy
TabAtkins: I won't fight it
AmeliaBR: The benefit of heycam's approach is that shipping for
shapes in clip-path and shape-outside, we don't need to
change anything, because the change would only come in
paths where the author behavior is different from the
current default behavior
heycam: Are there other elements other than <path> where we might
want to have a default value that's not "go and look at the
fill-rule property"?
AmeliaBR: All the other cases the default value will be to just use
one of the existing keywords.
TabAtkins: even-odd is the default
heycam: There's no value in adding an explicit auto keyword to say
"look at the fill-rule property" for these other cases?
TabAtkins: Those other cases don't have a property.
AmeliaBR: It wouldn't make sense to have a div with both a clip-path
and a shape-outside and also set a fill-rule in another
property. That would be confusing
TabAtkins: There's only the two things that have the information
defined by another property, and there isn't a use case
to have arbitrary things rely on those two, it's just due
to SVG's existing behavior to rely on those two
TabAtkins: and that's it.
astearns: The proposed resolution is to make this an optional
keyword with just the two values, and default to even-odd
or lookup depending on context
AmeliaBR: Within the context of it then, not specifying the keyword
would the the SVG legacy behavior. Specifying the keyword
behavior would mean "ignore the fill-rule and clip-rule
properties and use this value"
astearns: Any objections?
RESOLVED: Make an optional keyword with just the two values, and
default to even-odd or "lookup depending on context"
Definition of containing-box for ray()
--------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/369
TabAtkins: There's not actually a definition of what containing box
to use for ray(). It just says "the containing box" and
that's not a term. It doesn't mean any thing. So what's
the box? So we know how long the ray is. Where the 100%
point is. There's a few possibilities
TabAtkins: We could just choose one. Maybe the containing block of
the abspos. Or we can alter the grammar of the property a
bit to have its containing box specified like how shape()
does
TabAtkins: If we did so, we would be referring to the box of the
parent element, not the box of the element being
motion-pathed
chris: I prefer the second one
TabAtkins: Me too
AmeliaBR: Would this also affect other ways of defining the path? So
the path shape would also be repositioned to be relative
to the containing block instead of relative to the initial
position of the element that you're actually moving?
TabAtkins: Yes. That's what ewilligers is suggesting. URLs, rays,
and paths also gain the ability to have an optional box
AmeliaBR: Is this a breaking change?
TabAtkins: Shapes already have this, that's part of the grammar. For
paths, we can choose the default appropriately so paths
don't change behavior. Whatever value that is, ray()
should work the same way. IDR which value that is.
AmeliaBR: How does that apply to SVG if we're going up to the parent
element
AmeliaBR: Are we going to the literal parent element like <g>? Or
relative to the view box?
heycam: Does this come back to the previous discussion about the box
keyword that we moved into a different spec?
TabAtkins: We've already altered this spec for using the box keyword
heycam: So that should define how this works for SVG
AmeliaBR: It might not be the most intuitive if the parent is <g>
then the fill-box of that group might be a bit weird. But
if we define it early before there's too much content
using these properties ...
heycam: Was ray() added for rounded display?
TabAtkins: Yes
heycam: If we have control over what box, then that satisfies that
use case?
TabAtkins: I believe so.
astearns: Do we have a way forward here?
heycam: It feels slightly overkill having these keywords everywhere,
but it's okay.
TabAtkins: My own objection to that is that they're all the same,
shapes and paths and rays are all the same. I would like
CSS to do it consistently right from the start
heycam: If you can specify the box in some, then it should be all...
<fantasai> +1
TabAtkins: Yeah.
astearns: Proposed resolution: All of the offset-path values allow a
coordinate box, treated the same as today's basic shape (
which I know is under-defined)
astearns: It is well-defined, it's just in a weird part of the spec,
I will fix
RESOLVED: All of the offset-path values allow a coordinate box,
treated the same as today's basic shape
TabAtkins: shane is no longer part of CSSWG, can I replace him as an
editor?
astearns: Will you actually be able to spend time on it?
TabAtkins: I'd like to fix it up. I can spend more than 0 time.
astearns: okay
RESOLVED: Move Shane to former editors, add TabAtkins as a current
editor
CSS Fonts (Continued)
=====================
Scribe: fantasai
font-display: optional without relayout
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4108
TabAtkins: When I originally drafted the font-display values, the
last one, optional, I intended to be as much as possible
"make the user's experience smooth even if they don't get
pretty fonts"
TabAtkins: Wasn't super clear in the spec, and implementers came up
with answers that don't satisfy that goal
TabAtkins: Within first 100ms or less, still creates a layout jump
TabAtkins: Jake was running into the same problem
TabAtkins: wanted smooth page display without any layout jank, and
wasn't getting it
TabAtkins: I believe the current text addresses it, perhaps with an
extra comment
TabAtkins: Would like some discussion from y'all
<TabAtkins> https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-display-optional
TabAtkins: My text atm, if font can be loaded "immediately", can be
used, otherwise ignore it
TabAtkins: can't be used for the rest of the page's lifetime.
Refresh page, can try again
TabAtkins: Paired with some additional info
TabAtkins: MUST NOT cause the layout of the page to jump
TabAtkins: allowed to delay initial rendering if needed to load the
font
TabAtkins: Specifically, we have some issues wrt how to do in
Chrome, can put more detail in the spec
TabAtkins: Anyone have comments on details?
TabAtkins: If in memory cache for tab, use the font. Otherwise we go
to disk, takes too long, skip it
TabAtkins: Once loaded, may or may not be present for future
navigation depending on cache state
TabAtkins: Cannot depend on font ever being there
TabAtkins: Want to make sure that all font pre-loads bring the font
into the memcache
TabAtkins: track which fonts are there
TabAtkins: When preloaded font is optional, delay loading to give
time to get off disk -- or extremely fast network
TabAtkins: otherwise, don't delay
TabAtkins: If you don't do anything special on your page, just say
font is optional
TabAtkins: Almost guaranteed to not have font on first page load
TabAtkins: Chance of available on future page loads, but not
guaranteed, e.g. if on device with small memory
TabAtkins: If it's a preloaded font, then very likely to be load on
future navigations because we will delay rendering to
load into memory cache
TabAtkins: because preloading is a hint that something is important
enough to kick of load asap
TabAtkins: That seems to satisfy the use cases for optional that we
want to hit
TabAtkins: allowing people to have completely jank-free
font-optional experience
TabAtkins: Try your best to use it, but prioritize no jank
heycam: Not sure how much is normative vs heuristics
heycam: but seems a bit weird to me that you have two different
behaviors wrt disk cache
heycam: Without preloaded fonts, disk cache is deemed too slow, but
link rel=preload it's ok?
TabAtkins: Not so much it's too slow, but don't want to incur cost
of delaying rendering unless indication that it's
important to you
heycam: Is this because checking whether the font is in the disk
cache is also slow? is it the checking, not the loading?
TabAtkins: In our implementation, memcache check is fast enough to
be synchronous, whereas disk cache is async, we kick off
without loading
heycam: Disk cache can be very fast when it's not too big
TabAtkins: Definitely cool to keep things vague enough that UAs can
adjust
TabAtkins: but want preload to cause delay
heycam: Other thing I was going to say is I'm not really a big fan
of optional
myles: I have a lot to say so split into pieces
myles: Firstly, want to make sure it's clear that WebKit will never
ever defer first load. So that has to be not a case. That's
our philosophy
myles: Can you be super clear about which, you listed like 3 main
pieces-
myles: one is deleted number 100ms and replaced with words,
myles: one is never cause layout jank,
myles: last one was about preloading,
myles: which are normative
TabAtkins: First two are normative, in the spec
TabAtkins: Third one I would like to put in the spec
myles: The spec shouldn't use words mem cache and disk cache, those
are impl details
myles: Still not guaranteed to get the font even if preload
myles: there's nothing testable here
myles: So I think this should be evangelism, not in a spec
myles: "for our browser, you will get better results if you preload"
TabAtkins: Talking to internal customers who want no jank on initial
load
TabAtkins: if they don't get it, and instead block loading page,
that's a worse user experience
TabAtkins: so having some reasonable assurance of similar behavior
among browsers would be worthwhile
TabAtkins: Ultimately stochastic, can't depend on it, but difference
between 80% and 10%
myles: Are your internal customers only considering Chrome, or also
other browsers?
[unminuted]
myles: Other piece I want to mention, dbaron brought up a super
valuable point
myles: I think it supports what heycam said as is last sentence
dbaron: One of my concerns with this is that a lot of stuff around
downloadable fonts is designed to deal with the possibility
that you have a pretty large number of faces for various
reasons
dbaron: You might have fonts segmented by character range, multiple
weights 4-6 of them, a lot of the mechanisms around
downloadable fonts were designed to load lazily
dbaron: Define a library, fetch the ones you need
dbaron: so some of this pre-loading stuff...
dbaron: there are cases where you just use one font
dbaron: Those cases probably bias towards symbol font hacks, and
text that is all Latin
dbaron: and maybe things are more complicated in non-Latin
languages, or things that use more weights and stuff like
that
dbaron: One of my big concerns about font-display is that it is
per-face
dbaron: can have situation where your regular font cached and bold
font isn't
dbaron: and using downloadable font permanently for regular weight
and local font for bold might be worse than all of the other
cases (including flashing, or fallback for all the fonts)
TabAtkins: Those can still totally happen is the font load just
doesn't occur
dbaron: If you have network failures can happen
myles: Optional makes it more likely that it fails
fremy: As an author, at this point, with current proposal for
optional, I would be very unlikely to use it. Because more
likely to not get your font than to get it
fremy: Why bother?
fremy: Only if user keeps using your site regularly, not going to be
in memory
fremy: not unless constantly in use
myles: No, it's valuable for web sites while you're navigating
through multiple pages on the site
TabAtkins: Won't work on single-page app, don't use it in one
fremy: You're extremely unlikely to get the font, then why bother?
You are going to download the font anyway.
TabAtkins: Your case is a single-page app that gets closed and
reopened every day
TabAtkins: preload signal intention is that, if it's still in your
disk cache, it will likely get used the 2nd day and
subsequent days, because giving it enough time for that
fremy: Safari said they don't want to block rendering
myles: Internal clients care that usage gets up to 80%, but we're
absolutely not going to block rendering
myles: That's not going to work in Safari
TabAtkins: Assuming ppl aren't using optional, then comfortable with
janky 2 frames and then stable layout
myles: I'm OK with if you've shown the page with fallback font then
never show the page with loaded fonts
TabAtkins: ...
TabAtkins: If it's likely that optional will never give them
assurance to see font, then they'll use JS to delay
rendering manually
TabAtkins: or will use one of the values that will cause jank anyway
myles: This is an intractable problem. We can't never delay
rendering and have the disk cache be able to serve these
requests
myles: Given that these customers will never get what they're aiming
for, I don't think that the association with preloading makes
sense
TabAtkins: Want to check understanding
TabAtkins: Website authors using fallback, getting a couple frames
in one font and then frames in other font, it's better
than getting a few frames of nothing and then getting the
page?
AmeliaBR: I've heard a lot of confusion of what's the purpose of
this value
AmeliaBR: Tab said the goal was to avoid jank
AmeliaBR: If that's the goal then maybe other smarter ways this can
happen, like waiting until doing a major repaint anyway
and then block in the font
AmeliaBR: catches the single-page app update situation
AmeliaBR: but I don't know if that's the best
AmeliaBR: As a user, the idea of downloading fonts but then not
using them unless I happen to close the page and re-open
it before it gets lost from the cache, that's not a great
use of my data plan
TabAtkins: UA is allowed to skip downloading if it thinks that's
reasonable in the circumstances, and metered data is
definitely such a circumstance.
astearns: Done for today
Received on Wednesday, 19 February 2020 00:22:23 UTC