Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-shapes] Clarify which <basic-shape> are valid in shape-* #9728

Open
cdoublev opened this issue Dec 20, 2023 · 4 comments
Open

[css-shapes] Clarify which <basic-shape> are valid in shape-* #9728

cdoublev opened this issue Dec 20, 2023 · 4 comments

Comments

@cdoublev
Copy link
Collaborator

shape-outside (CSS Shapes 1) and shape-inside (CSS Shapes 2) are defined with this prose:

<basic-shape>: The shape is computed based on the values of one of inset(), circle(), ellipse() or polygon().

It is not clear to me if xywh(), rect(), path(), should be invalid.

In SVG 2, <basic-shape> is even further restricted in shape-inside and shape-substract, but I assume these are superseded by CSS Shapes.

This was previously reported in the multi-faceted issue #7390.

@smfr
Copy link
Contributor

smfr commented Jul 30, 2024

I agree that clarification here is needed. I think all Basic Shapes should be allowed for all shape-accepting properties.

@tabatkins
Copy link
Member

Agreed.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-shapes] Clarify which `<basic-shape>` are valid in `shape-*` , and agreed to the following:

  • RESOLVED: Shapes Level 1 is modified to say that shape-outside takes all <basic-shape>s
  • RESOLVED: Publish a new CRD of Shapes 1 with this change (and whatever else is already in since last publication)
The full IRC log of that discussion <TabAtkins> smfr: In Shapes 1 the spec says shape-outside accepts only a small list of functions
<TabAtkins> smfr: We have new shape functions now - xywh()/etc, shape(), path(), etc
<TabAtkins> smfr: Convenient would be to say that <basic-shape> is all such shape functions
<TabAtkins> smfr: I think in imp we avoided path() in <basic-shape> at first becuase it was hard to do the geometry to figure out where a line of text hit the boundary
<TabAtkins> smfr: But I think we just need to figure it out and make shapes work everywhere
<TabAtkins> astearns: Does this need to be in Level 1, or can it go to Level 2?
<TabAtkins> smfr: Woudl be a little weird for Level 2 to modify shape-outside here, but it could I guess?
<TabAtkins> astearns: No strong opinion eithe rway for me
<TabAtkins> astearns: makes sense to me
<TabAtkins> +1 from me
<TabAtkins> astearns: proposed resolution: Shapes Level 1 is modified to say that shape-outside takes all <basic-shape>s
<TabAtkins> RESOLVED: Shapes Level 1 is modified to say that shape-outside takes all <basic-shape>s
<TabAtkins> smfr: could i also ask for a new WD?
<TabAtkins> smfr: The ED changes the values accepted by circle()/ellipse() grammars too
<TabAtkins> astearns: I think this'll be a CRD at this point
<TabAtkins> astearns: Which is why I was thinking of putting it in l2, to be lazy
<TabAtkins> fantasai: It's not harder to publish a CRD than a WD
<TabAtkins> astearns: Do you want a resolution to publish now, or wait for the next issue?
<TabAtkins> smfr: next issue is definitely a l2 issue, let's do now
<TabAtkins> astearns: so proposed is: Publish a new CRD of Shapes 1 with this change (and whatever else is already in since last publication)
<TabAtkins> RESOLVED: Publish a new CRD of Shapes 1 with this change (and whatever else is already in since last publication)

@astearns
Copy link
Member

Changes made in b53255a. I’ll keep this issue open until the shapes-1 is published.

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

No branches or pull requests

5 participants