- From: <bugzilla@jessica.w3.org>
- Date: Tue, 20 Mar 2012 15:26:37 +0000
- To: public-css-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16448
Summary: Should we revisit the decision to not allow SVG path
syntax in the shape-inside, shape-outside properties
Product: CSS
Version: unspecified
Platform: PC
OS/Version: All
Status: ASSIGNED
Severity: normal
Priority: P2
Component: Exclusions
AssignedTo: vhardy@adobe.com
ReportedBy: vhardy@adobe.com
QAContact: public-css-bugzilla@w3.org
CC: eoconnor@apple.com, ratan@microsoft.com,
dschulze@adobe.com
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.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 20 March 2012 15:26:44 UTC