Bug 16448 - Should we revisit the decision to not allow SVG path syntax in the shape-inside, shape-outside properties
Should we revisit the decision to not allow SVG path syntax in the shape-insi...
Status: RESOLVED LATER
Product: CSS
Classification: Unclassified
Component: Shapes
unspecified
PC All
: P2 normal
: ---
Assigned To: Alan Stearns
public-css-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-20 15:26 UTC by Vincent Hardy
Modified: 2013-05-17 17:20 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Hardy 2012-03-20 15:26:37 UTC
Support for the SVG path syntax was recently added to the Canvas API:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects

Having a path construct as short-hand would be consistent technically because the properties already allow other shapes. The argument that was made in the past is that while it is quite expected people would hand-code basic shapes in their CSS, and it made sense to provide a syntax for that (instead of also requiring pointing to an SVG element), people do not expect most people to hand code SVG path data. So the idea is that SVG path data would anyway be authored by a tool. The other argument is that most SVG shapes are significantly longer and more verbose than the basic shapes and that justifies a different treatment.

The new data point we have compared to when we had the discussion is that the HTML5 canvas, when faced with a similar dilemma, decided to support the path syntax right there, and that is not consistent with the decision we made on a similar issue.

The proposal is to add a new primitive such as:

shape-inside: path(d);

where d would follow the SVG path syntax.
Comment 1 Alan Stearns 2013-05-17 17:20:09 UTC
This could be added in a later CSS Shapes module level. I've added it to the list of future features here:

http://wiki.csswg.org/spec/css-shapes