- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Feb 2020 19:52:59 -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.
=========================================
CSS Inline
----------
- RESOLVED: leading-trim doesn't change the overflow state of
anything sticking out of the linebox (Issue #4010: Is
overflow created by `leading-trim` ink-overflow or
scroll-overflow?)
- In discussing issue #3956 (leading-trim and descendant inlines)
the idea was raised to simplify further by trimming all the
inlines in the first line, and then do the linebox layout from
there (rather then trimming the linebox). dbaron and/or fantasai
will spend time fleshing this idea into a proposal.
CSS Sizing
----------
- RESOLVED: Add a property called contain-intrinsic-size (Issue
#4531: intrinsic-size)
CSS Fonts
---------
- RESOLVED: Change normative text for font-display: optional to say
that the font should never change rendering of the page
if it would you'd still just treat the load as failed
and don't use it again (Issue #4108: font-display:
optional without relayout)
- RESOLVED: Add notes for implementors and authors to the spec,
specific contents TBD (Issue #4108)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Scribe: TabAtkins
CSS Inline
==========
Is overflow created by `leading-trim` ink-overflow or scroll-overflow?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4010
koji: leading-trim trims upper or lower half of linebox
koji: Is the area it overflows considered ink or scrollable?
koji: No strong opinion from me
myles: Would it be overflow at all? Wouldn't it just make the box
shorter?
florian: It makes the box smaller. But the content of the box might
stick out of that.
florian: So is that poking ink or scrollable?
myles: So that's not the stuff that's got trimmed.
florian: Right. The box got smaller, so theoretically it might
slightly overflow.
astearns: No wrap differences, it's just the stuff sticking out.
TabAtkins: If you write in Zapfino, that's just ink overflow, right?
myles: Yes, it is. We're in agreement.
myles: fantasai says "overflow is whatever it would have been",
that's unchanged. I agree with that.
florian: Ah yes, I misread.
astearns: So no change, do we need a clarification?
koji: We might want to clarify that it's ink overflow, then.
florian: Rather, things that today would be ink when they stick out,
stay ink. Things that would be scrollable, stay scrollable.
leading-trim doesn't change that.
astearns: Objections?
RESOLVED: leading-trim doesn't change the overflow state of anything
sticking out of the linebox
leading-trim and descendant inlines
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3956
myles: The definition right now says "when you got your root box,
look at the primary font's metrics, subtract some stuff from
the top or bottom"
myles: But if there are children in the box, that might be the wrong
value. There might be a span with a larger font size, that's
now sticking out.
myles: One way to solve it is look at all the descendants and find a
good value.
myles: I think my feelings about this are obvious.
[The feelings were not obvious; he doesn't like that idea]
florian: So one is do the simple, based on root; another is to look
at all descendants and use the tallest one.
myles: Could be different evidence
myles: Issue was originally phrased to sound like fantasai was just
thinking thru it
myles: Rather than real complaints.
myles: That makes me less inclined to solve this with elaborate
solution.
myles: Next is that, for the use-cases it was designed for, was
simple flowing text in paras. Those don't need this.
myles: Finally, the "safe" thing sounds hard and slow to spec
dbaron: One thought I had that might work is that what you trim is
pieces of inlines.
dbaron: If leading-trim is set to trim stuff, you trim all the
inlines in the first line, and then do the linebox layout
from there.
florian: You trim the linebox itself tho.
dbaron: Right, I'm asking, why not do it this way? Rather than a
fancy calculation about the linebox, it's a simple
calculation about each inline's contribution to the linebox.
dbaron: In the simple case it works the same, but it produces
something pretty logical in more interesting cases.
myles: I think that's similar to line-height on an inline; linebox
amalgamates those
dbaron: It's not quite similar; you still set it on the block, but
you trim on each inline
myles: I think that's a mistake to repeat that model
florian: The line isn't just sized by the stuff inside; an empty
line still gets trimmed
dbaron: Right, that's the root inline box, which can get trimmed.
dbaron: I'm not as convinced as myles that that model is a mistake
dbaron: I think it makes sense in the world of CSS where the person
writing stuff doesn't know how the content will render:
wrapping, fonts, etc.
dbaron: The model we have is better at dealing with unknowns.
dbaron: That said, it could have been looking at different pieces of
data.
dbaron: The idea that that's how we apply *line-height*
specifically, probably broken.
dbaron: But the idea that we look at what's in the line
individually, that seems fine.
* fantasai is fascinated by dbaron's train of thought
jfkthame: dbaron's idea would handle superscript and subscripts for
free
myles: Not for free, you still need to iterate things
florian: Do we want to try and sketch out dbaron's proposal, and
rethink once we have it in detail and some time to think?
jfkthame: Would be interesting to consider.
<fantasai> +1
jfkthame: I'm not even sure if taking superscripts into account is
desirable.
dbaron: Partly this is veering into a separate discussion about
wanting a better line-height calculation.
dbaron: Had a lot of discussion about that
dbaron: Building a better model, tho, is separate from leading-trim
faceless: If goal is nice presentation text, not inconceivable you
might be using baseline-shift to mess with position around
the line.
<fantasai> One consideration could be to split leading-trim into
"what I want to trim to" and "whether I am trimming this
line", and could use the former metric as a way of
measuring whether something leaks outside the root
inline's leading boundaries
<fantasai> It would probably also cascade a little more
conveniently, as one usually wants to think about which
metric once, but whether to trim per element
astearns: So should we leave the discussion there, and action dbaron
to flesh out the proposal?
dbaron: You could, tho someone else might get to it faster.
dbaron: I'll bug fantasai about it if she could do it first
astearns: So let's do that
CSS Sizing
==========
Scribe: emilio
intrinsic-size
--------------
github: https://github.com/w3c/csswg-drafts/issues/4531
chrishtr: In December we discussed and concluded that if we couldn't
find other use cases we should add a property specific to
the size-contained case
chrishtr: Since then dbaron has come up with some use-cases related
to scrolling
chrishtr: so now the question is what to do with this information
chrishtr: Whether adding two separate properties (which I'd
recommend), or just one
dbaron: I would've preferred one property, but if you found a decent
name for the contain-specific one I'm ok with two
astearns: What's the name of that?
chrishtr: contain-intrinsic-size, credit to fantasai
TabAtkins: none or two lengths
<fantasai> If there are two properties, what's the interaction?
<fantasai> should be a shorthand for the various sizing longhands
TabAtkins: re. interaction: This only interacts if the element is
size-contained
<fantasai> right, but that could happen
TabAtkins: So I think the most consistent behavior would be that the
contain-specific one wins, as contain: size already
prevents a lot of other sizing-related calculations
<fantasai> it doesn't prevent 'width' and 'height' from doing things
<fantasai> so I'm not convinced about that
astearns: fantasai also asked about it being a shorthand for the
sizing props
<fantasai> e.g. contain-intrinsic-width
TabAtkins: Definitely disagree with it being a shorthand
<TabAtkins> specifically, since our use-cases want the "general" to
do things like cause scrollbars, which is similar to it
having a big child, and contain:size already ignores
children, I think it's most consistent to have
contain:size cause that to be ignored.
<smfr> do we need contain-intrinsic-aspect-ratio too?
<fantasai> smfr, no
<fantasai> smfr, aspect-ratio already exists, why would we need
contain-intrinsic-aspect-ratio?
dbaron: Do we also want logical versions?
TabAtkins: I guess so, we'd all all of them
chrishtr: What happens if you only specify one of them? The current
proposal doesn't allow that
Rossen: Auto?
TabAtkins: There's no auto
<fantasai> chrishtr, same in that dimension as if you didn't specify
the property?
TabAtkins: Given we need 4 longhands and such, can we skip it for
now and see if it's necessary later?
chrishtr: I don't see downsides with that
<fantasai> as long as the shorthand is consistent with the size
shorthand ...
<fantasai> which we still don't have
TabAtkins: We have good behavior turning something into a longhand
later into a shorthand
<fantasai> There's also an issue around what order the values go in,
if there are two of them
<TabAtkins> fantasai, yes, I imagine it'll be consistent.
<fantasai> @page { size: width height; } is currently the order there
<TabAtkins> fantasai: and yes indeed, we'll discuss which order to
put the things in
<fantasai> which puts us inconsistent with grid shorthand and
alignment ...
<fantasai> which is a mess, because we didn't listen to Brad Kemper
astearns: issues, concerns?
RESOLVED: Add a property called contain-intrinsic-size
TabAtkins: We should try to decide the order between the values
TabAtkins: I think we should do block/inline
<fantasai> I think we should do width/height
<fantasai> because all of our shorthands are physical
<fantasai> because 'size' is already physical in paged media
<fantasai> and it's width/height
<fantasai> and physical shorthands with two axes are width/height
<fantasai> not height/width
emilio: I think I agree with fantasai
TabAtkins: We're going to be inconsistent with some amount of
properties regardless
TabAtkins: because we have examples of both
<fantasai> Not really
<fantasai> Everything with physical longhands is consistent
<fantasai> everything that doesn't is consistent
<fantasai> the two sets are inconsistent
<fantasai> and size has physical longhands
<fantasai> so it goes in the first category
TabAtkins: We can defer this to the next meeting and discuss in the
issue with now
emilio: Should we discuss now the other use cases that dbaron
brought?
TabAtkins: If dbaron wants, sure
dbaron: Not sure we need to right now
TabAtkins: OK, we mostly wanted to see whether these concepts were
separable
CSS Fonts
=========
font-display: optional without relayout
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4108
TabAtkins: I think we probably have a plan even if WebKit disagrees
with this
TabAtkins: I don't think we will get into a deadlock
TabAtkins: As I said, the main goal of optional was to avoid layout
shift
TabAtkins: Layout shift is really annoying and font-display:
optional aims to solve that
TabAtkins: Another is performance
TabAtkins: Turns out that our data is that our the extra style and
layout that the font load triggers delays stable layout
significantly
TabAtkins: and if you waited one or two frames you'd just get the
final layout faster than if you did everything eagerly
TabAtkins: and getting reasonable assurance about getting local
fonts or downloaded fonts getting caches in getting the
details of this right
TabAtkins: and interesting quirk I found yesterday, some of our
internal teams are using font-display: optional on iOS
because caches there are usually faster than most android
phone
TabAtkins: So it usually hits the cache faster and if so... that's
great
myles: I see your strategy :P
TabAtkins: Proposal is that for preloaded fonts, as soon as you see
the preload tag, or as soon as you see the font-face rule
that would refer to them, pull them be into the memory
cache
TabAtkins: For normal pages you should be able to get all the fonts
you're using
TabAtkins: When you start loading, if any of the loads triggered not
from the cache, you're allowed to delay rendering before
starting your first layout
TabAtkins: and if you can't (too slow / whatever), then you discard
the load and never use them again for the lifetime of the
page
myles: I don't think any of those changes require any changes to any
spec
myles: the distinction between memory / disk cache is not something
that should be on any spec
myles: and if you use fuzzy words I don't think they would mean
anything
myles: specs doesn't forbid Chrome to delay rendering
myles: so it's untestable, doesn't need to be in any spec, I'd be ok
with no change
TabAtkins: I don't think I disagree with you, but it'd be good to
hint to other implementations about how you can achieve a
high quality implementation for this feature
myles: Yeah that's good, but shouldn't be normative
TabAtkins: Ok, compromise proposal: We remove normative text about
delaying rendering or what not, and we only state that
optional fonts must not cause layout jank
TabAtkins: and then provide notes to implementations
chrishtr: I think the spec must be clear that it's acceptable to
delay rendering rather to do partial rendering
TabAtkins: Yeah I'll put that in
myles: In the notes
TabAtkins: In the notes
myles: You can totally describe the intended use case in the spec
chrishtr: Right now our implementation of font-display: optional can
cause two layouts. I don't think it should
TabAtkins: Yeah that's the normative text described above means
TabAtkins: well as long as pixels don't move you're fine
myles: I think that's an important distinction
myles: if you want you can do layout every frame
chrishtr: Agreed
fremy: When you have sheets in a document you never render before
they load right?
TabAtkins: If you see them early enough or such
fremy: What I want to say is that there is a precedent for this
TabAtkins: Proposed text is to change normative text for
font-display optional to say that the font should never
change rendering of the page
TabAtkins: If it would you'd still just treat the load as failed and
don't use it again
fremy: I don't really understand what's the difference between the
font-face behavior and the stylesheet behavior
emilio: The main difference is that for stylesheets you statically
know it applies, but to determine the fonts you need is that
you need to do layout and styling
chrishtr: I think the main proposal to web devs is to add a <link
rel=preload> for important fonts and then use the
font-display: optional to avoid the jank
<fantasai> I think it's important to distinguish this from the block
behavior
<fantasai> You don't want to make the user wait more than a brief,
mostly-unnoticeable moment in the case of font-display:
optional
<fantasai> otherwise it's not really "optional"
<TabAtkins> fantasai, oh yes it's distinguished already; i'm just
gonna remove a bit of semi-normative text
<fantasai> ok
astearns: Objections to the proposed resolution?
RESOLVED: Change normative text for font-display: optional to say
that the font should never change rendering of the page if
it would you'd still just treat the load as failed and
don't use it again
jfkthame: The phrasing about the suggestion about <link rel=preload>
about an important font seems a bit off to me
jfkthame: because tagging it as font-display: optional means that it
is _not_ an important font
TabAtkins: You'd get the desired thing most of the time assuming a
high-quality implementation
astearns: There are a couple more assumptions there, like fast
network, fast disk, no contention...
chrishtr: We could probably add the <link rel=preload> bit separate
from font-display: optional
RESOLVED: Add notes for implementors and authors to the spec,
specific contents TBD
<meeting: end>
Received on Thursday, 20 February 2020 00:53:44 UTC