W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-24 Part IV: CSS Inline, CSS Sizing, CSS Fonts [css-inline] [css-sizing] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Feb 2020 19:52:59 -0500
Message-ID: <CADhPm3uJhyVm1pTKCv=1iF2=s2xMJzgjL0wiRRP4hRE88qrb-Q@mail.gmail.com>
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
  - 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)


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
  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
  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
  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
  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
  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

  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
  <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

  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
  TabAtkins: If dbaron wants, sure
  dbaron: Not sure we need to right now
  TabAtkins: OK, we mostly wanted to see whether these concepts were

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
  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
  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
  TabAtkins: So it usually hits the cache faster and if so... that's
  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
  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
  myles: I don't think any of those changes require any changes to any
  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
  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
  <fantasai> You don't want to make the user wait more than a brief,
             mostly-unnoticeable moment in the case of font-display:
  <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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:15 UTC