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

[CSSWG] Minutes Telecon 2022-04-06 [css-contain-3][css-content][css-images-4][css-overflow-3][css-ui][css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 Apr 2022 05:55:15 -0400
Message-ID: <CADhPm3tUWsdrdZBj2KQwjYXcNkQtnJeQ8EUUyHf3YtP-dX60pQ@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 Contain
-----------

  - RESOLVED: Require the container name in the shorthand syntax (Issue
              #7142: container :/ size)

CSS Content
-----------

  - RESOLVED: 'none' does not compute to 'normal' (Issue #6503:
              Implementing content:none on elements is not
              web-compatible)

CSS Images & Overflow
---------------------

  - RESOLVED: Add this path forward to the spec with a note linking
              back to this issue (Issue #7144: How do object-overflow
              and object-view-box interact with overflow and
              overflow-clip-margin?)
  - A use counter will be added to track the current usage of
      overflow:visible on replaced elements. If the use counter comes
      back with data this might be a breaking change the group will
      revert the above resolution and go back to exploring a separate
      property to have this behavior.
  - The spec text written for the above resolution will need to add
      details for handling of overflow-x and overflow-y

CSS UI
------

  - RESOLVED: Add a URL parameter-specific version of image-set
              function to the cursor property (Issue #5831: Should the
              cursor property support image-set()?)

CSS Cascade
-----------

  - RESOLVED: Close no change (Issue #7083: Should 'revert' really
              treat animation origin as author origin?)
  - RESOLVED: Specify what browsers currently do (Issue #7054: revert/
              revert-layer with logical properties)

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

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

Present:
  David Baron
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Ian Kilpatrick
  Vladimir Levin
  Peter Linss
  Alison Maher
  Cameron McCormack
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

Regrets:
  Tab Atkins Bittner
  Delan Azabani
  Jonathan Kew

Scribe: dael

  astearns: Announcement- We are going to have a physical TPAC with
            hybrid meetings
  astearns: W3C management made the decision today they are going to
            hold the physical meeting. Working with A/V contractors for
            better cameras and mics for the event and to get good
            ventilation
  astearns: Agenda-wise we'll skip item 4
  astearns: Got a request to move item 6, but I don't see Chris yet.
            We'll move up to #3 unless someone else can take
  astearns: Okay, let's put it as item 3
  astearns: Other changes?

CSS Contain
===========

container :/ size
-----------------
  github: https://github.com/w3c/csswg-drafts/issues/7142

  miriam: Since last week the spec is now up to date with current state
          of all the syntax changes
  miriam: Only thing missing from ED is CSSOM resolutions. All syntax
          is up to date which should help with this conversation
  miriam: Sebastian pointed out in thread currently it allows the
          shorthand syntax for container which takes name and
          type...currently both are optional meaning it could be empty
          as well as original issue where if only a type have to start
          with a /
  miriam: Proposal here is we could require a container name in the
          shorthand
  miriam: since we are right now container type of style is default on
          every element and heavily encourage names. If you just need a
          type you can use the longhand
  miriam: That's the proposal. Open for questions
  astearns: If I recall correctly have plenty of places where
            shorthands cannot express every possible value longhands
            can do
  miriam: And you could express it, but have to explicitly use 'none'
          in name of syntax
  astearns: Proposal: Require the container name in the shorthand syntax
  miriam: Right
  astearns: Any concerns?
  astearns: Objections?

  RESOLVED: Require the container name in the shorthand syntax

CSS Content
===========

Implementing content:none on elements is not web-compatible
-----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6503

  dholbert: Basically we arrived at a point where wondering if
            content:none and normal should be 2 values as computed
            style or if it should be alias
  dholbert: Seems everyone impl as 2 values. I think that's new
            information
  dholbert: I think we want to stick with that unless reason to change
  dholbert: Some subtlety around how none resolves to normal and
            browsers disagree a bit but I think it's mostly known bugs.
  dholbert: I think this issue is no change, but not 100% sure. oriol
            has done more investigation and left useful comments.
            Curious his thoughts

  oriol: The thing is that in Blink while content:none and normal are
         different computed values you cannot observe it from webpages.
         One resolves to the other. Possible this could change. When I
         impl none I didn't want to risk compat but I didn't try.
  oriol: In WK there's a recent change from Jan where if set
         content:none gCS provides none. Otherwise get normal. So get
         different in WK and they didn't have to revert so seems it's
         web compat
  oriol: I think FF implemented and that's web exposed. So maybe can
         consider different and say resolve to themselves

  florian: I think historically the 2 main contexts were regular
           elements where content:none did nothing and before and after
           pseudo where "normal" was empty. marker forces difference
           where normal isn't empty but none is.
  florian: From there I think should try for as distinct as we can. If
           we have compat issues we can do to the extent required but
           should keep separate by default

  astearns: dholbert you suggested close no change?
  dholbert: I had forgotten what oriol mentioned. I tend to think we
            should wait to see how the WK change survives. If they can
            keep as distinct in gCS that's the simplest and I'm sure
            easy change for Gecko and Blink
  dholbert: Potentially resolve in favor of that but might be premature
            since WK has recently shipped so I don't know how much
            exposure it has got
  <florian> [seems reasonable to me]
  astearns: Make no resolution and leave issue open for now?
  dholbert: Yeah. Might re-agenda+ for another question. I think
            original request to make them compute to same I think have
            decided we don't need to. now question of if we can keep
            them distinct
  dholbert: I can add a summary on the issue
  astearns: Could resolve we're not going to have them compute to each
            other
  dholbert: Happy on that since it matches existing impl
  astearns: Proposal: none does not compute to normal
  astearns: Will leave issue open with summary from dholbert on what we
            need to see with time
  astearns: Objections?

  RESOLVED: 'none' does not compute to 'normal'

CSS Images & Overflow
=====================

How do object-overflow and object-view-box interact with overflow
    and overflow-clip-margin?
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7144

  khushal: Supporting css overflow and overflow clip
  khushal: All replaced elements clip to content box by default. Each
           except SVG don't support overflow. When overflow is on SVG
           it diverts
  khushal: SVG clips to content box and we don't support properties
           that make it scrollable
  khushal: Discussion on issue toward supporting overflow for all
           replaced elements similar to SVG. All values supported
           except those that make it scrollable
  khushal: Ways in clipping diverges instead of doing the behavior in
           engine retail with UI css. Because it's in UI CSS devs can
           override
  khushal: Want to mention that we brought up this question with
           overflow for replaced elements and talked about adding
           object-overflow to permit
  khushal: In trying to explain interaction with overflow we realized
           it was easier to do similar so we can remove this property
           from the spec

  smfr: Sounds like in proposal that you're allowing author to set
        overflow:visible on replaced element. Is that true?
  khushal: If a website had overflow:visible today and defaulted to
           clip, it would now apply and cause visible
  smfr: Seems like could be compat issue
  khushal: Did come up that it might break backwards compat. Applying
           this property on existing page wouldn't have worked and does
           now. Could try and get use counter for how often it's used
           to confirm compat isk is minimal
  smfr: 2nd question is UA applies overflow:hidden. Does that allow
        scripts to programmatically scroll?
  khushal: That's a way replaced elements have behaved differently.
           Script won't be able to
  smfr: Should UA stylesheet use overflow:clip?
  khushal: Yes, you're right
  smfr: Thought I saw issue on iframes. Is this proposed for that?
  khushal: Another issue about which elements to limit this. Security
           reasons for iframes so could make it !important so devs
           can't override for something like iframe
  smfr: When a replaced element has overflow because overflow:visible,
        ink or layout?
  khushal: ink overflow
  smfr: Different to overflow on normal element, right?
  khushal: Right. Had discussed for object overflow that overflow for
           replaced should be considered ink
  smfr: I think because list of issues I'm not a big fan, but want to
        hear others

  <iank> is it enough to support just overflow:clip & overflow:visible ?
  <smfr> what about overflow-x & overflow-y?

  florian: I overlap with some of smfr. You said all values except
           scroll. but all of overflow other than visible and clip
           support scrolling
  florian: You talked about UA using overflow:clip, but it said in
           issue if author did overflow:scroll it was like hidden but
           hidden is scrollable.
  khushal: It should say clip. Anything that defines scroll maps to
           clip for replaced elements
  astearns: And for values of overflow that are not clip or visible do
            we want them to work and make a scrollable thing or should
            they all function as overflow:clip
  khushal: Later. All overflow:clip for replaced elements
  astearns: So they only get clip and visible
  khushal: Right. Either clipped or visible

  astearns: Question on IRC about overflow-x and -y. If we set -x are
            things visible in -y?
  khushal: I think it's reasonable for overflow clip and visible to be
           different in x or y direction
  khushal: I'm interpreting if you set overflow-x:clip and -y:visible
           it will clip in x and not y
  <iank> I think part of the question is if you do overflow-y: scroll
         for example
  florian: Yeah, I don't see why different for this
  smfr: Yeah, sounds okay
  astearns: Other questions or concerns?
  iank: I think part or a question that needs to be answers if you set
        overflow-y:scroll what happens
  iank: There's various fixup today
  florian: I guess either you first fixup the other dimension to be a
           scrolling value and then they both become clip or you coerce
           scrolling to slip immediately and other remains visible

  chrishtr: 3rd alternative could be ignore values other than visible
            and clip. Can set but don't do anything. Compute to visible
  chrishtr: May be less confusing than apply some behavior but not all.
            It would clip but not scroll and might not know why
  astearns: Use counter suggested for overflow:visible. If we want that
            need a use counter for all the other values on replaced
            elements
  chrishtr: Then alternative is we could go with new css property to
            avoid the concerns. Does seem behaviors are similar to SVG?
  iank: chrishtr if I understand correct and we just do visible and
        clip are there compat concerns since clip hasn't been out long
  chrishtr: Good point. Coerce hidden and scroll to visible then it's
            only sites with overflow clip
  smfr: Isn't compat issue overflow:visible?
  vmpstr: Right, it's the other side
  smfr: And object:fit would leak pixels
  khushal: I think it's something like object:position that would leak
  smfr: aspect-ratio resize version of object:fit doesn't that cause
        bits of image to leak and if it's overflow:visible it adds ink
        overflow
  khushal: Right. If dev used overflow:visible and object-fit:cover
           they would get slipping now but overflow visible would start
           after this
  florian: Back to visible in 1d and scroll in the other...I suspect
           doesn't matter for use case because you can get one behavior
           so for impl PoV seems easier to add conflict resolution as
           is. Visible in 1 and scroll in other leads to visible
           dimension hidden and now both behave as clip
  florian: Suggest to me we don't need to change style computation pass

  khushal: 2 issues. First how to deal with overflow in x and y
           direction being different. If 1d says visible and other
           scroll we coerce to scroll and then clip
  khushal: Second is if it's set to visible in both directions where
           previously ignored and now visible. Is there a way to check
           or is this a deal breaker
  florian: Need use counter. If it's a lot it's a deal breaker but if
           it's rare maybe not a problem
  smfr: Do we know if reset stylesheets set overflow:visible
  iank: I don't think it's common. Might be wrong

  fantasai: I want to bring up opinion from TabAtkins in thread.
            Overflow as a property currently clips to padding edge.
            Type of clipping we're looking at is content box. Replaced
            elements are special magic or do we need 2 properties?
  fantasai: oriol mentioned 7188 with a use case for clipping replaced
            elements to padding box. Haven't looked in detail but worth
            considering before we decide to merge to 1 prop
  <fantasai> https://github.com/w3c/csswg-drafts/issues/7188
  khushal: Suggestion on issue for changing ref box is UI CSS rule. The
           discussion on issue was toward if start allowing overflow on
           replaced elements makes sense for overflow to work as well.
           Idea was default behavior is done with existing properties
           and devs can change
  fantasai: Okay
  <florian> that makes sense to me

  <heycam> wonder if it would be difficult to make the use counter
           check for overflow:visible only if there's ink overflow
  astearns: [reads IRC from heycam]
  astearns: I think use counter is of overflow:visible is set on
            replaced elements at all. If it is can evaluate usage to
            see if introducing ink overflow is going to be unacceptable
            change
  heycam: Just looking to see if can skip manual step to check influence

  astearns: Before we collect use counter, say the use counter gives it
            as very rare. Would anyone continue to have a problem with
            this change? Is it worth the use counter?
  smfr: Need use counter data because would be compat. If use counter
        data is okay I'm okay with it
  astearns: Use counter seems like the next step. Given the details
            about various values and which replaced elements this
            impacts and overflow-x and -y and writing all that down.
            Once we have use counter data we can come back
  chrishtr: So accept pending use counter?
  astearns: Resolution is collect data and wait to resolve until it's
            analyzed
  fantasai: With a bias toward accepting if use counter says it's okay
  chrishtr: I think reasonable in my opinion to accept change and if
            use counter says otherwise we revert
  plinss: Quick point on use counter data. I think if use counter shows
          a lot of usage it's easy to say no. If use counter shows
          little usage that doesn't mean it's clear. Could be a lot of
          data behind something like corporate firewalls. If use
          counter is extremely low fine, but if use count is marginal
          might be breaking more than we think
  astearns: As far as accept change for now and revert I do like having
            spec text as opposed to a summary
  chrishtr: I would point out failure is showing more ink overflow
            which is not that bad
  astearns: But could obscure content. Making things unreadable that
            used to be readable is something we have to avoid
  fantasai: Example from smfr about cover image that is visible outside
            of img element suddenly could be significant data loss. If
            we do find significant use. Currently doesn't have effect
            but if someone used overlay-general selectors could have
            effect
  florian: I think use counters are in engine so could get behind
           corporate firewalls, but wouldn't get offweb usage like epub.
  iank: Not necessarily. Depends on if org has opted into metrics
        collection. Orgs typically do opt out
  iank: Other point is we do have some use counter blindness. I don't
        think will be case for this. Corps tend to use frameworks so if
        we see something on public likely to see it in the blindspot as
        well. Fair bit of correlation for these rendering changes
  <fantasai> +1 to iank, unlikely to find this problem on intranets if
             open web doesn't show the problem

  smfr: I think might be first time we allow contents to overlap
        border. Makes me wonder if we spec the paint order
  fantasai: Same as other elements
  smfr: So paint on top of borders?
  khushal: Was going to add SVG allows overflow today and I think they
           draw on top of border
  smfr: Okay
  iank: So replaced elements paint in content phase?
  astearns: We have spec a content phase in painting?
  <fantasai> CSS2 appendix E
  <fantasai> https://www.w3.org/TR/2011/REC-CSS2-20110607/zindex.html#q23.0
  <fantasai> The painting order of border vs replaced content is
             already defined

  khushal: Another question - earlier resolved having new behavior
           thought object overflow which is new property where if set
           to visible only contents of replaced element can overflow.
  khushal: If we do see use counter usage is high enough that change is
           risky, would it be good to continue using object overflow
           and come back to group on how to handle if visible is
           defined?
  astearns: Makes sense to me. If what discussed today doesn't work we
            figure out how object overflow would work as a separate
            property for this use case
  khushal: Issue was if object-overflow as defined in spec exists how
           does overflow interact with replaced and my take away is it
           continues as is. We can come back for more concrete
           resolution
  astearns: So adding the path of using overflow on replaced elements
            in a draft
  fantasai: Add and mark as tentative pending data with a link to the
            issue
  astearns: Remove object overflow or put an issue on that?
  fantasai: I would go with remove from spec and mentioning in issue
            that if we can't go in direction we're trying we may
            reconsider
  astearns: Objections to Add this path forward to the spec with a note
            linking back to this issue

  RESOLVED: Add this path forward to the spec with a note linking back
            to this issue

CSS UI
------

Should the cursor property support image-set()?
-----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5831

  florian: Has always supported url production to point to image
  florian: Since css ui 3 spec says it's allowed to support image
           production to do image sets, gradients, etc
  florian: It's as a may because as of time for css ui 3 no one did it
  florian: Since then we have 1 shipping and 1 experimental of more
           than urls but supporting image-set function as long as
           image-set only contains links to urls.
  florian: One possibility is we keep spec as is. Other is we
           explicitly call out now that there's 2 impl is you can do
           url and this version and may the rest. 3rd is switch entire
           spec to using image production and encourage browsers to
           fill in what's missing
  astearns: Opinions?
  * fantasai has no opinion
  florian: I'm inclined to spec what is implemented. We were refraining
           because no one had done it. Still not all impl but since we
           have more spec that would be nice. Can't just use image-set
           production because no one does gradients.
  florian: Since we have multiple implementations we should spec it

  astearns: I think fine to spec what's impl. I assume there's no tests
            in wpt
  florian: I haven't checked. As a spec writer I didn't create
  iank: This just covers image-set. Also the image function. Was that
        impl?
  florian: Don't think so. Only seen image-set with URLs. spec allows
           more but I don't think anyone has impl
  astearns: Prop: Add a URL parameter-specific version of image-set
            function to the cursor property
  astearns: Objections?

  RESOLVED: Add a URL parameter-specific version of image-set function
            to the cursor property

  astearns: Please do add tests
  florian: Sure

CSS Cascade
===========

Should 'revert' really treat animation origin as author origin?
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7083

  astearns: Suggested resolution at the end from TabAtkins
  <fantasai> https://github.com/w3c/csswg-drafts/issues/7083#issuecomment-1083631261
  fantasai: We suggest for revert-layer no change. There are use cases
            and how set is most natural way. This issues is around
            revert. We suggest close no change because this is
            specified and impl. If people think treat same as
            revert-layer that is reasonable behavior; main problem is
            it's a change
  astearns: Prop: Close no change
  <miriam> +1 close no change
  fantasai: Yeah. Unless someone feels significantly better to behave
            same as revert-layer

  oriol: Initially I filed this because impl that way had some
         performance cost in WK and in Blink there was a comment saying
         it disabled optimization. In discussion of issue turned out
         changing wouldn't improve perf in Blink because disabled due
         to em units.
  oriol: So I think changing would not improve perf so we can close no
         change
  astearns: dbaron you commented. Is this okay?
  <dbaron> no objections
  astearns: objections to Close no change

  RESOLVED: Close no change

revert/revert-layer with logical properties
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7054

  fantasai: Proposal: Spec what's implemented
  astearns: Is that the whole things?
  oriol: The thing is what happens if you have mix of logical and
         physical and set one to revert-layer do you roll back to same
         ignoring pairing property?
  oriol: I looked at impl and all agree that first they run the escape
         and when have final writing mode turn them physical ones.
         Logical and physical properties convert into same mapping.
         Once resolved you revert into resolved property
  oriol: If you have margin-left and revert-layer and previously you
         set margin-start you revert to that.
  oriol: Proposal is revert after resolving the properties
  fantasai: Makes sense to user. revert is rolling back value on this
            property to what would have been if author stylesheet
            didn't exist and this has that effect
  astearns: Thanks oriol
  astearns: Objections to specify what browsers currently do

  RESOLVED: Specify what browsers currently do

  astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 7 April 2022 09:56:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 7 April 2022 09:56:56 UTC