[css-overflow] overflow-clip-margin might want to set different boxes in the block and inline axes.

[emilio]

cc @chrishtr @khushalsagar

Gecko has a property similar to overflow-clip-margin called overflow-clip-box (actually a pair of properties, overflow-clip-box-{block,inline}), which we use to implement some of the form control magic that <input> and <textarea> need for compat (like clipping to the padding box in one edge but to the content-box in another).

It seems like it'd be nice if you could specify the margin in a per-axis basis? We can support the extension internally to remove the Gecko-internal property, perhaps, but if we need it maybe authors need it as well.

If we do this I don't have a strong opinion on whether we should make overflow-clip-margin a shorthand or two different longhands.

[chrishtr]

+1 to supporting per-axis.

[Loirooriol]

If different axes may want different clip margins, different sides may want that too?

[vmpstr]

When the property was introduced, we considered adding all of the directions as longhands but decided to add just the one for simplicity: #4934 (comment)

I think per side makes sense to be consistent with other margin-like things

[emilio]

The reason why I think per-axis might be sensible is that overflow itself is per-axis, but I guess per-side would also make sense.

[fantasai]

We can also start with per-axis and expand to per-side later if there's demand.

[Loirooriol]

Would this be only logical axes? So overflow-clip-margin would be a shorthand of overflow-clip-margin-block and overflow-clip-margin-inline. But if in the future we add overflow-clip-margin-{top,right,bottom,left,block-start,block-end,inline-start,inline-end}, then overflow-clip-margin should probably be a shorthand of the physical sides for consistency with margin. Changing the mapping logic of the shorthand may have some risk.

Or would we have overflow-clip-margin-{x, y, block, inline}? Though I think there is no precedence for having -x and -y shorthands for side properties.

[fantasai]

If block/inline is what's wanted we can just add those longhands and keep the shorthand as only capable of accepting one value. Then we can expand it out later once we figure out the whole situation with logical/physical shorthands.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow] overflow-clip-margin might want to set different boxes in the block and inline axes., and agreed to the following:

• RESOLVED: Add overflow-clip-margin-inline, -block, and the full set of properties

The full IRC log of that discussion

<dael> Topic: [css-overflow] overflow-clip-margin might want to set different boxes in the block and inline axes.
<dael> github: https://github.com//issues/7245
<dael> Rossen_: Can we discuss this w/o emilio?
<dael> fantasai: Probably. Next issue should wait
<dael> fantasai: On this, proosal we accepted to add overflow-clip-margin property. Takes a value to clip a little outside border edge.
<dael> fantasai: This allows some amount of overflow
<dael> fantasai: Typical margin properties have longhands that allow you to do sizes of box with physical or logical coord.
<dael> fantasai: Also semi-longhands that do both inline or both block sides at the same time
<dael> fantasai: emilio filed this saying might be useful to be able to set overflow-clip-margin independantly in block and inline axis. That brought up question of do we want full set of longhands or just per axis
<dael> fantasai: If we're going halfway overflow-clip-margin would take 1 value and set all 4. You could do overflow-clip-margin-block and -inline. Later we could add the full longhands if there's need
<Rossen_> q?
<dael> Rossen_: Comments?
<dael> vmpstr: Clarify, if both are set is there a precident of what happens?
<dael> fantasai: overflow-clip-margin is shorthand for overflow-clip-margin-block and -inline
<dael> vmpstr: Got it
<dael> Rossen_: And if you only set....okay...
<dael> Rossen_: Prop is start with the single value and extend to inline and block
<dael> Rossen_: Or do we want to resolve on the full expansion?
<dael> fantasai: That's my question. Just inline and block or explode all the way?
<dael> Rossen_: Would be quite inconsistent to have a shorthand with only 2 values. For consistency prefer if similar to margin
<dael> Rossen_: But that's a point for consistency
<dael> jensimmons: Agree to explode it out so we don't confuse people
<dael> Rossen_: And compat later is easier
<dael> Rossen_: When you have impl that only support 2 and other impl that support all
<dael> Rossen_: Sounds like we want to resolve to expand out the shorthand to support all the inline and block values, both logical and physical?
<dael> fantasai: Yeah, if we want all the sides we do the full set
<dael> Rossen_: Add overflow-clip-margin-inline, -block, and the full set of properties
<khush> q+
<dael> Rossen_: Additional thoughts? Objections?
<Rossen_> ack khush
<dael> khush: Clarifying one thing. Margin shorthand has syntax to spec value for all 4 sides. Resolution is not to make that work, right?
<dael> fantasai: If we're going to the full set that we'll be fully consistent
<dael> khush: Oh. Depending on how many values spec it was saying overflow-clip-margin could have 2 values to specifying content box and margin. If we see 2 is it supposed to be for top or both
<dael> fantasai: So b/c we have 1 or 2 values for each longhand we would have to figure out how to disambiguate shorthand
<dael> khush: Exactly
<dael> fantasai: Other option is pull out the box choice into own longhand so margins are all linked. But then couldn't choose different boxes to offset from. That would solve disambig.
<dael> fantasai: Other possibility is restrict the shorthand so it's only one but it's appled to all for the longhand. If you want to offset differently you have to use the longhand. We do have precedent
<dael> khush: So shorthand wouldn't let you supply both values. f you want that you have to use longhand
<dael> fantasai: Yeah, I think would be one easy way to do.
<dael> fantasai: To allow everything in shorthand we would have to either require box for every keyword or require length for everything or use a separator.
<dael> fantasai: A bunch of ways to handle. Probably should resolve to add all the longhands and then follow-up how to handle the shorthand parsing b/c should discuss more
<dael> khush: We did ship overflow-clip-margin in chrome which lets you spec both things. But exploring options separate sounds good
<dael> fantasai: I think if you do keyword + length all the options here still allow that
<dael> Rossen_: Prop: Add all the longhands to overflow-clip-margin-inline and follow up with a separate issue for how to handle the shorthand parsing
<dael> Rossen_: Does that sound reasonable?
<dael> khush: sgtm
<dael> Rossen_: Additional comments or objections to add overflow-clip-margin-inline, -block, and the full set of properties
<dael> RESOLVED: Add overflow-clip-margin-inline, -block, and the full set of properties
<dael> Rossen_: khush or fantasai please open separate issue

[frivoal]

Looks good to me, except that I think it'd be worth having the ability to use two lengths in the -inline and -block shorthands.