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

[CSSWG] Minutes Virtual F2F 2020-05-07 Part I: CSS Align, CSS Fonts, CSS Font Loading [css-align-3], [css-fonts] [css-font-loading-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 16 May 2020 06:41:10 -0400
Message-ID: <CADhPm3uRGcuGtMe4+j_j52j++onJmE5J5Ss2tmfyvzFjyv=b0w@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 Align 3

  - There are two potential solutions to issue #4957:
      1)  Abspos descendants are shifted by content alignment, so they
          maintain the same positioning relative to the alignment
      2) Abspos resolves its insets against the scrollable area,
          unmodified by the content-alignment properties.
  - The test case to understand the current behavior (option 2 above)
      is http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8069
      [note: scrolling/scrollbars aren't part of this discussion,
       just the initial view; there's lots of bugs on scrolling]
  - More thought needs to be done on what the expected behavior is for
      this case so discussion will continue on github.

  - dbaron will review the open issues with baseline alignment to see
      if it's possible to keep baseline alignment in level 3 (Issue
      #4660: Punt baseline-alignment to level 4). Since flexbox refers
      to baseline alignment it's preferable to leave it in level 3
      with undefined sections if that doesn't create future problems.
  - There's no use case listed in issue #4545 (Apply align-content to
      replaced elements) so a request for use cases will be added to
      the issue in order to determine if it's something worth putting
      effort into specifying.

CSS Fonts

  - Everyone agreed that "Rounded" was a good candidate for a generic
      font family (Issue #4605). However, given the conversations
      prior about deciding if there's a purpose for generic font
      families or if they're too prone to becoming a fingerprinting
      vector (see April 29 Part II), the group will hold on agreeing
      to add a new generic font family until they've decided the
      future of local font families.
  - RESOLVED: The first available font is the first available in the
              font-family list whose unicode-range includes the space
              character (Issue #4796: Reconsider the definition of
              "first available font")
  - RESOLVED: Issue #3691 (Suggest allowing a list of font-family
      values in @font-face) is easy syntactic sugar, but we don't see
      evidence of a need for it, so closing as no change.

CSS Font Loading

  - RESOLVED: Publish Updated WD of css-font-loading-3


Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-four-time-slot-3b

  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Dave Cramer, Hachette Livre
  Elika J. Etemad, Invited Expert
  Simon Fraser, Apple
  Javier Fernandez, Igalia
  Chris Harrelson, Google
  Daniel Holbert, Mozilla
  Dael Jackson, Invited Expert
  Brain Kardell, JS Foundation
  Jonathan Kew
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Myles Maxfield, Apple
  Theresa O'Connor, Apple
  Xidorn Quan, Mozilla
  Florian Rivoal, Invited Expert
  Devin Rousso, Apple
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: dael

CSS Align 3

Abspos in an end-aligned scroll container?
  github: https://github.com/w3c/csswg-drafts/issues/4957

  TabAtkins: While fantasai and I were doing the position re-write we
             found an inconsistency
  TabAtkins: 2 ways to resolve
  TabAtkins: When you do align-content: end, it aligns end of content
             with end of container. If container is scrollable don't
             don't want to do that, because can't scroll to the
             overflow (which is now on the start side of the
             container). Instead, we adjust scroll position for same
             visual effect.
  TabAtkins: If you flip overflow from auto to visible you should have
             content looking the same.
  TabAtkins: However abspos position themselves in a way that doesn't
             work well. If you say top:0 it's positioned against top
             edge of scrollable area. If you set align-content: end to
             start at bottom of scroll abspos is out of view. If you
             turn overflow back to visible abspos is now attached to
             top and in view. Different results.
  TabAtkins: Two ways to deal.
  TabAtkins: 1) say that's fine and overflow is slightly different
             positioning model. I think I prefer this.
  TabAtkins: 2) We do adjust how abspos is positioned when it's
             non-start alignment so abspos containing block is moved
             in the scroll container to allow to sit in same spot
             wrt content as when not scrollable
  TabAtkins: Requires some fixup but not too complicated. Another
             thing in there. Not sure authors expect. When they say
             abspos 'top:0' they expect top.

  <fantasai> https://www.w3.org/TR/2020/WD-css-align-3-20200421/#overflow-scroll-position
  <fantasai> whiteboard:
  <fantasai> ^ is what happens with in-flow content
  <fantasai> Now we're talking about interaction with abspos

  Rossen: Inner border box edge?
  TabAtkins: Scollable area edge when scrollable.
  Rossen: Top and left logical establish origin and you don't go past
  TabAtkins: Yes

  <dbaron> I think I understand the question here, and I don't yet
           have an opinion on which behavior seems better -- and given
           that I think it's preferable to go with the simpler one as
           Tab suggested. But it's possible thinking about it more
           would make me have a different intuition for what "should"

  fantasai: One key point is the origin of the scrollable overflow
            area is not necessarily the initial scroll position.
            Initial scroll position can depend on alignment. Separate
  Rossen: I'm unclear in your definition when they expect it to be
          aligned to top important to define what top means. If we
          allow abspos elements to redefine scrollable area as they
          extend past the origin in the negative before the start than
          your statement is circular
  TabAtkins: We're saying the opposite
  TabAtkins: In the thread there's 100px high scroll container and
             abspos with top:0 inset. 200px of content. If you set
             align-content: end, scroll container starts at bottom.
  TabAtkins: Right now abspos still connected to top of area so it's
             not visible. Attached to 0 position.
  TabAtkins: That means difference in render for visible and
             scrollable overflow. We try and avoid that with normal
  TabAtkins: Is that okay? For abspos position to jump depending on if
             visible or scrollable?
  TabAtkins: That vs where authors expect abspos to be. Does it push
             down to always be visible?

  iank: Concerned if this flipped on overflow status because webdev
        will change that to disable scroll for example. A bit
  TabAtkins: Not sure which you argue for in that case
  Rossen: My expectation is the behavior would be closer to how we
          handle static in-flow layout. Favor stable rather than
          jumping with the overflow toggle
  TabAtkins: You prefer we redefine abspos position to rely on
             alignment. So top:0 within align:end would be visible
             within the original scroll position
  iank: No, the other one.
  TabAtkins: It maintains stable position relative to static content
             but visually jumps based on if you flip overflow on/off
  iank: Yes. It's not jumping, just that the initial scroll position
        is set differently.
  TabAtkins: It's jumping visually. align-content:end and you have the
             abspos top:0 Either top of container or top of scrollable
             area. align-content:end top of the scrollable is above
  TabAtkins: Glad the answer wasn't obvious

  <fantasai> testcase -
  fantasai: I made a test case if you want to load the testcase and see
  fantasai: [shares testcase]
  fantasai: Blue double border is abspos and aqua box is in-flow.
            First two examples is typical flexbox where both origin
            and scroll are top left
  fantasai: In first example, same code as second, but it's not a
            scroll container. First has visible overflow, is all.
  fantasai: First and second have same layout inside the container.
  fantasai: First is abspos and an item and you can see they align.
  fantasai: Second is overflow auto. In otherwords we clip. Layout is
  fantasai: Third we have the flex-flow changed to be reversed in both
            axes so it overflows to top and the left. abspos doesn't
            care about flex-flow, stays to top left of block.
  iank: There's something slightly different in [missed]
  fantasai: This is about expectations
  fantasai: Rendering for first 3 is correct.
  iank: No vertical scroll in 2nd?
  fantasai: This is just layout and position. There's lots of bugs
            about scrollers. Let's not pay attention to them.
  fantasai: I can switch to overflow: hidden if you prefer.
  fantasai: 4th example is same code as 3rd but we applied hidden or
            auto. Ends up clipping around the behavior.
  fantasai: Question from TabAtkins is- is this what we should see or
            something different? Important to see aqua box is top and
            left in 3. We defined alignment to allow people to align
            to bottom. Don't want clip so you can't scroll to them.
            Goal of def is you should be able to scroll to upwards and
            leftwards to see content.
  fantasai: Description in spec to say you do the alignment... instead
            of align to bottom left you keep everything and change
            initial scroll position
  fantasai: Scroller in 4th should be able to scroll to the left and
            up. Question we have is for an abspos element depending on
            how we describe it: do we want to have it layout so that
            when you're in its initial scroll position it's in its
            described position? Or describe it so when you scroll to
            origin you get the describe position?

  iank: Clarification: How you're calculating the layout overflow...
        If you've got a scrollable overflow container. Calc layout
        overflow from right to left. Starts on right. But initial
        position is still 0.
  iank: With align-content:end are you assuming layout overflow calc
        starts from bottom or start at top and scroll to bottom?
  fantasai: That's what we're trying to figure out

  Rossen: Mental model when I implemented containing box edges defined
          by inner border box. That inner border box defines origin.
          You may or may not allow scrolling into the negative for
          purpose of accommodating alignment. Third case here
          illustrates using alignment you may create situations where
          overflow has to allow scroll to negative
  Rossen: Origin is always well defined and not redefined. Position
          always in respect to that box.
  Rossen: That makes both the layouts stable because adding or
          removing scrollbars doesn't change position of abspos
          elements. Always everyone has expected top/left is in
          respect to border box
  Rossen: Otherwise a little unstable
  fantasai: 2 renderings we're looking at for last case is what you're
            seeing in FF where you can scroll to see everything. One
            possibility is you see this initially and scroll in both
  Rossen: That's overflow not positioning
  fantasai: Other is the same rendering as the second case but initial
            scroll position is to bottom right. See bottom right
            corner but can scroll to everything.

  iank: Maybe different way to do align-content:end. Maybe in 3rd the
        aqua box should overlap and then when container is big enough
        the aqua box sticks
  fantasai: Distinction between safe and unsafe. You can request
            overflow to always bottom but that's not the default.

  Rossen: We've been at this for 25 minutes. I think we have 2
          choices. We can contain working on the issue or make a
          resolution here
  fantasai: I'm not sure. I can see that it's a nice invariant to be
            able to flip overflow on and off and have thing you see
            the same. I can also see authors surprised if they
            position top-left and it's not there, it's in the middle
            of the scrollable content.

  Rossen: How I'm reading conversation is top left is defined by
          origin established by inner border box of containing block.
          If it's overflow and has scrollbars in that case there might
          be additional mechanism that require scrollers to enable
          going negative but that's separate. Shouldn't redefine size
          for overflow
  TabAtkins: No one has mentioned scrolling negative
  Rossen: With the aqua box aligned bottom and right, it's overflowing
          to the negative of the origin of the dark containing block.
          Do we agree? Overflow is the negative in the inline and block
  TabAtkins: Aqua is inflow box? If that's unscrollable that's blink
  Rossen: Do we agree here aqua overflows in negative?
  TabAtkins: Nothing in spec makes it go negative
  fantasai: I think Rossen is talking about negative in respect of top
            and left of border box of scroll container. You're talking
            negative coordinates of scrollable area, which makes it
  fantasai: We all agree aqua box extends out to left and top of
            container just like ex 3. Impl not considering that as
            scrollable and that's a bug.

  iank: One thing good to clarify is...when blink does reverse we
        treat similar to a [missed] container so overflow starts in
        top right. reverse we start from bottom
  iank: That will influence decision
  dholbert: We intend to be same in Firefox
  iank: For row:reverse and column?
  dholbert: Yeah
  iank: The question is how do you want align-content to work. Start
        overflow from bottom and right and scroll position in initial
        or you start top left and scroll position is at end. That
        influences this decision

  Rossen: We're getting into the weeds. I suggest we continue in the
          issue and bring back for resolution
  Rossen: 2 clear choices that were well articulated. I'd encourage
          you to continue discussion there.

  TabAtkins: Last bit. Because one behavior falls out if we don't
             resolve on anything we're in effect choosing one.

  fantasai: Showing this whiteboard (
            that's around concept in spec. Wanted to make sure we
            didn't mix up scroll to bottom of scrollable vs making
            extra space you need.

Punt baseline-alignment to level 4
  github: https://github.com/w3c/csswg-drafts/issues/4660

  fantasai: We can punt. We had resolved to push baseline alignment
            out to L4. Looked into it and I think it's awkward and
  fantasai: Baseline keyword is part of initial flexbox keywords.
            Implemented across all browsers. Pushing I think is
            confusing to authors
  fantasai: A little uncomfortable with that resolution. I don't think
            we're that far from fixing remaining baseline issues. If
            we started from scratch sure, but since it's been in
            flexbox from the beginning hesitant to pull it out.

  Rossen: Opinions? Concerns?
  <astearns> would prefer to keep it in level 3
  fantasai: Main concern is there's some issues with definition of
            intrinsic sizing and sizing algorithms interacting with
            baseline alignment. Not sure how to deal. Not clear errors
            in spec. That's main thing we're stuck on.
  Rossen: I know of some issues that will be... or dependencies from
          grid. What other sizing algorithms affected?
  fantasai: Flex, grid, and tables
  fantasai: Not aware of significant concerns from implementors about
            implementability. That's the one thing we're stuck on.
            Everything else is fixable soonish so we can take whole L3
            to CR

  fantasai: Just my thoughts. That's why I haven't edited it in
  dbaron: Alternatives in space of keeping baseline alignment in but
          saying x is undefined
  fantasai: Not sure what should be undefined.
  dbaron: I'd need to dig in more.
  dbaron: Issue 1409 is about how baseline alignment changes intrinsic
          sizes. Example might be spec saying that it's undefined.
          Need to dig more to see if it makes sense
  fantasai: Would you be willing to take a look into what it would be
            acceptable for spec to say?
  dbaron: I can look
  Rossen: So we hold on pushing to L4 until then?
  fantasai: Yes, goal is dbaron to come back to something and we take
            it to CR

  ACTION: dbaron take a look at baseline alignment and how to keep it
          in L3 by undefining things

Apply align-content to replaced elements
  github: https://github.com/w3c/csswg-drafts/issues/4545

  TabAtkins: Mats wants the content alignment property to apply to
             replaced elements. It adds magical padding. Replaced
             elements can have padding on them. Easy theoretical model
             there's nothing wrong with having content alignment work.
  TabAtkins: Seems fine to me. We hadn't thought of it. Similar to
             object fit and position, but separable because this
             adjusts outside content box
  TabAtkins: I'm fine adding this in. Want to make sure; check
             temperature of group

  fantasai: Size of replaced element when not stretched?
  fantasai: In order to align something within something need size of
            container and thing being aligned. Know container. Size of
            thing being aligned what's the size?
  TabAtkins: intrinsic of content
  fantasai: Is that useful? What does it mean if something w/o
            intrinsic size
  TabAtkins: Stuff w/o intrinsic doesn't work. How useful, I don't
             know. Works in the model
  <tantek> does this actually enable any new use-cases that aren't
           already solved by object-fit etc.?
  fantasai: It's possible, but I don't know if it's useful. If not
            useful why do we spend time to define and test and
            implement. What new use cases does this enable? Gotta do
            something or not worth effort.
  <tantek> right if it's not useful (new use-cases, or great
           simplification of existing use-cases), we should not do it
  TabAtkins: Unless anyone has ideas perhaps push back until we get a
             use case. Looking over issue from Mats there isn't one
  <tantek> I'd leave the issue open to allow gathering of new use-cases
  <tantek> or ways to simplify existing use-cases. I trust mats had
           something in mind
  jensimmons: Wondering what reason was to file issue
  dholbert: Might be easier to have it work than add an exception

  Rossen: If we don't know the reasoning it's a fair ask to go back
          and see what he replies with.
  Rossen: If it's pure theory it's one thing but if there's actual use
          cases... grid is a common layout that's being used more and
          more with replaced content for various image and media
          presentation. Ideally he'll have an example
  Rossen: Let's continue in the issue.

CSS Fonts

Proposal for a new generic font family "Rounded"
  github: https://github.com/w3c/csswg-drafts/issues/4605

  Rossen: myles can you summarize?
  myles: Sure.
  myles: We got a bunch of font families, add a new one.
  myles: 2 reasons in the issue. First, we have ui-rounded already.
         Makes sense to add rounded font family
  myles: 2nd argument is it's common typographic style in Japan. If
         we've got serif/sans serif for the west this makes sense in
         Japanese context

  myles: Backing up to talk about what rounded is.
  myles: It's a typographic style where terminals of letters are
  <fantasai> http://www.identifont.com/similar?MZ
  <TabAtkins> Note particularly
              which talks about "rounded" having a simple consistent
              definition, and which is used as a typographic style
              across many languages.

  florian: ui-rounded not particularly Japanese, right?
  myles: Correct
  florian: My feeling is this interacts a bit with a thing the spec
           says is possible, but not done, which is map generic font
           families to a set of fonts
  florian: If you say rounded I would expect it in Japanese and Latin
           fonts, but what I think would happen is one or the other
  myles: Not sure I agree. ui-rounded is a UI style font. I don't
         think type of fonts here are for UI, but for other purposes
  fantasai: I think separately florian wants 'rounded' to reliably
            give rounded font, whether glyphs needed are Latin or
            Japanese, not give rounded for one and fall back to e.g.
            serif for the other.

  Rossen: I want to channel a question on the issue, do we expect
          different fonts between rounded and ui-rounded. I'm aware of
          some fonts for windows cjk that are way optimized for small
          and thinner to allow better fit for overall UI that's closer
          between different scripts. That's where ui-rounded and
          rounded will map differently.

  TabAtkins: Last week talked about larger issue about generics.
  TabAtkins: Rounded satisfies any reasonable constraints for
             generics. Sounds reasonable to me
  myles: One proposed criteria was 2 major OSs have built in rounded
         fonts. Is that true?
  AmeliaBR: I think at least arial rounded is on Windows. Might be MS
            office pack.
  Rossen: I'm not sure off the top of my head. Could get back to you.

  florian: I think this is a good idea. Support it. Might be a generic
           font family that's meaningful across multiple scripts.
           That's why I raised point that spec says you can map to
           sets of fonts. In this case you should. Spec I'm fine,
           hoping people will do what spec allows
  <fantasai> +1 to florian
  myles: I understand your point now
  fantasai: I support what florian said

  jfkthame: I just checked windows standard list and there's nothing
            rounded there. I guess that must come from office.
  myles: Are installations of office common enough that it should be
         considered built in?
  florian: Yes
  Rossen: No comment
  myles: Serious about the requirement, though. I think it's legit
         that 2 OSs should have it built in.
  fantasai: Clarify to say not necessarily built in, but a common
            config of OS
  myles: Yes
  florian: If you buy a computer and it's on it it counts
  fantasai: Windows with MS Office installed is very common.
            Installations will vary by region and language also

  Rossen: From PoV of addition to generic fonts I'm hearing this makes
          sense. Some questions about how this will be impl and actual
          behavior. Not sure we need to define this now.
  Rossen: Question here is does new generic rounded make sense to add
  myles: If it can't be demonstrated there are 2 common config with
         rounded fonts I think I would object

  <dbaron> My Windows 10 system does not have a font called "Arial
           Rounded", if that's what I'm supposed to be looking for...
  <Rossen> Arial Rounded is certainly part of Office fonts
  <TabAtkins> https://docs.microsoft.com/en-us/typography/font-list/arial-rounded-mt
              Confirmation that Arial Rounded is shipped with Office

  jfkthame: Hesitant adding any generic while we're hesitant what
            generic fonts are for.
  AmeliaBR: Agree with that. Whatever we think about rounded it's
            worth first discussing syntax and general overall design
            goals with CSS and what generic keywords mean
  AmeliaBR: No pressing demand to add right now so let's take time and
            do right
  jensimmons: Web front end dev use generics constantly, usually as a
              fallback font. Try and use something tightly controlled
              but generics are used as fallbacks constantly
  <TabAtkins> +1 to Jen
  <jensimmons> if "rounded" starts to mean something (if) — Authors
               will use it, gladly

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4605#issuecomment-619318179
  fantasai: Draw attention to Kida-san's comment^. They have been
            working on i18n and on jltf. Pointing out rounded is more
            significant in Japan and East Asia. Need to consider it.
            Also unlike other generics rounded is a style that exists
            across writing systems so makes sense in that way as well
  fantasai: He mentions both macOS and windows have those
  florian: You may want to look for maru which is Japanese for rounded
           if you're searching for default rounded fonts
  fantasai: Fonts in other writing systems it's likely to be much more
            common to find rounded. Shouldn't be biased to only
            consider if it's common in European installations.
  <jensimmons> +1 to that — need for international thinking

  Rossen: Are people convinced we should add this or not right now?
  florian: I think we should add this, but we haven't decided the
           syntax. We might want to wrap a new family in a function so
           might want to wait a bit
  myles: Rossen is right we don't need to decide on that. We can say
         we want a way to trigger a rounded font without deciding
  myles: I'm also willing to accept MS office as a common config so
         we've passed the criteria and typographically it's valuable
         so I'm on board
  fantasai: We draft spec and we mark issue so we can draft it and say
            we're not sure if it's compat yet.

  jfkthame: If we're going to add a generic based on a font from MS
            Office that might be in tension with work going on to
            reduce fingerprintability with fonts shipped by system
  myles: Two ideas on surface in tension but if goal is putting users
         in buckets and making sure none of small all users with MS
         Office is a pretty big bucket.
  <dbaron> Windows version * office version might be smaller buckets

  Rossen: We're at time for a break.
  fantasai: Should we resolve?
  AmeliaBR: On the general concept?
  fantasai: Yeah
  Rossen: Proposal: Add the ability to have rounded fonts and we
          decide on syntax later
  fantasai: Placeholder syntax and separate issue
  Rossen: Proposal: Add ability to expose and target rounded fonts.
          Syntax TBD

  dbaron: Little nervous about fingerprinting. May need to consider
          versions. Office by version is small buckets and office
          version + windows version is small.
  myles: Font is only from office it's not a matrix, just office
  dbaron: Windows version from other things
  dbaron: So we expose office version which might be a matrix against
          windows version
  florian: Broader, though. It's maybe all versions before 2008 vs
  Rossen: dbaron enough of a concern to hold off on resolution?
  dbaron: Given discussion about font fingerprinting I'd prefer to hold
  dbaron: To respond to florian fonts have revisions. They're not
          atomic and unchanging. Could have differences across versions
  florian: Yes. I would expect larger buckets than each version,

  myles: How do we make progress on this?
  AmeliaBR: Gets to issue of general purpose of generic fonts and how
            to move forward. If we add new generics rounded is
            logical. Security concerns are part of discussion about do
            we want more generics
  Rossen: We're going back into generic fonts topics. I want us to
          stop here. It's a fair point dbaron is raising to hold off.
          Sympathize with myles to find a way to progress.
  Rossen: Let's have additional conversations about if this can be
          unwedged by what the font metrics look like and are the
          buckets small enough to concern? If not we can resolve later.
  Rossen: Outside the fingerprint issue people are fine
  Rossen: We won't resolve for now.

  <br type=10min>

Reconsider the definition of "first available font"
  github: https://github.com/w3c/csswg-drafts/issues/4796

  AmeliaBR: fantasai's comment is resolution from a couple months ago
            was illogical so we should take it from there
  fantasai: We rescinded the resolution in the same session because we
            said it should be 0.5 em or a glyph, but a font is neither
            a length nor a glyph so it makes no sense. I think we start
            at the top.
  Rossen: What's the proposal?

  florian: It's okay if the first available font does not contain all
           glyphs. I think ch unit uses 0 glyph, ic uses a particular
           character. If the glyphs are missing the units can say I
           default to 1em or whatever. But we should still figure out
           what the first available font is.
  AmeliaBR: So one proposal is the first font in the font stack with
            any valid glyphs is your first available font?
  myles: That's what we do in WK. The first font is the primary font
         and if it doesn't support the characters we'll use another one
  florian: Problem in the spec is it says first font if it doesn't
           contain space it doesn't count.
  florian: One reason is common to put first font and reduce it via
           the unicode range. You're just using that font for & or
           something and want rest of the stack for the rest.
  florian: As jfkthame pointed out it's if the font contains. If the
           change to if the unicode range it's webcompat.
  dbaron: Suggestion in issue is change it to be if unicode-range
          matches the space and then it was added what to fallback to
          if there's not a glyph
  fantasai: Sounds like it's what we did before is for the value of ch,
            and then need to amend the algorithm for first available
            font to see if space is in its unicode-range
  florian: And for ch unit it already says that. It says in [reads]
  florian: Could be interpreted as if not in first available font.

  <fantasai> https://www.w3.org/TR/css-values-3/#ch
  <fantasai> "In the cases where it is impossible or impractical to
             determine the measure of the “0” glyph, it must be
             assumed to be 0.5em wide by 1em tall."
  <fantasai> "Equal to the used advance measure of the "0" (ZERO,
             U+0030) glyph found in the font used to render it."

  AmeliaBR: Can someone type up a resolution text for the proposal?
  <myles> Proposed Resolution: The first available font is the first
          font in the font-family list whose unicode-range supports
          the space glyph
  <dbaron> I think a more specific proposed resolution is to accept
           jfkthame's proposal at the end of

  dbaron: I don't quite understand what happened last time, though we
          did retract original resolution in that discussion
  florian: Because it made no sense. We said font becomes 0.5em which
           makes no sense.
  fantasai: I put in chat the text from Values. It says ch is the
            advance measure of the 0 in font used to render it. Which
            is not same as first available. So that's separate. Need
            to resolve what first available font is. If there's an
            issue with ch it's separate.
  fantasai: We should take proposal from myles and if there's an issue
            for definition of ch that's separate issue against values
            and units.
  AmeliaBR: On proposed resolution do we have concept in spec what
            unicode-range means for system and generic
  myles: Assumed to have definite range of every unicode-range
         character. Spec lists it out.

  florian: Another clarification. If the first font in stack doesn't
           have space we skip it. If it does do we look if it has the
  myles: We do not.
  Rossen: Thoughts or objections to "The first available font is the
          first font in the font-family list whose unicode character
          includes the space glyph"
  dbaron: There was wording in issue
  jfkthame: Should be talking about character not range

  RESOLVED: The first available font is the first available in the
            font-family list whose unicode-range includes the space

Suggest allowing a list of font-family values in @font-face
  github: https://github.com/w3c/csswg-drafts/issues/3691

  faceless2: I couldn't see a reason not to
  faceless2: It expands to multiple fontface blocks. Not sold on need
             for it, but struck me as a why not. I think Chris is
             trying to clear issues.
  myles: I think AmeliaBR brought up a problem with it.
  TabAtkins: Problem is same as if you do multiple font faces still.
             Possibly not what author intends, but well defined what
             would happen.
  TabAtkins: You can define multiple faces that are identical except
  myles: If 2 font face blocks, one with a one with a,b should they be
         combined together
  TabAtkins: Should be exactly as if a,b was to separate faces

  AmeliaBR: One related question is will this only apply to font
            family name or other descriptors
  faceless2: Only intended name. Easiest to leave at that
  AmeliaBR: I think the example of something like a black font which
            is sometimes referred to with black or as 900 weight
            generic is a good example
  AmeliaBR: Question for me if it's sensible syntax

  myles: Mike said it's a why not instead of use case. If this is
         valuable you would see authors having to duplicate and I
         don't see it on the Web.
  faceless2: That's there I got to as well
  AmeliaBR: Sounds like we lean no change?
  faceless2: If there's an argument against change for change sake
             that's it. Might be a localization argument to give fonts
             Japanese and English name. I'm not qualified for that.
  florian: This is just syntactic sugar for repeating
  fantasai: So unless we see that happening already, no good reason
            to change

  florian: Is there a css preprocessor that does it?
  faceless2: Not that I know of
  Rossen: Then let's hold now and come back if there's use cases
  myles: Let's close it.

  RESOLVED: Close no change, for lack of compelling need to change.

CSS Font Loading

Updated WD of css-font-loading-3

  Rossen: Any reason why not? Outstanding issues that need to be
          worked in?
  AmeliaBR: If it's just update WD and editor asked for it it's a +1
            from me.
  Rossen: That's how I read it. The draft has drifted from current ED
  AmeliaBR: We've got a list of changes
  TabAtkins: Yes, there is still a chunk of open issues but the draft
             as stands is worth publishing.
  <astearns> font-loading change list is incomplete, yes?
  TabAtkins: At minimum the current TR draft has a definition for
             promise interface and if nothing else I'd like to remove
  florian: Also we linked to it from the snapshot b/c progress

  RESOLVED: Publish updated WD of css-font-loading-3
Received on Saturday, 16 May 2020 10:41:59 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 16 May 2020 10:42:00 UTC