[CSSWG] Minutes Telecon 2021-07-21 [css-fonts] [cssom] [css-highlight-api] [css-flexbox] [css-scrollbars]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: Republish CSS Fonts L4 and L5 (Issue #6462)
  - RESOLVED: Republish CSSOM (Issue #6446)

Highlight API

  - RESOLVED: Highlights associated with creator document. Throw on
              mismatches when registering ranges/etc. (Issue #6417:
              Specifying behavior for Highlights involving multiple
  - RESOLVED: UA does not add any default styles to custom highlights
              (Issue #6375: Need clarification on expected default
              values for style properties)

CSS Flexbox

  - RESOLVED: Move order property to Display module (Issue #5865: Order
              property definition only mentions "flex items")
  - RESOLVED: Close no change, Firefox is correct (Issue #4852:
              Indefiniteness when sizing grid tracks in a flexible flex
  - Discussion will continue on github for issue #4311 (Should a
      definite flex-basis always make the main size be definite?) to
      determine if the proposed behavior is followed by all browsers or
      if Firefox is doing something different.


  - RESOLVED: Defer [scrollbar-color accepting a single color] to L2
              (Issue #5651: Using scrollbar-color to tint the scrollbar)
  - The group began to discuss issue #2252 (Is it possible to have a
      position: sticky horizontal scrollbar?) and came to a common
      understanding of the problem. However, there wasn't time to
      discuss possible solutions so the topic will continue on github.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jul/0010.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Oriol Brufau
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Sanket Joshi
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Morgan Reschenberg
  Cassondra Roberts
  Miriam Suzanne
  Lea Verou

Scribe:  fantasai

  <Rossen> https://wiki.csswg.org/planning/virtual-july-2021
  Rossen: Reminder about the vF2F
  Rossen: Please add yourself to the wiki
  Rossen: and add items for agenda
  Rossen: Any changes to agenda?
  lea: Reminder that Color API breakout is right after this call

CSS Fonts


CSS Fonts
  github: https://github.com/w3c/csswg-drafts/issues/6462

  Rossen: css-fonts-4 and css-fonts-5
  Rossen: I looked over changes, seems fine
  Rossen: Any objections?

  RESOLVED: Republish CSS Fonts L4 and L5

  github: https://github.com/w3c/csswg-drafts/issues/6446

  Rossen: Next is updated WD for CSSOM
  <chris> note some broken link issues that need to be fixed before
          publication https://github.com/w3c/csswg-drafts/issues/6463
  Rossen: some PR merged recently
  Rossen: emilio, chris any thing holding back?
  chris: Some broken links, don't know what to replace with
  * emilio can look into that
  [emilio and chris will look into it]
  Rossen: Any objections to republishing?


Highlight API

Specifying behavior for Highlights involving multiple documents
  github: https://github.com/w3c/csswg-drafts/issues/6417

  dandclark: Issue is Highlight API doesn't do cases where multiple
             highlight trees and multiple documents interact
  dandclark: e.g. in same-origin iframes, ranges can be passed back and
  dandclark: Should we be allowed to have highlight covering ranges in
             different windows?
  dandclark: Can a single highlight cross documents?
  dandclark: Could reject these cases by throwing
  dandclark: I would propose something different
  dandclark: I have a 3-part proposal
  dandclark: 1st, should allow highlight to contain ranges from
             multiple trees
  dandclark: 2nd, allow highlight to be added to multiple registries
  dandclark: might mean tracking multiple highlight registries for each
  dandclark: When a highlight registry painting, will only paint
             highlights associated with that document
  dandclark: If it finds a range in another window/iframe, it does not
             reach over there and paint there. Only paints within its
             own document
  dandclark: Wanted to get people's thoughts on this proposal

  smfr: Proposal seems to be the most complex version of the solution,
        allowing highlights to involve multiple documents and allowing
        them to live in multiple registries
  smfr: What's the reason to avoid the simpler solution, of restricting
        to single document and single registry
  dandclark: Philosophical whether to reject early or to be more
  dandclark: If I create a highlight but don't give it any ranges, is
             it associated with that document?
  dandclark: ...
  dandclark: Do I need to do comparison whether new ranges in another
  dandclark: Some interesting cases there I don't know how to work
  dandclark: We could say something like highlight is associated with
             document that created it
  dandclark: and registry associated with that document
  dandclark: and if try to insert range from another document, throws
  smfr: That would be my preference for the first version

  sanketj: Seems fine, preference for the first version. If necessary
           could add these abilities later.
  sanketj: Need to define which exception to throw
  sanketj: Different documents, multiple registries, and multiple
           ranges to single highlight, need to define exception for
           each of those
  sanketj: Might be simpler to allow those cases and don't paint the
           ranges in different document
  <emilio> (sorry, no mic) Strongly prefer associating it with the
           creator document and throwing on mismatches. There's
           precedent for this w/ constructable sheets, FontFace, etc
  <TabAtkins> Agree with emilio - we already have a decent precedent to
              only allow same-document usage.
  <GameMaker> I also agree et. all with throwing

  Rossen: Any other comments/feedback?
  sanketj: If we are throwing, do we want just one exception or
           separate exceptions for each case? Seem like slightly
           different operations
  TabAtkins: I think they all boil down to same category
  TabAtkins: using something in a wrong context
  Rossen: If this proposed path forward works for you, suggest go back
          to GH and work out the details in terms of exceptions
  Rossen: Once all happy, come back and we can resolve
  Rossen: Unless you feel strongly on resolving this path forward now
  dandclark: Sounds good, thanks
  Rossen: Proposal is that we associate with creator document and throw
          on mismatches
  <sanketj> SGTM
  Rossen: Any objections?
  <dandclark> +1 to resolution

  RESOLVED: highlights associated with creator document. Throw on
            mismatches when registering ranges/etc.

Need clarification on expected default values for style properties
  github: https://github.com/w3c/csswg-drafts/issues/6375

  sanketj: CSS Pseudo specifies default values for certain native
           highlights. Should there be any defaults for custom
  sanketj: Since these are author-defined highlight, don't think should
           define any styles in UA styles
  sanketj: Also no way to do this
  sanketj: Seems better to let it just inherit from originating element
  sanketj: Might want to make explicit that UA should not give default
  fantasai: I agree with this
  fantasai: Doesn't make any sense for UA to add default styles to
            custom highlights
  Rossen: Any objections?

  RESOLVED: UA does not add any default styles to custom highlights

CSS Sizing

Compressible Elements with Aspect Ratio
  github: https://github.com/w3c/csswg-drafts/issues/6341

  TabAtkins: Forgot to discuss this last week...
  iank: I won't be around next week
  Rossen: Anything urgent?
  iank: patch waiting in my queue is all
  TabAtkins: I just haven't had a chance to think through it. Though
             you're probably right anyway

CSS Flexbox

Order property definition only mentions "flex items"
  github: https://github.com/w3c/csswg-drafts/issues/5865

  TabAtkins: Brought up that the definition of order only mentions flex
             items, but also applies to other layout modes (grid at
  TabAtkins: so we should be generalizing this property, but then where
             should it live?
  TabAtkins: We think Display is the most appropriate place for it
  TabAtkins: Would like resolution to move it to Display, unless
             someone has a better idea
  <rachelandrew> +1 for display
  Rossen: Feedback or other opinions?
  smfr: Seems fine
  <emilio> Display or maybe position sounds good
  Rossen: Objections?

  RESOLVED: Move order property to Display module

Indefiniteness when sizing grid tracks in a flexible flex item
  github: https://github.com/w3c/csswg-drafts/issues/4852

  oriol: Case where we don't have interop between FF and Chrome
  oriol: When have column flex container which has for example height
         set to some value bigger than the content
  oriol: This flex item has a flex that causes it to expand
  oriol: and this flex item is also a grid container
  oriol: which contains an auto row
  oriol: Usually auto rows, if you have free space at end of track
         sizing, they are expanded to cover this extra space
  oriol: Specifically for the case where we set the height property, we
         have interop
  oriol: but instead of setting height on flex container you set
         min-height, in Chrome the auto height doesn't grow
  oriol: At first I was confused and thought Chrome was right, but
         actually after some feedback from iank I think it's actually
         Firefox which follows the spec
  oriol: iank also said that he's willing to change Chrome to adapt to
         what FF is doing
  oriol: So I guess we can close this no change, agreeing that Firefox
         is the right behavior

  Rossen: comments/objections?
  iank: ...
  fantasai: I think authors would be happy with this resolution

  RESOLVED: Close no change, firefox is correct

Should a definite flex-basis always make the main size be definite?
  github: https://github.com/w3c/csswg-drafts/issues/4311

  TabAtkins: There's an example in the issue
  TabAtkins: Column flexbox with a flexible child
  TabAtkins: child has a definite height, but it is flexible so can
             become larger or smaller
  TabAtkins: Flex item has a child with a percentage height
  [TabAtkins has connection issues]
  fantasai: Spec says this case is indefinite, and percentage won't
  fantasai: But implementations do resolve
  fantasai: so should we change the spec to match implementations?

  iank: I think all of the implementations are following the spec here
  iank: in that they are not resolving ...
  cbiesinger: Not true
  cbiesinger: Testcase is red, which means it is resolving
  cbiesinger: Interesting thing here is that the percentage would
              resolve outside a flexbox
  cbiesinger: it doesn't resolve if you put it inside the flexbox (per
  cbiesinger: I doubt authors expect that
  fantasai: Originally definiteness was identifying cases where
            percentages are very simple to calculate
  fantasai: and we restricted percentage resolution to these cases
  fantasai: but authors would be happier to resolve more often
  fantasai: so if implementers are already doing it, might as well
            match the spec
  iank: This seems fine to me
  fantasai: Does mean that concept of definiteness is more complicated
  cbiesinger: Want to mention, in Chrome we only take into account the
              width/height property, not the flex-basis. But that's
              probably a Chrome bug

  Rossen: Do we know if this is safe to change?
  fantasai: Planning to match spec to implementations, so shouldn't
            have any concerns

  jensimmons: Seems folks doing a good job of raising flex bugs and
              addressing them
  jensimmons: Would love to ask if filing bugs against WebKit as well,
              seems our implementation is same as Chrome
  iank: No bug required here, spec is aligning to implementations
  jensimmons: on this issue, but not last one
  cbiesinger: Should be a wpt test also
  Rossen: WPT tests should raise to webkit
  <jensimmons> no

  dholbert: Wanted to clarify what the proposed change is here. Are we
            making the spec match implementations in this case?
  <cbiesinger> I think change is: definite flex-basis makes the size
               definite, even if the item is flexible
  dholbert: I think that doesn't match what we do
  dholbert: It might be that this case is triggering a more subtle
  fantasai: That's interesting, we should investigate
  dholbert: I think intent of our behavior is to match the spec
  dholbert: We do check if flex item is flexible when testing for
            flexible flex-basis, to see if we want to make item definite
  cbiesinger: I feel like you and I had a discussion about this years
              ago and you were going to match our behavior
  dholbert: We fixed a number of bugs in last 6 months also
  dholbert: so maybe previously did something more esoteric
  fantasai, rossen: Maybe need to go back to GH to figure out


Using scrollbar-color to tint the scrollbar
  github: https://github.com/w3c/csswg-drafts/issues/5651

  fantasai: So one thing discussed is whether scrollbar-color should
            accept a single color, auto-generating the second color
            from the first
  fantasai: another is around allowing 'auto' as a keyword in the
            two-value syntax, explicitly triggering auto-generation of
            the other color
  fantasai: We put it on the agenda to ask if there was interest in
            allowing this
  <emilio> I'd prefer not to add this unless there's strong author
           demand for it
  <emilio> Not opposed per se but...

  lea: I think there should be some defined algorithm for UA to
       generate other color
  lea: Reasonable for authors to define which color they want to alter,
       and UA to define other color
  lea: Would prefer that option rather than specifying only one color
       and having magic other color
  TabAtkins: Note that the spec currently requires two colors, so we'd
             first have to agree to allow only one color before the
             rest becomes relevant
  lea: Should be possible to specify one color

  smfr: Wanted emilio to clarify, want single color to be invalid?
  emilio: So far, Firefox requires 2 colors, and I haven't seen anyone
          particularly complain about that
  smfr: I'm not opposed to a single color, but some ambiguity around
        whether lightening or darkening to generate the other color
  smfr: especially with dark mode
  smfr: Might need to specify somehow
  lea: With regards to dark mode and whether UA darkens or lightens
  lea: that has to depend on the color as well
  lea: Defined which direction to go, then what do you do when author
       specifies black?
  smfr: That's my point, there has to be a defined threshold where UA
        flips lightening vs darkening
  smfr: Maybe dark mode is not relevant, maybe authors provide
        different colors

  <TabAtkins> I'm on the side of "just have the author provide both"
             (aka no spec change), I think

  lea: I think we're discussing minutiae of specifying a single color
  lea: but there's no consensus on whether this is desirable
  emilio: Same issue that smfr mentions is already a thing with
  emilio: Scrollbar-color already needs to synthesize other colors,
          e.g. for :hover effects
  emilio: If there's a strong desire to auto-generate track color...
          I'd rather not
  emilio: Authors might get what they want in some browsers and
          something different in other browser
  smfr: Ideal way to specify would be to just use color-5 functions
  smfr: Similar to ridge/groove situation
  <TabAtkins> Yeah, unlike accent-color, this is a place where we
              absolutely know where and how each color is going to be
              used. Auto-generating colors would be purely a
              convenience, not a necessity like in accent-color.

  fantasai: Main question is, do we want to do this or do we want to
  Rossen: What's the consensus?
  smfr: I think it's nice to have, but fine to defer to scrollbars-2
  emilio: Same
  Rossen: proposed to defer to l2, any objections?

  RESOLVED: Defer to L2

  Rossen: Encourage folks to engage on the issue and continue
          discussion there

Is it possible to have a position: sticky horizontal scrollbar?
  github: https://github.com/w3c/csswg-drafts/issues/2252

  Rossen: Asking if possible to have position:sticky horizontal
  fantasai: This issue is a clear case of an unfortunate user situation
  fantasai: Very large code block, with overflow:scroll so you can
            scroll horizontally, but it's also tall enough that the
            horizontal scrollbar is off the screen
  fantasai: Person trying to read has to scroll down to reach the
            scrollbar, scroll horizontally, then scroll up to see the
  fantasai: Which is a very bad UX
  fantasai: So wondering if there's a way to make a horizontal
            scrollbar stay "above the fold"
  fantasai: florian and I discussed this; you can't just
            position:sticky the scrollbar (it doesn't exist)
  fantasai: Maybe we can do something else
  fantasai: Or maybe it's just quality-of-implementation, and browsers
            could handle this themselves

  smfr: Seems only case for ...
  TabAtkins: No, if the box is tall enough, this is a problem
  smfr: That's 2 separate scrollers right? Document scroller and inner
        scroll container
  TabAtkins: Right, but document scroller isn't causing it
  TabAtkins: The problem is the inner scroller is too tall to be
             visible within outer scroller
  smfr: I understand the problem
  smfr: Quality of implementation seems difficult
  smfr: UA wouldn't know whether to add sticky scrollbar, might obscure
        some other content
  smfr: Other solution might involve...
  smfr: Need to think about it

  Rossen: Maybe continue conversation back in issue, come back to it
          next week or afterwards

Received on Thursday, 22 July 2021 10:53:30 UTC