1 files changed, 29 insertions, 37 deletions

diff --git a/src/sp-item.cpp b/src/sp-item.cpp
index eb3abce16..486e00d16 100644
--- a/src/sp-item.cpp
+++ b/src/sp-item.cpp
@@ -640,46 +640,38 @@ sp_item_write(SPObject *const object, Inkscape::XML::Node *repr, guint flags)
     repr->setAttribute("transform", c);
     g_free(c);
 
-    SPObject const *const parent = SP_OBJECT_PARENT(object);
-    /** \todo Can someone please document why this is conditional on having
-     * a parent? The only parentless thing I can think of is the top-level
-     * <svg> element (SPRoot). SPRoot is derived from SPGroup, and can have
-     * style.  I haven't looked at callers.
-     */
-    if (parent) {
-        SPStyle const *const obj_style = SP_OBJECT_STYLE(object);
-        if (obj_style) {
-            gchar *s = sp_style_write_string(obj_style, SP_STYLE_FLAG_IFSET);
-            repr->setAttribute("style", ( *s ? s : NULL ));
-            g_free(s);
-        } else {
-            /** \todo I'm not sure what to do in this case.  Bug #1165868
-             * suggests that it can arise, but the submitter doesn't know
-             * how to do so reliably.  The main two options are either
-             * leave repr's style attribute unchanged, or explicitly clear it.
-             * Must also consider what to do with property attributes for
-             * the element; see below.
-             */
-            char const *style_str = repr->attribute("style");
-            if (!style_str) {
-                style_str = "NULL";
-            }
-            g_warning("Item's style is NULL; repr style attribute is %s", style_str);
-        }
-
-        /** \note We treat object->style as authoritative.  Its effects have
-         * been written to the style attribute above; any properties that are
-         * unset we take to be deliberately unset (e.g. so that clones can
-         * override the property).
-         *
-         * Note that the below has an undesirable consequence of changing the
-         * appearance on renderers that lack CSS support (e.g. SVG tiny);
-         * possibly we should write property attributes instead of a style
-         * attribute.
+    SPStyle const *const obj_style = SP_OBJECT_STYLE(object);
+    if (obj_style) {
+        gchar *s = sp_style_write_string(obj_style, SP_STYLE_FLAG_IFSET);
+        repr->setAttribute("style", ( *s ? s : NULL ));
+        g_free(s);
+    } else {
+        /** \todo I'm not sure what to do in this case.  Bug #1165868
+         * suggests that it can arise, but the submitter doesn't know
+         * how to do so reliably.  The main two options are either
+         * leave repr's style attribute unchanged, or explicitly clear it.
+         * Must also consider what to do with property attributes for
+         * the element; see below.
          */
-        sp_style_unset_property_attrs (object);
+        char const *style_str = repr->attribute("style");
+        if (!style_str) {
+            style_str = "NULL";
+        }
+        g_warning("Item's style is NULL; repr style attribute is %s", style_str);
     }
 
+    /** \note We treat object->style as authoritative.  Its effects have
+     * been written to the style attribute above; any properties that are
+     * unset we take to be deliberately unset (e.g. so that clones can
+     * override the property).
+     *
+     * Note that the below has an undesirable consequence of changing the
+     * appearance on renderers that lack CSS support (e.g. SVG tiny);
+     * possibly we should write property attributes instead of a style
+     * attribute.
+     */
+    sp_style_unset_property_attrs (object);
+
     if (flags & SP_OBJECT_WRITE_EXT) {
         repr->setAttribute("sodipodi:insensitive", ( item->sensitive ? NULL : "true" ));
         if (item->transform_center_x != 0)