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

[CSSWG] Minutes Telecon 2019-08-21 [writing-modes] [css-images] [css-color-adjust] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Aug 2019 19:22:49 -0400
Message-ID: <CADhPm3vFzv8dDSGTfsWvzq-JRGPMJz3DLavabeQJ5grpC8ZpVw@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.


  - Charter issue #219 ( https://github.com/w3c/charter-drafts/issues/219 )
      needs to be resolved before the charter goes for approval since
      no one is happy with the current horizontal review text

Writing Modes

  - The implementation report has been updated
      Implementors are requested to review to see if any of the
      changes are small bug fixes that can be addressed quickly and
  - The unintentionally dropped text about sizing orthogonal flows
      (Issue #4220) was edited back into the spec for review:
  - RESOLVED: Republish Writing Modes L3 with added/missing section
              for orthogonal writing modes provided no issues raised
              before Friday

CSS Images

  - RESOLVED: Loading images are not invalid but treated similarly as
              explained in https://drafts.csswg.org/css-images-3/#image-values
              (Issue #1984: Specify fallback behavior when replaced or
              background image content not available)
  - RESOLVED: Republish CR of CSS Images 3

CSS Color Adjust

  - RESOLVED: background-color computes to the system background-color
              for all values but the alpha channel (Issue #4175:
              background-color in forced color modes needs more than a
              simple unset)

Quick intro to content-size

  - TabAtkins briefly introduced the proposal for content-size
      http://tabatkins.github.io/specs/css-content-size/ so that
      people could review in advance of a longer discussion. Comments
      can also be added to github issue #4229

CSS Fonts

  - myles introduced the proposal to add system-ui-serif,
      system-ui-monospaced, and system-ui-rounded in order to
      reference the new fonts introduced in iOS and macOS (Issue #4107)
      - The fallbacks need to be clearly defined for these values
      - Environmental variables should also be investigated as a
          possible solution to this use case
      - There wasn't time for a full conversation so this will be
          discussed on next week's call


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

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Florian Rivoal
  Devin Rousso
  Jen Simmons
  Alan Stearns
  Lea Verou
  Fuqiao Xue

  Brian Kardell
  Melanie Richards
  Greg Whitworth

Scribe: dael

  astearns: Does anybody have extra things for the agenda?
  astearns: I do
  <astearns> https://wiki.csswg.org/planning/tpac-2019
  astearns: We have a meeting coming up with 10 people attending and 2
            items ^-^
  astearns: If that seems small to anyone else please add agenda items
            and yourself to those planning on attending


  <chris> charter status 3 issues closed
          https://github.com/w3c/charter-drafts/issues/228 one open
          but not blocking https://github.com/w3c/charter-drafts/issues/219
  astearns: Little changes going in
  astearns: xfq anything to add?
  xfq: I saw chris sent some links
  xfq: W3C management has reviewed charter. If no one objects to
       charter in 24hr we'll extend current charter to end of sept and
       put new charter for AC review

  xfq: 2 unresolved issues. One is 219 about horizontal review
  <xfq> https://github.com/w3c/strategy/issues/188#issuecomment-523071407
  xfq: Other is ^
  xfq: Richard hopes for more completion dates for specs related to
       i18n users including text, text-decor, ruby [missed some of the
  chris: Seems similar to 228 and seems a request to work on it rather
         then surely you must have dates. Don't know how to answer

  florian: I'd like 219 addressed before charter sent for review.
           Current text is not what other horizontal review WGs asking
           for. Richard explains what he wants and current text
           doesn't do that and constrains us beyond requirements. I
           don't see why we should go with the text we don't want. If
           we can't find text we want we should go with process. Seems
           reasonable to agree with Richard but no text for that
  florian: Either wait for text or go with nothing. Having text we
           don't want isn't great
  chris: Agree. Text is from charter template, though. Can you express
         your opinion on the github issue and raise this on the
  florian: Can you see if my last comment is enough for my objection?
           I will follow up on template
  chris: You haven't expressed urgency.
  <xfq> +1 to chris
  florian: Will do. Thank you.

  florian: Thank you for all the work xfq and chris
  chris: xfq did most of the work
  Rossen: Is that everything?
  xfq: Yes, on my side

Writing Modes Update

Dropped definition of automatic block sizing
  github: https://github.com/w3c/csswg-drafts/issues/4220

  Rossen: fantasai I think you raised an issue about part of a chapter
          being dropped and it warrants a republication?
  Rossen: Is fantasai on?
  fantasai: Section about how to size orthogonal flow was dropped.
            There is a section on available space, but not sizing.
            Need to put that section back.
  fantasai: It was dropped with text about multi-col.
  Rossen: Editorial mistake during the update? Or did we resolve?
  fantasai: Resolution was to drop everything at risk which does not
            include sizing block elements in orthogonal flow. Without
            that you interpret rules quite differently
  Rossen: Don't disagree this is core functionality on how we size.
          I'm surprised we had it out of the spec so far and just
          discovering it's out.
  fantasai: Also surprised, but I don't know.

  dbaron: Also feels like we should have a chance to review it again
          since there has been lots of spec review with it out.
  fantasai: Sure. But what is dropped was related to what's
            implemented. Without that text we do not match
  florian: It's in L4 right?
  fantasai: Text is in L4 but it's...its embedded in multicol text. It
            says this is what you do if you support multicol and this
            is what you do if you don't. Then we made multicol a may
            and the alternative behavior ended up dropped as well
  fantasai: If you want I can do that
  AmeliaBR: I think question was is this missing from both L3 and L4?
  fantasai: L4 includes all the text
  florian: dbaron said we need to review again and we have as part of
           L4? Given it has been part of a CR spec we don't need to
           heavily review
  dbaron: L3 and L4 have had different amounts of review
  fantasai: If anyone reviewed the spec and paid attention to this
            part they would have noticed it does not match impl
  <tantek> that sounds bad (that nobody noticed)
  dbaron: I think add it back, but I'd like to look at it.
  fantasai: Of course
  Rossen: Review before merge into L3?
  dbaron: No.
  dbaron: I'd like to look before it's a new CR
  Rossen: For sure
  Rossen: Let's add the missing section back.

  Rossen: We can come back next week. Are we close to republish CR?
  florian: We just did. This is only issue since. Should be close to
  Rossen: What would this section mean from testing PoV?

  <florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
  florian: That's the next topic; I have just compiled the impl report
  florian: I have not checked if the tests aligned with presence or
           absence of that section. I only reviewed failing tests for
  florian: We have ~1200 tests and ~25 are mandatory and lack 2 impl
  florian: Some is related to recent fix about propagating from body
           to root at used time. A few are sizing in orthogonal flow
           and I think there's work planned to fix.
  florian: One large-ish problem is orthogonal table cells have
           problems. Edge reasonably well, FF with some problems, WK
           and Blink don't do it.
  florian: There are small corner cases we might decide to overlook.
           Not quite PR but may be close
  Rossen: Thank you for putting this together
  Rossen: I'm expecting new section might require additional tests
  florian: Have tests for that area, if need verified need to decide
  Rossen: With that we can see if we need to address the 18 with
          mandatory pass of 2+

  <florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08#pb
  florian: I encourage impl to look at the report. 1st section with
           detailed results is the list of things that need to fix
           before move forward. If you can look and see if there's
           anything easy to fix it would be appreciated
  florian: It's not that many
  Rossen: That's a reasonable ask
  Rossen: The things that would have put a pause for me are table
          related. From impl PoV tables were particularly rusty when
          we had to impl writing modes. Should be something we can
          hope to impl in Blink once layout has enough wind behind it
          for purposes of common-based browsers. Hopefully FF and WK
          can follow
  florian: FF is closer. WK does not support orthogonal table flows.
           FF only has problems with sizing, rest works.
  <dbaron> Firefox table-cell issues are related to
           https://bugzilla.mozilla.org/show_bug.cgi?id=1231656 and
  Rossen: Case where orthogonal cell sizing is titchy. Missing section
          will help

  Rossen: In summary; we have a number of cases impl should go back
          and look to see what can be done to address in short term.
          If they're bug level I hope people can address soon. If
          major refactor we need another conversation about if we
          insist on those cases to pass or if we push the spec with
          the fails
  Rossen: We'll give it a week for dbaron and anyone else to look at
          the dropped section we're going to add and then we'll have a
          resolution to add it next call.
  florian: Didn't we say add now and discuss republish next week?
  Rossen: We don't gain anything by doing that. I'd prefer anyone has
          opportunity for feedback before we do editorial
  florian: Easier to read if it's edited in
  <chris> yes, easier to read in-place
  Rossen: Missing section is clear in the PR fantasai pasted. It's
  florian: What fantasai pasted is a deletion that deletes too much.
           Only parts need to be added back. I'd rather an editor
           decide what parts.
  <dbaron> I agree with Florian
  Rossen: Fair. If we can prepare PR for added section that would be
  Rossen: fantasai will you handle this?
  Rossen: I'm hoping you're saying yes to a muted mic
  fantasai: Yes I'll do it today

  Rossen: Thanks florian for taking time to piece together impl
          report. It's super helpful. Hopefully make progress before
  Rossen: One more nudge to impl to look at failing test cases

CSS Images

Specify fallback behavior when replaced or background image content
    not available
  github: https://github.com/w3c/csswg-drafts/issues/1984

  fantasai: Just waiting on myles to review
  myles: I did review and commented on issue
  Rossen: Said it looks fine
  Rossen: Let's try and resolve. Any additional comments or concerns?
          Anyone need summary before we resolve?
  Rossen: I'll take silence as a no.

  TabAtkins: Proposal: Accept edits to images spec about specifying
             behavior of not yet loaded images [missed, bad connection]
  fantasai: Proposal: Specify what's happening when you're loading
            image and add text explaining what you do while it's
  <fantasai> https://drafts.csswg.org/css-images-3/#image-values
  fantasai: Added a section for what it means for an image to be in
            process of loading and what you're supposed to do ^
  fantasai: [reads spec]
  <chris> That wording on loading images sounds great to me!
  <AmeliaBR> 👍
  Rossen: For those hearing this for the first time, any questions or
  chris: sgtm. It covers and don't need anything else
  Rossen: Proposal: Loading images are not invalid but treated
          similarly as explained in
  Rossen: Fair summary?
  fantasai: Yes
  Rossen: Comments or objections?

  RESOLVED: Loading images are not invalid but treated similarly as
            explained in https://drafts.csswg.org/css-images-3/#image-values


  <fantasai> https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012
  <fantasai> DoC https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012
  fantasai: That's all the issues
  Rossen: Are we ready to republish Images 3?
  <chris> +1 to republish!
  fantasai: I am
  <xfq> \o/

  Rossen: Objections to republish CSS Images 3?
  smfr: Draft does not have image orientation removal note. Or is
        that 4?
  fantasai: Should. Thought I added it.
  TabAtkins: It's there
  <smfr> https://drafts.csswg.org/css-images-3/#the-image-orientation
  Rossen: Section 5-1
  smfr: That right? Oh, I see.
  smfr: nevermind
  Rossen: You're good?
  smfr: Yeah, that's fine.
  Rossen: Thanks
  Rossen: Other comments or objections?

  RESOLVED: Republish CR of CSS Images 3

  <fantasai> xfq, note this publications requires a change of shortname
  <xfq> noted, thanks fantasai

CSS Color Adjust

background-color in forced color modes needs more than a simple unset
  github: https://github.com/w3c/csswg-drafts/issues/4175

  Rossen: I'll take it since melanierichards is on vacation
  astearns: How much time do you need?
  Rossen: Quick.

  <Rossen> https://www.w3.org/TR/css-color-adjust-1/#forced-colors-properties
  Rossen: When the forced color behavior was desc in the link^
  Rossen: These are the properties overwritten by system colors.
          Fallback was spec that every property that has no overrides
          gets the revert !important which means revert to original UA
          stylehseet which for background color is transparent
  Rossen: Not expected. All other colors reverting makes sense.
          Background being reverted to transparent you lose all
          non-transparent. Intended it go to system background color

  <aja> re: forced-colors, should transparent (borders-color only?) be
        allowed in addition to the non-deprecated system colors? will
        file issue if it sounds reasonable.

  Rossen: Idea from fantasai was can re do something to transparent
          color and see if computes to self similar to currentColor.
          Not really the same. Transparent color is a named color.
  Rossen: If we spec transparent computes to itself as computed we're
          making an exception for one named color. Think it's a bit
          weird. currentColor is an instruction to cascade algorithm
          to go back to a value. Not really the same
  Rossen: Ask here is that we take background color out of the list
          and spec the behavior that it falls back to system
          background color in case of forced colors
  Rossen: That was intended implementation that we had to back out
          when making code according to spec

  AmeliaBR: This would need to be defined in prose because involves a
            switch on computed value we can't define in cascade.
  Rossen: Yes
  AmeliaBR: Would it work to force all background to be opaque?
  Rossen: Inverse problem which would be just as bad
  AmeliaBR: Okay.
  AmeliaBR: It really has to be done with a little magic and special
  Rossen: Magic is simple. When you compute value of background color
          for non-transparent the value is computed to the system
          background color.
  Rossen: To your observation AmeliaBR the explanation will be
          background color only.
  AmeliaBR: Any interaction with background image? Background image
            the current proposal is keep the image and use backplate
            behind text to add contrast. Would you do them separately?
  Rossen: What you said is right for background image. For background
          color if the color is non-transparent it will be system
          background color. So if you draw a backplate it would be
          non-observable visually or object model. Somewhat wasteful
          to render.
  Rossen: Otherwise for background image the backplate takes effect
          and guarantees foreground in desired contrast

  dbaron: Is this the right treatment for background colors with alpha
          between transparent and opaque. Alternative is don't touch
          alpha and change color components to system color
  Rossen: Valid point. There's a different issue that addresses what
          you described when talking about interpolation. It will end
          up interpolating most of alpha channel. I like your proposal

  astearns: Summary Rossen?
  Rossen: Proposal: background-color computes to the system
          background-color for all values but hte alpha channel
  astearns: Can we resolve on this?
  astearns: Objections?

  RESOLVED: background-color computes to the system background-color
            for all values but the alpha channel

  astearns: Can we have the Quick intro to content-size quick and if
            have time go to item #12

Writing Modes

  fantasai: There is a 28 day waiting period after we publish. Do we
            want a async cfc to get to Friday's deadline or wait?
  Rossen: Okay as soon as possible. I defer to dbaron because he
          wanted to review this
  * fantasai will get the edits done today, probably this morning
  Rossen: If dbaron you're okay to review then I'm fine doing the CFC
          over email
  Rossen: Or we resolve to republish as long as no objections before
  dbaron: Fine with me
  Rossen: Objections to Republish Writing Modes L3 with added/missing
          section for orthogonal writing modes provided no issues
          raised before Friday ?

  RESOLVED: Republish Writing Modes L3 with added/missing section for
            orthogonal writing modes provided no issues raised before

Quick intro to content-size
  Link: http://tabatkins.github.io/specs/css-content-size/
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4229

  TabAtkins: Quick intro, will bring up properly at TPAC-ish
  TabAtkins: Larger context. You may have seen Chrome team efforts on
             async layout. Ability to tell a dom tree don't render
             what's in you yet. Go ahead and keep invisible and let me
             know when you're ready
  TabAtkins: While exploring found a small number of additions to CSS
             that would be generally useful. Content-size property is
             intro here. Important part of async layout is it not
             effecting outside subtree. Need to constrain size in
  TabAtkins: Don't want it to render to 0 size, usually have a rough
             idea of size and update when finish rendering.
  TabAtkins: Idea to fix that is content-size property. When none,
             none pretend 1 child with spec size and render like that
  TabAtkins: Still gives you layout shielding effects of contain-size
             but ensures it's not going to get too small
  TabAtkins: Why not use width and height? A few reasons. Biggest is
             different layout modes react differently to fixed vs
             auto. If you pop this into grid won't stretch anymore.
  TabAtkins: I had a reason not to use min-width/height but I forget it
  florian: Because in a flex situation where trying to shrink beyond
           natural size?
  TabAtkins: Yes. I feel like more, but yes. There are layout effects
             you may not want.
  TabAtkins: This is be as normal as possible and assume the kids will
             be about this big
  TabAtkins: We'll want to discuss properly in a call in 2 or 3 weeks
             or in TPAC but thoughts and feedback are welcome in the
  Rossen: Thank you TabAtkins. I think TPAC would be good with a

CSS Fonts

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

  myles: In latest version of macOS and iOS we've added 3 new fonts.
         You can see them in this issue
  myles: These are new fonts but aren't like regular fonts. Don't show
         in font pickers and you can't get them in native apps by
         name. There's a new codepath that causes these fonts and
         that's intentional
  myles: These fonts are designed to match design language of OS. Not
         intended to be used in a document font. Not supposed to use
         in an essay in Word.
  myles: There's nothing you can type in CSS to use these fonts which
         is unfortunate. Have heard requests to use them.
  myles: Proposal is that because these fonts designed to match the
         system they should be added as siblings to system UI generic
         font family
  myles: Might ask why not use existing generic font family. Reason is
         mechanically we can't because serif face is mapped to Times
         and if we change that we break the web. Need to be a new
         opt-in thing.
  myles: New fonts shouldn't be used as a document typeface

  myles: What do you guys think about adding a way to get to these
  Rossen: Curious if another way is have them in static variables
          introducing for other system things like scrollbar thickness
  myles: Mechanically fine. Confusing to authors because there's a way
         to ask for font-family from system.

  <dbaron> I'm curious about whether we want the 'rounded' name in
           CSS, rather than our existing 'sans-serif' which it seems
           similar to...
  <AmeliaBR> dbaron, rounded isn't the same as sans; it's usually a
             sans font, but with rounded ends of strokes. Myles'
             naming system assumes that the default system-ui is
             sans-serif, so they haven't included a system-ui-sans.

  chris: Why do this if whole point is not to use in Word documents?
         If you give CSS they can do specifically that. I'm curious
         why you hide in one hand and available on the other hand
  leaverou: Seems this is adding a very specific language feature
            that's OS specific. I don't think we generally do that.
  myles: One at a time. Chris' question: This is interesting. On our
         platform there's a tension between system fonts and not.
         There isn't that on the web. Only distinction is they're font
         families that start with 'system-ui'. Can't stop people, but
         it's more important to give access then the design
  myles: Trying to indicate these are system fonts by manner exposed
         to CSS and hoping that's good enough people will do the right
         thing. Things are either present or not in CSS 3.
  chris: If an impl supports these keywords by on platform they don't
         map would it fallback to next font or system-ui? I'd like to
         propose clarify that case
  myles: I see both arguments. Willing to go with WG desires
  <chris> I can see merits in both options also. I just want it to be

  AmeliaBR: For the existing generic fonts I think we still require
            UAs to have something match those. I think we have
            exceptions for emoji generic font. If we have generic font
            names that are allowed to not match that would be a new
            way of talking about what a generic font is
  AmeliaBR: One benefit of the suggestion to use environment variables
            is they then allow authors to decide what the fallback
            would be. Would have to think carefully of how that works
            with the way environment variables work with replacing
            tokens and how that works with font-family fallback. Don't
            want to invalidate entire expression
  AmeliaBR: Fallbacks worth thinking about because don't have logical
            equivalent in other systems

  Rossen: Need to think through use cases.
  Rossen: We're a minute over. myles I don't think we'll get to
          resolve. Anything else you want to add before we end the
          call? Of course there's a call for people to read proposal
          and comment on the issue.
  myles: It sounds like there's more to discuss so I hope this comes
         up on a future call
  Rossen: Will put it on next weeks call as well. Hopefully people can
          also discuss on github

  Rossen: Thank you everyone and we'll chat again next week.
Received on Wednesday, 21 August 2019 23:24:28 UTC

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