Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
'd' presentation attribute: use path() function #374
@ewilligers This does not seem correct. For compatibility reasons, the
Which implementations support a string version of the presentation attribute?
Do you mean consistency with the attribute? Note we already have unitless distance attributes (width etc) that have units in their CSS presentation attributes. Attribute syntax and CSS syntax are different.
For reference, there is discussion in the following issues:
I still strongly disagree with using
But none of the other implementers have weighed in to argue for that approach, and Chrome has been shipping it following Eric's proposal.
I will point out that the current state (
The proposal should probably be discussed with CSS WG as well as SVG.
@ewilligers The change you made affects the
Also, the spec text should say what happens when a
@AmeliaBR I totally agree with you. IMO it is fine that Chrome starts shipping with
IMO we should not make this change for SVG2 at all and instead split the
I'd agree with @dirkschulze that there would need to be additional prose for the presentation attribute form of
referenced this pull request
Feb 5, 2018
The Working Group just discussed
The full IRC log of that discussion<BogdanBrinza> topic: 'd' presentation attribute notation and PR
<BogdanBrinza> GitHub: https://github.com//pull/374
<BogdanBrinza> We discussed this just now and the current change introduces the CSS notation for the d attribute. For compatibility SVG attribute would need to take the string as well, not just the path function - so we'd like to ask to update the PR to capture this difference in SVG vs CSS syntax more prominently.
@dirkschulze Based on the resolutions we made in August (#320 (comment)), the revised spec would match one implementation (Chrome). Considering how eagerly anticipated it is by authors, I don't think it's appropriate to remove just yet.
(But @ewilligers, any chance you could update that PR so we can land it?)
@AmeliaBR I'd love to keep it but we need 2 implementations for transitioning the spec. Other implementations might be willing to implement it but this needs to happen before the transition. Lets discuss how we want to deal with features that have implementers feedback but no 2 implementations yet in our next WG call.
The SVG Working Group just discussed
The full IRC log of that discussion<AmeliaBR> Topic: `d` as a property (at-risk status)
<AmeliaBR> github: https://github.com//pull/374
<AmeliaBR> Eric: I've updated the PR to reflect different syntax for the attribute.
<AmeliaBR> Amelia: I'll try to take a look at that.
<AmeliaBR> Eric: Issue for today is, can we get a second implementation in time for PR?
<AmeliaBR> Tav: I'd be willing to do it for Inkscape.
<AmeliaBR> Eric: Are there any polyfills?
<AmeliaBR> Dirk, Tav: Not that we know of.
<AmeliaBR> Amelia: The main stumbling block for implementations in browsers, I think, was discrepancy between spec and shipped implementation in Chrome. Now that is sorted, we need to poke browser tracking issues again.
<AmeliaBR> Dirk: So, first step is to merge that PR to get the up-to-date spec.
<AmeliaBR> ... And then we can review status again before going to proposed Rec
<AmeliaBR> Resolved: Keep `d` as geometry property in SVG 2, merging the amendments previously agreed upon after review
<AmeliaBR> (discussion about difficulty implementing in Inkscape)