- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Sep 2019 07:32:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Define path() in Shapes 1 or 2`, and agreed to the following: * `RESOLVED: Move path() down to Shapes 1, adding it to <basic-shape>.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Define path() in Shapes 1 or 2<br> <TabAtkins> astearns: A number of specs are using <basic-shape>, which has several functions in Shapes 1, but not path().<br> <TabAtkins> astearns: But path() is being implemented for *some* of the <basic-shape> properties.<br> <TabAtkins> astearns: It's weird to have them linking to a definition in Shapes 2 that's just a diff.<br> <TabAtkins> astearns: One option is to flesh out Shapes 2 into an actual spec, with a proper definition for <basic-shape> including path()<br> <TabAtkins> astearns: Another option is to pull path() back into Shapes 1, which implies we should implement it for shape-outside<br> <TabAtkins> astearns: I don't much care which one we do.<br> <TabAtkins> astearns: But would like to resolve on which way to o.<br> <TabAtkins> TabAtkins: My preference is whatever gets all the props using the same set of shape functions; all the props use a different subset right now and it's terrible.<br> <TabAtkins> TabAtkins: Spec's easy, I'm fine with it in level 1.<br> <TabAtkins> astearns: I think Ian said it woudln't be trivial, but seems plausible to do.<br> <TabAtkins> eae: Yes.<br> <TabAtkins> s/it/doing path() in shape-outside/<br> <TabAtkins> astearns: So I propose adding path() to Shapes 1. There's other things that need to be done in the spec, we can get a draft out that everyone can refer to with all the functions.<br> <TabAtkins> astearns: Can deal with how that slows down Shapes 1 from PR as we find impls to try it out.<br> <TabAtkins> astearns: Objections?<br> <AmeliaBR> The problem with adding path() to shapes 1 is that, as currently defined, it can't be used everywhere a shape is. It only defines the outline, not the fill area.<br> <TabAtkins> heycam: Any objection to shipping path() in things like offset-path - do they need to ship together?<br> <TabAtkins> TabAtkins: [reads Amelia's IRC comment]<br> <TabAtkins> astearns: Yeah that's a bit of th eproblem, some properties don't need fill-rule at all.<br> <TabAtkins> astearns: So I'm imagining it's an optional param to the function. But I haven't thought about how it's specified yet.<br> <TabAtkins> heycam: Would that block Motion Path?<br> <TabAtkins> astearns: My proposal is just to put it in Shapes 1. It shoudl improve the Process situation for Motion Path; it can then refer to a CR-level spec instead of a FPWD diff spec.<br> <AmeliaBR> Motion path would just ignore the fill rule. But for the SVG `d` property, allowing fill-rule in the path() function is possibly confusing, since there's a separate fill-rule property that applies.<br> <TabAtkins> astearns: This is really all about Process.<br> <TabAtkins> astearns: Tab, you mentioned Chris Coyier's annoyance with the shapes being different everywhere.<br> <TabAtkins> astearns: There's the path attribute in SVG; it's possible we won't get all the way to SVG syntax in CSS.<br> <TabAtkins> [discussion about CSS tokenization not being compatible with SVG]<br> <TabAtkins> myles: Does that mean you can't build up paths from varia les?<br> <TabAtkins> TabAtkins: Not without defining a new syntax that's CSS compatible.<br> <TabAtkins> AmeliaBR: Or doing the string-concat function.<br> <TabAtkins> myles: Didn't we resolve to add that?<br> <TabAtkins> AmeliaBR: Yeah, but no one's written it yet.<br> <TabAtkins> AmeliaBR: wrt it being a Process issue; if we want to put path() in Shapes 1, we have to figure out these issues before Shapes 1 can move forward in the process.<br> <TabAtkins> AmeliaBR: I'm not sure who's responsible for Shapes's progress, I think Alan; at this point is it best ot clean up and stabilize, or are we fine to take on this new work? Becaus eit's also abuot impls.<br> <TabAtkins> astearns: I think my strat will be to add it to the spec as an at-risk feature, so that we can punt it if we need to move Shapes 1 forward, but I'm perfectly happy with it sitting at CR for a while, or even going back ot WD if there are enough changes.<br> <TabAtkins> astearns: I'm not that concerned with getting it to Rec real quick.<br> <TabAtkins> AmeliaBR: Does adding path() mean we have to cycle back to WD, as a significant new feature?<br> <TabAtkins> florian: Nah it's fine.<br> <TabAtkins> florian: Patent Policy will handle it fine; as long as you've got wide review and what not is fine.<br> <TabAtkins> AmeliaBR: It's been reviewed in Motion Path, but review there...<br> <TabAtkins> florian: The easier it is to demonstrate review, the easier time you'll have.<br> <TabAtkins> astearns: And if we have to bounce to WD, that's fine.<br> <TabAtkins> AmeliaBR: So long term, is our goal that shapes should be shapes, and you should be able to specify motion-path with circle(), etc?<br> <TabAtkins> TabAtkins: Yeah, a circle is a path, whatever.<br> <TabAtkins> astearns: So any objection to adding path() to Shapes 1?<br> <TabAtkins> RESOLVED: Move path() down to Shapes 1, adding it to <basic-shape>.<br> <TabAtkins> krit: I missed - are impls willing to support path() in shape-outside?<br> <TabAtkins> astearns: Missing a few people that would answer that.<br> <TabAtkins> TabAtkins: Ian says it's non-trivial, but doable.<br> <TabAtkins> astearns: So yeah that might slow us down, but getting things consistent and well-explained is more useful than a quick Rec for Shapes.<br> <TabAtkins> krit: Would it be good to add a note about precision in paths? A very complex path might get transformed to a polygon, maybe have a lot of points, etc. So can we add a note that impls can decide on how precise it wants to be?<br> <TabAtkins> astearns: I don't know if we currently have text to that effect with polygons...<br> <TabAtkins> s/astearns/AmeliaBR/<br> <TabAtkins> astearns: We do have text for some degenerate/difficult situations, saying you do have to do the difficult stuff.<br> <TabAtkins> astearns: I'm not sure we need to define that; precision's going to be an impl detail. Tests will have to be fairly coarse anyway to avoid being flaky.<br> <TabAtkins> astearns: So I think it's just a QoI detail they can live with.<br> <TabAtkins> krit: So if we agree it's just QoI, it's probably fine.<br> <TabAtkins> AmeliaBR: There's already a lot of flexibility for, say, *drawing* SVG paths.<br> <TabAtkins> krit: Ok.<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4270<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4270#issuecomment-531669816 using your GitHub account
Received on Monday, 16 September 2019 07:32:16 UTC