[css-shapes] Remove padding-box, content-box values from <shape-box>.

[bfgeek]

https://drafts.csswg.org/css-shapes-1/#shapes-from-box-values

padding-box, content-box aren't general enough to fix within the wider CSS box model. E.g. consider an element with scrollable overflow:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6857

In the above example the content-box of the element with shape-outside is technically larger than the element itself, but the specification doesn't (? i believe) mention how do deal with this.

Last year we also added use-counters within our codebase for how often these values were getting used:
padding-box:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2426
(when making the value non-parsable, sites have minimal (<2px) behaviour change).

content-box:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2425
The use-counter for above was over-reporting due to a bug in the code, this was now fixed, and most reports are for a buggy version where it considered images as using content-box.
I couldn't find any sites actually using this value, and relying on its behaviour.

border-box:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2427
There are a couple of sites which would have a large behaviour change if we'd remove this. However they'd have the same behaviour as if they had shape-outside:margin-box.
Unlike the other values border-box does have a use-case for web developers.

Given the values don't generalize to the wider css box-model, the zero use-counts for this feature, I believe that we can simplify this feature, and remove these values.

I'm not proposing removing border-box, however this could be considered for simplicity. border-box does have a relatively strong use-case compared to the other values.

[bfgeek]

cc/ @astearns , @tabatkins

[tabatkins]

padding-box, content-box aren't general enough to fix within the wider CSS box model. E.g. consider an element with scrollable overflow:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6857

In the above example the content-box of the element with shape-outside is technically larger than the element itself, but the specification doesn't (? i believe) mention how do deal with this.

I'm not sure what you mean by this. padding-box is well-defined, and is not the same as the scrollable overflow, sure. So the result you get is well-defined, if a little weird.

That said, I agree the use-cases for the lesser boxes seem pretty minimal; I think we just reused the box definitions because they were there.

There are a couple of sites which would have a large behaviour change if we'd remove this. However they'd have the same behaviour as if they had shape-outside:margin-box.

What do you mean by this? That switching to margin-box would cause a large behavior change for them?

[bfgeek]

I'm not sure what you mean by this. padding-box is well-defined, and is not the same as the scrollable overflow, sure. So the result you get is well-defined, if a little weird.

Sure - well-defined - that results in bad, strange behaviour ;) .

What do you mean by this? That switching to margin-box would cause a large behavior change for them?

Some of the sites have:

width: 50px;
height: 50px;
border-radius: 25px;
shape-outside: border-box;

To create a circle shape area.
Removing the border-box value would mean that they'd lose that behaviour. However if they notice the broken behaviour they could replace their CSS with:

width: 50px;
height: 50px;
border-radius: 25px;
shape-outside: margin-box;

And it would work fine.

[tabatkins]

Ah, k, so removing it would break them, even if it's fixable.

I think we probably shouldn't remove border-box, then. ^_^ It has a reasonable usage beyond margin-box, I think; using the box's margin to push it away from the edge, but having text wrap a different distance from it, seems totally reasonable.

[aethanyc]

@heycam points to me this discussion. As a firefox shapes implementer, I'm OK with removing padding-box and content-box to simplify code. Note that shape-box can be used with basic-shape. I'm not sure the use-counter include the usage with shape-box and basic-shape combined.

cc @jensimmons

[AmeliaBR]

I would be very disappointed if we just removed these values, as that would prevent authors from aligning shapes with actual content elements or with content or padding-clipped background.

(Note that the <shape-box> value has two effects: it can define the shape directly, OR it can act as a reference box for aligning and scaling shapes defined by images or the shape functions.)

But, it is clear that we have unspecified behavior. We need rules for what happens in scrolling containers. Maybe what should happen is that shapes aligned to these boxes instead gets treated as border box at used value time if the element has scrollable overflow.

Regarding the use counter: current usage of shape-outside is often limited by support for clip-path. A clip-path is also supposed to support many reference boxes, but Chrome does not support it. Chrome only supports the default border-box, so if you want a shape-outside shape to match a clip-path shape, you currently need to make your shape-outside shape reference border-box.

Of course, this also means that any decisions about reference boxes for scrollable elements should affect clip-path, too. Which means, they should also probably affect mask-origin, which defines reference boxes for masked elements. But mask-origin is intentionally designed to be consistent with background-origin, and backgrounds in scrollable containers apply to the inside dimensions, not the outside dimensions that are used for the float wrapping area, which is what shape-outside relates to…

In other words, we're not going to define a rule that is consistent everywhere when it comes to scrollable elements. But that doesn't mean that we should prevent authors from using these properties in a consistent way on non scrolling elements.

[css-meeting-bot]

The CSS Working Group just discussed Remove padding-box, content-box values from <shape-box>, and agreed to the following:

• RESOLVED: no change on this issue

The full IRC log of that discussion

<dael> Topic: Remove padding-box, content-box values from <shape-box>
<dael> github: https://github.com//issues/3872
<dael> iank_: As redoing parts of shapes impl for our layout engine I noticed something that bugged me. I put in use counters. Padding-box and content-box as values on shape outside is weird. If you have scrollable content inside it won't respect scroll bars. Not a strong use case for these values
<dael> iank_: Use counter was basically 0.
<dael> iank_: Given all this, to simplify can we remove?
<dael> Rossen_: Move to L2 or at all?
<dael> iank_: Just remove it. I don't know there are strong use cases for these values. Be interested if there are.
<dael> amelia: mentioned a few use cases in a comment earlier today. It's matching up shapes with either actual content image of an element. shape-outside can be defined using an image and you use it to match actual content image and you need them to align to correct layout box
<dael> amelia: Also aligning...shape-outside shapes with clip-path shapes functions. One issue there is Chrome and poss WK don't support shape boxes on clip-path and default is border-box so if people are using a combo they're almost automatically using border box. That might effect use counter more than anything else.
<dael> amelia: Other is matching with background images that can be aligned to many other boxes. Definitely use cases, but need to deal with...there's inside boxes and outside boxes when talking about scroll and that doesn't seem thought of in the spec
<dael> amelia: Something needs to change in the spec. I don't think deleting is best b/c then have to deal with that that set of boxes is used in a lot of graphic properties. Also clip-path and shape-inside in the future.
<dael> amelia: Getting rid of it all together will prob cause problems with consistency to other properties
<dael> iank_: Doesn't sound like...we haven't shipped padding box for clip path
<dael> amelia: no
<dael> iank_: My primary issue is no one has thought about scrollable boxes. It's also weird for engine caching, this reaches inside internals of the box.
<dael> fantasai: I think for dealing with scrollable boxes you would want to, for clip-pathas well, only thing that would make sense is inset it by border edge by amount of border and padding width. Can't draw it around scrollable area
<dael> amelia: That's one option. Makes perfect sence. Figure out what padding box would be working from existing box.
<dael> amelia: Other option is for scrolling boxes only you make at used value time these values get re-written but still allow content-box and border-box to work on non-scrollers. I like fantasai suggestion better
<dael> fantasai: As we switch to incorporate padding into scrollable [gives example]
<dael> iank_: Other thing to keep in mind for boxes with scrollers you've got to account for where scrollbars are with is a potential world of pain
<dael> iank_: I don't care where we fall on this issue. 9 months ago I found this weird, hence use counters
<dael> fantasai: If we hadn't impl it would make sense to drop. Since they are impl i'm ambivellent
<dael> iank_: Impl but no usage. I can drop based on that.
<fantasai> s/ambivellent/ambivalent/
<dael> amelia: Willing to accept this. Going back to Rossen_ question is make them invalid for now and defer to L2 where people can look more carefully about how should impl. If we've got something not impl consistently and we don't agree how and it's not used a lot we should take it out. I don't want to resolve to never support
<dael> jensimmons: Do we know if we have interop and complete impl or a lack of interop and confusion what it should be
<dael> iank_: Based on amt of WPT there's good interop. Good between Blink and WK because of heritage. Good with FF based on WPT.
<dael> amelia: On the things you want to remove?
<dael> iank_: Yes. There's well tested I believe. I can check. But that said they have 0 usage
<dael> amelia: But if weve got clear interop why is issue to get rid of it? You don't like behavior standardize on?
<dael> iank_: Yeah. Behavior is weird for scrollers
<dael> amelia: Wrapping around area overflowing the box? I don't have any pictures...
<dael> iank_: ake simple impl, apply to scroller and that's what you get.
<dael> Rossen_: Going back to original motivation to add them was completeness and symmetry with other prop. That's what motivated us to add them in
<dael> Rossen_: Given there's no uptake on the values and a reason to remove from a given impl. In terms of being safe to unship it sounds okay. Technical PoV sounds like we can unship with no negative effect on content.
<dael> Rossen_: Question is are we completely uninterested or are we saying we don't know enough but might have reasons to work on it and we push to L2
<dael> Rossen_: Where on this spectrum are we? Push to L2 and worry later? Or no use cases and let's move on.
<dael> fantasai: amelia point that some things it would work with aren't shipped yet means we won't know potential usage accurately until those are widespread
<dael> Rossen_: Push to L2
<dael> fantasai: If we have interop and spec and impl there's no reason to move to L2 b/c it would pass REC. If we didn't have impl it would make sense to drop
<dael> Rossen_: Sounds like one impl will unship so we won't reach rec without having another impl
<dael> florian: Don't we have 3?
<dael> Rossen_: 2 only
<dael> amelia: WK and Chromium aren't independent is the issue?
<dael> iank_: Correct
<dael> amelia: Agree playing witht he demo what's happening is not good behavior. If we leave as a valid value we'd want to spec and define better behavior. Considering status of spec I don't think that can really happen in timelines we want.
<dael> Rossen_: Yeah
<dael> florian: Suggestion is push to L2 with an issue saying there is interop but we want to change?
<dael> Rossen_: If it is unshipped from blink there's no interop
<dael> amelia: FF and Chrome aren't identical. Both bad, but not interop
<dael> Rossen_: Let's see if we can resolve. Objections to move these properties out of L1 and into L2 and add a note about the interop problem?
<dael> dbaron: What does that imply impl should do?
<dael> florian: [missed] work before usage and then fix it
<florian> s/[missed]/rediscuss how it should/
<dael> Rossen_: In short term blink is looking into removing their impl. In long term spend more time thinking about how should work in conjunction with scrolling, overflow, etc.
<dael> amelia: One thing, if we change definition there will be dependencies beyond this one property.
<dael> amelia: Just practical for whoever does edits
<dael> amelia: We've got a shape-box type that's equal to set of keywords. Used in more than this one property
<dael> Rossen_: Right
<dael> jensimmons: For me...I'm not hearing that a browser needs to unship this in order to get through re-engineering of platform. not hearing a compelling reason to remove. AS a person that's taught about this property adjusting the shape-box property is the last thing people think about or learn. Switching from border-box to margin-box makes sense, but makes me nervious to unship.
<dael> jensimmons: THat people aren't using it doesn't convince me b/c I think peoplehave not dug into it. I haven't thought of use cases, but makes me nervious
<dael> TabAtkins: Shouldn't fall pray to status quo fallicy. Since no one hascome up with reasonable reason to have it in, it's weakly supported at best
<dael> dbaron: Sounds like reason to remove isn't that it's complicated, but it's not useful.
<dael> dbaron: Could argue using it on a thing with scrollbars is a bad idea. Then it's not that bad that it has wierd results. Clipping a scrollbar is prob not what you wanted. QUestion is are there use cases for non-scroll bar
<dael> amelia: That's what I brought up. There are use cases. Simpliest solution from spec is add a warning that using content-box or padding-box on an element with scrollbars has undefined behavior. it's a warning to authors you'll get weird stuff. In non-scrollbar case we've got clear interop. but for the intersection of properties adding a warning behavior is undefined might be quick
<dael> TabAtkins: Officially undefined is something we try not to use. All it means is we hope to revisit once web compat has frozen.
<dael> TabAtkins: No one has brought up use cases and I can't think of when I'd want text outside to flow into a box past a border
<dael> fantasai: WE see this frequently with first letter shapes. You can have a light color bg and want text to flow over and wrap shape of letter. This kind of design does happen
<dael> jensimmons: And a lot of ability to overlap with negative margin. You can't do that here.
<dael> fantasai: I don't see use case for padding box, but for content-box you have that
<dael> iank_: In the wild when people want that they reach for insets to modify
<dael> fantasai: If you want to take an image, cut into a circle. You don't want to have to do an inset of your border and padding when you can just say make the circle that covers the content box. Less repeating yourself, less complications. That's what these keywords are for. If want to cut image to a circle, then want text wrap in a circle
<dael> TabAtkins: And also have the image have a border and have text overlap?
<dael> fantasai: Might not be a circle so yeah. I think it's not the common case, but I don't think it's totally crazy
<dael> jensimmons: Interesting question to ask now. If we asked a year ago when there's one impl and the question at the time is this is complicated. But we jsut shipped it all and we've got interop except the corner case of scrollbars, why remove it now? Only reason I'm hearing is it would make things feel better for those reading the code so you don't have to drag around extra code. I get that as an engineer, but not compelling to change a spec
<dael> TabAtkins: Trying to ignore scrollbar doesn't work, we still need interop. People will have to add code to handle it. It's not a matter of leave it alone, someone will have to pay additional cost to get it right. Then there's the non-0 matienence for a feature we're not going to use and doesn't have a realistic use case
<dael> fantasai: We've spent a lot of time talking about removing a feature that's mostly interop. I'm inclined to leave things along with no change
<dbaron> +1 to spending time on other things
<dael> Rossen_: Also a valid option
<dael> Rossen_: iank_ would you be okay no change for now?
<dael> iank_: Fine. No work for me now, this is for someone down the line with scrollers.
<dael> Rossen_: Objections to no change on this issue?
<dael> amelia: Can we leave an issue about scrollbar case?
<dael> Rossen_: We can
<dael> RESOLVED: no change on this issue