[CSSWG] Minutes Cupertino F2F 2023-07-19 Part II: Text Decoration, Lists, Align, Backgrounds, Position [css-text-decor] [css-lists] [css-align] [css-backgrounds] [css-position]

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

Text Decoration

  - RESOLVED: Other text decoration properties don't apply when native
              text-decoration-styles are in effect (Issue #7522:
              Default ‘text-decoration-color' of ‘spelling-error' and

CSS Lists

  - RESOLVED: counter-increment is ignored on overflow (Issue #9029:
              counter-increment and counter-reset overflow/underflow)
  - RESOLVED: counter-increment will ignore the increment if it
              underflows or overflows (Issue #9029)
  - RESOLVED: Add counter-style that associates default counter styles
              with each counter specified by counter-reset on the same
              element (Issue #8997: Add counter-style property to
              associate default counter style)
  - RESOLVED: counter-style property takes a list of counter style
              keywords, which are matched up to counter-reset using
              coordinated list logic (name TBD) (Issue #8997)
  - RESOLVED: Work on counter shorthand (Issue #8997)

CSS Align

  - RESOLVED: Default behavior for align-content on block containers
              is safe (Issue #8992: Safe vs unsafe defaults for block

CSS Backgrounds

  - oriol introduced some new test cases for issue #7103 (The shape of
      box-shadow should be a circle for a box with border-radius:50%
      and big spread) and asked the group to investigate further.

CSS Position

  - RESOLVED: Don't consider margins in sticky-pos calculations (Issue
              #9052: Sticky position and margins (should margins be
              considered at all?))


Agenda: https://github.com/w3c/csswg-drafts/projects/38

Scribe: emilio
Scribe's scribe: bramus

Text Decoration

Default ‘text-decoration-color' of ‘spelling-error' and ‘grammar-error'
  github: https://github.com/w3c/csswg-drafts/issues/7522

  schenney: UA sheets need to specify a color for spelling / grammar
  schenney: No way to specify the platform-appropriate color to
            account for hcm etc
  emilio: That is what system colors are for?
  emilio: In gecko we use internal system colors for this
  emilio: If we come up with a good name it seems it'd be ok to expose

  myles: Our spelling and grammar dots are images, not just solid
  myles: so I'm not convinced we should expose this through system
  myles: Also not sure there's a use case to use the system color but
         not the system design

  fantasai: I think when we brought the issue there were three
            options: (1) text-decoration-color don't apply without a
            style (2) add text-decoration-color: auto and make it
            compute depending on the text-decoration-line value
  fantasai: I'd be ok with saying you can't use text-decoration-color
            unless you also specify style

  schenney: I agree that using the system design is probably better
  schenney: but if we use a color can we pick a good one?
  myles: How do we know to pick a good or bad color?

  fantasai: The original intention for text-decoration-style:
            spelling-error/grammar-error was to accommodate for
            platforms where it's not a simple style
  florian: Agreed, color should just do nothing for those
           text-decoration-style values

  emilio: Is this parallel to how we deal with outline style? and
          right now there are differences in how browsers deal with
          that. I think it should be possible for a browser to not use
          text-decoration-color or their native style
  florian: Yes, that is allowed
  emilio: Do we allow UAs to use it? e.g. ??? have their outline
          derived from something else. Do we want to allow this for
          this styles or say just no?
  florian: UA is allowed to but not required
  emilio: Is myles fine with that? or should we say
          text-decoration-color explicitly has no effect?

  GameMaker: With our current grammar error is blue dots, is that ok?
  fantasai: Yes

  GameMaker: I don't know if I can speak to this but if our designers
             wanted to take this into account, to draw orange dots if
             the author specified that, would that be fine?
  florian: That's what the spec says right now
  fantasai: The spec is very flexible now, the downside to not
            forbidding it is that authors might expect it to have an
            effect based on the browser they're testing it
  fantasai: Let's say Mozilla implements it and allows it, then
            firefox and chrome do that
  fantasai: they put something on a blue background and use
            text-decoration-color: orange
  fantasai: then safari users get blue on blue
  fantasai: Not sure that's worth locking it down more or not

  schenney: Curious, say chromium on mac wanted to match the macOS
  schenney: We could have a system color and we'd be ok not defining
            that color
  fantasai: If we're going to honor the color automatically but not
            all the time then we need a keyword to distinguish

  nicole: It seems something where what's good for the user might be
          different from what's good for the developer
  nicole: User probably wants to match the OS
  nicole: Then there's a developer need
  nicole: to change it if needed
  nicole: Is that the case? if so it might be worth doing something
          like with accent-color
  florian: Going back to fantasai's example, that's one case where it
           might be needed to break the convention
  florian: If the apple folks have blue dots, they need to deal with
           blue backgrounds in some way
  nicole: I'm thinking something about grammarly when they might have
          more sophisticated than what browsers provide
  florian: But they can either pick the default platform style, or
           changing text-decoration-style is already available
  hober: The grammarly case is handled by customizing it
  fantasai: Yeah grammarly could use the default grammar style
  fantasai: or they could specify their own text-decoration style
  nicole: So authors can't opt into the UA style?
  myles: They can, but they either get all of the magic or none of the
  myles: we object to a middle ground where you get some of the magic

  florian: The other thing is you can also select based on the element
           to opt in or out of the native style
  nicole: How would they do it if you want to ensure contrast?
  florian: If you know the background you can get the color
  florian: Otherwise you set the background style to the UA and hope
           the UA does a good job at it
  Rossen: the problem nicole is describing is a lot more general

  emilio: The current spec seems fine. but we need to be careful with
          compat. Also see what fantasai said a while ago.
  emilio: the default style should work on any bg
  emilio: if images need a different order; that's how native outlines
          work as well.

  ntim: I think it'd make sense to behave like outline-style: auto
        where the color is ignored
  emilio: The point is that there are browsers that can customize.
          e.g. firefox uses AccentColor for the native outline-style
  myles: I don't understand
  emilio: The whole point of this discussion is to determine if UAs
          are allowed or not to change the rendering of their native
          grammar styles based on text-decoration-color
  emilio: Right now they are allowed. Question is should we restrict it
  emilio: some browsers allow to change the color, some don't
  emilio: the ones that allow it do it in different ways
  emilio: are we fine with that? more grammar styles or not?
  ntim: outline-color does not change the color of the built-in outline
  emilio: In firefox we allow you to customize the AccentColor, but
          default it is the OS one
  ntim: I guess spelling-error and grammar-error would be up to the UA
  ntim: maybe that's all up to them?
  emilio: That is the question
  ntim: I think customizing it via text-decoration-color would be a

  florian: I don't think this is the question. That's already allowed
           in the spec, the question is "can we do something with the
  florian: and it seems answer is no
  <florian> Proposed resolution: No change

  schenney: I was hoping to propose a resolution
  schenney: question is "should the browser and the author agree and
            define custom grammar markers"
  schenney: Seems like we want the UA to allow any current color
  emilio: No

  fantasai: We're looking at several options
  fantasai: (1) no spec change, ua may interpret text-decoration-line:
            grammar-error using the system pattern and color
  fantasai: or they can honor text-decoration-color
  fantasai: if you are a UA that doesn't want to allow customization
            you ignore all text-decoration props
  fantasai: but otherwise when the author has set a , you honor
  fantasai: then the q is what is "when the author has set a color"?
  fantasai: text-decoration-color: currentColor? Something else?
  fantasai: that's not clear
  [fantasai: (2) don't allow text-decoration-color to affect
             text-decoration: grammar-error ]
  fantasai: So we can say text-decoration-color doesn't affect
            text-decoration-style: grammar-error
  fantasai: or we say text-decoration-color allow
            text-decoration-color but provide a magic
            text-decoration-color: auto or something
  fantasai: Third option is introducing new system colors
  fantasai: doesn't seem we're going with that
  fantasai: but we should pick between the other two options
  <ntim> I'm in favor of "Don't allow text-decoration-color to affect
         spelling/grammar errors."

  florian: For the UAs that want to ignore it the spec is fine but for
           the others it's not entirely clear what should happen
  florian: so adding a normal/auto initial kw for text-decoration-color
  florian: sounds useful
  fantasai: Right but we want to go to the question of "do we want to
            allow that"
  schenney: I think authors would be confused at not being able to
            specify the color
  fantasai: But they can
  schenney: If you specify ::grammar-error {}
  fantasai: ::grammar-error {} has text-decoration-style:
            grammar-error, but I can also style it on an `<u>` element
  fantasai: and then I'd get that style
  fantasai: or if I want to style `::grammar-error {}` and I want a pink
            double underline I can set `text-decoration: pink
            double-underline` and that's already
  fantasai: but if I do `u { text-decoration: grammar-error;
            text-decoration-color: pink }`
  fantasai: do I get a pink styling?
  fantasai: so if we allow it to be influenced by
            text-decoration-color we need something to differentiate
  <astearns> my vote is to disallow UA-provided decorations to respond
             to CSS property values
  schenney: I see in that case I'd vote to disallow
            text-decoration-color to influence text-decoration-style:

  emilio: There is an alternative to providing a new value for
          text-decoration-color, similar to borders. UA already has
          mechanism to see if author specified a new value.
  emilio: seems we are arriving to consensus of not allowing
          text-decoration-color to influence it
  ntim: I agree with not allowing
  <florian> Option 1: disallow taking the color into account
  <florian> Option 2: allow it and introduce a initial value (auto or
            normal) to text-decoration-color. When that value is
            specified, do whatever the platform want, if some other
            color is specified, the UA may take it into account.
  <emilio> option3: Use the same UA magic for appearance and borders/
  <ntim> +1 to that
  <schenney> +1

  fantasai: Proposal is for native text decorations none of the other
            text-decoration properties apply
  emilio: Do we want to do color or also offsets and stuff?
  fantasai: nothing

  RESOLVED: Other text decoration properties don't apply when native
            text-decoration-styles are in effect

CSS Lists

counter-increment and counter-reset overflow/underflow
  github: https://github.com/w3c/csswg-drafts/issues/9029

  vitorroriz: Currently spec says that if counter-increment overflows
              the integer storage, it should clamp
  vitorroriz: FF and chrome ignore the increment instead
  vitorroriz: WebKit behavior is arguably a bug, so I was looking at
              how to fix this

  myles: Just clarifying that overflow is not about layout overflow,
         just integer overflow?
  [multiple]: Yes

  TabAtkins: I think I like the ignore behavior more than clamping for
  TabAtkins: if you do counter-increment: 1billion, and you'd
             eventually get to INT32_MAX, which looks weird
  TabAtkins: seems better to stick to <last-valid-increment>
  TabAtkins: for set/reset I think clamping makes more sense
  TabAtkins: I don't have a strong opinion on this
  fantasai: I support all of Tab's arguments, and that's what we
            should do
  fantasai: doesn't seem like an implementation problem
  TabAtkins: proposed resolution is "do the Gecko and Blink behavior"
  TabAtkins: so change the spec so that increment ignores rather than

  RESOLVED: counter-increment is ignored on overflow
  RESOLVED: counter-increment will ignore the increment if it
            underflows or overflows

Add counter-style property to associate default counter style
  github: https://github.com/w3c/csswg-drafts/issues/8997

  fantasai: When you define a counter there's no association with
            counter style, just number+scope
  fantasai: for anything other than decimal you need to explicitly set
            it every time you use counter() functions
  fantasai: That's a minor difficulty, but it gets even worse with
  fantasai: Also when you want to do multi-level lists you can't use
            different styles
  fantasai: Proposal is a counter-style list property, matching to
  fantasai: that associate counters with a default style
  fantasai: I think it's a reasonable way of solving the issue

  emilio: Would target counter take the counter from the element you
          are styling or the target element?
  fantasai: From the style associated with the counter when it's reset
  fantasai: if you use implied counters but don't use counter-reset
            then you can't associate a style
  emilio: seems fine
  fantasai: it only works when you specify counter-reset

  ntim: How does this interact with the second argument to counter()?
  TabAtkins: That wins. Right now if you don't specify a second
             argument you get decimal, we'd change that

  oriol: You mention this could be like counter-reset list, which
         doesn't use commas and has been a problem
  TabAtkins: +1 for commas
  fantasai: I'd prefer to use commas, but only if we used commas
            everywhere else
  fantasai: so I'd be ok with adding a shorthand or something that
            uses commas
  fantasai: but it'd be weird to make this the only counter property
            that takes commas

  fantasai: Proposal is add counter-style that associates default
            counter styles with each counter specified by
            counter-reset on the same element

  RESOLVED: Add counter-style that associates default counter styles
            with each counter specified by counter-reset on the same

  fantasai: Follow-up question: there are two ways of binding styles
            with the names
  fantasai: Right now counter-reset gets name and value
  fantasai: We should counter-style either just get the values and use
            the positional matching
  fantasai: or follow the same syntax as counter-reset
  fantasai: and specify the name
  emilio: I think I have slight preference to use the positional one,
          otherwise it would feel like it would work without using
          counter-reset. My understanding is that it wouldn't
  emilio: Feels more confusing with the ?? and is slightly more
  emilio: but that last thing is a minor thing
  <TabAtkins> I should come up with a `counter` shorthand
  <TabAtkins> but +1 to emilio, don't have a strong opinion and that
              sounds fine

  oriol: I think we have the typical problem of what happens when you
         specify a list that's longer
  fantasai: We do the same as for background and animations etc
  fantasai: so if you use counter-style: alphabetic and two counter
            resets then both are alphabetic
  emilio: so the shorter this behavior I think at some point some
          browsers clamped the bg list and that is not great. It
          computes as a specified and then uses ???.
  fantasai: we should use the same rules

  dbaron: I think I agree with the conclusion about using the styles
          without the names and the list matching
  dbaron: The issue I find with that solution is the name of the
  dbaron: counter-style doesn't feel like something that's talking
          about counters you are resetting
  fantasai: Not concerned about it because we already have list-style
            and counter()
  dbaron: I think people are going to try using it on the element
          that's using the counter and get confused

  oriol: Why are we tying this to counter-reset? Could we provide a
         way of specifying the associations separately?
  fantasai: You need to do it when the counter is created and
            counter-reset is what does that
  fantasai: so it has to be tracked with the property that instantiate
            the counter
  fantasai: counter-increment/set can only create implicit resets
  oriol: Couldn't you provide a way to change the style separately
         from the counter
  fantasai: Maybe I don't think that's useful?
  fantasai: Then we'd need to define the scoping etc
  oriol: Other properties are not tied to reset
  fantasai: Right because they change the value of the counter

  ntim: Can we make this new property inherited?
  fantasai: No
  fantasai: that doesn't give you good result
  TabAtkins: Won't pair well, it also prevents shorthandifying counter
  fantasai: Inheriting would cause wrong results if you only specify
            counter-reset somewhere down the tree

  emilio: My other question is can we extend the counter-reset syntax
          to allow this?
  TabAtkins: No, unless we want it to take a function
  TabAtkins: which can be space separated. but because lack of commas
             we can't
  emilio: counter-reset takes item number
  TabAtkins: ident optional number
  emilio: I guess you could maybe put the style with brackets but that
  TabAtkins: that is essentially a function
  TabAtkins: we should define a counter shorthand
  TabAtkins: and it will have commas
  fantasai: yes
  TabAtkins: we screwed up the counter-* props initially. don't
             know why
  dbaron: I think counter props might be the first list valued prop
  fantasai: font-family!

  miriam: I'm not totally convinced by arguments against tim's proposal
  miriam: I might want to to set the counters for the whole site
  fantasai: Then set it on * but otherwise inheriting gives you weird
            behavior for all the decimal-based counters that already
  ntim: My rationale was more something like list-style where you put
        list-style on the list-container
  TabAtkins: That's fair but list props are all inherited
  TabAtkins: we're keeping those as consistent as possible
  emilio: You usually counter reset on the list container. so that
          would still work

  fantasai: proposed resolution is a counter-style prop that takes a
            list of names
  emilio: Regarding the name; counter-reset-style maybe?
  TabAtkins: Fine with something like that

  ntim: Can we resolve on working on the shorthand?
  TabAtkins: I'd be happy to resolve on that
  <fantasai> PROPOSED: counter-style property takes a list of counter
             style keywords, which are matched up to counter-reset
             using coordinated list logic

  RESOLVED: counter-style property takes a list of counter style
            keywords, which are matched up to counter-reset using
            coordinated list logic
  RESOLVED: name tbd
  RESOLVED: Work on counter shorthand

CSS Align

Safe vs unsafe defaults for block containers
  github: https://github.com/w3c/csswg-drafts/issues/8992

  fantasai: Currently when you apply align-/justify-content to flex/
            grid they are unsafe, but UA's are not supposed to shift
            stuff off the unscrollable region, but nobody implements
  fantasai: for safe centering if the content is more than the
            container you clip to the top
  fantasai: The spec behavior is technically limit by the
            scroll-container edges but nobody implements that
  fantasai: the align is spec'd to also apply to block containers
  fantasai: Currently nobody implements (that except the Firefox
            checkout on my laptop)
  fantasai: There are some concerns about web compat but also whether
            unsafe centering is right for block
  fantasai: I think for block layout in general safe centering by
            default makes more sense
  fantasai: also reduces the chances of a compat issue
  fantasai: Proposal is that for block containers we default to safe
  Rossen: This would be in both directions right?
  fantasai: Block containers don't support justify-content, just

  bramus: The default grid/flex has definitely tripped off authors
  bramus: So +1 but people might rely on unsafe alignment?
  fantasai: Not implemented anywhere yet

  iank: This seems fine overall
  iank: We find that for table cells where they fall back to
        vertical-alignment: middle it uses unsafe
  iank: as long as it's not messing with table cells seems fine
  iank: I don't think it's a huge compat mitigation, the biggest risk
        is the new bfc behavior

  oriol: I'm reading that you're proposing it for block containers
         that are not scroll-container
  oriol: Do you want to keep this distinction? If so, why?
  fantasai: For block containers that are scroll containers you don't
            have this unsafeness because you don't have overflow
  fantasai: your entire scrollable region is aligned and the initial
            scroll position changes
  fantasai: Per spec, you're not supposed to shift the content
  fantasai: you're supposed to change the initial scroll position

  oriol: I also wanted to ask that you mentioned that the default is
         unsafe, but wasn't there some magic if neither was specified?
  fantasai: Yeah, which nobody implements. we wouldn't do that for
            blocks and just default to safe which is also simpler

  RESOLVED: default behavior for align-content on block containers
            is safe

CSS Backgrounds

shape of box-shadow should be a circle with  border-radius:50%
  github: https://github.com/w3c/csswg-drafts/issues/7103

  oriol: IIRC we had a webpage where you could test the various
  <fantasai> -> https://yarusome.github.io/box-shadow-proposal/
  <oriol> https://drafts.csswg.org/css-backgrounds-3/radius-expansion.html
  oriol: Summary, when going inwards with border-radius you can just
         reduce the amount of radius
  oriol: but when going outwards if we just add the spread-distance
         then we break border-radius: 0
  oriol: Browsers checked if border-radius is zero, but that's not
         great because it's not continuous
  oriol: Spec tries to use a cubic formula that keeps being zero if it
         was zero but that has an issue but that deforms the inner
         shape with circles etc
  oriol: We had various ideas for ways to try to approach these
  oriol: One of the ideas was to try to keep percentages
  oriol: So we'd express the border radius as percentages and apply it
         to the inner and outer box
  oriol: but that doesn't work if the aspect ratio of the inner and
         outer didn't match
  <astearns> three more options added from the latest comment:
  oriol: Then fantasai proposed an interpolation between the two
  oriol: I found some cases when this was not behaving that well
  oriol: I proposed a modification to the current spec but with the
         addition of another factor
  oriol: that also considers the ratio of the element size that's
         covered by the radius
  oriol: So if the horizontal radius is >50% of the width of the
         element then we want this factor to be 1
  oriol: even if the spread is much bigger than the radius
  oriol: You can see the test-case, it seems it was better in some
  oriol: Then someone else (yarusome) proposed some other ideas
  oriol: Not sure if we should try with a whiteboard or some
         brainstorming to try to come up with a solution
  oriol: short version is take a look at the test-case
  oriol: I don't think we have the right answer yet
  oriol: someone added more funny cases

CSS Position
  scribes: fantasai, TabAtkins, emilio

Sticky position and margins (should margins be considered at all?)
  github: https://github.com/w3c/csswg-drafts/issues/9052

  iank: I was looking into sticky positioning optimizations
  iank: noticed that margins were a little bit weird, quirky, in
  iank: so wanted to ask what was the original intention with margins,
        and should we change it

  iank: Currently today there are 3 rectangles we care about
  iank: 1. scroll container
  iank: 2. sticky view rectangle (which is usually the parent of the
        stickypos rectangle)
  iank: 3. stickypos element itself
  iank: Most of the stickypos calculations don't use margin box, they
        use border box of stickypos element
  iank: e.g. you scroll to the top, sticks the border box
  iank: This seems desirable

  iank: Where margins come in is they don't affect stickypos element
  iank: it affects sticky view rectangle, reduces by the margins
  iank: It has some unfortunate effects
  iank: margins are used for positioning
  iank: so e.g. if using auto margins, stickypos no longer works for
        that element
  iank: Also if you set margins, it may not go all the way down to
        stickypos rectangle when using for positioning
  iank: Comments? Thoughts?
  iank: atm, Blink and WebKit would ignored auto margins (treat as
  iank: So only Firefox is affected by that part

  emilio: So blink and webkit are already doing what you want to
  iank: What I think might be better is to ignore margins completely
        from stickypos calculations
  iank: From examples I've seen online, no one is using margins for
        the sticky pos rectangle interaction
  iank: If we do want to keep margins around, there's a question about
        how auto vs fixed should work
  iank: Blink and webkit have other issues, e.g. uses margins that
        don't exist (e.g. on table cells)
  flackr: Also don't respect margin collapsing
  flackr: If we use margins, we should use margin collapsing
  flackr: weird if switching to position:sticky made margins act

  fantasai: Breaking this down, I think we can definitely take a
            resolution that auto margins are 0 for stickypos
  <flackr> sgtm
  fantasai: Are there any objections to that? If not we can just
            resolve that and move to the rest of the sub-issues
  smfr: So my original thoughts for sticky is that when it's not
        constrained by the scroller it behaves identical to relpos
  iank: It doesn't [??]
  smfr: So only when it's being affected by scrolling are we doing a
        different margin behavior?
  iank: Yes
  iank: and we're happy to see if this is web compatible
  fantasai: So we think there's a question of what do auto margins do,
            I think we all agree it should be treated as zero
  fantasai: Then another question of whether margins should be used at
            all for stickypos positioning
  fantasai: and if we continue to honor the margins, do we use
            collapsed or not
  fantasai: And I think the right answer for that is to use the boxs
            own margins and descendants but not siblings/parents
  iank: I'd prefer to avoid the complexity of margin collapsing
        entirely, we don't store enough info for block-start of our
  iank: So my preference is to ignore margins completely
  fantasai: I think it's reasonable if you're doing margins to use
            only the element's own margins

  TabAtkins: Given the constraint, which is correct, that in absence
             of doing stickypos should act like relpos,
  TabAtkins: margins should work, collapse, etc.
  TabAtkins: If you scroll slightly, don't want to jump
  TabAtkins: don't want to change behavior of margins at that point
  TabAtkins: Only reasonable behavior is to either do complicated
             partial collapsing
  TabAtkins: or don't care about margins at all
  TabAtkins: only use the border box
  TabAtkins: That's consistent with how we choose margin-box vs
  TabAtkins: When complicated margins we use border-box, because
             that's the only reasonable thing to do
  TabAtkins: stickypos shifting is solely on whether border box is
             escaping or not

  emilio: Does that change negative margins on sticky element? because
          that seems like a reasonable thing to do
  emilio: I'm ok trying this, but... I'm a bit concerned
  emilio: if you're willing to test compat, sure
  iank: When I play with examples, I don't see people using margins

  fantasai: If we're gonna honor margins I don't think you want to
            honor collapsing margins
  fantasai: You want to honor just the element's own margins
  fantasai: and if the element's own margins collapse with the parents
            then you treat that as zero
  iank: impl wise I don't particularly want to do that
  iank: can of worms
  TabAtkins: If you were collapsing a margin and you're sufficiently
             close to the top of the scroller
  fantasai: It's not about the scroller, it's about the CB and the
  fantasai: in that case you're adding to your margins
  fantasai: but if you want margins and they collapse you zero-them out
  fantasai e.g. if the element has 3px margin, use that to define
           spacing between containing block edge and the stickypos
  TabAtkins: Anything we do with margins that ignore clearance it's
             going to impose a change from sticky to relpos
  TabAtkins: I'd rather not do that
  iank: fwiw for other scroll related features they use the
  <flackr> My demo in
           shows a margin from the CB
  fantasai: I think this means that if you want spacing between a
            stickypos and its containing block even while it's
            shifting around by scrolling you need to use padding
  fantasai: and margin won't work anymore
  TabAtkins: Yeah, that's right
  fantasai: We should be pretty clear about that implication

  iank: I think folks are using margin-trim... ??? (missed)
  iank: I could see the interaction if we used the margin box of the
        sticky pos but this weird mixed model is weird
  flackr: I think that the way it behaves right now is conflating
          margin in two different contexts, the relpos layout is
          collapsing margin but the sticky margin is wrt the
          containing block
  flackr: I'd rather have the zero interpretation, having these two
          interpretations is awkward
  PROPOSED: Don't consider margins in sticky-pos calculations

  RESOLVED: Don't consider margins in sticky-pos calculations

  <br type=lunch>

Received on Sunday, 10 September 2023 15:23:01 UTC