Skip to content

[css-gaps-1] Asymmetric start and end offsets #12603

Closed

Description

@kbabbitt

We have a couple of use cases from author feedback where there's a desire to have asymmetric starts and ends for decoration offsets. Examples:


MicrosoftEdge/MSEdgeExplainers#996

Image

MicrosoftEdge/MSEdgeExplainers#1100 (comment) - from https://dribbble.com/shots/3768565-Photography-Portfolio-Masonry-Gallery-Grid / https://www.northlandscapes.com/

Image

This is related, but I think distinct, from #12024 which contemplates having the offset behavior at the edges be distinct from the rest of the container.

The second case above actually might be better served with something other than a gap decoration, at least as they're defined today. The use case calls for a line segment of a specific length, and we define the endpoints of gap decorations relative to the locations of intersections.

But the first case I think makes a good argument for *-rule-offset to take two values, or perhaps to turn it into a shorthand of *-rule-offset-start and *-rule-offset-end to control these values separately.

Activity

  1. self-assigned this
    on Aug 13, 2025
  2. kbabbitt commented on Aug 14, 2025

    @kbabbitt
    CollaboratorAuthor

    Minor correction to the above: The current properties are named *-rule-outset to reflect the fact that the value determines how far the gap decoration extends past the edge of the intersection.

  3. moved this from FTF agenda items to Wednesday Afternoon in CSSWG August 2025 meeting agendaon Aug 18, 2025
  4. css-meeting-bot commented on Aug 20, 2025

    @css-meeting-bot
    Member

    The CSS Working Group just discussed [css-gaps-1] Asymmetric start and end offsets.

    The full IRC log of that discussion <fantasai> kbabbitt: another piece of author feedback that we got. The property would control how far into or away from an intersection the gap decoration extends
    <fantasai> kbabbitt: They might want to meet exactly, or overshoot, or undershoot, the intersection
    <fantasai> kbabbitt: For flexbox, there was an author who wanted different offsets on different sides of it
    <fantasai> kbabbitt: Suggestion was to have the outset value control start vs end independently
    <fantasai> kbabbitt: e.g. taking two values, or make it a shorthand
    <SebastianZ> q+
    <astearns> ack SebastianZ
    <fantasai> kbabbitt: another somewhat related issue is shorthanding the offset and the break, so keep that in mind
    <fantasai> SebastianZ: Not up to date on how this is currently defined, but it take into account the expansion outside the grid, or also within the container, btween the items?
    <JoshT> q+
    <fantasai> kbabbitt: Can specify outset either ith pixel value or percentage value, where percentage is relative to crossing gap
    <fantasai> kbabbitt: you can extend outside the container if you want
    <fantasai> kbabbitt: can keep it flush
    <fantasai> SebastianZ: separate question wrt outside of container and internal
    <fantasai> SebastianZ: but I like being able to control both outsets
    <astearns> ack JoshT
    <fantasai> JoshT: The example with the landscapes is interesting, especially if we assume it's a grid of the entire page layout
    <fantasai> JoshT: I don't think this proposal gives us a way to give a fixed width for the decorator
    <fantasai> astearns: but did have a thought, might want 5em
    <fantasai> alisonmaher: I don't think you can, because 100% is relative to gap
    <astearns> ack fantasai
    <emilio> fantasai: this example with a short line looks like a border in the preceding paragraph, but with a shortened border
    <astearns> thought that you’d be able to get a particular length with calc, but alisonmaher is correct that it would be centered
    <emilio> ... there's been various proposals in borders-4
    <emilio> ... this particular pattern is common
    <emilio> ... I think that's a separate feature from gaps
    <emilio> ... we should also do it, there's a spec and we should probably revisit it
    <emilio> ... so this seems tangential
    <emilio> ... just having the outset property is enough
    <emilio> ... each side independently I'd expect us to go in that direction at some point
    <emilio> ... so that it seems fine to do whenever there's sufficient demand
    <emilio> ... but the point about making sure we design so that the syntax can be accommodated makes sense
    <emilio> ... we should expand rule-offset to have more than one offset
    <emilio> kbabbitt: do you think this is one prop with 1/2 values or different props?
    <emilio> fantasai: if they don't need to cascade independently I don't think we should split it into longhands
    <fantasai> fantasai: If an author would want to set one value in one style rule and another value in another style rule and have them combine, then you need longhands. otherwise not.
    <fantasai> SebastianZ: Could be use cases wrt animating the outset-start individually from that
    <fantasai> fantasai: yeah, you can do that
    <fantasai> SebastianZ: i can imagine wanting to extend the lines outside the container, but not within
    <fantasai> astearns: We can start with a single rule-offset with two lenghts, and split out to longahnds later
    <fantasai> fantasai: important question -- here the proposal is start vs end
    <fantasai> fantasai: what Sebastian is suggesting is interior vs exterior
    <fantasai> kbabbitt: another issue on that
    <fantasai> fantasai: the syntax might interact then
    <fantasai> astearns: ok, let's go to that issue then
  5. css-meeting-bot commented on Aug 20, 2025

    @css-meeting-bot
    Member

    The CSS Working Group just discussed [css-gaps-1] Asymmetric start and end offsets, and agreed to the following:

    • RESOLVED: rule-outset: <inner-start> <inner-end>? [/ <outer-start> <outer-end>?]?
    The full IRC log of that discussion <emilio> fantasai: inner / outer should take too value, but shorthand will take four values
    <kbabbitt> rule-outset: <inner-start> <inner-end> / <outer-start> <outer-end>
    <emilio> SebastianZ: three right? outer only one?
    <kbabbitt> rule-outset: <inner-start> <inner-end> [/ <outer-start> <outer-end>]
    <alisonmaher> q+
    <emilio> fantasai: it's reasonable to extend differently
    <astearns> ack alisonmaher
    <emilio> ... we should do it in both axes
    <emilio> alisonmaher: going back to this impacting layout... gap decorations are painted at the container level, so item level control we're proposing...
    <emilio> fantasai: we're not doing item-level control here, that's start v end
    <emilio> ... for the other issue the container is still painting the decorations, just consulting the items
    <emilio> emilio: just like tables :')
    <SebastianZ> q+
    <emilio> kbabbitt: I propose single values for all, slash separates inside vs. outside, space start and end
    <astearns> ack SebastianZ
    <emilio> SebastianZ: wondering whether that targets the intersections between...
    <emilio> ... we should have a value for ?? both
    <emilio> ... to meet both?
    <emilio> fantasai: 50%?
    <emilio> SebastianZ: I think so
    <emilio> fantasai: we could add a keyword if we want
    <fantasai> emilio: for the 50% thing, you need to be careful with transparency
    <fantasai> emilio: don't paint two borders in the same place
    <fantasai> emilio: when they meet, you either combine the borders into one and paint with that color, or paint both
    <fantasai> emilio: are there use cases for these?
    <emilio> fantasai: I think what you want is that as long as they overlap you do one line
    <astearns> proposed shorthand syntax: rule-outset: <inner-start> <inner-end> [/ <outer-start> <outer-end>]
    <emilio> emilio: but that's tricky right? that depends on DPI
    <emilio> emilio: some questionmarks missing I think?
    <emilio> ... but yeah that seems fine
    <fantasai> PROPOSED: rule-outset: <inner-start> <inner-end>? [/ <outer-start> <outer-end>?]?
    <kbabbitt> rule-outset: <inner-start> <inner-end>? [/ <outer-start> <outer-end>?]?
    <fantasai> RESOLVED: rule-outset: <inner-start> <inner-end>? [/ <outer-start> <outer-end>?]?
  6. jav099 commented on Oct 28, 2025

    @jav099
    Collaborator

    The property names we are considering and have some level of agreement on are:

    • column-rule-edge-start-outset
    • column-rule-edge-end-outset
    • column-rule-interior-start-outset
    • column-rule-interior-end-outset
      (same with row)

    and the shorthands we are currently considering as well are:

    • column-rule-edge-outset, row-rule-edge-outset
    • column-rule-interior-outset, row-rule-interior-outset
    • rule-edge-outset
    • rule-interior-outset
    • rule-outset

    which seems like a rather large set of shorthands, so we might want to decide on a subset of those that we'd actually like to expose, unless we really want all of them.

  7. SebastianZ commented on Oct 28, 2025

    @SebastianZ
    Contributor

    I'd argue that the -start and -end suffixes should be at the end of the keywords, so that the shorthand match the longhand names. That's how property names are usually structured.

    Also, @kbabbitt pointed out in #12848 that those properties should rather be insets than outsets. Furthermore, in #8402 (comment) we resolved on coupling the names of them with the new one for text-decoration-trim, which likely seems to be text-decoration-inset.

    Given that, the properties should rather be the combinations of {row|column}-rule-{edge|interior}-inset-{start|end}.

    And instead of edge and interior we might also choose inside and outside or inner and outer, see #12024 (comment).

    Sebastian

  8. jav099 commented on Oct 28, 2025

    @jav099
    Collaborator

    I don't particularly love inner and outer just because they are both very similar to inset or outset so it kind of flows weird when saying it out loud column-rule-outer-outset/column-rule-inner-inset. But the others I think are good suggestions and I don't have a big preference.

  9. 72 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions