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

[CSSWG] Minutes Telecon 2022-05-04 [css-variables-1] [mediaqueries] [css-flexbox] [css-colors] [filter-effects] [selectors] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 5 May 2022 06:13:20 -0400
Message-ID: <CADhPm3sgkCrgR9=xPa7VJNVyvT0gou=xfMGvLU1PkxnDzAOGwg@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 Variables 1
---------------

  - RESOLVED: Move CSS Variables 1 to CR Snapshot after May 9

Media Queries
-------------

  - RESOLVED: In all levels of MQ we will make 'layer' syntactically
              invalid media type (Issue #7225: Restrict 'layer' from
              the <media-type> production?)

Flexbox
-------

  - RESOLVED: Not required to re-wrap from column flexboxes in order to
              avoid overflow (Issue #6855: Multi-line column flexbox
              fragmentation)

CSS Colors and Filter Effects
-----------------------------

  - chris will write up text for the proposal to add new color
      interpolation and change the default and add it to issue #7100
      (Should no-op filters produce different output from no filter?)
      for further discussion. They'll also pull in more implementers to
      ensure the proposal can be implemented.

Selectors
---------

  - RESOLVED: Name is :modal for pseudo-class. It is defined as the
              element/dialog that restricts interaction to everything
              as described in the issue (Issue #6965: Add :modal-dialog
              pseudo-class)

CSS Text
--------

  - RESOLVED: Text area will rely on text-space collapse and break and
              those properties will be defined in Text 4 (Issue #6309:
              whitespace inside text areas)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0000.html

Present:
  Rossen Atanassov
  Tab Atkins Bittner
  Elika Etemad
  Simon Fraser
  Mason Freed
  Megan Gardner
  Chris Harrelson
  Dael Jackson
  Ian Kilpatrick
  Daniel Libby
  Chris Lilley
  Peter Linss
  Alison Maher
  Florian Rivoal

Regrets:
  Delan Azabani
  Jonathan Kew
  Miriam Suzanne
  Sebastian Zartner

Scribe: dael

  Rossen: 2 minutes past. Still a little lite on attendance but should
          try and get going
  Rossen: As usual, first is any changes to the agenda?
  Rossen: I saw a request to skip item 4 which we will do
  Rossen: Anything else?

CSS Variables 1
===============

Horizontal Review #6808
-----------------------
  github: https://github.com/w3c/csswg-drafts/issues/6808#issuecomment-1114959228

  Rossen: Transition to CR snapshot. Understanding we're ready by end
          of this week
  Rossen: Anything else you want to talk about before resolution?
  chris: Not really. Went through horizontal review including TAG so
         all ready
  Rossen: Awesome. Everything but security review is done; security
          review times out on 8 May
  chris: Correct
  Rossen: Then in position to move to CR snapshot
  Rossen: Additional comments or concerns? Otherwise will call for
          objections
  Rossen: Objections to Move CSS Variables 1 to CR Snapshot after May 9?
  <florian> go for it

  RESOLVED: Move CSS Variables 1 to Snapshot after May 9

  Rossen: chris will you handle?
  chris: I will
  Rossen: Thanks

CSS Lists
=========

counter-reset in UA sheet causing some compat issues
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7227

  Rossen: fantasai can we do this without emilio?
  fantasai: Better to have him

Media Queries
=============

Restrict 'layer' from the <media-type> production?
--------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7225

  florian: We have a syntax ambiguity. When you do @import if you write
           @import <url> layer it could either mean import layer or it
           could be a MQ for a media type called layer
  florian: TabAtkins suggests in MQ 4 spec we declare layer cannot be a
           media type so if you try and parse that way it's a syntax
           error. When used in MQ it wouldn't work and when in @import
           it's a layer
  florian: Mostly doesn't change anything because layer isn't a valid
           media type and is not proposed. Error handling is slightly
           different. If you do @media not-layer it would handle
           differently. Unlikely this is being done
  florian: I think TabAtkins suggestion is good and we should go for it

  Rossen: Process question- MQ 4 is a CRD. How close are we...would
          that reset anything in terms of MQ 4 process?
  florian: I don't think it would. MQ 4 is largely waiting on tests and
           impl. It's not really a new feature, it's error handling.
           Adding it to 5 would make 5 incompat with 4 and we'd have to
           patch 4 eventually.
  florian: Possibly want to add an errata in MQ 3
  Rossen: Yeah, do we need to?
  florian: Probably in ED at first, let it sit to make sure we don't
           change our mind, then include as a correction
  Rossen: Sounds good. Let's proceed with MQ 4

  Rossen: Additional suggestions or ideas?
  Rossen: TabAtkins is trying to join
  florian: We're taking his proposal anyway
  <TabAtkins> yeah, no need to comment
  Rossen: Not hearing anything else
  florian: Prop: In all levels of MQ we will make 'layer' syntactically
           invalid media type
  Rossen: Objections?

  RESOLVED: In all levels of MQ we will make 'layer' syntactically
            invalid media type

  Rossen: We'll worry about errata later
  florian: I'll put in the ED for now

Flexbox
=======

Multi-line column flexbox fragmentation
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6855

  alisonmaher: I think fantasai put this on the agenda so could do a
               better job summarizing
  fantasai: We were gonna spec the behavior but had questions about
            exactly what to spec in terms of fragments influencing
            sizes of boxes
  fantasai: Let's say you have 4 boxes inside container and splits
            across pages. Point it fragments can cause flex items to
            get taller which changes alignment and space distribution
  fantasai: Ideally no overflow. Author doesn't expect overflow because
            said to wrap
  <Rossen> example being described -
https://github.com/w3c/csswg-drafts/issues/6855#issuecomment-1102928864
  fantasai: Question is do we want to put an algorithm that requires
            passing info and possibly re-wrapping or do we want to have
            overflow? What are the consequences of fragmenting that
            we'll accept

  iank: I can touch on this for grid since has similar problems
  iank: Grid will run the full layout algorithm, get where everything
        is and size. Then it will perform fragmentation step
  iank: There's just small adjustments when it makes sense. If a grid
        item is auto-height then we will grow out that item and shift
        things below it down. Try not to cause overlap. Similarly will
        stretch other grid items
  iank: When looking at flex wanted to follow similar. When you try and
        rerun is a problem. Similar where you run algorithm once and do
        fragmentation fixups seems good solution
  fantasai: Difference between grid and flexbox, grid you placed the
            items in the rows. If the author has over-constrained then
            you overflow, but if it will fit there is no problem.
            Flexbox you run for a column, see what fits, and then wrap.
            If you grow because the stacking you will overflow the box
  iank: Unless box is auto height
  fantasai: In which case you wouldn't wrap
  iank: Right. I think this is relatively rare for flexbox columns.
        Fundamentally issue with fragmentation is in order to fragment
        you need to place in fragmentainer. Codependency on position
        and size
  iank: I don't think it's bad...most of the time if opt for new column
        there may be space under. Most of the time expansion is small.
        Don't know if it's much of a problem in practical
  fantasai: Could be an image. Point is are we going to overflow when
            frag and is that acceptable
  iank: I think cases would be rare and it's acceptable
  iank: alisonmaher did you want to add anything?
  alisonmaher: Not much to add. Agree. Note for out of flow frag we'd
               overflow or go past the end if end aligned. Doing
               similar is not too big a problem

  fantasai: I don't think overflow bottom aligned stuff is great idea.
            Authors bottom align a lot and don't expect overflow when
            print. Case with columns and wrapping you don't have a
            choice, but for alignment there's all that space you could
            have used to fit the item. Overflow doesn't make sense
  iank: Alignment topic has same problem in grid. If you center or
        bottom align have potential to overflow. If you don't do that
        algorithm becomes impossible to impl
  iank: In order to know how large something is you have to place, if
        you change placement need to resize
  fantasai: Not impossible, but really unpleasant if layout from top to
            bottom. Could do from bottom to top, but I don't expect that
  fantasai: More important to align correctly or not have overflow when
            print? Or a way to not have either problem
  Rossen: It's important to make sure we have a stable algorithm so we
          don't run into performance clips that would be terrible when
          not printing
  Rossen: With infinite time we can compute beautiful layouts, but want
          to make sure this is close to linear
  fantasai: I don't think linearity is problem there. I can accept
            fixed height column wrapped fragmenting is rare. I don't
            think that is true for alignment in general. I don't think
            we should overflow content when printing things bottom
            aligned. More complicated and simpler ways to avoid, but
            shouldn't cause overflow on layouts that should never be
            overflowing in the common cases
  fantasai: But that is separate issue
  iank: Yeah. Happy to discuss more
  iank: When I experimented with grid only happens when item itself
        fragments. Mitigation is something like break inside a void
  fantasai: People do entire page layouts in grid, though. A lot of
            grid layout where you don't want to break, but a bunch
            other with flow content that expects to break across
            multiple pages

  Rossen: How do we want to move forward?
  florian: Seems to me we have multiple similar but distinct situations
           here
  florian: fantasai argument makes sense, but there is question of
           implementation complexity. Are there subcases in here where
           we can decide or do we need it all in one go?
  iank: Fragmentation has codependency on position. For block and table
        always know position before layout. When introduce alignment in
        grid and flex sometimes have this not typically
  iank: When you position it effects size, sometimes in large and
        unpredictable ways. Moving one px might be drastic because have
        a 100px monolith in it. Without testing every px can't know
        size at a position
  iank: I'd be against saying test every position, but that's the impl
        complexity
  fantasai: You don't have to do that to prevent overflow. You could
            say that if it fragments such that it will overflow, you
            don't align but instead start-align so it fits.
  fantasai: If you want lots of work but great you can frag
            bottom-aligned containers separately, but wouldn't recommend
  iank: Can't do if content has overflowing content inside
  iank: I think this is slightly separate from the issue
  fantasai: Yeah.

  fantasai: For case of column wrapping stuff I think it is rare enough
            that if it overflows and looks like a mess the user will be
            unhappy but it's rare. If we want to cause overflow I'm
            willing to accept for this one. not willing to accept for
            normal alignment and common things. It's more important to
            avoid overflow than to honor alignment
  <florian> +1
  Rossen: So, iank or alisonmaher what's your position? Continue
          thinking more?
  iank: For alignment should open separate issue. This is complicated
        stuff. We should discuss separately
  Rossen: If we open the alignment issue, what can we resolve for this
          issue?
  iank: I don't think we need to resolve on anything. Maybe wrong
  Rossen: fantasai anything to keep this issue open?
  fantasai: Need to resolve that fragmentation algorithm for
            column-wrap flex containers can cause items to overflow
            even if would not have overflowed otherwise
  Rossen: I think that's an easy resolution to take
  fantasai: Specifically to avoid re-wrapping the columns
  fantasai: Not required to re-wrap the columns
  fantasai: to avoid overflow

  plinss: Can live with that. but I don't want spec language to say you
          must overflow. If you can do better want to make sure you can
  <fantasai> plinss++
  Rossen: Sure. Can resolve as may overflow
  plinss: Generally reluctant to have attitude that fragmentation is
          hard so let's do what's easy. Have been doing that for 25
          years and fragmentation has been broken. Rare is not
          justification to do wrong
  Rossen: Agree, but think you're overstretching. Everyone is trying to
          make fragmentation as good as possible. Edge cases we'll do
          in performant way
  plinss: Saying people can do simple because rare. Not happy with that
  iank: Yeah. We're focusing a lot of time to have a high quality
        baseline engine. Number of bug reports for fragmentation is
        very high so we see it's important use case
  plinss: I accept that and accept that impl is hard and bugs need to
          be prioritize. Impl won't always get it right. Want to be
          careful not to spec bad behavior
  Rossen: Fair. I think proposed resolution here for the described case
          it should be may overflow
  florian: We've had other cases where spec may where no one felt they
           could do good thing at the time and then we could eventually
           remove it. Let's keep the door open
  Rossen: And I think great work happening across the board on
          fragmentation so hopeful we'll get there

  fantasai: Proposal: not required to re-wrap from column flexboxes in
            order to avoid overflow
  Rossen: Additional comments?
  Rossen: Objections?

  RESOLVED: Not required to re-wrap from column flexboxes in order to
            avoid overflow

  Rossen: Let's open new issue for alignment case

CSS Colors and Filter Effects
=============================

Should no-op filters produce different output from no filter?
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7100

  smfr: This is the problem where filter like blur-0 flattens p3 colors
        to srgb per spec but impl, chrome always and some webkit, will
        propagate p3 colors through filters
  smfr: chris suggested new value for color interpolation, but doesn't
        solve problem I'd like. Spec doesn't match impl and I'd like
        them not to flatten P3 colors
  chris: Suggestion seemed to be compositing is in device color space.
         All filter operations or just compositing?
  smfr: I believe impl are running filter operations in display color
        space which is P3 and close to srgb
  chris: Looks okay but is wrong. What I suggested would fix that but
         doesn't fix existing issue
  chris: Slightly concerned about making it do what you want because
         makes it hard to test if it's behaving correct. Not completely
         opposed but want to get it right

  smfr: svg filters are spec in srgb color space and all constants work
        in srgb. One approach would be how to spec those in lab color
        space so impl can filter in that
  chris: lab not good choice. svg are linear srgb not gamma encoded. I
         suggested an extended linear srgb. Outside P3 clor would be
         fine. If want to upgrade whole thing to another color space
         then xyz would be a better choice then lab.
  chris: Doing in extended linear srgb would give you same result if
         not clipping
  smfr: Might be possible

  chris: You and I are attacking different bits of problem and maybe
         can do both
  smfr: You mean add new color interpolation and change default?
  chris: Yeah

  Rossen: Possible in current impl or compat issue?
  smfr: Won't match what impl do. Would be significant work in one
        webkit codepath
  Rossen: Academically good, but would be avoided by impl
  smfr: Our slow path, CPU based which is 8-bit unsigned. We'd have to
        change that to floating point or non-8bit
  smfr: Our codepath with GPU is assuming srgb so applying that to
        values in P3 which happens to work most of the time. Probably
        what Chrome does too
  Rossen: chrishtr do you know if that's what you're doing?
  smfr: For GPU accelerated you're feeding through P3 color values when
        using srgb matrix?
  chrishtr: Not sure, need to talk to Chris Cameron (?)
  smfr: Would be good to see if willing to change to chris suggestion
  chrishtr: Is that in the issue?
  smfr: Yes, thing so
  chrishtr: I'll re-read and ask Chris
  chris: Please also get back to me in issue if something not clear.
         linear srgb extended should be GPU friendly
  smfr: This should come up with canvas filters too so someone should
        think about that case too

  Rossen: Sounds to me like we need to have more eyes on the problem
  chris: Agree
  Rossen: Want to capture proposed combined solution
  <chrishtr> +1 to issue
  chris: I'd rather write it on the issue instead of try and word on
         the fly
  Rossen: Alright, please add to issue
  Rossen: Anything else on this?

Selectors
=========

Add :modal-dialog pseudo-class
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6965

  chrishtr: We discussed at length, almost resolved on modal or
            modal-dialog. Question if modal is well defined or slightly
            different.
  chrishtr: Spoke offline and now agree modal or modal-dialog
  chrishtr: I propose we try and resolve on one of those two names
  Rossen: Do you have a favorite?
  chrishtr: Mine is modal and I think TabAtkins is modal-dialog
  TabAtkins: I prefer mine, but okay with other. Temp check of group
             would be fine with me
  <fantasai> I agree with chrishtr's comment
https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1115460853
  Rossen: If this is only about naming I would straw poll. But I see a
          queue

  fantasai: I agree with chrishtr suggestion to define modal rather
            than modal-dialog and define using concept of modal as
            defined in comment. Not about being top-layer but about
            being a UI that limits interaction to dismiss pr interact
            with that thing
  fantasai: Can craft a definition that's clear when applies and
            doesn't so doesn't need to limit to just dialogs
  Rossen: Reasonable. Other opinions?
  <masonf> +1 to fantasai's comment
  Rossen: Objections to accepting modal?

  TabAtkins: Would still like straw poll
  Rossen: Okay, let's type opinions
  <chrishtr> :modal
  <fantasai> :modal
  <Rossen> :modal
  <smfr> :modal
  <plinss> :modal
  <dholbert> no preference
  <TabAtkins> :modal-dialog
  <masonf> :modal
  <dlibby> slight preference for :modal-dialog
  masonf: Can we also make the resolution that it's as defined in
          comments?
  Rossen: Yes, modal as defined in the issue
  Rossen: Sounds like besides TabAtkins there's only 1 slight
          preference for modal-dialog
  <fantasai> proposal: :modal defined in terms of limits on interaction
             as defined in chrishtr's comment

  RESOLVED: Name is :modal for pseudo-class. It is defined as the
            element/dialog that restricts interaction to everything as
            described in the issue

CSS Text
========

whitespace inside text areas
----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6309

  fantasai: This was filed and I wanted to close it out. florian and I
            think that there's not really a problem with having
            whitespace apply to text area as everything else. A bit
            weird how it applies, but author shouldn't ask if they
            don't want.
  fantasai: Prop: No whitespace magic on text areas, whitespace defines
            as on other elements
  fantasai: Then Chrome would need to do a slight change for that
  iank: History where this came from; I think it was a user affordance
        that some websites placed whitespace on text areas and
        difficult for users to edit those. That's the history.
  iank: Won't object to changing it
  Rossen: Other opinions?
  Rossen: Prop: Text areas whitespace behaves as it does on any other
          element

  Rossen: Objections?
  smfr: Concerned. Historically this tried to match OS conventions. I'm
        a bit concerned about a blanket make it behave like others, but
        don't have context to know good or bad
  iank: We were trying to match Microsoft Edge
  smfr: If I hit space multiple times that means I don't want it
        collapsed so have to but multiple nbsps. Does that get rid of
        this?
  iank: Yes, whitespaces would collapse
  smfr: Let's not get rid of that,then.
  smfr: I think users expect if you keep pressing space in text input
        you get multiple spaces

  fantasai: Alternative is in css text 4 proposed to split whitespace
            into 2 longhands. One for wrap and the other for collapse.
            That text is still under development, but could define the
            behavior here and saying UA has an important rule that
            prevents collapsing of whitespace and that way it's not
            magic
  <iank> Our mapping is normal->pre-wrap, nowrap->pre,
         pre-line->pre-wrap
  Rossen: How far is that definition. Can we resolve here and point to
          that? Or still pretty early?
  <fantasai> https://www.w3.org/TR/css-text-4/#white-space-collapsing
  fantasai: What we've got so far is there text-space-collapse
            property. Naming not sure if that's what we want. And
            break-spaces doesn't have a setting and need to make that
            work. Shouldn't be very difficult
  Rossen: Would that be fine if we define the behavior as split control
          between collapse and text-wrap.
  fantasai: Whitespace sets collapse and wrap at same time. And we
            would prevent collapse using UA !important rule
  iank: That's fine. We also do this in non-standard plaintext mode
  Rossen: That level of control can handle all permutations. Then it
          becomes UA specific if you want to match OS or anything else

  florian: One thing to check on. If we don't enforce through UI
           stylesheet there used to be a spec that claimed UA was
           supposed to let user press spacebar repeatedly and treat as
           space then nbsp, then space. Are we giving up on that?
  Rossen: We treated it as a preserve in Edge. I don't believe we
          flipflopped
  florian: I know it used to be spec
  iank: I don't think we implemented
  <smfr> i have a vague memory that Netscape 4 did
         <space>&nbsp;<space>&nbsp;….

  Rossen: We're overtime. Happy to resolve or we can do more discussion
  Rossen: Objections to resolve this as text area will rely on
          text-space collapse and break and those will be defined in
          Text 4

  RESOLVED: Text area will rely on text-space collapse and break and
            those properties will be defined in Text 4

  Rossen: We will have enough capabilities to preserve existing
          behavior and come closer in terms of impl
Received on Thursday, 5 May 2022 10:14:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 5 May 2022 10:14:01 UTC