SVG: Promote d to a property

third_party/WebKit/Source/core/style/SVGComputedStyleDefs.h

Index: third_party/WebKit/Source/core/style/SVGComputedStyleDefs.h
diff --git a/third_party/WebKit/Source/core/style/SVGComputedStyleDefs.h b/third_party/WebKit/Source/core/style/SVGComputedStyleDefs.h
index ae3e3a9a69802b7cf775d15fd36be1b4fc1400d7..451822411d5c41a31e3fd187cc3d3a27429dcb28 100644
--- a/third_party/WebKit/Source/core/style/SVGComputedStyleDefs.h
+++ b/third_party/WebKit/Source/core/style/SVGComputedStyleDefs.h
@@ -29,6 +29,7 @@
 #define SVGComputedStyleDefs_h
 
 #include "core/CoreExport.h"
+#include "core/svg/SVGPathByteStream.h"
 #include "platform/Length.h"
 #include "platform/graphics/Color.h"
 #include "wtf/Allocator.h"
@@ -289,6 +290,7 @@ class StyleLayoutData : public RefCounted<StyleLayoutData> {
         {
             return !(*this == other);
         }
+        OwnPtr<SVGPathByteStream> d;

[fs, 2015/11/26 12:51:40]

Why not something similar to StyleMotionPath here?

[Eric Willigers, 2015/12/10 23:52:52]

For motion path, we didn't need to animate the path, so Path was a sufficient
representation. The inheritance from StyleMotionPath was to prepare for
"<url> | [ <basic-shape> | <path()> ] || <geometry-box> | none"

[fs, 2015/12/11 13:01:58]

I don't think it would be too far-fetched to expect "d: <basic-shape> |
<path()>" (or <shape> or whatever production that might be). FWIW, ISTR that
having happened for some <shape> consuming properties already (clip-path). So I
think gravitating towards a Style<something?>Path for use in such cases may be
good. We can iterate on the exact representational requirements (<Path, String>
vs. <Path, SVGPathByteStream> etc) though I think as long as we make sure to not
hurt "stable" performance.

         Length cx;
         Length cy;
         Length x;