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

[CSSWG] Minutes Virtual F2F 2020-04-29 Part II: CSS Grid & CSS Contain, Generic Font Families [css-grid] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 12 May 2020 19:06:21 -0400
Message-ID: <CADhPm3uMumOZG8MtP+Vpqgo4EQJ7AKPg2m_k7RArcQ+qibmgPQ@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 Grid & CSS Contain
----------------------

  - A few items came up when discussing issue #4931 (Clarify that
      contain:size affects track sizing) that need to be worked
      through on github prior to reaching a resolution.
      - Given the discussion before on an @container rule, do we
          need to ignore sizing inputs like like grid-template-columns
          so that they can be safely altered on a size-contained box?
      - Contain spec may need to clarify that children are ignored
          (such that intrinsic tracks are not generated even, in grid
          layout) when calculating intrinsic sizing contributions, but
          are considered (and do therefore generate tracks) when doing
          layout within the box.

Generic Font Families
---------------------

  - The group reviewed the proposed definition of what criteria must
      be met for a generic font family (Issue #4910: Criteria for
      generic font families) as well as the broader question of what
      purpose are these generic font families serving.
      See notes in https://wiki.csswg.org/spec/css-fonts

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-one-time-slot-a

Scribe: myles

CSS Grid
========

Styling of grid gaps and gutters
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2748

  fantasai: I don't remember why I put this on the agenda.
  Rossen: I don't know.
  fantasai: <shakes head>
  Rossen: It wasn't that long ago
  fantasai: I don't remember this at all

CSS Grid & CSS Contain
======================

Clarify that contain:size affects track sizing
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4931

  florian: Mats Palmgren and I were having a long discussion about
           what the spec currently means. We are coming down to
           agreeing what's desired, but not what the actual words in
           the spec say. contain:size says that when you try to figure
           out the size of an element or its intrinsic size, you treat
           it as if it has no descendants, then you do layout. He was
           wondering does this mean, you do track sizing of grid with
           or without descendants?
  florian: AFAIAC, track sizing for layout, it's not intrinsic sizing.
           If you have no children, then you have no implicit tracks,
           then you look at explicit tracks, then you know the grid,
           and you lay out.
  florian: But if there is intrinsic sizing of the tracks, should this
           be canceled out?
  florian: Earlier, number of tracks is not described as being sizing
  florian: The conclusion is that no, you don't create implicit tracks
           for the grid, because that would change the size of the
           grid. But when you do a layout, you calculate the track
           size property. We are now agreeing now. But we are
           disagreeing on whether the words in the spec say that.
  florian: If your track sizes have a fixed min number of pixels, then
           you incorporate it, and do a full layout.

  oriol: Currently in chromium, the contents are taken into account.
         They are placed in the grid and they can create implicit
         tracks.
  oriol: This defeats the point of having size containment, since now
         the size of the grid container can depend on contents. But
         the dependency is not on the size of the contents, but
         instead their computed style.
  oriol: But instead this would be style containment... but I'm fine
         with what florian is proposing.
  florian: Size-containment means your own size is unaffected by your
           children. Not that your children's sizes are contained.
  florian: To achieve that, we need children not to create implicit
           tracks.
  <AmeliaBR> Size containment is supposed to prevent intrinsic sizing
             from affecting parent/siblings. So shouldn't affect
             internal grid layout beyond the size of the box.
  <fantasai> +1 to AmeliaBR's description

  iank: I agree with that model. However, we may want to consider
        changing what size containment means, given container queries
        we just discussed. Currently, your grid template columns will
        affect the inline size of your element. In dbaron's proposal,
        if you have a container query and it can affect some subset of
        properties, grid-template-columns can't do that with this def.
  iank: There are only 2 layout modes that are special here: grid and
        multicol.
  iank: So we could change size containment to act more like block and
        flexbox, and ignore grid-template-columns. This means that
        containment queries, if you can style a certain amount of
        properties, grid-template can be one of these properties
  dbaron: I think we're a few steps away from determining whether this
          is a possibility at all. But it sounds reasonable. Not sure
          we're ready to make decisions based on it, but also not sure
          we want to foreclose it.
  iank: I worry if we don't consider this soon, we'll start closing
        off opportunities.
  iank: This might be a better way to write the spec and avoid this
        whole problem.

  florian: I think this is compatible with the goals. If we do get the
           ability to do container queries, that could make this
           restriction worth it. Later, we might also want a stricter
           kind of containment, if that's valuable
  iank: I would push back against that. Having one grid+multicol ...
        people understand what size containment does. It matches that
        mental model. I don't think we should add unnecessary
        complexity there.
  florian: Thinking through this, if you have a grid that is a
           block-level child of whatever's around it, it will be sized
           with width, and everything is fine. But if its intrinsic
           size ... [missed]

  AmeliaBR: There seems to be a bit of confusion of whether the issue
            is about which properties affect the calculated size that
            you're containing to, vs once you've contained that size
            which features are you restricting. Do these two
            necessarily have to be the same? Are we allowed to look at
            the column properties and figure out they determine a
            minimum size, and say "okay that's the size we're
            containing to we can figure out just by looking properties
            on this element, no need to look at children"
  AmeliaBR: But then in another case, the column properties might be
            auto, or otherwise based on intrinsic size of the child
            contents, and so in that case the size that would be
            contained would be dependent on other properties on the
            element we're containing. When we go to lay out the grid
            inside that element, can we still lay out that grid based
            on the children and if the results from laying out the
            grid is larger than the container size, then we get
            scrollbars
  florian: The spec say you have to do that. That's what I was trying
           to say when I wrote it. Mats disagrees that's what it says.
           Perhaps either TabAtkins or I should rewrite it to make
           sure it says that. But maybe if container queries happen,
           this will need updating
  florian: Notice that this is further along on the req track than
           grid is, so maybe this text should be done in grid instead.

  fantasai: I agree with florian. This is the most straightforward way
            to define it.
  fantasai: Even if we weren't tracking these specs process-wise. It
            could be called out in contain.
  florian: There's a note already.
  fantasai: Yes. iank's point about wanting grid-template-columns to
            be changeable is a good one, but if we're not doing that,
            then if the idea that it doesn't create intrinsic tracks
            [even during layout] is unworkable--we have to put them
            in tracks somehow, we can't put them all on top of each
            other just because the container has size containment
  florian: There are two phases. 1. size 2. lay out. For the first
           phase, pretend it has no children, don't consider implicit
           tracks but do consider explicit ones. 2nd phase: Of course
           we consider implicit tracks.

  fantasai: Proposal: Clarify the contain spec about ignoring children
            when doing intrinsic sizing, but don't ignore for layout
  <fremy> (+1 to proposal)
  fantasai: And open a second issue about whether grid should have
            grid-template-columns be ignored for intrinsic sizing, and
            put it in the grid spec
  iank: It should go in the containment spec. The min- and max-content
        size is affected.
  florian: For multicol as well?
  iank: Potentially. Columns won't affect intrinsic size of multicol.
  florian: What if you say columns: 3 300 column-gap: 300, what's the
           benefit of [missed]
  iank: Inside the container query, you can change the size of the
        contents, but you can't change the number of children
  iank: This is a strictly better if we get container queries. Now is
        the right time to do it.
  Rossen: I see support in IRC by fremy

  florian: This will also be a change in form controls, which are
           weird and not completely replaced elements, and are not 0
           when they are empty
  florian: I ran into a bug about this. Dropdowns with no children are
           big enough to not only have the arrow but also have some
           space where its contents would be
  Rossen: What is the summary?
  florian: Proposal: Replace what we have in .1 of size containment,
           where it says [reads]
  florian: And to say that all elements are .... no. we don't want 0.
           we still want to fill available width.
  florian: If you're a block and you're size contained, you're
           supposed to fill your container
  iank: I agree it should be potentially an exception for replaced
        elements and non-replaced elements

  <fantasai> Kinda discussing 'contain: size' vs 'contain: children',
             seems like...
  <fantasai> ... where 'contain: size' treats min-content and
             max-content sizes as `contain-intrinsic-size`, and
             'contain: children' pretends there's no children for
             purpose of intrinsic sizes...

  Rossen: Let's take these one by one
  Rossen: For the contain spec, we are going to add a clarification of
          ignoring children for intrinsic sizing purposes and not
          layout
  florian: We're either going to tweak the wording editorially, or
           we're changing that min-content and max-content width and
           height are 0
  dbaron: I'm nervous about addressing min-content and max-content
          only without also saying what the effects on layout are.
          Size containment affects both of them.
  florian: There is no effect on layout.
  dbaron: I think there is from one layout model to another. That's
          correct for grid, but I don't think every layout model lays
          out that way. For example, block does in one dimension but
          not the other
  AmeliaBR: How about "for the purposes of determining size,
            min-content and max-content are 0, but they go back to
            normal when laying out children?"
  dbaron: I'm trying to think through it again.
  dbaron: Don't wait on me.
  Rossen: It's valid to not resolve on this if we're not ...
  florian: We've uncovered something new and significant. There is a
           benefit to simplify the definition for the purpose of
           container queries, then we can go back to github to see
           what it would be.
  Rossen: It would be great to consider more than grid in here. Would
          this ever be possible in tables?
  florian: Size containment does not apply to various table parts
  iank: Table size containment is broken in many browsers

  Rossen: Let's end here.
  Rossen: florian, you have lots of feedback here to put into the
          issue. Let's continue making forward progress there. Feel
          free to open the grid-related issue if we need to go that
          way.
  Rossen: That's everything for this one. Thank you!

Generic Font Families
=====================
  github: https://github.com/w3c/csswg-drafts/issues/4910

  chris: Myles started a wiki for criteria for new generic fonts
  <astearns> https://wiki.csswg.org/spec/css-fonts
  [Archived at https://lists.w3.org/Archives/Public/www-archive/2020May/0000.html
]
  chris: I changed that to "what are generic fonts *for*"
  chris: Started in a very different, Latin-centric CSS1 world
  chris: Where we didn't know what fonts were available, etc
  chris: Need to revisit
  chris: Bunch of issues about generic fonts, but until we decide what
         they're for, we can't progress
  chris: One answer is we take an axe to them
  chris: Another is "for writing system X you need to distinguish
         between 3 things, generics only do 1, we need more" so we end
         up with bunches of generics
  chris: Fine with either solution, but we need to decide and not get
         a mix

  <leaverou> Not sure if this issue is appropriate, but it would be
             good to have generic font families that are subcategories
             of the current ones, e.g. rounded-sans, slab-serif, etc.

  r12a: So chris outlined two possible routes.
  r12a: There's a third option from Kida-san - "it's so hard to
        predict what fonts would exist on someone's machine, I'd
        prefer to use generic fonts all the time"
  r12a: So the third option is to deprecate non-generic local fonts
        entirely

  r12a: Currently the generics are very Western-centric, and people
        can't decide whether they're about style or substance.
  r12a: I think generics could be about allowing people in various
        different writing system to ensure they get a particular type
        of font, which can be important for different things - like
        how we use italics for emphasis, they might use a different
        typeface style.

  r12a: Other situations where if you're writing content in Kashmiri
        or Urdu, and it falls back to a plain Naskh font, you lose
        the cultural signifier, and it becomes hard for Kashmiri/etc
        to even read it.
  r12a: So if a font doesn't exist on the system you, want to go back
        to a particular type of font, not a random one.
  r12a: Big concern is that people could think up zillions of
        different types of fonts.
  r12a: I see a gap for i18n [internationalization].

  r12a: For just a few things, not a huge number
  r12a: The things I listed in the thread are pretty fundamental to
        users of those scripts
  <xfq> r12a's list ->
https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-619342561

  myles: I'm sympathetic to Kida's argument
  myles: Scrapping all generics seems like the wrong direction
  myles: Content blockers commonly disallow all webfonts
  myles: So it would be cool for sites without webfonts to still have
         some control
  myles: So let's not delete the entire generic feature
  chris: Fair

  chris: Another thing that hasn't come up yet is, to what extent is
         this mapping from the browser, vs. from the user?
  myles: Let's say we gathered this evidence, what would that inform?
  chris: If the browser, we need a registry saying what types of fonts
         map to each generic.
  chris: Otherwise we just describe what they do, and the user chooses.
  chris: But most users don't customize, so I'd be wary of that
         solution.
  <xfq> Should we start a registry for additional generic fonts? ->
        https://github.com/w3c/csswg-drafts/issues/4566
  myles: Right, the spec right now has some examples and descriptions.
  myles: I think that's sufficient, and we don't need a registry of
         specific fonts.

  fantasai: I think Richard's point about fonts used for
            differentiation, similar to Latin use of italics, is a
            really important point.
  fantasai: We need to solve that problem for all the writing systems
            that need it.
  fantasai: Whether through generics or other mechanism, there just
            needs to be controls for that kind of differentiation.
  <chris> good point that this could be done by new font-style values
  <xfq> to be pedantic, latin italics is controlled by a different CSS
        property
  fantasai: Myles' point in his wiki draft, that it needs to be
            something that there are at least two fonts that do it,
            seems like a base level of requirement [but doesn't
            describe the goal]
  fantasai: For the concern about cultural identity between different
            linguistic groups, I think that should just be the browser
            taking language into account when it maps generic fonts.
  fantasai: I don't think we need to add generic font families for
            every cultural variation, the lang attribute can handle
            it. That might reduce the number of generics.
  fantasai: So we mainly need to hit where a document uses the same
            type of text in two or more styles.

  myles: When you have a single element with two different langs, and
         you style it with a single generic...
  myles: If we want generics to have a meaning across langs, they need
         to be similar
  myles: So like 'sans-serif' with an Arabic character inside, it
         would need to have a reasonable "sans-serif-ish" font for
         Arabic
  myles: So it makes sense to overload the term and use it for various
         writing systems.
  myles: But in Richard's list, I don't see much overlap.
  myles: So don't think we can come up with one token that works
         across those writing systems.
  fantasai: I think you're addressing a different point.

  <fantasai> https://wiki.csswg.org/spec/css-fonts
  fantasai: I think the stuff that Myles wrote is two good tests; I'd
            shift the second one to not just be pre-installed, but
            include "commonly installed", to handle language packs.
  fantasai: Otherwise I'd say that's a good test.
  fantasai: But we also need goals for new ones. One we should
            consider is where a single doc needs to differentiate
            between two kinds of text.

  myles: About the pre-installed vs not, the reason I picked that term
         is that it's clearly testable.
  myles: You can point to an OS that has it.
  myles: The vaguer it gets, the harder it is to test.
  myles: Hopefully we can come up with a more general term that's
         still testable.
  <chris> +1 to testability
  <fantasai> Like, what does "preinstalled" mean for a Mongolian user
             on Linux? It needs to handle common configurations of
             operating systems, not just pre-installed.

  dbaron: We've had some discussion about "does the user choose" vs
          "does the browser choose"
  dbaron: In a rough approximation, users don't configure their
          browsers, so we shouldn't depend on that.
  dbaron: Third option though is that the font designer chooses.
  dbaron: It would take a longer amount of time to make the feature
          work well, but I think it's something we should think about.
  dbaron: Something we could design towards in the long run even if it
          doesn't work in the short run.
  dbaron: "Browser chooses" has more power on some systems, where the
          browser vs OS has more control over installed fonts.
  dbaron: On Mac you can make stronger assumptions than on Linux or
          Android

  dbaron: On a different topic, another question about generics is, is
          it meaningful to fall back past a generic?
  dbaron: In CSS2 it was not meaningful to fall back past serif, etc,
          because there wasn't anything else.
  dbaron: But we could think of generics as covering part of the
          character space, that could still trigger fallback.
  chris: We did change to allow that
  myles: We changed it to match browsers in fact; the names are just
         aliases, so fallback can happen normally.
  myles: I think that makes sense with my earlier point about the
         proposed new names not being generic.
  myles: Best way to handle writing-system-specific names is to allow
         the browser to fall past sans-serif and hit nastaliq, etc.
  florian: Same with say "nastaliq" on Japanese.
  chris: We can close a lot of issues of "how to match X on Y" with
         "it doesn't"
  <faceless2> +1 to allowing fallthrough, solves lots of problems.

  stantonm: Use-case of ebooks too.
  stantonm: Licensing structure for shipping fonts on ebooks is...
            hard. Often charge per copy, cost prohibitive.
  stantonm: So a lot of people want to use generics.
  stantonm: That way they can get around these licensing issues but
            still have interesting styles in their books.

  r12a: I'm not so sure I agree with fantasai where she says identity
        isn't that important, I think it's very important.
  r12a: I think it's equally important to the other things she
        mentioned, matching content to the right font.
  r12a: I'm generally dealing with the long tail of the web, watching
        languages struggling to get onto the web because we haven't
        catered to them.
  r12a: Many of those, requiring two fonts could be problematic,
        because they might only have one font for a while, or at least
        only one good one..
  r12a: So that could prevent these languages from being equal
        partners on the web.
  r12a: So in the thread I was playing with the idea of users making
        the assignment of installed fonts to generic names.
  r12a: I take the point that users don't mess with prefs much
  r12a: But if you're in northern Nigeria, and everyone around you use
        a kano style of Arabic, you're quite motived to get your
        browser to produce that type of font
  r12a: So I think we shouldn't deny users the ability to make that
        association.
  fantasai: I'm not saying it isn't something we should address, I'm
            saying it should be automatic when you choose a generic
            font, by taking notice of the lang of the document.
  fantasai: So if you have a writing system with two variants,
            language A and language B, if the doc says it's in
            Language B you should get an appropriate style.
  fantasai: Shouldn't require the author to specify a new keyword,
            should be built into the way generics behave generally.
  r12a: My concern is that people developing browsers don't understand
        the reqs to make that work.
  fantasai: Agree, so I agree that users should be able to configure;
            I just don't think that's a reason for new generic names.
  r12a: Also note that shoehorning some of these into the existing
        generics doesn't work, too many differentiations and they
        don't map well to serif vs sans-serif anyway.
  <AmeliaBR> +1 to using names that are actually relevant to the
             writing system

  atsushi: Calling from i18n wg and jlreq
  atsushi: So for CJK fonts, quite a drudge to make it available via
           webfonts, particularly since they can be many megabytes in
           size
  atsushi: Similar generic fonts already in OSes
  atsushi: So defining generics for CJK could help webdevs a lot.
  atsushi: And also for epub, it's widely used in Japanese publishing
           industry. Additional generic fonts beyond serif/sans-serif
           would help a lot for Japanese book publishers.

  florian: I don't have a strong view as to *how* to address the
           identity question, but agree it's very important
  florian: Easy example for Latin speakers - what if the system fell
           back to Fraktur when the fallback failed? That's what
           people are living with in other languages.

  florian: So about "what if there's only one font"? In that case you
           can use it by name.
  florian: And when there are multiples, we can come up with a generic
           name as needed.
  florian: So we could come up with an at-rule that lets authors
           specify a font that can get overridden by UAs later
  myles: That's just a @font-face with a local() source, right?
  florian: Hm, if there's no real parsing differences, maybe
  fantasai: What about blocking local fonts? Then it wouldn't work
  myles: Still discussing balance of privacy vs minority fonts, yeah

  florian: Also, letting fonts decide which category they go in - what
           if it matches multiple categories? Which do you pick?

  faceless2: I think the list Myles came up with to restrict choices,
             requiring 2 versions etc, it strikes me that if we make
             the cost of adding generics much cheaper (like 3rd party
             registry), a lot of these restrictions wouldn't need to
             be there
  faceless2: I'm a big fan of the counter-styles registry, for example
  faceless2: Wondering about the interaction there
  faceless2: myles, you said you were against a registry
  myles: No registry can cover every OS/browser combo.
  faceless2: Sure, but interested groups could maintain that.
  myles: OSes change yearly, who's gonna maintain that?
  florian: I think this is effectively happening decentralized now -
           if I want the right font in Japanese, blogs say "if you
           want to handle these version of Windows, Mac, Linux, here's
           the big font stack to use in your stylesheet"
  dbaron: If we do something like "Window 10 has a new Japanese font
          we want to use for serif", changing Firefox to do that is
          sometimes involved, there's webcompat issues, etc.
  dbaron: So maintaining that set of stuff is part of maintaining a
          browser, it's not just "we can change that and everything's
          fine"

  <r12a> for clarity: I was talking about a registry for generic
         names, but not for assigning fonts to those generic names

  myles: Quick mention - atsushi mentioned CJK fonts in particular can
         be big
  myles: WebFonts WG is currently in the middle of investigating
         options for streamable fonts, so the browser only downloads
         the glyphs it actually needs from a font file.
  myles: Some early exploration suggests this is orders-of-magnitude
         speedup.
  <faceless2> @myles actually we've implemented the ability to
              download parts of fonts already - it's a variation on a
              loading technique used for PDF. Doesn't work for WOFF2
              but for regular OpenType it does. No proper figures on
              performance but I can look into this
  <r12a> (there are also pages like this https://r12a.github.io/scripts/phrases
          that would involve downloading LOTS of fonts to display)

  chris: I think we still haven't really solved what generics are for,
         but we're some ways toward that. I think we can continue in
         the issue. Shouldn't close the other generic issues until we
         work out an overarching strategy
Received on Tuesday, 12 May 2020 23:07:04 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 12 May 2020 23:07:05 UTC