- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:22:25 -0400
- 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.
=========================================
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
‘grammar-error')
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
containers)
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?))
===== FULL MEETING MINUTES ======
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
markers
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
it?
myles: Our spelling and grammar dots are images, not just solid
colors
myles: so I'm not convinced we should expose this through system
colors
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
platform
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
magic
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
mistake
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
color"
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:
grammar-error
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/
backgrounds
<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
incrementing
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
clamps
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
target-counter()
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
counter-reset
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
element
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
inefficient
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
property
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
styles
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
sucks?
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
work
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
that
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
alignment
Rossen: This would be in both directions right?
fantasai: Block containers don't support justify-content, just
align-content
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
algorithms
<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:
https://yarusome.github.io/box-shadow-proposal/
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
cases
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
implementations
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
itself
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
zero)
iank: So only Firefox is affected by that part
emilio: So blink and webkit are already doing what you want to
propose?
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
differently
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
boxes
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
border-box
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
viewport
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
scroll-margin
<flackr> My demo in
https://github.com/w3c/csswg-drafts/issues/9052#issuecomment-1639234115
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