[CSSWG] Minute Telecon 2020-12-09 [css-text-3] [css-fonts-3] [css-text-decor-3] [css-conditional-3] [css-variables] [css-grid] [css-flexbox] [quirks] [css-color-4]

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

Next virtual long-form meeting (early Feb?)

  - The group was in favor of having more long-form meetings since
      they're now virtual. Rossen and astearns will propose specific
      days/times on the private list.

Reminder for re-joining group next week

  - Due to the change in patent policy, everyone will need to re-join
      the working group to accept the policy. Emails should go out

CSS Text, CSS Fonts, and CSS Text Decor

  - The PR to change the applies to text was merged (Issue #5303: CSS
      Text, CSS Fonts, and CSS Text Decor). Any issues or missed specs
      should be raised as separate issues.

CSS Conditional

  - Issue #5697 (Inconsistent phrasing around placement of @import
      rules) will be closed as editorial. A new issue will be opened
      for the naming of the <stylesheet> grammar construct.

CSS Variables

  - leaverou introduced her proposal for fixing the current limitation
      that custom element authors cannot use custom properties in the
      place of presentational attributes (Issue #5624: Higher level
      custom properties that control multiple declarations). There was
      a lot of interest in solving and some discussion around creating
      some syntactic sugar and using if() conditions to make it
      possible. Discussion will continue on the issue.

Grid, Flexbox, and Quirks

  - Everyone agreed that quirks should not skip grid and flexbox items
      (Issue #5545: Avoid percentage height quirk in new layout
      models). There was concern about web compat in making the
      change, but the group will try for it and revert if there's
  - RESOLVED: dholbert to make a change to quirks spec to clarify
      behavior for flex and grid items and containers (Issue #5545)

CSS Color 4

  - Several browser vendors will go back and check with their teams if
      there are any concerns requiring a higher number of minimum bits
      for storing colors in css data structure (Issue #5667: Minimum
      bit depth for serializing color() values)


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Dec/0011.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Jonathan Kew
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  François Remy
  Morgan Reschenberg
  Jen Simmons
  Miriam Suzanne
  Lea Verou
  Greg Whitworth
  Jeffery Yasskin

 Hui Jing Chen

Scribe: dael

  astearns: First is if anybody has amendments to agenda. We will pull
            item 9 up to probably 5 because leaverou can't stay on long
  <leaverou> thanks astearns!

  rune: I have an announcement
  rune: At Google we are exploring containing queries. We are figuring
        out how you can implement and what spec may look like
  rune: Was brought as 1d containment last call. I wanted to announce
        we are working on it and communicating about it on chromium
        slack. Any input from other vendors is welcome
  astearns: Great you're discussing. Don't know if slack is best
  rune: That's where contributors to chromium discuss. We'll bring to
        WG things to discuss more globally
  astearns: Great. Questions?

Next virtual long-form meeting (early Feb?)

  astearns: We usually meet end Jan, early Feb.
  <fantasai> https://www.timeanddate.com/calendar/

  astearns: Rossen asked last week for discussion on the ML. I didn't
            see any. Unless there's a strong opinion about time we may
            just pick a week in early Feb and slot some times to get
            together in longer form
  Rossen: This is also the time when we discuss if we want 2 or 3
          meetings + TPAC. I don't have visibility of when TPAC is. If
          it's later might make sense to have 3 additional. If it's
          earlier like Sept perhaps 2. If anyone knows it would be
  Rossen: We should try to decide before we start to pin dates

  hober: One thing I would like group to consider after experiment
         with TPAC is maybe group should not meet during or near TPAC.
         Personally between the sections I found the 3 week slog
         exhausting. I think it would be good to have WG avoid a month
         on either side of TPAC to not overburden.
  <florian> +1 to hober
  <gregwhitworth> +1 to hober
  <Rossen> +1 to hober
  astearns: Yeah. Agreement on IRC. I like the idea of not overloading
            if it's virtual
  <rachelandrew> +1 if it is virtual no reason to bundle them
  <leaverou> +1 to only joint meetings during virtual TPAC

  chris: Reason we went from 4 to 3 meetings was travel budgets type
         of thing none of which applies to virtual. I think we could
         have more. If we have 4 before TPAC we get more work done
  chris: To hober's point, I totally agree. Virtual TPAC means we
         should focus on joint meetings. We should push our meetings
         out since it's virtual
  <Rossen> chris, Travel and time away from the office - travel is not
           a problem but time away is still there
  <gregwhitworth> I wouldn't mind a once per month 2-3 hour session

  fantasai: I was going to suggest more often seems to make more
            sense. We frequently fill the agenda and it's not like
            people need to travel. We don't know TPAC time. Seems more
            like late Oct or Nov so there's more of a chance for in
            person. I think we should plan for more
  astearns: I believe all our virtual meetings this year we did not
            get through agenda. Slightly more frequent might get
            through issues

  florian: I will insist some fall in daytime my time is we have more.
           I understand most people don't live in Asia but some do. If
           we have many of them some should be at hours nice to people
           in my time
  astearns: I thought I was careful to make sure half was in favorable
            times to you
  florian: Somewhat the case. When I have meetings that end at
           midnight or start at 5am I find myself thinking better than
           3am but they're not great. If we're having many meetings I
           would like some during my actual work hours. I know not
           most will, but if there are many I'd like some at nice hours
  astearns: Okay. We will continue on private list. Rossen and I will
            propose something and then we can talk about it and
            further meetings.

Reminder for re-joining group next week

  astearns: Everyone will be forced out and have to re-join because
            we're opting in to the new patent policy. Everyone has to
            click some boxes on a web form. If you don't get it by
            early next week please let me know.
  astearns: Just an FYI

  Rossen: One more before technical agenda.
  Rossen: Plan is to take the last 2 weeks of Dec off
  astearns: Yes. We will meet next week and then no meetings for the
            last 2 weeks of the year. It's been a long year, there are
            holiday,s people need time.

CSS Text, CSS Fonts, and CSS Text Decor

Distinguish applying to text vs applying to boxes
  github: https://github.com/w3c/csswg-drafts/issues/5303

  fantasai: Looks like chris merged the PR. This will change applies
            to line for as many specs as I can think of. I guess heads
            up it's merged. There were questions about writing modes
            where so far text-combine-upwrite does apply and
            writing-mode does not
  fantasai: css 3 text we're getting toward 0 issues. If i18n and tag
            sign off I'll ask to transition next week
  florian: On testing front we're doing pretty good. Large amount of
           tests and gaps documented. We have test for many things.
           Don't need all for CR.
  astearns: Any other bits on this?
  astearns: It was just informative? No resolutions?
  fantasai: I guess if we want to close 5303 which is the bug
  astearns: Since PR is merged yes I assume
  florian: Might have missed some, but none was wrong. Can open new
           issue for anything missed

CSS Conditional 3

Inconsistent phrasing around placement of @import rules
  github: https://github.com/w3c/csswg-drafts/issues/5697

  jeffery: Looks fine
  fantasai: Remaining question is there is a stylesheet construct that
            isn't for entire style sheet. Confusing and should change.
            Should we file as separate issue? Concerns?
  astearns: Tracked as a separate issue
  fantasai: Should we resolve it should be changed?
  astearns: Why don't you raise the separate issue, discuss there, see
            if anyone disagrees, particularly TabAtkins.
  astearns: We'll close this as editorial?

CSS Variables

Higher level custom properties that control multiple declarations
  github: https://github.com/w3c/csswg-drafts/issues/5624

  leaverou: There is a very reasonable TAG guideline that custom
            elements should use properties for presentational
            elements. With current state of custom properties this is
            impossible for non-trivial
  leaverou: Current custom properties can only be literal fragments
            and you need to transform
  leaverou: There are problems where we need to add inline
  leaverou: However, when you have lots of these properties
            intersecting then it can get really messy if only 2 you
            have is inline functions that need both conditions.
  leaverou: Ideal is something to cascade but not sure feasible.
            Wanted implementor feedback and then I can draft a more
            detailed proposal
  leaverou: Examples I've looks at from component liberties are in the
  leaverou: Some impl have weighed in in the issue [missed]
  leaverou: Wondering if set of constraints could be introduced to
            make it more feasible. Wanted to bring to attention of
            group for more ideas or thoughts

  astearns: Feedback on the shape of the feature?
  fremy: I think it's a pretty good idea.
  fremy: Really something that's a limitation of custom properties.
         Quite true when you use attributes you do more than reuse
  fremy: Pseudo class you can't use in theory but it would be really
         nice to have syntactic sugar. I know you can do it meta
         languages. Good to auto-prefix with an if() condition. That
         would give us most of advantages. Extend the css selector
         syntax to have an id for all properties
  <TabAtkins> Assuming we're fine with simple conditionals in an if()
              function (which we've discussed before and this should
              be okay), doing an at-rule inside holding a block of
              props could have a reasonable desugaring to that.
  <TabAtkins> It would have some side-effects - any properties in the
              block are effectively using a variable, so it would kick
              in IACVT [invalid at computed value time] behavior, etc.
  leaverou: One thing to keep in mind is these often need to control
            multiple elements in the component. Alignment might need
            to control margins and padding. Ideally should work
  leaverou: [missed]
  leaverou: Often they need to control properties in mutli elements.
            Example alignment controls spaces, padding, etc in multi
            child elements. Good to keep in mind that it plays nicely
            with nesting module
  leaverou: Some reasonable syntax to combine and falling back to
            invalid at computed value time would prob be acceptable
  <leaverou> As long as we can combine conditions and nest them,
             having IACVT as the ultimate fallback is acceptable
  <fremy> @TabAtkins: I would think it solves many issues
  <TabAtkins> so like `.foo { color: blue; @if (var(--state) = one)
              { color: red; } }`, it'd desugar to `.foo { color: cond(
              var(--state) = one, red; blue); }`
  <TabAtkins> The nice part of this is that it inverts the grouping
              from "all variants of a given property" to "all
              properties associated with a given variant", which can
              be much more readable in some circumstances.

  astearns: I think this is a really interesting proposal and I'd like
            to see further discussion on what we can do here. Any
            major concerns about spending time on this?
  astearns: I think we should take this back to the issue and/or come
            up with a proposal which we can file issues on. It's a
            really good idea. Anything else from group?
  leaverou: I primarily wanted to draw impl attention. I can't design
            impl needs. Continue on issue is fine

Grid, Flexbox, Quirks

Avoid percentage height quirk in new layout models
  github: https://github.com/w3c/csswg-drafts/issues/5545

  oriol: This is about this % quirk. When in the block axis you have %
         and your containing block has auto height in quirks mode
         sizing skips the ancestor until it find another with a
         definite height and resolves % against this
  oriol: For compat reasons must happen in flow layout. Quirks spec
         says shouldn't happen for grid and flex
  oriol: I'm proposing we should say quirk should not skip over grid
         and flex items
  oriol: The current behavior chromium has where grid item with auto
         height and inside an element with % height it's resolved from
         grid area not grid item. If item is stretched the height is
         supposed to be definite. But knowing if we will stretch
         before is tricky and I think it's bad to propagate this to
         new layout modes
  <fantasai> wfm
  oriol: Firefox does not skip grid and flexbox items. WebKit skips
         flex not grid. Chromium skips both. I think we should align
         with Firefox and never skip
  TabAtkins: I'm very satisfied to limit quirks here if other impl are
  <dholbert> I'm happy to align with the Firefox behavior. :)

  iank: I'm okay with this...it's a pretty late hour to do this change
        to flexbox in particular but also grid. Chromium can try but
        might have revert if there's web compat issues.
  iank: I think WebKit is closer to Chromium than issue says and I
        think it exposes a WebKit bug. I'm okay with this but want to
        reserve the right to go back if there's compat issues

  Rossen: One thing to double check, you said quirk shouldn't apply to
          anything in grid and flex items. I didn't hear you say
          anything about grid and flex items themselves
  oriol: Grid and flex items have grid or flex container parent and
         spec says about that already so already not happening.
  Rossen: Means later subgrid as well. If we all agree with rule,
          which makes sense, but we should define anything in a grid
          boundary should not have to take the quirk
  oriol: Not sure I would go that far. A grid item can have varied
         structure. If you have nested block we could keep the quirk.
         Maybe breaking that on whole tree of grid item would be more
  Rossen: Having had to impl this quirk twice it's super nasty. Less
          we have to do it the better. If we can't get away, it is
          what it is

  iank: I forgot to say a couple things. Would it be possible to
        instead of relying on quirks spec pull it into flexbox and
        grid specs? Quirks spec doesn't necessary spec correctly and
        leaves open to interpretation
  iank: Also, would have been nice if when Firefox did the change this
        was brought up
  dholbert: Sorry, I don't think I did enough testing of other
            browsers when impl. I was aligning to quirks spec, I think.

  dholbert: To forbidding quirk inside grid I think best way to think
            is it tunnels up through blocks and if you hit an
            unsupporting container it just stops. If you think of flex
            and grid as an unsupporting container you have it. It's
            not that flex items are special but that flex and grid
            container are special
  Rossen: I believe this is the exact issue. If flex or grid item fits
          the bill and has a spec height you can use in quirks
          algorithm this item can later stretch with a lot of
          properties that effect fixed height.
  Rossen: Fully agree we should have a stronger rule here about flex
          and grid items to have them not partake in quirks.
  Rossen: I don't disagree with anything you say, but the less we can
          have the nasty quirk the better

  fantasai: Note on edits, I don't think makes sense to have in flex
            and grid. It's really a special behavior for block and
            anything other then that should not have quick. Quirks
            should say these boxes do this thing and if you hit any
            other kind you terminate.
  fantasai: In flexbox and grid we'd have to list a lot of exceptions.
  astearns: I agree it should be defined in one place
  fantasai: We don't have a block layout spec so we don't have a place
            to put it
  astearns: I was thinking flex and grid specs could have a note
            saying we're not doing this thing for the reason it defines
  fantasai: I don't think there's a natural place to put that. Update
            the quirks mode spec, at some point it goes into a block
  oriol: Quirks mode mentions block containers, but grid and flex can
         be block containers
  fantasai: Whatever correct term is. Seems related to block layout
            and not about flex or grid. It's not an exception, it's
            block being special and that shouldn't have anything to do
            with flex and grid items
  Rossen: sizing?
  fantasai: It's special for blocks.
  Rossen: We have a lot of sizing things that do apply to not
  TabAtkins: I don't mind sizing since it will apply to table sizing
             as well

  astearns: Do we need a resolution to move the definition of the
            quirk to sizing and be explicit about how it does not
            apply to grid and flex items
  fantasai: Need to say it's only blocks and tables.
  astearns: Might be good to have as an example because has been
            implementor confusion
  plinss: Need to be careful about is this really a quirk and only in
          a compat mode or is this normal css behavior?
  fantasai: It's not normal.
  plinss: Then it should stay in quirks and not be in a normal module
          in my opinion
  astearns: Fair. We do need to firm up the definition
  fantasai: dholbert do you want to propose a change to quirks spec?
  dholbert: I can take a look at it.
  dholbert: Firefox behavior falls out of how I understood quirks
            spec. I'll take a look
  <jensimmons> I do think we need something to help future
               implementors / anyone who doesn't remember this call to
               know what to do if they are implementing Flex/Grid/
               Future stuff. Something far off on the side is too off
               in the side. A note, as Alan suggested, or something
               would be good.

  astearns: Proposal: dholbert to make a change to quirks spec to
            clarify behavior in this case
  astearns: And iank is okay with it being tried in chromium to check
            for compat
  plinss: Is this only in quirks or is it certain conditions of normal
  ??: Only quirks mode
  astearns: Objections?
  iank: Test would be nice as well
  astearns: Yes. Test would have shown this earlier, but thanks oriol
            for finding. Can you write tests?
  oriol: Didn't hear
  astearns: Will need tests to show we have interop behavior. Could
            you commit to adding tests?
  oriol: Yeah
  oriol: I think Firefox already has tests. I'll look better and write
         some if needed
  astearns: Would be great to have in WPT

  RESOLVED: dholbert to make a change to quirks spec to clarify
            behavior for flex and grid items and containers

  astearns: Anything else?

CSS Color 4

Minimum bit depth for serializing color() values
  github: https://github.com/w3c/csswg-drafts/issues/5667

  chris: Request for impl feedback. Spec says you must preserve 8
         bits. Fine for sRGB but not for other color spaces. 2020 min
         is 10 and recommended is 12. smfr said they're storing as
         floats so they're good with whatever
  chris: I think TabAtkins said it's 16 bit range. Would be great to
         have more confirmation. I thought Chrome canvas rejected it
         because too many bits
  chris: Haven't heard from Mozilla

  smfr: I want to clarify something. Careful to distinguish between
        bits to store css color values vs depth of backing store.
        Backing store can use half float. Have to be very specific
  chris: Internal storage where when you serialize for OM you can
         return with specificity
  smfr: And that has not round-tripped between buffer
  chris: Right
  chris: Given that clarification can anyone from Mozilla answer?
  astearns: Anyone from Mozilla willing to commit to finding the
  astearns: Or could say who we could ping
  dholbert: Start with emilio maybe. Not sure

  astearns: Chromium clarification?
  rune: I thought we just stored 32 bit.
  chris: I mean 8 bit per component which is not sufficient except for
  chris: I think TabAtkins was talking about future plan
  <chris> 16bit half float
  TabAtkins: What I heard is plan to handle higher color profiles was
             to switch underlying texture to be a 16 bit half float
             per channel. It gives more than 8 bits of precision.
             Don't know how that reflects rest of stack
  smfr: But this is not about texture formats
  TabAtkins: Underlying format of images we use to paint
  smfr: This is storing colors in css data structure
  TabAtkins: But if we're planning to deal with half-floats I presume
             we'd reflect across internal stack
  <smfr> generally code wouldn’t use half-float in data structures, so
         you’d probably store floats
  chris: Clear, but can you get someone to confirm. Else I'm going to
         start putting bigger minimums and don't want people saying
         can't do that.
  iank: Not sure explicit details. I think we did have concerns about
        increasing size of representing colors. I can find out about
  chris: That would help, thanks
  <emilio> in Gecko we store 32-bit integer, 8-bit per channel of rgba
  <emilio> But we're going to probably do something else for new color
           spaces or what not
  <smfr> iank: webkit just sets a bit that says “go look at this other
         data structure"
  chris: 8 bit is a nice round stable thing. If you go beyond you
         basically use 16 bits unless you're packing
  <emilio> Yeah, same concern iank mentions about growing too much
           style data structures
  <emilio> At least when they're not using non-rgba colors

  chrishtr: When you say min 10, 12 bits what section?
  chris: Serialization on how you get back string of a color spec. How
         many digits do you round to. 2 digits is 100 values which
         isn't enough.
  chris: I had said 8 bits but needs to be higher because will get
         bounding. Depends on the space how many bits to avoid bounding
  chrishtr: And what to know if min would be too large and make too
            large memory buffer
  chrishtr: I think need min possible because memory constraints are
            possible. Memory is main reason I hesitate to add these
            color spaces to chromium
  smfr: Spec allows 8 bit even if allow extended svg. We render P3
        colors because render to another color space. I don't think
        this requires all buffers to be half float
  chrishtr: To represent all things in color space you need more
  smfr: Potentially yes
  chrishtr: So you have 8 bits and map with different transfer function
  smfr: Yeah, might get bounding. Have been shipping for years on iOS
        and no complaints.
  chrishtr: Is that compliant
  chris: Spec doesn't say how many to render. Purely on rendering
  chrishtr: Serialization or interpolation you need the bits. But if
            browser uses lossy way to render that's quality of impl
  chris: It's fine. Most frame buffers are still 8 bits. It's avoiding
         cumulative rounding errors in processing which can blow up
  chrishtr: Got it, thank you

  chris: Sounds like we shouldn't close because need to get back.
         Happy with discussion and okay to move on
  astearns: Sounded like people are okay with spec something here

  chrishtr: smfr, how many bits do you use in the WebKit CSS data
  smfr: If color is P3 we set a bit in our color data structure saying
        interpret this as a pointer to another data structure and the
        other data structure has the bits. We only pay the cost if
        it's outside sRGB
  chrishtr: If page had a bunch of P3 it would use 4 floats for every
            color in CSS in the stylesheet, but not for every pixel
  smfr: And only colors that are spec that way, not every color
  chrishtr: And that's not similar memory impact because not common
  rune: Current Chrome impl uses 64 bits. 32bit RGB and flags on
        either side. System colors are keywords too
  chris: That sounds like nice impl. Only pay cost if you need it
  chris: Thank you! This is all I wanted to know

  astearns: Only have a couple minutes. Not sure anything on the
            agenda that's 2 minutes
  astearns: I'll close the meeting early, thank you everyone

Received on Wednesday, 9 December 2020 23:56:04 UTC