W3C home > Mailing lists > Public > www-style@w3.org > December 2021

[CSSWG] Minutes Telecon 2021-12-01 [css-highlight-api] [css-contain] [css-cascade] [css-values] [css-scrollbars] [css-images]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 2 Dec 2021 07:14:37 -0500
Message-ID: <CADhPm3sOq=oMyR+jkP46bmDPqe5=bAS91ri8u0s2mMEwPh_UpQ@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.

Highlight API & Contain

  - The proposal to solve issue #4598 (Static ranges and css-contain)
      was to have static-range-backed custom highlights paint across
      paint-contain boundaries and allow changes in static range
      validity to also invalidate the intersection. On the call there
      were concerns expressed that this did not address cases where the
      paint-contain area is offscreen. Discussion will continue on
      github to work through this use case.

CSS Cascade

  - RESOLVED: Accept suggested behavior, where `revert-layer
              !important` in style attr only reverts the style-attr
              origins and the animations origin, ignoring other author
              origins (Issue #6743: `revert-layer` keyword in style
  - RESOLVED: Reject this proposal; unlayered styles have a specified
              location in the layer stack which can't (currently) be
              controlled (Issue #6323: Allow authors to explicitly
              place unlayered styles in the cascade layer order)
  - RESOLVED: Cascade 4 to CR
  - RESOLVED: Cascade 5 to CR

CSS Values

  - RESOLVED: Spec FF/WK behavior of eager simplification (Issue #4399:
              What should non-calc() math functions serialize to when
              they're fully resolved?)

CSS Scrollbars

  - RESOLVED: Change SHOULD to MUST in the normative text about UAs
              ensuring the scrollbars are wide enough to interact with
              (Issue #6675: Some scrollbars aren't accessible for
  - RESOLVED: Publish Scrollbars as a CR.

CSS Images

  - RESOLVED: object-fit affects the rendering of iframes with
              expressed intrinsic sizes (Issue #6817: Layout of iframes
              with content intrinsic sizing that does not match the
  - RESOLVED: object-position applies to iframes in the above case as
              well (Issue #6817)


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Dec/0000.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bo Cupp
  Elika Etemad
  Robert Flack
  Simon Fraser
  Chris Harrelson
  Sanket Joshi
  Vladimir Levin
  Peter Linss
  Cameron McCormick
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

  Jonathan Kew
  Chris Lilley
  Lea Verou

Scribe: TabAtkins
Scribe's scribe: fantasai

  Rossen: One agenda request about CSS images
  Rossen: Any other changes?
  <dandclark> Can we bump the highlight issue to the first 30 mins? I
              think Sanket is only available then
  chrishtr: Admin request: #6464, shared element transitions, could
            people please read the new explainer and provide feedback?
  chrishtr: We're having incubation community meetings that anyone can
            come to, let me know

Highlight API & Contain

Static ranges and css-contain
  github: https://github.com/w3c/csswg-drafts/issues/4598

  sanketj: There was discussion in a previous meeting to just add a
           paint step that ignores static ranges that cross a
           containment boundary
  sanketj: It didn't seem like it was something unique to the highlight
  sanketj: Selection also adds ranges, and they're allowed to cross
           containment boundaries
  sanketj: so if this should be disallowed for highlights, it should be
           done at a more general level
  sanketj: So Dan's proposal is that we shouldn't need to handle this
           case in the Highlight API specifically
  sanketj: but there's also a question of what forum this question
           should be taken up in
  dandclark: Even for live ranges today, if I'm using a live range to
             paint a selection, I can use the range API to make it
             encompass a paint-contained element and cause paint
             changes inside that contained element
  dandclark: So we already don't really pay attention to paint contain,
             and that makes sense - they're not really bound to the
             tree hierarchy
  dandclark: Before we were looking at this the wrong way - if I have a
             range across a paint boundary, and I remove the element
             that one end is on, we have to invalidate it and that
             requires more invalidation than seemed reasonable
  dandclark: But really this sort of invalidation is akin to live range
  <dandclark> Proposed resolution: Allow static-range-backed custom
              highlights to be painted across paint-contain boundaries.
              Changes in static range validity can invalidate an
              intersected element with paint-contain. This is OK, and
              we will document this interaction in the highlight spec.
  dandclark: So proposed resolution [above]

  florian: I think I disagree
  florian: Problem is not whether something crosses a paint boundary.
           Crossing is fine
  florian: The initial problem with static range is that if it starts
           outside the paint contain and goes inside, and the dom
           changes within the paint-contain area, and the paint-contain
           area is offscreen, then in that case there is part of the
           range inside and outside
  florian: The part that is outside isn't changing, it still goes up to
           the edge, but the part inside does change, because you
           changed the DOM. But that breaks an invariant of paint
           containment, that you don't need to worry about the painting
           of a contained element that's offscreen
  florian: I think that's different from your examples
  florian: If you have a live range that you change, so the part that's
           outside should be different, well you changed it, of course
           you have to repaint
  florian: With selection it's the same - if you change the selection,
           surely you have to repaint it
  florian: also, paint containment allows browsers to skip painting,
           and paint-based invalidation. it doesn't allow browser to
           skip dom updates.
  florian: So if dom updates you do still have to handle that
  florian: So that's why the live vs static range is important
  florian: live ranges are effectively part of the dom, so modifying
           the dom modifies the live range
  florian: but the point of the static range is that it doesn't get
           updated; the author is meant to take care of that
  florian: and it might get inconsistent where the entire thing
           shouldn't be painted
  florian: So statics can give us an inconsistent state that live
           ranges can't
  florian: Just not painting ranges that cross paint boundaries might
           not be right, we can explore this space more
  BoCupp: In both cases, it's the state of the range that's changing.
          The range that's intersecting an element with paint
          containment needs to be able to invalidate inside that
  BoCupp: Misleading us is that we're using nodes that are inside or
          outside the containment, to trigger changes in the range.
  BoCupp: I don't think it matters that the state is computed for
          static ranges so you can tell they're valid or invalid, or
          you change the start node so it moves from inside to outside
          the containment
  BoCupp: So we don't think there's a new case here. We might need to
          dig more into what florian is bringing up
  BoCupp: Ultimately this is about optimizations browser can pursue,
          and rather than put in complicated rules, put the onus on
          browsers to pay attention to ranges that might intersect
  florian: That invalidates the point of contain, though. Point is that
           it removes several things that it no longer needs to pay
           attention to.
  BoCupp: It only requires them to pay attention to this one thing,

  Rossen: Sounds like this discussion should continue on GH, there's
          more detail to be ironed out before we're ready for

CSS Cascade

`revert-layer` keyword in style attribute
  github: https://github.com/w3c/csswg-drafts/issues/6743#issuecomment-971826541

  miriam: We talked about this a few weeks ago, and resolved that the
          revert-layer keyword in a style attr should only revert the
          style attr.
  miriam: but that becomes complex and unclear when thinking about how
          style relates to normal and important layers
  miriam: We've drawn some diagrams in the thread about different ways
          this could work
  miriam: Main question is: if you use `revert-layer !important` in a
          style attr, is that still only revert the style attr, and
          maybe the animations layer, but no author layers? Or is it
          also reverting important author layers, taking you down to
          normal author layers?
  miriam: I think we meant the former, but there's some confusion there.
  miriam: Proposal is that setting `revert-layer !important` in the
          style attr, it reverts the style-attr layer, the animations
          layer, and nothing else

  fantasai: Looking at the ascii diagram from Xiaocheng, most revert
            behaviors cut from the important to the normal origin, and
            remove everything between those two points
  fantasai: but because style attr is weird, on top of both normal and
            important, if we similarly cut thru like that, it'll remove
            important styles from layers but not the normal styles from
            those layers
  fantasai: So I think because it's likely to break expectations of
            someone writing a layer to remove the important part but
            not the normal part, I think it's better to do this
            skipping behavior
  fantasai: A little concerned about how this plays out in impls, but
            since Xiaocheng wants it, I think we should go with it
  TabAtkins: Looked it over before the meeting, and with you all and
             Xiaocheng agreeing, I'm happy to go with this
  Rossen: objections?

  RESOLVED: Accept suggested behavior, where `revert-layer !important`
            in style attr only reverts the style-attr origins and the
            animations origin, ignoring other author origins

Allow authors to explicitly place unlayered styles in the cascade
    layer order
  github: https://github.com/w3c/csswg-drafts/issues/6323

  miriam: We left this at taking back to the thread to discuss syntax,
          and a lot happened
  miriam: two frontrunner proposals
  miriam: (1) unlayered styles are like any other layer, we just have a
          name for that layer and allow you to place it
  miriam: That's the simplest option conceptually
  miriam: it means the final page author always has control over
          layering, as they can place the unlayered style wherever they
  miriam: But it could cause problems if people explicitly need their
          styles above or below the default
  miriam: If we need that...
  miriam: (2) track two layer stacks, one above and one below the
          default unlayered styles
  miriam: If we need that, fantasai and I came up with a syntax, you
          can put a slash in your @layer to designate whether your
          layers are in the "below default" or "above default" stack
  miriam: Think this'll work well, but you're conceptually tracking two
          layer stacks
  fantasai: Third option is close no change, and just leave unlayered
            at the top of the layer stack

  jensimmons: I talked with Elika about this a lot recently. I think I
              agree with Elika that the simpler version won't work.
  jensimmons: Think about a team with a complex custom design with
              their own styles, then they pull in bootstrap or other
              third party complicated lib
  jensimmons: And you crush those two together, there's a lot of room
              for unintended consequences
  jensimmons: But as we talk thru the more complex versions, it's too
  jensimmons: Layers are meant to make the cascade more understandable,
              and I think making these two stacks, plus the combo with
              important vs normal, I think it'll be too hard
  jensimmons: and there is a way - I'd need a diagram to fully explain
              - for the 3rd party framework to say "hey I want to
              rearrange the order of the layers" and end up overriding
              layers the custom stack doesn't want overridden
  jensimmons: As soon as I started to understand how this could happen,
              I just said NOPE
  jensimmons: So right now I'm okay with option 3, just leave the
              unlayered styles at a specified point. We can revisit in
              the future if we think we really need it.
  TabAtkins: I was not a fan of the 2-stack approach
  TabAtkins: while there are use cases for control, I'm fine with
             leaving no change for now
  miriam: wfm
  Rossen: Anyone object?

  RESOLVED: Reject this proposal; unlayered styles have a specified
            location in the layer stack which can't (currently) be

CSS Values
  scribe: fantasai

What should non-calc() math functions serialize to when they're
    fully resolved?
  github: https://github.com/w3c/csswg-drafts/issues/4399#issuecomment-949067282

  TabAtkins: Should be a small clarification
  TabAtkins: Previous resolution didn't quite hit this
  TabAtkins: Issue is, when you have a unit that is not a canonical
             unit in a math function
  TabAtkins: when precisely does it turn into the canonical unit?
  TabAtkins: eg. when do you turn 1in into 96px?
  TabAtkins: Browsers all differ on this matter
  TabAtkins: Safari and Firefox canonicalize eagerly
  TabAtkins: Chrome only does this during the simplification process,
  TabAtkins: For specified styles it won't always fully simplify
  TabAtkins: for computed values will sometimes simplify
  TabAtkins: It's weird, calc(1in + 1in) becomes 2in
  TabAtkins: but calc(1in + 10px) becomes 106px
  TabAtkins: I think we should go with Firefox and Safari's behavior
  TabAtkins: What Chrome is doing is complicated and unnecessary
  TabAtkins: and two browsers are doing eager simplification already
  Rossen: Any other opinions?

  RESOLVED: Spec FF/WK behavior of eager simplification

CSS Scrollbars
  scribe: TabAtkins

Some scrollbars aren't accessible for interactions
  github: https://github.com/w3c/csswg-drafts/issues/6675

  Rossen: Do we need Greg?
  florian: I'll try.
  florian: Two parts to the issue
  florian: Some people complain that scrollbars found on the web were
           weird or unusable
  florian: Those were ::-webkit-scrollbar, not thru our specced
  florian: The spec doesn't need to write about how to use those, since
           we consider them to not exist
  florian: The part we do need to talk about is that the spec currently
           says that narrow scrollbars "should remain wide enough to be
           usable". Greg says this should be a MUST.
  florian: At least, when the user begins interacting.
  florian: I'd skip that last part, because we're not really specifying
           that the narrow scrollbar has a dynamic width; browsers can
           do whatever.
  florian: But going from "should be usable" to "must be usable"... why
           not? Not sure it's enforceable, but a browser deciding its
           narrow scrollbars don't need to be usable would be odd.
  florian: WCAG, note, says that the minimum size to be interacted with
           is 40px, and wide scrollbars aren't ever anywhere near that,
           so what it means to be "wide enough to be interacted with"
           seems difficult to understand
  florian: For overlay scrollbars, having them dynamically change size
           is fine, but layout scrollbars you probably don't; I don't
           think we should exclude it though.
  Rossen: Just moving the SHOULD to MUST and leaving the text otherwise
          the same makes sense

  flackr: I raised this in OpenUI - even if the scrollbar isn't
          visually large enough, we do "fuzz" touches on buttons, and
          could do the same thing for the scrollbar, so as long as your
          finger touches near the scrollbar it considers you to be
          touching it
  flackr: I think it should be a reasonable way to have a narrow
          scrollbar that's still usable
  florian: Perhaps we can include this in a note - if you're overlay,
           feel free to enlarge it on hover; if not, maybe fuzz hit
           testing. Nothing normative, just suggestions

  Rossen: Stepping back, from pure a11y, the change makes sense.
  Rossen: Said many times - we shouldn't be specifying how the UI
          frameworks should work.
  Rossen: But if we've already gone to the extend of adding normative
          text about "scrollbar width must be large enough", changing
          that to a MUST makes sense
  <TabAtkins> +1
  Rossen: Objections?

  RESOLVED: Change SHOULD to MUST in the normative text about UAs
            ensuring the scrollbars are wide enough to interact with


  florian: At this point all issues are closed, all horizontals are
           complete, security review has timed out
  florian: Which means that once I double-check that changes and doc
           are up-to-date, we're ready for CR. Can I ask for that?
  <fantasai> +1 to CR
  Rossen: Any objections to moving Scrollbars to CR?

  RESOLVED: Publish Scrollbars as a CR.

CSS Cascade


  fantasai: At this point we're zero open issues aside from small
            editorial tweak
  fantasai: So would like CR transition for Cascade 4 and 5
  florian: Horizontal kicked off?
  fantasai: Yes, though Security never got back to us
  Rossen: Consider it a timeout
  Rossen: Objections?

  RESOLVED: Cascade 4 to CR
  RESOLVED: Cascade 5 to CR

CSS Images

Layout of iframes with content intrinsic sizing that does not match
    the <iframe>
  github: https://github.com/w3c/csswg-drafts/issues/6817

  chrishtr: About iframes with content size different from the iframe
  chrishtr: Currently not possible
  chrishtr: But two upcoming features that might change this
  chrishtr: fenced frame that prevents iframe content from changing
            size after loaded, to avoid info leaks
  chrishtr: And cooperative iframe sizing, which may let the content
            document size differently from the iframe element
  chrishtr: I propose we apply object-fit semantics to this, and
            default to object-fit: contain
  chrishtr: (thus letterboxing the iframe)
  fantasai: Does this mean you'll shrink/zoom out the iframe if it's
            smaller than the document?
  chrishtr: Yes
  chrishtr: I think that would look the best, if they differ.
  smfr: not sure I agree - flashes of scaled content are weird
  smfr: Could just attach it to start-start corner

  chrishtr: So two potential resolutions: one is whether object-fit
            works, and second is what the default value is
  TabAtkins: Applying object-fit makes sense, it's designed to handle
             this kind of thing
  TabAtkins: No reason not to work as it does elsewhere
  TabAtkins: No strong opinion about default value
  TabAtkins: If question between losing data because doing object-fit:
             none and overflowing in some way
  TabAtkins: or making something very small, either squished or zoomed
  TabAtkins: they're both pretty bad
  TabAtkins: I'm not sure which is best for the user
  chrishtr: None would cut off content
  chrishtr: There's also "smaller" - only transform if you have to make
            it smaller to fit
  chrishtr: "scale-down"
  smfr: Is this a frozen iframe?
  chrishtr: For a fenced frame, this would persist for the life of the
            frame - they'd interact with it potentially
  chrishtr: These are for, like, ads - the 3rd party doesn't see what
            size the iframe ends up being
  chrishtr: Authors should avoid having this happen, but when it does
            we need some dfn for the behavior
  dholbert: This have any effect on regular iframes?
  TabAtkins: no, they continue to have no intrinsic size and work as
             they do today
  Rossen: What's the scenaro?
  dholbert: <iframe src="giant-image.jpg">
  dholbert: Chrome displays at full res, Firefox does scaled down but
            you can click it to go full, unsure what webkit does
  Rossen: Given we don't have interop...
  dholbert: That's what I'm getting at, does this have any effect on
  chrishtr: This shouldn't have any effect on today's iframes, only on
            the new stuff the cited proposals can bring up
  chrishtr: Only situations where there is an expressed intrinsic
            sizing (iframes today don't have it at all) and there's a
  Rossen: Objections?
  TabAtkins: Should we resolve separately on whether to apply the
             property and what the default should be?

  RESOLVED: object-fit affects the rendering of iframes with expressed
            intrinsic sizes

  chrishtr: I'd like the resolution for the second now, if possible
  Rossen: We can change in the future
  dholbert: object-position should also be relevant
  TabAtkins: Oh yeah I assumed it would be
  Rossen: Objections?

  RESOLVED: object-position applies to iframes in the above case as well

  Rossen: Please work out the defaults in the issue and we can resolve
          next week

  Rossen: We have a long call next week, Alan provided some details in
          the private list
  Rossen: We'll have a gh project with the issues to discuss
Received on Thursday, 2 December 2021 12:15:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:19 UTC