Comments (14)
I think if we can decide on a name for the property, it should be safe to implement it for <path>
and then generalize it later.
And yes, I agree with @tabatkins' arguments for why it makes sense to have sub-properties for circle, rect, etc, but not for path d
versus polygon points
.
from svgwg.
Some rough sketches of a proposal.
See also the discussion from the 3 March 2016 telcon.
I think there is agreement that we need distinct property names for distinct features:
- text path
- geometry of paths & probably other shapes
- maybe geometry path fragments used within the new paint servers (or maybe they could be covered under same property as geometry of paths)
I've written up notes on text path as Issue #59. This issue will focus on shape geometry.
Defining shape geometry in CSS
-
There is a desire from the CSS side to use CSS shape functions instead of raw path data strings as the value of the property.
-
This already means that there won't be a simple presentation attribute which matches the property syntax. So might as well create a better property, which then pulls in the value of the attribute through the user stylesheet.
-
Given this, it should be straightforward to use the same property for path/polygon/polyline. Just use different shape functions and different
attr()
calls in the default stylesheet. We would need to define a newpolyline()
function, but that will be useful for CSS motion path as well. -
I had suggested a
geometry: <shape-function>
as the simple-to-understand syntax. -
Extrapolating to other shapes is a little more complicated, because we need to accommodate the individual geometric attributes (
cx
,cy
, etc.). These have had good implementer & author support. They are also preferable for animation as compared to a single property with a shape function. (For the same reasons thattransform
is being decomposed into individual properties.) -
I had suggested that
geometry
could also accept keywords (as opposed to complete functions)circle
,ellipse
,line
, andrect
to defer to the individual geometric attributes.This would, however, mean that it is possible either to specify
geometry: circle(50%)
as a complete shape, independent of the geometry attributes, or specifygeometry: circle
which then usescx
,cy
, andr
to draw the actual shape. Which is possibly very useful or possibly very confusing. Or both.
Dealing with the DOM interfaces
All this is great and backwards-compatible if you're only looking at the declarative side. However, we also have DOM interfaces which are customized for each shape type.
My approach would be to define a universal shape interface that is the union of the existing shape interfaces. The existing interface names would still exist as subclasses for backwards compatibility, but wouldn't add any unique features.
The shared behavior:
.pathLength
: author-specified path length to use for normalization of stroking, etc..getTotalLength()
,.getPointAtLength(distance)
: everybody's favourite methods for<path>
, now available on basic shapes and polygons. (Yay!)- Some way to get the computed path (or path equivalent for a basic shape) in a useful format, to replace the torn-out path segment API.
- Some way to normalize a computed path value, so that any two identical paths have the same normalized representation.
.points
to access the start and end-points of all segments in the path (e.g., every point at which a marker could be drawn) as an SVGPointList. This would be backwards-compatible with the existing points property in polygon/polyline, but would also be useful in other shapes and paths..x
,.y
..width
,.height
,.cx
, and so on, as a way to get the computed value/ set the inline style for the corresponding geometric property as an SVGAnimatedLength (or whatever better backwards-compatible interface we come up with in the future to represent typed lengths).
Path fragments in paint servers
Need to figure out how <hatchPath>
and path segments in <mesh>
stops fit in.
Future wish list:
The following features probably won't be in SVG 2, but should be kept in mind as features we'd like to remain compatible with:
-
a
concat(<shape>, <shape>, ...)
function that combines the path representations of the individual shapes (or path fragments) into a compound path. If the shapes are open paths/polylines, this would just extend the paths. If the shapes are closed, it would create a path with multiple closed sub-paths.For example, a donut shape could be created with
geometry: concat( circle(5em), circle(3em) )
and the appropriate fill-rule.In combination with CSS variables, this could make it much easier to share the geometry of borders between adjacent shapes.
-
a
reverse(<shape>)
function which would reverse the relevant path. The normal clockwise basic shapes would become counterclockwise and custom paths would be measured from the opposite end. -
a
transform(<shape>, <transform-list>)
function which would create a transformed version of that path fragment which could then be used in aconcat()
function. In combination with variables this could make it much easier to create symmetrical shapes.
from svgwg.
I’ve got a comprehension question: You aren’t suggesting to rename the d
attribute in the <path />
element, so that <path d="…" />
won’t work in SVG2 anymore, are you?
from svgwg.
@prlbr No, the 'd' attribute will remain.
from svgwg.
Yes, we wouldn't want to change that! There is precedent for having a name mis-match between the attribute and the corresponding CSS property: the patternTransform
and gradientTransform
attributes now map to the standard transform
property.
from svgwg.
Thanks!
from svgwg.
In blink-land we are trying to decide what to do with the 'd' property. The work is done to wire up css path animations through the 'd' property, but I definitely don't want to jump the gun on the spec. Is 'd' still being proposed as an alias of a future better name, or is css path animation still up in the air (https://lists.w3.org/Archives/Public/www-svg/2016Feb/0033.html)?
from svgwg.
So I think I like this. It lets us somewhat explain how the different elements get rendered; rather than "based on tagname", which doesn't exist anywhere else in CSS, it's "based on 'geometry'". Which properties get used is based on the 'geometry' value, which is no different than 'display' controlling whether 'flex-basis' or 'grid-template' get used.
I thus support the idea that circle
, rect
, etc be keywords on geometry
, meaning "use the appropriate properties to render as a circle/rect/etc". This preserves the authoring/animation convenience of having separate properties for their component bits.
I presume that <path>
, <polygon>
, and <polyline>
can desugar straight to presentational hints for geometry: path(...);
functions, since they don't have any independently-controllable bits, just a single attribute defining their entire geometry. Alternately we can have 'd' and 'points' properties, and give 'geometry' path
/polygon
/polyline
keywords that make the element pay attention to those properties, but less properties is better in general I think.
(I'm gonna talk with Shane and pdr on Wednesday about this so we can get a unified Blink opinion.)
from svgwg.
For those of us in the cheap seats, is it the suggestion that d=""
would be a shortcut property equivalent to geometry="path()"
? And <polygon points="">
would be equivalent to <path geometry="polygon()">
?
And you could do something like the following?
<path geometry="circle() circle()" ..>
if we can decide on a name for the property
Given all the mentioned elements are defined as "shape" in the spec, could that be an acceptable name for the property? It's a little shorter and would save some bytes. Perhaps a little more overloaded than geometry though :)
from svgwg.
I like 'shape', simply because it's a little shorter than 'geometry'.
from svgwg.
I think I avoided shape
because of shape-inside
/shape-outside
. It would seem like a shorthand property, but it's something different entirely, since those properties are both about text layout, not SVG fill and stroke.
@BigBadaboom Your interpretation is pretty much equivalent, except that I was suggesting that we'd need to define explicit new functions to concatenate multiple shapes into a single compound path. Which keeps things straightforward at the CSS parser level and opens up the possibility that the new functions could be used in any CSS property that accepts a shape function. But that's something to explore in the advanced Paths module.
from svgwg.
New idea after a full night's sleep:
With CSS WG approval, we could define a property shape-paint
(the shape that is used for fill and stroke) and a shorthand shape
that sets, shape-inside
, shape-outside
, and shape-paint
all to the same value.
All three properties would not be active on the same element, but you would often want to set shape-outside
to the same value as either shape-inside
(if it is a floated or excluded text element) or as shape-paint
(if it is an SVG shape that you're going to use as an exclusion area for a text element with shape-substract
).
We might want to rename shape-subtract
to make it clear that it's not re-set by the shorthand (it sets the list of excluded elements, it doesn't define a shape for this element).
from svgwg.
Actually, I suspect we do want shape-subtract
to be reset. Setting shape
to something should set you to that shape, not "that shape, minus some other stuff because you forgot to reset another property too".
For those of us in the cheap seats, is it the suggestion that d="" would be a shortcut property equivalent to geometry="path()"?
I'm not intending for this property to exist as an attribute on SVG elements. They already have everything they need - <path>
has d=""
, <circle>
just has its tagname dictating that it's a circle, etc. If you do want to invoke this explicitly, set the style
attribute.
The idea is that, for example, <path d="...">
is a presentation attribute for geometry: path("...");
. As Amelia said earlier, this is similar to patternTransform="..."
being a presentation attribute for transform: ...;
.
And
<polygon points="">
would be equivalent to<path geometry="polygon()">
?
Equivalent to <path style="geometry: polygon(...)">
.
from svgwg.
For now, we're going to make d a presentation attribute that takes path data as a string.
#119
We're open to the above proposal, but would like to tackle that as a separate module.
from svgwg.
Related Issues (20)
- The IDL of SVGSVGElement.getElementById does not allow null
- Should SVG's `<image>` element support the `fetchpriority` attribute analogous to HTML's `<img>` element? HOT 1
- Decimal point not allowed according to Path Data ENBF HOT 3
- Enable lazy loading for URLs on use href HOT 1
- Does SVG support Custom elements? HOT 1
- Error about drawto_command in SVG 2.0 path EBNF HOT 2
- What should happen when trying to insert empty strings or separators into SVGStringList
- SVGAElement.prototype.text should be removed HOT 6
- Serialization of transform functions and transform attribute.
- Update UA stylesheet rules to use :any-link instead of :visited or :link HOT 2
- Incorrect description of path horizontal and vertical movement HOT 7
- Publish current status of SVG
- Is the `path()` function allowed for the `d` property? HOT 2
- Can we fix arc interpolation? HOT 4
- Implementing CSS Text Wrapping in SVG HOT 1
- optional
- Arc sweep vs clockwise explanation HOT 1
- incorrect syntax for svg_path in SVG2 draft
- Define path interpolation when relative and absolute segment types are used. HOT 4
- gradient stroke along path direction HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svgwg.