W3C home > Mailing lists > Public > www-style@w3.org > August 2019

[CSSWG] Minutes Telecon 2019-08-28 [css-fonts] [css-sizing] [css-text] [css-grid] [media-queires]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 28 Aug 2019 19:05:37 -0400
Message-ID: <CADhPm3usUudeZ=E3gz7qE3g9aWnKqbGSbm9FGDxsW5cdCyUdPQ@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 Fonts

  - The group continued discussing the proposal to add
      system-ui-serif, system-ui-monospaced, and system-ui-rounded
      (Issue #4107).
  - The main focus was if there is a valid use case to support these
      new values instead of having Apple expose these as named fonts.
      - The primary use case is for web apps where they want it to
          look as native as possible including using the same fonts as
          the system uses.
      - There was disagreement in the group as to if this is really
          useful since not all systems have fonts that map to these
          three values.
  - If this proposal is accepted, the group also discussed how to
      handle fallbacks. The two options are to fallback to a regular
      system font or to allow these values to be a part of a font
      family so authors can control the fallback.
  - Discussion will continue on github to try and reach a consensus.

CSS Text/CSS Sizing

  - Issue #3440 (When to/not to include preserved trailing spaces) has
      clearly defined proposals and PRs and anyone with an interest
      was requested to review them and weigh in on github.

CSS Grid/CSS Sizing

  - Having sizing available for aspect-ratio only boxes (Issue #4228:
      aspect-ratio-only boxes should be able to size to grid
      container) was a desired behavior.
  - However there were concerns about this adding significant
      complexity to the layout algorithm for implementors, especially
      when there are nested grids or when subgrid is introduced.
  - Comments on github are welcomed, especially from implementors of
      layout to see how large of a concern the algorithm changes

Media Queries/CSS Sizing

  - The group's direction was to not simplify values when aspect-ratio
      is <number>/<number> (Issue #3757: Support <number> (and
      therefore calc) as a <ratio>). There wasn't time to discuss
      other problematic cases (such as negative numbers and 0 in the
      denominator) so discussion will continue on github.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0011.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Henricus Cabanier
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Thierry Michel
  Anton Prowse
  François Remy
  Devin Rousso
  Florian Rivoal
  Christopher Schmitt
  Jen Simmons
  Alan Stearns
  Lea Verou

  Tab Atkins
  Christian Biesinger
  Chris Harrelson

Scribe: dael

CSS Fonts

system-ui-serif, system-ui-monospaced, and system-ui-rounded
  github: https://github.com/w3c/csswg-drafts/issues/4107

  myles: We started talking about this last call
  myles: Refresh memories: 3 new system fonts in macOS and iOS.
         Question in last call if we add a keyword and platform
         doesn't have this what happens
  myles: Because this is designed to be used in system UI having a
         fallback to match system UI would be best way for it to work.
         Proposal is if you're on a platform that doesn't support
         requested font, the font is rendered as system-ui rather then
         system-ui-serif or whatever is requested. Proposal and open
         to change
  myles: Other thing from last week is which platforms support these.
         macOS and iOS support all 3. Android has serif and mono.
         Windows has sego-script which I think is a good match for
  myles: Love to hear thoughts.

  AmeliaBR: Good point on issue discussion: We have well defined
            fallback in font spec. If there isn't a match reasonable
            to not match anything and let author say where they want
            it to fallback. Author can decide if it's more important
            to match system or have a style feature.
  AmeliaBR: Using fallback in the font stack author can decide
  <chris> fallback to fallback to system-ui seems good to me, but I
          also appreciate amelia's point about flexibility
  AmeliaBR: Similar, I don't think we should stretch to match system
            fonts. Sego scripts are very different then the rounded.
            If we encourage browsers to randomly attach fonts they'll
            end up as useless as current generic keywords. No one uses
            "cursive" or "fantasy" because don't know one device to
            the next

  Rossen: Other thoughts?
  * tantek is leaning towards the proposal
  myles: To reply. Your first point is fine for fallback. There was
         support on issue for both directions to either is okay
  myles: Second point I defer to people working on Window OS what's a
         good match
  Rossen: Fair
  Rossen: I'm going to have to defer responding until have a chance to
          discuss with windows fonts team and see if they have a
          suggestion and if they want to take dependency on
  Rossen: High level I don't think we should have a problem to match a
          font provided to resolve to accept this
  <chris> agreeing with the side point that cursive is almost useless,
          and fantasy should really be removed from the spec!
  <bradk> Good point about cursive and fantasy fonts
  <tantek> bad design of past generic families is not a reason to
           block an improved modern way to access system-ui variants
  <AmeliaBR> tantek, no, my point is that we should be careful not to
             repeat the mistakes of the past!

  myles: If people are done discussing feature request there is
         related discussion on syntax to trigger. If we're done we can
         migrate to syntax.
  Rossen: First being if we want to do this?
  myles: Exactly
  Rossen: Based on GH issue discussion it feels like we're ready to
          take on this feature?
  myles: Looks like that to me
  Rossen: I want to resolve on this and then sweat the details.

  tantek: I have an opinion with historical view. Traditional system
          fonts were derived directly from windows UI. When impl on
          mac didn't map well and weren't good design.
  tantek: I read github and I don't think old system font names should
          block having this be considered.
  tantek: Similarly, the fantasy and cursive fonts I agree no one uses
          them because unpredictable. If I recall they came from
          truetype fields. That was before we incubated specs. We took
          values from another spec with no demand. I wouldn't count
          either of those against this proposal
  tantek: I looked at github examples and do present a strong case for
          having those 3 ways act as system-ui variants if fallback is
          system UI font. Seems safe and useful, especially for mobile
          web UIs. That's a strong priority for the web platform,
          higher fidelity mobile web design
  tantek: I lean strongly toward proposal. Having worked on CSS UI for
          20 years I like minimalism

  fantasai: I would like clarity on if we use keywords for generic
            font family or if they are different kind of keyword that
            can say I don't exist
  myles: Proposal is generic font family names. If you're on a
         platform where meaningless they're the same as the system UI
         font family
  AmeliaBR: But there isn't agreement that's way to go
  fantasai: I feel like that makes sense for rounded, but monospace
            you want to fallback to monospace font
  <tantek> that would be sensible (fallback to monospace)
  <astearns> +1 to mono point - we should just have authors add
             `system-ui` to their font stack if that's the intent

  leaverou: Small comment, people don't use cursive because it's ugly,
            not just unpredictable. Second, these keywords seem like
            they're centered around something Apple did. Not sure what
            need is or how they work in other platforms. I'm failing
            to see use cases. In github most of the discussion is
            fallback and not why this is needed.
  leaverou: We should have a generic rounded font family, not
            system-ui-rounded. Seems like we're doing this because
            apple did something and needs to expose and not because
            author want
  myles: We have plenty of requests form people that have attended
         events and they want to use these fonts.
  leaverou: That's a different point.
  AmeliaBR: That people want to use these fonts is different then
            people wanting an OS tuned rounded font on every OS
  AmeliaBR: If you expose these fonts as a keyword that's mac specific
            that would be something that could be in a normal font spec
  leaverou: system-ui-monospace has a semantic difference. I'm using
            the system's monospace. If people are telling you they
            want these fonts they would use them if they're exposed.
            They're not saying they want a system UI
  myles: On macOS and iOS there is nowhere in the OS where you can
         type New York and get these. They're described by the token
         of rounded, serif, etc. And that's because we're allowed to
         change these fonts with the future of OS. That's intentional
  <tantek> I like the system-ui- prefix from an authoring perspective
           because it clearly communicates the UI use-case and
           discourages use in just "content" (body copy etc.)
  fantasai: Not sure why that means we can't expose the names to the
            web platform
  myles: Second piece is these are designed to be system UI fonts and
         not document fonts.
  Rossen: You're exposing them to be document fonts
  myles: Not intentionally. No way to use them only in a UI context in
         web platform
  fantasai: Also a number of kinds of fonts. There's fonts only for
            title. Different fonts for different functions is not a
            new thing. There's plenty of fonts that don't have special
  florian: And if there's a bunch of people wanting the pretty font
           and give a keyword that returns it not but not in the
           future you haven't given what they wanted

  <tantek> To me the use-case is building mobile web UIs that fit in
           with the platform. This is a good proposal for solving that
  <tantek> You don't want to use specific named fonts for UI
  <tantek> We have plenty of things in the platform that can be
           misused/abused, that in itself is insufficient as an
           argument. The point is whether a feature is designed to
           nudge authors toward the positive use-cases, and if so,
           then it's at least a good feature.

  Rossen: Want to timebox to 5 minutes then back to GH. There's a
          queue. Challenges about exposing font on web layer vs having
          them exposed behind a keyword was recorded and myles
          addressed it. Want to go to queue
  leaverou: People who said fonts are pretyt, did they mention their
            use case? How do you know they'll use it right? And people
            at WWDC much more likely to make Apple specific and I
            don't want that.
  Rossen: That point was made leaverou I think myles addressed. myles
          more to add?
  myles: Group is right, it's possible to expose using names like any
         font. We brought this up to try and be good citizens of web
         platform and try and figure out if there's interest in having
         platform non-specific way to get these system ui variants. If
         group doesn't want we can pick names for them. It will have
         to be similarly generic, but it's a valid path if group
         thinks this is not desirable
  myles: Platform conventions of macOS and iOS this is best match of
         design intent for these fonts
  <tantek> The GitHub issue already addressed how to do Android
           interop with this too
  <tantek> feels like people are not reading the GitHub issue existing
  Rossen: Please keep comments as to if we're interested in a feature
          to have generic system fonts

  florian: Two points. If we decide against doing this generic and
           apple does it I would encourage a normal fallback mechanism.
  florian: Second, maybe I misunderstanding use in native system.
           Increasing ability to mimic native OS seems like a spoofing
           mechanism for me to make it look more like it's part of the
           native app. Already somewhat possible, but maybe not easier
  <tantek> so add it to the Security Considerations section
  myles: It is common in web view apps and on the web to display UI as
         would natively look if native app. One person "spoofing"
         system UI design is another person's feature
  <tantek> ^^^ this, making mobile web UIs that look native to the
           platform is a *good thing*
  <tantek> I feel there's a bit of mischaracterizing going on of
           myles's use-case
  fantasai: I'm still not clear what the strength of use case is for
            special keywords vs exposing font. Use case you've given
            us is fonts are pretty. But that's not use case for
            system-ui-rounded, that's a use case to let people specify
            the font. If these fonts were exposed with a name, would
            there still be a need for these keywords? If so, where is
            demand from?
  myles: I don't have anything new to add
  <fremy> @fantasai @myles: I guess if you are making a book-reading
          experience, you might want to pickup the native serif font
  florian: I don't think you need to report why you don't want to. But
           if you had been okay exposing them, would there still a
           separate need for the special name?
  myles: Two reasons is 1) they have applicability to other platforms
         2) Even on apple platforms they are not IDs by name so
         meaning might change
  fantasai: Keyword can have a meaning change. Font by name you do
            change the name if you change the style of the font
  <tantek> when you author a UI with the web platform, you DONT want
           to have to specify the specific font by name for each
           platform, because that's A LOT of extra work. consequence:
           authors pick 1 or maybe 2 platforms to look good, then
           others look poor
  <tantek> you really want these kinds of generic font names for web
           UI, to encourage/enable cross-platform UIs rather than
           making non-majority platform second-class
  fantasai: I don't see the second and a thing that needs to be
            considered, it's a quirk of the platform.
  fantasai: First case there's a lot of cases where it's not clear if
            there is one.
  jensimmons: Can I answer that?
  Rossen: I'd like to close. Please make it quick
  jensimmons: I think from author prospective it would be good if they
              had access to fonts. If we have system-ui-serif,
              system-ui-monospaced, and system-ui-rounded as an author
              they will expect it's different on different OSs. If
              Apple redesigns it would automatically update. People
              might want to do that as they're making web apps. It's
              why people like material design. It gives quick access
              to Google design
  <tantek> +1 jensimmons. thank you for making this point clearer
  jensimmons: I think this would be similar where if you want
              something to look like OS this is how you do it. Authors
              might think it's a shortcut to get the pretty fonts, but
              the primary use case is you want to look like system
  <fantasai> I would be OK with that if it wasn't the only way to get
             access to these fonts.
  <fantasai> So that if someone wanted to use the font, they didn't
             have to use a system-ui keyword if they didn't want it to
  <tantek> no I don't want that (apple- prefixed fonts), because THAT
           is how you get apple only designs. a generic system-ui-
           font is how you get at least *a chance* of cross-platform
           nice looking web UIs
  <jensimmons> I would say yes, you need to expose them in this way if
               Author’s can access them directly. In the past, people
               could use a font stack that would give them the same
               result — but without an ability to name these new fonts
               directly you can’t use the old techniques.

  Rossen: We keep repeating this; do we need to expose specific system
          fonts and figure out if they will be mapped to what author
          wants to expose
  <dauwhe> the jensimmons comment was helpful to me and did not sound
           like repetition
  AmeliaBR: I was going to suggest can we have font keywords that are
            apple prefixed. Used across browser to match apple font on
            their system. After this I don't think that's a good idea
  AmeliaBR: I do think it's a use case to have a system-ui font that
            works on android and apple and will work on windows in
            future if they add serif. Important not to force systems
            without these fonts to match they keywords and instead
            have normal fallback where authors have control
  myles: If these don't turn into system-ui we would probably expose
         as apple prefix.
  tantek: And that's worse in my opinion
  AmeliaBR: Let's discuss on issue
  <jensimmons> In fact, this makes it *easily* for Authors to
               specified OS fonts directly, instead of having to go
               learn what they are… update when they change… figure
               out a font stack that works.
  <tantek> I kind of want to see examples from folks here actually
           building UIs in HTML+CSS, especially those arguing
           *against* the proposal
  <tantek> I see this proposal as *improving* the situation vis-a-vis
           existing system fonts. That's good enough for me.

  Rossen: I want to close this discussion. Issue is alive and healthy.
          Let's cover there and bring back maybe next week
  Rossen: First thing is: is there a need to have a way to target the
          system fonts for UI purposes.
  Rossen: jensimmons summary of the use case is excellent. That's in
          the notes. Please engage on github. We'll come back next week

CSS Text/CSS Sizing

When to/not to include preserved trailing spaces
  github: https://github.com/w3c/csswg-drafts/issues/3440

  florian: Is koji on?
  [he is not]
  florian: Comment to rest of group. We resolved on this about half a
           year ago. I worked on a PR to apply resolution and found a
           weakness. I proposed a close alternative to the design. I
           asked fantasai to review.
  florian: koji is other person close on that discussion. I'm not
           clear why he disagrees. He sees both options as a
           regression to what was there before. But I think the
           requirements are what he expressed in the past and now
           calls regression. I could be confused.
  florian: It would be helpful to have more people looking. You have
           white-space: pre-wrap and there's whitespace at the end.
           There's detailed PRs and examples. If you have any interest
           I would very much appreciate someone looking and seeing if
           I got it right or if there's a problem
  florian: It would be helpful to have people look. We can't resolve
           without koji
  Rossen: And there's always TPAC

CSS Grid/CSS Sizing

aspect-ratio-only boxes should be able to size to grid container
  github: https://github.com/w3c/csswg-drafts/issues/4228

  fantasai: I think case where we found as we audited sizing rules.
            When we don't have definite available space, could provide
            grid-container size. Currently undefined or infinity. You
            have an item and an auto-sized grid track. Tries for
            max-content. Row doesn't have size so when we try and size
            we say infinite. Maybe we should provide grid-container
  fantasai: This would be change to way grid works
  fantasai: How it finds the max-content size of an item in a row that
            is not fixed
  jensimmons: When fantasai talked this through I liked what she
              proposed. Image should fill what's available. I was +1
              to it
  fantasai: When trying to find max-content width and item needs to
            know height to resolve it then we need to take into
            account height to find width. If we don't have one we try
            and shift to container size. In grid container case the
            container is the grid area and if it's auto it doesn't
            have a size we can pass to algo
  fantasai: So it ends up as infinity or undefined and not a number.
  fantasai: Proposal: in case of grid if row doesn't have a size you
            can use then you look up to grid container and use that
  <fantasai> https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes
  fantasai: Applies in sizing of image with aspect ratios ^

  Rossen: Every time we try and make a dependency all layout algorithm
          become difficult. All layouts are defined to operate on a
          single container item relationship basis. Breaking that rule
          and defining this layout type you will be defining a size
          based on an ancestor things become difficult
  Rossen: We have made that exception before like orthogonal flows,
          but it is implemented as an exception to find the ancestor
          with a defined size. This is an exception and usually ugly
          at cost of artifacts.
  Rossen: You can always create cases where this becomes inefficient
  fantasai: Not looking at ancestor, grid row looks to grid container
  Rossen: But you have a grid inside a grid inside a grid. Always a
          case where these exceptions fall and people think it's just
          a few above. Already one ancestor, why not more?
  fantasai: It's not an ancestor. It's grid container
  Rossen: Layout PoV we're going through area that's used for layout
          considerations for resolving positioning. We are proposing
          to escape layout area and go to container which is next
          level ancestor of grid item
  fantasai: Containing block corresponds to actual box in other layout
            cases. Grid has abstract containing block as a sub part of
            grid. When using that to calc max content when itself
            isn't fixed we look at grid container sizing property. I
            think this is reasonable to do
  Rossen: In case where grid container has undefined size?
  fantasai: No change to that case
  Rossen: But the point I was trying to make is grid container could
          be a grid item. It needs to go to its container grid
  fantasai: Not doing that for writing modes so not doing for aspect
            ratio. If the grid container was height 100% and 400px
            it's fixed and would pass down to its children. It's child
            to parent but in grid there's a structure which is the
            grid. Grid is containing block of grid child but doesn't
            look at containing block to get a size
  fantasai: Proposal is to say that even though parent is not
            containing block it takes a size from it when it needs a
  Rossen: That's my point
  fantasai: You're arguing we'd walk up chain, but we're doing child
            to parent directly
  Rossen: Once we add things like subgrid we'll have to keep that use
          case in mind and continue thinking bout this exception case
          where we defer to a different level. You will face that case
          all the time if we make an exception now
  Rossen: Would prefer if we're using the grid item's type
          contribution. I think it was second proposal? max-content
          size from available space
  fantasai: That's what we're trying to define here

  AmeliaBR: Might be helpful to look at breaking this algorithm to add
            more detail. It's true that there are very simple cases
            where you gave explicit grid-row height and you want grid
            items with aspect ratios to fill explicit dimension and
            auto-size in other and that should happen automatically
  AmeliaBR: Rossen concern about what if you have rows dependent on
            parents and other children and how to define non-circular
            I think there will be using the existing grid text and
            text with flexbox and aspect ratio where we redefined how
            aspect ratio boxes worked because initial behavior wasn't
  AmeliaBR: I suspect we have necessary sub algo defined
  fantasai: We do this for the orthogonal dimension. If the available
            space when sizing a grid item is taken from row with
            constraint it looks to grid container. Just not with
            aspect ratio
  fantasai: For aspect ratio we need to take from inline dimension and
            that's not designed
  <fantasai> https://drafts.csswg.org/css-grid-1/#algo-overview
  <fantasai> "If calculating the layout of a grid item in this step
             depends on the available space in the block axis, assume
             the available space that it would have if any row with a
             definite max track sizing function had that size and all
             other rows were infinite. If both the grid container and
             all tracks have definite sizes, also apply align-content
             to find the final effective size of any gaps spanned by
             such items; otherwise ignore the effects of track
             alignment in this estimation."
  <fantasai> We need to do this in the inline dimension
  AmeliaBR: Are you able to break down where in all existing layout
            algorithm there would need to be new rule? That would make
            it less scary
  fantasai: Yes, right now depends on available space in block axis.
            We would address it in this section [above] if you don't
            have definite row we can provide by grid container
  fantasai: If people want to look more we can come back

  Rossen: Own this more thinking, it's a fundamental thing and careful
          what to select
  Rossen: My pushback is based on working on a lot of it and making
          such an exception requires adding a lot more information
          that needs to be kept track of and that complicates layout
          algo tremendously
  Rossen: Need to see if this manifests as super common use case with
          adverse effects or if this is something most people won't
  Rossen: I'd prefer to let others comment, especially other people
          implement layout
  Rossen: That work for you fantasai?

Media Queries/CSS Sizing

Support <number> (and therefore calc) as a <ratio>
  github: https://github.com/w3c/csswg-drafts/issues/3757

  emilio: A contributor implemented this in FF. Couple issues related
          to thing we didn't resolve on. Resolved to allow syntax as
          <number> but not on serialize, if you can do two negative
          numbers. Regular aspect ratio we only allow positive int
  [audio problems with emilio]
  Rossen: While we wait on emilio to reconnect...
  AmeliaBR: I can fill in
  <emilio> thanks AmeliaBR!
  AmeliaBR: Resolution we had previously was to loosely allow any
            number over a number or a single number as valid syntax
  AmeliaBR: Simple question of serialization we've got backwards
            compat on people expecting int/int Anything spec that was
            should continue to serialize that way
  AmeliaBR: Options from there are remember if it is spec with a / and
            keep that or always serialize with a / and add /1 if it's
            single number
  AmeliaBR: As emilio points out there are other questions about how
            much do we simplify, if you've got -int/-int does it
            simplify or clamp. /0 is valid according to syntax, how to
  AmeliaBR: One option is treat like calc but in serialization we add
            in the /1. Can lose numeric precision in some fractions
  AmeliaBR: If you specify 2/3 to get 0.6667/1 that would be a problem.
  AmeliaBR: If we're not simplifying into fractions what to do with
            arbitrary numbers. Keep as two separate? Lean to keep 2 as
            separate and if isn't spec insert a 1. Simplest approach
            and least likely to surprise

  fantasai: Shouldn't reduce everything to over 1. Have principle we
            serialize to most backwards compat and shortest, not just
            shortest. The older form serialization will need both
            numbers. Shouldn't simplify fractions down.
  fantasai: Could do 9/3 to 3/1 but don't see a benefit to doing that
  jensimmons: For clarity, is this visible to authors or is this in
              the calculation when you get to computed
  fantasai: For getComputedStyle
  AmeliaBR: Effects both reading back value from dom, simple
            serialization, and serialization from getComputedStyle
  fantasai: Important to note values from getComputedStyle need to
            roundtrip without loss. Simplifying 1/3 to 0.667 isn't in
            keeping with those principles. Not appropriate to do here.
  AmeliaBR: We do it with calc, though
  AmeliaBR: Worth mentioning for backwards compat the syntax is
            currently only in MQ. Not sure how much people are reading
            back values, but I'm sure someone is somewhere.

  Rossen: Couple minutes overtime. I don't believe we can resolve on
          this. Again, I invite folks to engage on GH and we'll pick
          up next week
  Rossen: Sorry we couldn't make any resolutions today, let's hope
          it's different next week. Thank you all for calling and
          we'll chat next week. It's APAC time.
Received on Wednesday, 28 August 2019 23:06:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:15 UTC