From 059d31787650bd6adc46b31a1705e380e51413e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:16:23 +0000
Subject: [PATCH 01/22] Update and rename 0000-template.md to
 0000-declarative-actions.md

---
 ...template.md => 0000-declarative-actions.md | 29 ++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)
 rename 0000-template.md => 0000-declarative-actions.md (82%)

diff --git a/0000-template.md b/0000-declarative-actions.md
similarity index 82%
rename from 0000-template.md
rename to 0000-declarative-actions.md
index 0c61215..9c918ca 100644
--- a/0000-template.md
+++ b/0000-declarative-actions.md
@@ -6,7 +6,34 @@
 
 ## Summary
 
-> One paragraph explanation of the feature.
+This RFC proposes a declarative way to write actions.
+
+```html
+<!-- action -->
+<script context="action">
+  // Not used in this example, I just binded the element to demonstrate 
+  // actions could still be writter purely imperatively as they are now with "onDestroy", "onUpdate" and "onMount".
+  let target;
+  
+  let isHeld = false;
+</script>
+
+<style>
+  .red-background() {
+    background.color: red;
+  }
+</style>
+
+
+<!-- target is an alias to the Element this action is applied to -->
+<!-- ".svelte" files with an action context script may only have one element, a target, and target shall have 0 children.-->
+<target
+  class:red-background={isHeld}
+  on:pointerdown={() => {isHeld = true;}}
+  on:pointerup={() => {isHeld = false;}}
+  bind:this={target}\>
+```
+
 
 ## Motivation
 

From 399aa1ca254f6b6b7e2e30b1284c41dc3412e7a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:17:29 +0000
Subject: [PATCH 02/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 9c918ca..4aba4e1 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -19,8 +19,8 @@ This RFC proposes a declarative way to write actions.
 </script>
 
 <style>
-  .red-background() {
-    background.color: red;
+  .red-background {
+    background-color: red;
   }
 </style>
 

From 163c5c08c6be5b184a2c83e1bd80b36a5d45c440 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:22:09 +0000
Subject: [PATCH 03/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 4aba4e1..6c06a44 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -9,7 +9,7 @@
 This RFC proposes a declarative way to write actions.
 
 ```html
-<!-- action -->
+<!-- action.svelte -->
 <script context="action">
   // Not used in this example, I just binded the element to demonstrate 
   // actions could still be writter purely imperatively as they are now with "onDestroy", "onUpdate" and "onMount".
@@ -34,6 +34,24 @@ This RFC proposes a declarative way to write actions.
   bind:this={target}\>
 ```
 
+```html
+<!-- Consumer.svelte -->
+<!-- works like current action consumption -->
+<script context="action">
+  import action from "./action.svelte";
+</script>
+
+<style>
+  .blue-text {
+    color: blue;
+  }
+</style>
+
+<div use:action>
+  I am declaratively styled by an action! yey
+</div>
+```
+
 
 ## Motivation
 

From 8d132ed3ef29fea0811e04b1143823e3675be8c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:23:13 +0000
Subject: [PATCH 04/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 6c06a44..4846cdc 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -11,8 +11,11 @@ This RFC proposes a declarative way to write actions.
 ```html
 <!-- action.svelte -->
 <script context="action">
-  // Not used in this example, I just binded the element to demonstrate 
-  // actions could still be writter purely imperatively as they are now with "onDestroy", "onUpdate" and "onMount".
+  /*
+    Not used in this example, I just binded the element to demonstrate 
+    actions could still be writtnr purely imperatively as they are now
+    with "onDestroy", "onUpdate" and "onMount".
+  */
   let target;
   
   let isHeld = false;
@@ -32,9 +35,11 @@ This RFC proposes a declarative way to write actions.
   on:pointerdown={() => {isHeld = true;}}
   on:pointerup={() => {isHeld = false;}}
   bind:this={target}\>
-```
 
-```html
+  
+  
+
+
 <!-- Consumer.svelte -->
 <!-- works like current action consumption -->
 <script context="action">

From bc0460c4befe7623541fa02b7684267a045b023f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:24:10 +0000
Subject: [PATCH 05/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 4846cdc..ed0233d 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -8,6 +8,8 @@
 
 This RFC proposes a declarative way to write actions.
 
+Action: 
+
 ```html
 <!-- action.svelte -->
 <script context="action">
@@ -35,11 +37,11 @@ This RFC proposes a declarative way to write actions.
   on:pointerdown={() => {isHeld = true;}}
   on:pointerup={() => {isHeld = false;}}
   bind:this={target}\>
-
-  
+```
   
+Consumer component:   
 
-
+```html
 <!-- Consumer.svelte -->
 <!-- works like current action consumption -->
 <script context="action">

From 9875610eeafc8aa4b7804a19267461f455b01dc0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:24:47 +0000
Subject: [PATCH 06/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index ed0233d..94caf8a 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -31,7 +31,10 @@ Action:
 
 
 <!-- target is an alias to the Element this action is applied to -->
-<!-- ".svelte" files with an action context script may only have one element, a target, and target shall have 0 children.-->
+<!--
+  ".svelte" files with an action context script may only have one element,
+  a target, and target shall have 0 children.
+-->
 <target
   class:red-background={isHeld}
   on:pointerdown={() => {isHeld = true;}}

From f17702050d62da758d030e17cb48d77619f117ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:25:43 +0000
Subject: [PATCH 07/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 94caf8a..2fae370 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -47,7 +47,7 @@ Consumer component:
 ```html
 <!-- Consumer.svelte -->
 <!-- works like current action consumption -->
-<script context="action">
+<script>
   import action from "./action.svelte";
 </script>
 

From 3233194b6252f462260a0354fea98dbbc8fdbaa7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 18 Nov 2020 04:26:02 +0000
Subject: [PATCH 08/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 2fae370..870445a 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -15,7 +15,7 @@ Action:
 <script context="action">
   /*
     Not used in this example, I just binded the element to demonstrate 
-    actions could still be writtnr purely imperatively as they are now
+    actions could still be written purely imperatively as they are now
     with "onDestroy", "onUpdate" and "onMount".
   */
   let target;

From 2130a0f9b60e6740e45058c2922c9f1d1d053430 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Thu, 19 Nov 2020 04:55:41 +0000
Subject: [PATCH 09/22] progress nas motivations

---
 0000-declarative-actions.md | 171 +++++++++++++++++++++++++++++++-----
 1 file changed, 148 insertions(+), 23 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 870445a..a8a69d2 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -2,24 +2,24 @@
 - RFC PR: (leave this empty)
 - Svelte Issue: (leave this empty)
 
-# (RFC title goes here)
+# Declarative Actions
 
 ## Summary
 
 This RFC proposes a declarative way to write actions.
 
-Action: 
+Action:
 
 ```html
 <!-- action.svelte -->
 <script context="action">
   /*
-    Not used in this example, I just binded the element to demonstrate 
+    Not used in this example, I just binded the Element to demonstrate 
     actions could still be written purely imperatively as they are now
-    with "onDestroy", "onUpdate" and "onMount".
+    with 'onDestroy', 'afterUpdate', 'beforeUpdate' and 'onMount'.
   */
   let target;
-  
+
   let isHeld = false;
 </script>
 
@@ -29,20 +29,20 @@ Action:
   }
 </style>
 
-
 <!-- target is an alias to the Element this action is applied to -->
 <!--
   ".svelte" files with an action context script may only have one element,
   a target, and target shall have 0 children.
 -->
 <target
-  class:red-background={isHeld}
-  on:pointerdown={() => {isHeld = true;}}
-  on:pointerup={() => {isHeld = false;}}
-  bind:this={target}\>
+  class:red-background="{isHeld}"
+  on:pointerdown="{() => {isHeld = true}}"
+  on:pointerup="{() => {isHeld = false}}"
+  bind:this="{target}"
+/>
 ```
-  
-Consumer component:   
+
+Consumer component:
 
 ```html
 <!-- Consumer.svelte -->
@@ -57,14 +57,139 @@ Consumer component:
   }
 </style>
 
-<div use:action>
+<div class="blue-text" use:action>
   I am declaratively styled by an action! yey
 </div>
 ```
 
-
 ## Motivation
 
+# Think about how custom variables as props would affect this.
+
+# Action arguments {} -> {{}} desugaring.
+
+Currently, writing an action takes away all Svelte's ergonomics. You can't use directives, you can't use {# ... } blocks and you can't apply styles using css sheets (or `<style></style>` blocks) without somehow including it globally (my particular use case).
+
+As an example of a slightly more complicated action than the one I provided in the [Summary](#Summary), I will use the tutorial's [pannable](https://svelte.dev/tutorial/actions).
+
+Something like:
+
+```javascript
+// pannable.js
+export function pannable(node) {
+  let x;
+  let y;
+
+  function handleMousedown(event) {
+    x = event.clientX;
+    y = event.clientY;
+
+    node.dispatchEvent(
+      new CustomEvent("panstart", {
+        detail: { x, y },
+      })
+    );
+
+    window.addEventListener("mousemove", handleMousemove);
+    window.addEventListener("mouseup", handleMouseup);
+  }
+
+  function handleMousemove(event) {
+    const dx = event.clientX - x;
+    const dy = event.clientY - y;
+    x = event.clientX;
+    y = event.clientY;
+
+    node.dispatchEvent(
+      new CustomEvent("panmove", {
+        detail: { x, y, dx, dy },
+      })
+    );
+  }
+
+  function handleMouseup(event) {
+    x = event.clientX;
+    y = event.clientY;
+
+    node.dispatchEvent(
+      new CustomEvent("panend", {
+        detail: { x, y },
+      })
+    );
+
+    window.removeEventListener("mousemove", handleMousemove);
+    window.removeEventListener("mouseup", handleMouseup);
+  }
+
+  node.addEventListener("mousedown", handleMousedown);
+
+  return {
+    destroy() {
+      node.removeEventListener("mousedown", handleMousedown);
+    },
+  };
+}
+```
+
+Would become:
+
+```html
+<!-- pannable.svelte -->
+<script context="action">
+  let x;
+  let y;
+
+  let windowMousemove;
+  let windowMouseup;
+
+  let target;
+
+  function handleMousemove(event) {
+    const dx = event.clientX - x;
+    const dy = event.clientY - y;
+    x = event.clientX;
+    y = event.clientY;
+
+    target.dispatchEvent(
+      new CustomEvent("panmove", {
+        detail: { x, y, dx, dy },
+      })
+    );
+  }
+
+  function handleMouseup(event) {
+    x = event.clientX;
+    y = event.clientY;
+
+    target.dispatchEvent(
+      new CustomEvent("panend", {
+        detail: { x, y },
+      })
+    );
+
+    windowMousemove = () => {};
+    windowMouseup = () => {};
+  }
+
+  function handleMousedown(event) {
+    x = event.clientX;
+    y = event.clientY;
+
+    target.dispatchEvent(
+      new CustomEvent("panstart", {
+        detail: { x, y },
+      })
+    );
+
+    windowMousemove = handleMousemove;
+    windowMouseup = handleMouseup;
+  }
+</script>
+
+<svelte:window on:mousemove="{windowMousemove}" on:mouseup="{windowMouseup}" />
+<target on:mousedown="{handleMousedown}" bind:this="{target}" />
+```
+
 > Why are we doing this? What use cases does it support?
 
 > Please provide specific examples. If you say "this would be more flexible" then
@@ -102,7 +227,7 @@ Consumer component:
 ### Implementation
 
 > Explain the design in enough detail for somebody familiar with the framework to
-understand, and for somebody familiar with the implementation to implement. Any
+> understand, and for somebody familiar with the implementation to implement. Any
 > new terminology should be defined here.
 
 > Explain not just the final design, but also how you arrived at it. What
@@ -119,21 +244,21 @@ understand, and for somebody familiar with the implementation to implement. Any
 ## How we teach this
 
 > What names and terminology work best for these concepts and why? How is this
-idea best presented? As a continuation of existing Svelte patterns, or as a
-wholly new one?
+> idea best presented? As a continuation of existing Svelte patterns, or as a
+> wholly new one?
 
 > Would the acceptance of this proposal mean the Svelte guides must be
-re-organized or altered? Does it change how Svelte is taught to new users
-at any level?
+> re-organized or altered? Does it change how Svelte is taught to new users
+> at any level?
 
 > How should this feature be introduced and taught to existing Svelte
-users?
+> users?
 
 ## Drawbacks
 
-> Why should we *not* do this? Please consider the impact on teaching Svelte,
-on the integration of this feature with other existing and planned features,
-on the impact of the API churn on existing apps, etc.
+> Why should we _not_ do this? Please consider the impact on teaching Svelte,
+> on the integration of this feature with other existing and planned features,
+> on the impact of the API churn on existing apps, etc.
 
 > There are tradeoffs to choosing any path, please attempt to identify them here.
 

From bbd14c85b82171085184e505986f26f2ff9ef9ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Thu, 19 Nov 2020 05:23:39 +0000
Subject: [PATCH 10/22] comentarios e panning

---
 0000-declarative-actions.md | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index a8a69d2..422392b 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -31,7 +31,7 @@ Action:
 
 <!-- target is an alias to the Element this action is applied to -->
 <!--
-  ".svelte" files with an action context script may only have one element,
+  ".svelte" files with an action context script may only have one Element (excluding Special Elements),
   a target, and target shall have 0 children.
 -->
 <target
@@ -136,13 +136,12 @@ Would become:
 ```html
 <!-- pannable.svelte -->
 <script context="action">
+  let target;
+
   let x;
   let y;
 
-  let windowMousemove;
-  let windowMouseup;
-
-  let target;
+  let panning = false;
 
   function handleMousemove(event) {
     const dx = event.clientX - x;
@@ -160,18 +159,17 @@ Would become:
   function handleMouseup(event) {
     x = event.clientX;
     y = event.clientY;
+    panning = false;
 
     target.dispatchEvent(
       new CustomEvent("panend", {
         detail: { x, y },
       })
     );
-
-    windowMousemove = () => {};
-    windowMouseup = () => {};
   }
 
   function handleMousedown(event) {
+    panning = true;
     x = event.clientX;
     y = event.clientY;
 
@@ -186,10 +184,15 @@ Would become:
   }
 </script>
 
-<svelte:window on:mousemove="{windowMousemove}" on:mouseup="{windowMouseup}" />
+<svelte:window
+  on:mousemove="{panning ? handleMousemove: undefined}"
+  on:mouseup="{panning ? handleMouseup: undefined}"
+/>
 <target on:mousedown="{handleMousedown}" bind:this="{target}" />
 ```
 
+The second version
+
 > Why are we doing this? What use cases does it support?
 
 > Please provide specific examples. If you say "this would be more flexible" then

From 185245a4b7d2a81d26576cb4b3f89045ceb36982 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Sun, 22 Nov 2020 04:36:27 +0000
Subject: [PATCH 11/22] Motivation e detailed design done

---
 .vscode/settings.json       |  13 ++
 0000-declarative-actions.md | 262 ++++++++++++++++++++++++++++++------
 2 files changed, 234 insertions(+), 41 deletions(-)
 create mode 100644 .vscode/settings.json

diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 0000000..effd5f8
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,13 @@
+{
+    "cSpell.words": [
+        "mousedown",
+        "mousemove",
+        "mouseup",
+        "panend",
+        "panmove",
+        "pannable",
+        "panstart",
+        "pointerdown",
+        "pointerup"
+    ]
+}
\ No newline at end of file
diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 422392b..65c8ae6 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -14,9 +14,13 @@ Action:
 <!-- action.svelte -->
 <script context="action">
   /*
-    Not used in this example, I just binded the Element to demonstrate 
+    Not used in this example, I just bound the Element to demonstrate 
     actions could still be written purely imperatively as they are now
-    with 'onDestroy', 'afterUpdate', 'beforeUpdate' and 'onMount'.
+    with "onDestroy", "afterUpdate", "beforeUpdate" and "onMount". Or with
+    an action specific API with only "onMount" and "onDestroy". "onUpdate"
+    is no longer needed since you'd be able to use reactive declarations
+    ("$: foo = bar;"), and Svelte would automatically update the DOM if you
+    used the parameters in the markup.
   */
   let target;
 
@@ -31,8 +35,9 @@ Action:
 
 <!-- target is an alias to the Element this action is applied to -->
 <!--
-  ".svelte" files with an action context script may only have one Element (excluding Special Elements),
-  a target, and target shall have 0 children.
+  ".svelte" files with an action context script may only have
+  one Element (excluding Special Elements), a target, and target 
+  shall have 0 children **.
 -->
 <target
   class:red-background="{isHeld}"
@@ -46,7 +51,7 @@ Consumer component:
 
 ```html
 <!-- Consumer.svelte -->
-<!-- works like current action consumption -->
+<!-- works like current action consumption*  -->
 <script>
   import action from "./action.svelte";
 </script>
@@ -62,15 +67,21 @@ Consumer component:
 </div>
 ```
 
+##### [\*parameters will slightly vary from current action consumption](#Parameters)
+
+##### [\*\*more on the Target Element](<#The\ Target\ Element>)
+
 ## Motivation
 
 # Think about how custom variables as props would affect this.
 
 # Action arguments {} -> {{}} desugaring.
 
-Currently, writing an action takes away all Svelte's ergonomics. You can't use directives, you can't use {# ... } blocks and you can't apply styles using css sheets (or `<style></style>` blocks) without somehow including it globally (my particular use case).
+## Motivation
+
+Currently, writing an action takes away all of Svelte's ergonomics. You can't use directives, you can't use {# ... } or {@ ... } blocks and you can't apply styles using css sheets (or `<style></style>` blocks) without somehow including them globally (my particular use case).
 
-As an example of a slightly more complicated action than the one I provided in the [Summary](#Summary), I will use the tutorial's [pannable](https://svelte.dev/tutorial/actions).
+As an example of a slightly more complicated action than the one I provided in the [summary](#Summary), I will use the tutorial's [pannable](https://svelte.dev/tutorial/actions).
 
 Something like:
 
@@ -131,7 +142,7 @@ export function pannable(node) {
 }
 ```
 
-Would become:
+Could become:
 
 ```html
 <!-- pannable.svelte -->
@@ -169,18 +180,15 @@ Would become:
   }
 
   function handleMousedown(event) {
-    panning = true;
     x = event.clientX;
     y = event.clientY;
+    panning = true;
 
     target.dispatchEvent(
       new CustomEvent("panstart", {
         detail: { x, y },
       })
     );
-
-    windowMousemove = handleMousemove;
-    windowMouseup = handleMouseup;
   }
 </script>
 
@@ -191,27 +199,145 @@ Would become:
 <target on:mousedown="{handleMousedown}" bind:this="{target}" />
 ```
 
-The second version
+This way of writing actions seems more inline with Svelte's idiomaticity.
+Since most of what you're doing with an action is modifying an Element I don't see why there shouldn't be a way to do so declaratively. This is the sole reason for the existence of directives, they make it easier to use DOM features without having to worry about cleanup or what is happening behind the scenes.
+
+Apart from the ergonomic differences there are also functional differences. As I mentioned [above](#Motivation), being able to use Svelte's extensions to the Markup and being able to style the target Element without bypassing Svelte's style system are benefits of this implementation of actions that are in no way possible with the current one.
+
+### More on CSS
+
+Personally, styling is my greatest concern. Currently there is no way to abstract styles applied directly to an element cleanly. As of today there are 3 routes you can take:
+
+1.  Make a wrapper Svelte Component with the styles which you wish to abstract:
+
+```html
+<!-- RedBackground.svelte -->
+<style>
+  .abstracted-styles {
+    background-color: red;
+  }
+</style>
+
+<div class="abstracted-styles" style="height: min-content; width: min-content;">
+  <slot />
+</div>
+```
+
+A problem with this specific solution would be, for example, if a consumer sets `border-style` and `border-radius`, the background would ignore that styling:
+
+```html
+<!-- Consumer.svelte -->
+<script>
+  import RedBackground from "./RedBackground.svelte";
+</script>
+<style>
+  .rounded-corners {
+    border-style: solid;
+    border-radius: 30px;
+    width: 160px;
+    height: 90px;
+  }
+</style>
+
+<RedBackground>
+  <div class="abstracted-styles" />
+</RedBackground>
+```
+
+This would cause the red background to extend past the border corners.
+We could forward the `styles` attribute of the top level `div` but then, our consumers still wouldn't be able to use stylesheets (or `<style></style>` blocks) to style the component.
+
+---
+
+2.  Make a wrapper or an inner Svelte Component with the styles which you wish to abstract (for this example I will use the "inner" implementation, since you can guarantee that a Component only has one parent but not that it only has one child):
+
+```html
+<!-- RedBackground.svelte -->
+<script>
+  let target;
+  $: {
+    if (target)
+      target.parentElement.style.setProperty("background-color", "red");
+  }
+</script>
+
+<div bind:this="{target}" />
+```
+
+```html
+<!-- Consumer.svelte -->
+<script>
+  import RedBackground from "./RedBackground.svelte";
+</script>
+<style>
+  .rounded-corners {
+    border-style: solid;
+    border-radius: 30px;
+    width: 160px;
+    height: 90px;
+  }
+</style>
+
+<div class="rounded-corners">
+  <RedBackground />
+  I am imperatively styled by a Svelte Component!
+</div>
+```
+
+This option works fine but has the disadvantage of not being able to use Svelte's style system. You can only use inline styles. To use a CSS sheet (be it for style abstraction purposes or because you need to use an external library) you have to do something like:
+
+```css
+/* external.css */
+.red-background {
+  background-color: red;
+}
+```
+
+```html
+<!-- RedBackground.svelte -->
+<script>
+  let target;
+  $: {
+    if (target) target.parentElement.style.classList.add("red-background");
+  }
+</script>
+
+<div bind:this="{target}" />
+```
+
+This way you need to rely on the consumer to somehow include your stylesheet globally.
 
-> Why are we doing this? What use cases does it support?
+---
+
+3. Since you are doing everything imperatively you might as well write an action:
+
+```javascript
+// redbackground.js
+export function redbackground(node) {
+  node.style.setProperty("background-color", "red");
+}
+```
 
-> Please provide specific examples. If you say "this would be more flexible" then
-> give an example of something that becomes easier. If you say "this would be make
-> it easier to do X" then give an example of what that looks like today and what's
-> hard about it.
+```html
+<!-- Consumer.svelte -->
+<script>
+  import redbackground from "./redbackground.js";
+</script>
+<style>
+  .rounded-corners {
+    border-style: solid;
+    border-radius: 30px;
+    width: 160px;
+    height: 90px;
+  }
+</style>
 
-> Don't assume that others recognize the problem is one that needs to be solved
-> Is there some concrete issue you cannot accomplish without this?
-> What does it look like to accomplish some set of goals today and how could
-> that be improved?
-> Are there any workarounds that are necessary today?
-> Are there open issues on Github where people would be helped by this?
-> Will the change have performance impacts? Can you quantify them?
+<div class="rounded-corners" use:redbackground>
+  I am imperatively styled by a Svelte Action!
+</div>
+```
 
-> Please focus on explaining the motivation so that if this RFC is not accepted,
-> the motivation could be used to develop alternative solutions. In other words,
-> enumerate the constraints you are trying to solve without coupling them too
-> closely to the solution you have in mind.
+This has the same disadvantages as option 2.
 
 ## Detailed design
 
@@ -227,22 +353,76 @@ The second version
 > design inspiration from others who have done this well and improve upon the
 > designs or make them better fit Svelte.
 
-### Implementation
+### The Target Element
+
+The Target Element should alias to the the Element the action is applied to. Any attributes set in this Element should be set in the Element the action is applied to.
+
+### `<style></style>`
+
+Any style created in an action should be scoped, and should be removed if it is not used by the action itself, just like what happens in Svelte Components.
 
-> Explain the design in enough detail for somebody familiar with the framework to
-> understand, and for somebody familiar with the implementation to implement. Any
-> new terminology should be defined here.
+### Parameters
 
-> Explain not just the final design, but also how you arrived at it. What
-> constraints did you face? Are there corner cases you've come up with solutions for?
+Currently the only way to pass multiple arguments to an action is by having an object as the second parameter. This is the convention I am proposing to implement parameters in declarative actions. The exported props of an action would be set with an object (it's really simple with an example).
 
-> Explain how your design fits into the larger picture. Are the other open problems
-> in this area you're familiar with? How does this design fit with potential
-> solutions for those issues?
+Example (TypeScript for clarity):
 
-> Connect your design to the motivations you listed above. When describing a part of
-> the design, it can be useful to share an example of what it would look like to
-> utilize the implementation as solution to the problem.
+Current implementation of actions:
+
+```javascript
+// parametersExample.ts
+export type Args = {
+    fontSizePixels: number;
+    color?: string;
+}
+export function parametersExample(node: Node, args: args)
+    const element = node as HTMLElement;
+    element.style.setProperty("color", args.color);
+    element.style.setProperty("fontSize", args.fontSizePixels + "px");
+```
+
+```html
+<!-- Consumer.svelte -->
+<script lang="ts">
+  import { parametersExample } from "parametersExample";
+
+  const color = "blue";
+  const fontSizePixels = 34;
+</script>
+
+<div use:parametersExample="{{fontSizePixels, color}}" />
+<div use:parametersExample="{{fontSizePixels}}" />
+```
+
+Declarative action:
+
+```html
+<!-- parametersExample.svelte -->
+<script lang="ts">
+  export let color: string = "";
+  export let fontSizePixels: number;
+</script>
+
+<target
+  stye="color: {color}; font-size: {fontSizePixels ? fontSizePixels + 'px' : 'initial'};"
+/>
+```
+
+```html
+<!-- Consumer.svelte -->
+<script lang="ts">
+  import { parametersExample } from "parametersExample.svelte";
+
+  const color = "blue";
+  const fontSizePixels = 34;
+</script>
+
+<div use:parametersExample="{{fontSizePixels, color}}" />
+<div use:parametersExample="{{fontSizePixels}}" />
+
+<!-- could be sugared to the following for single arguments-->
+<div use:parametersExample="{fontSizePixels}" />
+```
 
 ## How we teach this
 

From 81cc0c029b9d9a28287bed6516d9c5871d28b705 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Tue, 24 Nov 2020 18:04:55 +0000
Subject: [PATCH 12/22] done! needs revision

---
 0000-declarative-actions.md | 242 +++++++++++++++++++++++++++---------
 1 file changed, 184 insertions(+), 58 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 65c8ae6..452412f 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -37,7 +37,7 @@ Action:
 <!--
   ".svelte" files with an action context script may only have
   one Element (excluding Special Elements), a target, and target 
-  shall have 0 children **.
+  shall have 0 children.*
 -->
 <target
   class:red-background="{isHeld}"
@@ -51,7 +51,7 @@ Consumer component:
 
 ```html
 <!-- Consumer.svelte -->
-<!-- works like current action consumption*  -->
+<!-- works like current action consumption**  -->
 <script>
   import action from "./action.svelte";
 </script>
@@ -67,15 +67,9 @@ Consumer component:
 </div>
 ```
 
-##### [\*parameters will slightly vary from current action consumption](#Parameters)
+##### [\*more on the `<target />` Element](<#The\ \`\<target /\>\`\ Element>)
 
-##### [\*\*more on the Target Element](<#The\ Target\ Element>)
-
-## Motivation
-
-# Think about how custom variables as props would affect this.
-
-# Action arguments {} -> {{}} desugaring.
+##### [\*\*parameters will slightly vary from current action consumption](#Parameters)
 
 ## Motivation
 
@@ -208,6 +202,19 @@ Apart from the ergonomic differences there are also functional differences. As I
 
 Personally, styling is my greatest concern. Currently there is no way to abstract styles applied directly to an element cleanly. As of today there are 3 routes you can take:
 
+- Not abstracted:
+
+```html
+<!-- BaseLine.svelte -->
+<style>
+  .styles-to-abstract {
+    background-color: red;
+  }
+</style>
+
+<div class="styles-to-abstract">I'm a styled div!</div>
+```
+
 1.  Make a wrapper Svelte Component with the styles which you wish to abstract:
 
 ```html
@@ -240,16 +247,16 @@ A problem with this specific solution would be, for example, if a consumer sets
 </style>
 
 <RedBackground>
-  <div class="abstracted-styles" />
+  <div class="rounded-corners">I'm a div styled by my parent!</div>
 </RedBackground>
 ```
 
 This would cause the red background to extend past the border corners.
-We could forward the `styles` attribute of the top level `div` but then, our consumers still wouldn't be able to use stylesheets (or `<style></style>` blocks) to style the component.
+We could forward the `styles` attribute of the top level `div` but then, our consumers still wouldn't be able to use stylesheets (or `<script></script>` blocks) to style the component.
 
 ---
 
-2.  Make a wrapper or an inner Svelte Component with the styles which you wish to abstract (for this example I will use the "inner" implementation, since you can guarantee that a Component only has one parent but not that it only has one child):
+2.  Make a wrapper/inner Svelte Component that imperatively styles the desired Element (for this example I will use the "inner" implementation, since you can guarantee that a Component only has one parent but not that it only has one child):
 
 ```html
 <!-- RedBackground.svelte -->
@@ -280,11 +287,11 @@ We could forward the `styles` attribute of the top level `div` but then, our con
 
 <div class="rounded-corners">
   <RedBackground />
-  I am imperatively styled by a Svelte Component!
+  I am imperatively styled by an inner Svelte Component!
 </div>
 ```
 
-This option works fine but has the disadvantage of not being able to use Svelte's style system. You can only use inline styles. To use a CSS sheet (be it for style abstraction purposes or because you need to use an external library) you have to do something like:
+This option works fine but has the disadvantage of not being able to use Svelte's style system. You can only use javascript to do the styling. To use a CSS sheet (be it for style abstraction purposes or because you need to use an external library) you have to do something like:
 
 ```css
 /* external.css */
@@ -305,11 +312,11 @@ This option works fine but has the disadvantage of not being able to use Svelte'
 <div bind:this="{target}" />
 ```
 
-This way you need to rely on the consumer to somehow include your stylesheet globally.
+This way you need to rely on the consumer to somehow include your stylesheet (`external.css`) globally.
 
 ---
 
-3. Since you are doing everything imperatively you might as well write an action:
+3. Since you are doing everything imperatively you might as well use an action:
 
 ```javascript
 // redbackground.js
@@ -339,23 +346,92 @@ export function redbackground(node) {
 
 This has the same disadvantages as option 2.
 
+---
+
+With Declarative Actions it would look like this:
+
+```html
+<!-- redbackground.svelte -->
+<script context="action"></script>
+
+<style>
+  .abstracted-styles {
+    background-color: red;
+  }
+</style>
+
+<target class:abstracted-styles="{true}" />
+
+<!-- I avoided: -->
+<target class="abstracted-styles" />
+<!-- or -->
+<target style="background-color: red;" />
+<!-- because, in this case, I didn't want to overwrite the styles/classes set by the consumer -->
+```
+
+Consumer component:
+
+```html
+<!-- Consumer.svelte -->
+<script>
+  import redbackground from "./redbackground.svelte";
+</script>
+
+<style>
+  .rounded-corners {
+    border-style: solid;
+    border-radius: 30px;
+    width: 160px;
+    height: 90px;
+  }
+</style>
+
+<div class="rounded-corners" use:redbackground>
+  I am declaratively styled by a Svelte Action!
+</div>
+```
+
 ## Detailed design
 
-### Technical Background
+### The `<target />` Element
+
+The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to adn vice versa.
 
-> There are a lot of ways Svelte is used. It's hosted on different platforms;
-> integrated with different libraries; built with different bundlers, etc. No one
-> person knows everything about all the ways Svelte is used. What does someone who
-> knows about Svelte but hasn't necessarily used anything outside of it need to
-> know? Are there docs you can share?
+In the summary I alluded to the fact that `<target />` should be the only Element, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway. But would lose all the goodness of Declarative Actions. We could even allow Target to have children (?!?! iffy). The children could be added at the end/start of the children the Consumer already applied to the action's target. Or could replace them (!?!) idk. In my opinion adding elements around the `<Target />` (parents, grandparents etc.) could be an idea worth discussing but adding children seems too convolute.
 
-> How do different libraries or frameworks implement this feature? We can take
-> design inspiration from others who have done this well and improve upon the
-> designs or make them better fit Svelte.
+Something like:
+
+```javascript
+export function domTreeManipulation(node) {
+  const dupNode = node.cloneNode(true);
 
-### The Target Element
+  const div = document.createElement("div");
 
-The Target Element should alias to the the Element the action is applied to. Any attributes set in this Element should be set in the Element the action is applied to.
+  const span = document.createElement("span");
+  span.innerText = "DOM Tree Manipulation";
+
+  const dupSpan = span.cloneNode(true);
+
+  div.appendChild(span);
+  div.appendChild(dupNode);
+  div.appendChild(dupSpan);
+
+  node.replaceWith(div);
+}
+```
+
+Could become:
+
+```html
+<!-- domTreeManipulation.svelte -->
+<script context="action"></script>
+
+<div>
+  <span>DOM Tree Manipulation</span>
+  <target />
+  <span>DOM Tree Manipulation</span>
+</div>
+```
 
 ### `<style></style>`
 
@@ -363,7 +439,7 @@ Any style created in an action should be scoped, and should be removed if it is
 
 ### Parameters
 
-Currently the only way to pass multiple arguments to an action is by having an object as the second parameter. This is the convention I am proposing to implement parameters in declarative actions. The exported props of an action would be set with an object (it's really simple with an example).
+Currently the only way to pass multiple arguments to an action is by having an object as the second parameter. This is a convention we could use to pass arguments to Declarative Actions. The exported props of an action would be set with an object (it's really simple with an example).
 
 Example (TypeScript for clarity):
 
@@ -375,10 +451,11 @@ export type Args = {
     fontSizePixels: number;
     color?: string;
 }
-export function parametersExample(node: Node, args: args)
+export function parametersExample(node: Node, args: args) {
     const element = node as HTMLElement;
-    element.style.setProperty("color", args.color);
+    if (args.color) element.style.setProperty("color", args.color);
     element.style.setProperty("fontSize", args.fontSizePixels + "px");
+}
 ```
 
 ```html
@@ -390,22 +467,21 @@ export function parametersExample(node: Node, args: args)
   const fontSizePixels = 34;
 </script>
 
-<div use:parametersExample="{{fontSizePixels, color}}" />
-<div use:parametersExample="{{fontSizePixels}}" />
+<div use:parametersExample="{{fontSizePixels, color}}">2 arguments</div>
+
+<div use:parametersExample="{{fontSizePixels}}">1 argument</div>
 ```
 
 Declarative action:
 
 ```html
 <!-- parametersExample.svelte -->
-<script lang="ts">
-  export let color: string = "";
+<script context="action" lang="ts">
+  export let color: string = "initial";
   export let fontSizePixels: number;
 </script>
 
-<target
-  stye="color: {color}; font-size: {fontSizePixels ? fontSizePixels + 'px' : 'initial'};"
-/>
+<target stye="color: {color}; font-size: {fontSizePixels + 'px'};" />
 ```
 
 ```html
@@ -417,41 +493,91 @@ Declarative action:
   const fontSizePixels = 34;
 </script>
 
-<div use:parametersExample="{{fontSizePixels, color}}" />
-<div use:parametersExample="{{fontSizePixels}}" />
+<div use:parametersExample="{{fontSizePixels, color}}">2 arguments</div>
+
+<div use:parametersExample="{{fontSizePixels}}">1 argument</div>
 
 <!-- could be sugared to the following for single arguments-->
-<div use:parametersExample="{fontSizePixels}" />
+<div use:parametersExample="{fontSizePixels}">1 argument</div>
 ```
 
-## How we teach this
+Another option would be to rework the parameters completely. An idea I had, which could even potentially be used with the current actions, would be to use [Custom Data Attributes](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*). The action could capture the respectively named Data Attribute. A parameter called `foo` would have the value of an attribute called `data-foo`.
+
+Example Consumer (the action would be the same as the Declarative Action above):
+
+```html
+<!-- Consumer.svelte -->
+<script lang="ts">
+  import { parametersExample } from "parametersExample.svelte";
 
-> What names and terminology work best for these concepts and why? How is this
-> idea best presented? As a continuation of existing Svelte patterns, or as a
-> wholly new one?
+  const color = "blue";
+  const fontSizePixels = 34;
+</script>
+
+<div
+  use:parametersExample
+  data-color="{color}"
+  data-fontSizePixels="{fontSizePixels}"
+>
+  2 arguments
+</div>
+
+<div use:parametersExample data-fontSizePixels="{fontSizePixels}">
+  1 argument
+</div>
+
+<!-- there could even be a directive to set Data Attributes -->
+<div use:parametersExample data:fontSizePixels="{fontSizePixels}">
+  1 argument
+</div>
+
+<!-- for short -->
+<div use:parametersExample data:fontSizePixels>1 argument</div>
+```
+
+## How we teach this
 
-> Would the acceptance of this proposal mean the Svelte guides must be
-> re-organized or altered? Does it change how Svelte is taught to new users
-> at any level?
+We should teach this roughly the same as we teach Components with Slots. Though `<Target />` "only accepts one child", since the action is applied with a directive, therefore it can alias to said child.
 
-> How should this feature be introduced and taught to existing Svelte
-> users?
+Current svelte guides shouldn't have to be reorganized since there should be a section for Actions already.
 
 ## Drawbacks
 
-> Why should we _not_ do this? Please consider the impact on teaching Svelte,
-> on the integration of this feature with other existing and planned features,
-> on the impact of the API churn on existing apps, etc.
+- This would be a breaking change. Although it may be possible to keep the old actions around (I assume, I'm not well versed in the Svelte internals), it might not be worth the complexity. Having multiple ways to write an action might be more confusing than it needs to be, specially for new users.
 
-> There are tradeoffs to choosing any path, please attempt to identify them here.
+- Verbosity. For simple actions that need to be written imperatively anyway, this will be more cumbersome.
+
+- As for teaching, although this is a little more complicated than just a simple function, it shouldn't be that hard to teach/learn (I think ?).
+
+- Performance? I have no clue.
+
+##### I will add more as/if they rise in the pull request.
 
 ## Alternatives
 
-> What other designs have been considered? What is the impact of not doing this?
+The only alternative I could come up with was to introduce the `<Target />` Element, as described, and allow its use in Components, which would leave the current Action developer experience (arguably lesser) as it is.
 
-> This section could also include prior art, that is, how other frameworks in the
-> same domain have solved this problem differently.
+By not making this change, as I mentioned above, it would still be impossible to apply styles directly to an Element, defined, styled, etc.. by the consumer.
+
+##### I will add more as/if they rise in the pull request.
 
 ## Unresolved questions
 
-> Optional, but suggested for first drafts. What parts of the design are still TBD?
+I have brought up some already:
+
+1. Should we allow more Elements than the `<target /> ` Element in an action?
+2. What approach should we use for parameters (Data Attributes vs Object)?
+
+More:
+
+1. How should we distinguish Components from Actions?
+
+   My idea would be to add `context="action"` to scripts in actions. `context="module"` would still be supported. A single `.svelte` file shouldn't have a script without context and a script with `context="action"`. `<Target />` shouldn't be used in `.svelte` files without a `context="action"` script. Another way could be to force action's files' names to start with a lower case letter.
+
+   I'm open to suggestions.
+
+2. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
+
+3. Should custom CSS properties, set inside the Action, be available to the children of the component the Action is applied to?
+
+##### I will add more as/if they rise in the pull request.

From 61e879b24992b13e2f4432d2023bb7a541e09529 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Wed, 25 Nov 2020 13:03:29 +0000
Subject: [PATCH 13/22] Update 0000-declarative-actions.md

---
 0000-declarative-actions.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/0000-declarative-actions.md b/0000-declarative-actions.md
index 452412f..cb30f7a 100644
--- a/0000-declarative-actions.md
+++ b/0000-declarative-actions.md
@@ -1,4 +1,4 @@
-- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- Start Date: 2020-11-25
 - RFC PR: (leave this empty)
 - Svelte Issue: (leave this empty)
 
@@ -36,7 +36,7 @@ Action:
 <!-- target is an alias to the Element this action is applied to -->
 <!--
   ".svelte" files with an action context script may only have
-  one Element (excluding Special Elements), a target, and target 
+  one Element (excluding some Special Elements), a target, and target 
   shall have 0 children.*
 -->
 <target
@@ -194,7 +194,7 @@ Could become:
 ```
 
 This way of writing actions seems more inline with Svelte's idiomaticity.
-Since most of what you're doing with an action is modifying an Element I don't see why there shouldn't be a way to do so declaratively. This is the sole reason for the existence of directives, they make it easier to use DOM features without having to worry about cleanup or what is happening behind the scenes.
+Since most of what you're doing with an action is modifying an Element I don't see why there shouldn't be a way to do so declaratively. This is the sole reason for the existence of some directives, they make it easier to use DOM features without having to worry about cleanup or what is happening behind the scenes.
 
 Apart from the ergonomic differences there are also functional differences. As I mentioned [above](#Motivation), being able to use Svelte's extensions to the Markup and being able to style the target Element without bypassing Svelte's style system are benefits of this implementation of actions that are in no way possible with the current one.
 
@@ -291,7 +291,7 @@ We could forward the `styles` attribute of the top level `div` but then, our con
 </div>
 ```
 
-This option works fine but has the disadvantage of not being able to use Svelte's style system. You can only use javascript to do the styling. To use a CSS sheet (be it for style abstraction purposes or because you need to use an external library) you have to do something like:
+This option works fine but has the disadvantage of not being able to use Svelte's style system. You can only use javascript to do the styling. To use a stylesheet (be it for style abstraction purposes or because you need to use an external library) you have to do something like:
 
 ```css
 /* external.css */
@@ -395,9 +395,9 @@ Consumer component:
 
 ### The `<target />` Element
 
-The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to adn vice versa.
+The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to and vice versa.
 
-In the summary I alluded to the fact that `<target />` should be the only Element, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway. But would lose all the goodness of Declarative Actions. We could even allow Target to have children (?!?! iffy). The children could be added at the end/start of the children the Consumer already applied to the action's target. Or could replace them (!?!) idk. In my opinion adding elements around the `<Target />` (parents, grandparents etc.) could be an idea worth discussing but adding children seems too convolute.
+In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Consumer already applied to the action's target. Or could replace them (!?! idk). In my opinion adding elements around the `<Target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
 
 Something like:
 
@@ -477,7 +477,7 @@ Declarative action:
 ```html
 <!-- parametersExample.svelte -->
 <script context="action" lang="ts">
-  export let color: string = "initial";
+  export let color = "initial";
   export let fontSizePixels: number;
 </script>
 
@@ -503,7 +503,7 @@ Declarative action:
 
 Another option would be to rework the parameters completely. An idea I had, which could even potentially be used with the current actions, would be to use [Custom Data Attributes](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*). The action could capture the respectively named Data Attribute. A parameter called `foo` would have the value of an attribute called `data-foo`.
 
-Example Consumer (the action would be the same as the Declarative Action above):
+Example Consumer (the Action would be the same as the Declarative Action above):
 
 ```html
 <!-- Consumer.svelte -->
@@ -531,7 +531,7 @@ Example Consumer (the action would be the same as the Declarative Action above):
   1 argument
 </div>
 
-<!-- for short -->
+<!-- or, for short -->
 <div use:parametersExample data:fontSizePixels>1 argument</div>
 ```
 
@@ -549,15 +549,15 @@ Current svelte guides shouldn't have to be reorganized since there should be a s
 
 - As for teaching, although this is a little more complicated than just a simple function, it shouldn't be that hard to teach/learn (I think ?).
 
-- Performance? I have no clue.
+- Performance? I have no clue (could even be a benefit (?!) rather than a drawback since Declarative Actions would be statically analyzable).
 
 ##### I will add more as/if they rise in the pull request.
 
 ## Alternatives
 
-The only alternative I could come up with was to introduce the `<Target />` Element, as described, and allow its use in Components, which would leave the current Action developer experience (arguably lesser) as it is.
+The only alternative I could come up with was to introduce the `<Target />` Element, as described, and allow its use in Components, which would leave the current Action developer experience (arguably lesser than Declarative Actions) as it is.
 
-By not making this change, as I mentioned above, it would still be impossible to apply styles directly to an Element, defined, styled, etc.. by the consumer.
+By not making this change, as I mentioned above, it would still be impossible to apply styles directly to an Element defined, styled, etc.. by the consumer.
 
 ##### I will add more as/if they rise in the pull request.
 

From be6b02babafb6a7fda0ea9918a017f804e78b2f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 16:24:28 +0000
Subject: [PATCH 14/22] done. still needs 1 moree read through

---
 0000-template.md                              | 185 ++++++++++++++++++
 .../0000-declarative-actions.md               |  16 +-
 ...properties.md => 0002-style-properties.md} |   0
 ...tive-stores.md => 0003-reactive-stores.md} |   0
 ...tions.md => 0004-reactive-declarations.md} |   0
 ...position.md => 0005-better-composition.md} |   0
 6 files changed, 196 insertions(+), 5 deletions(-)
 create mode 100644 0000-template.md
 rename 0000-declarative-actions.md => text/0000-declarative-actions.md (95%)
 rename text/{0000-style-properties.md => 0002-style-properties.md} (100%)
 rename text/{0002-reactive-stores.md => 0003-reactive-stores.md} (100%)
 rename text/{0003-reactive-declarations.md => 0004-reactive-declarations.md} (100%)
 rename text/{0004-better-composition.md => 0005-better-composition.md} (100%)

diff --git a/0000-template.md b/0000-template.md
new file mode 100644
index 0000000..65559d9
--- /dev/null
+++ b/0000-template.md
@@ -0,0 +1,185 @@
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: (leave this empty)
+- Svelte Issue: (leave this empty)
+
+# (RFC title goes here)
+
+## Summary
+
+> One paragraph explanation of the feature.
+
+## Motivation
+
+> Why are we doing this? What use cases does it support?
+
+> Please provide specific examples. If you say "this would be more flexible" then
+> give an example of something that becomes easier. If you say "this would be make
+> it easier to do X" then give an example of what that looks like today and what's
+> hard about it.
+
+> Don't assume that others recognize the problem is one that needs to be solved
+> Is there some concrete issue you cannot accomplish without this?
+> What does it look like to accomplish some set of goals today and how could
+> that be improved?
+> Are there any workarounds that are necessary today?
+> Are there open issues on Github where people would be helped by this?
+> Will the change have performance impacts? Can you quantify them?
+
+> Please focus on explaining the motivation so that if this RFC is not accepted,
+> the motivation could be used to develop alternative solutions. In other words,
+> enumerate the constraints you are trying to solve without coupling them too
+> closely to the solution you have in mind.- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: (leave this empty)
+- Svelte Issue: (leave this empty)
+
+# (RFC title goes here)
+
+## Summary
+
+> One paragraph explanation of the feature.
+
+## Motivation
+
+> Why are we doing this? What use cases does it support?
+
+> Please provide specific examples. If you say "this would be more flexible" then
+> give an example of something that becomes easier. If you say "this would be make
+> it easier to do X" then give an example of what that looks like today and what's
+> hard about it.
+
+> Don't assume that others recognize the problem is one that needs to be solved
+> Is there some concrete issue you cannot accomplish without this?
+> What does it look like to accomplish some set of goals today and how could
+> that be improved?
+> Are there any workarounds that are necessary today?
+> Are there open issues on Github where people would be helped by this?
+> Will the change have performance impacts? Can you quantify them?
+
+> Please focus on explaining the motivation so that if this RFC is not accepted,
+> the motivation could be used to develop alternative solutions. In other words,
+> enumerate the constraints you are trying to solve without coupling them too
+> closely to the solution you have in mind.
+
+## Detailed design
+
+### Technical Background
+
+> There are a lot of ways Svelte is used. It's hosted on different platforms;
+> integrated with different libraries; built with different bundlers, etc. No one
+> person knows everything about all the ways Svelte is used. What does someone who
+> knows about Svelte but hasn't necessarily used anything outside of it need to
+> know? Are there docs you can share?
+
+> How do different libraries or frameworks implement this feature? We can take
+> design inspiration from others who have done this well and improve upon the
+> designs or make them better fit Svelte.
+
+### Implementation
+
+> Explain the design in enough detail for somebody familiar with the framework to
+understand, and for somebody familiar with the implementation to implement. Any
+> new terminology should be defined here.
+
+> Explain not just the final design, but also how you arrived at it. What
+> constraints did you face? Are there corner cases you've come up with solutions for?
+
+> Explain how your design fits into the larger picture. Are the other open problems
+> in this area you're familiar with? How does this design fit with potential
+> solutions for those issues?
+
+> Connect your design to the motivations you listed above. When describing a part of
+> the design, it can be useful to share an example of what it would look like to
+> utilize the implementation as solution to the problem.
+
+## How we teach this
+
+> What names and terminology work best for these concepts and why? How is this
+idea best presented? As a continuation of existing Svelte patterns, or as a
+wholly new one?
+
+> Would the acceptance of this proposal mean the Svelte guides must be
+re-organized or altered? Does it change how Svelte is taught to new users
+at any level?
+
+> How should this feature be introduced and taught to existing Svelte
+users?
+
+## Drawbacks
+
+> Why should we *not* do this? Please consider the impact on teaching Svelte,
+on the integration of this feature with other existing and planned features,
+on the impact of the API churn on existing apps, etc.
+
+> There are tradeoffs to choosing any path, please attempt to identify them here.
+
+## Alternatives
+
+> What other designs have been considered? What is the impact of not doing this?
+
+> This section could also include prior art, that is, how other frameworks in the
+> same domain have solved this problem differently.
+
+## Unresolved questions
+
+> Optional, but suggested for first drafts. What parts of the design are still TBD?
+
+### Technical Background
+
+> There are a lot of ways Svelte is used. It's hosted on different platforms;
+> integrated with different libraries; built with different bundlers, etc. No one
+> person knows everything about all the ways Svelte is used. What does someone who
+> knows about Svelte but hasn't necessarily used anything outside of it need to
+> know? Are there docs you can share?
+
+> How do different libraries or frameworks implement this feature? We can take
+> design inspiration from others who have done this well and improve upon the
+> designs or make them better fit Svelte.
+
+### Implementation
+
+> Explain the design in enough detail for somebody familiar with the framework to
+understand, and for somebody familiar with the implementation to implement. Any
+> new terminology should be defined here.
+
+> Explain not just the final design, but also how you arrived at it. What
+> constraints did you face? Are there corner cases you've come up with solutions for?
+
+> Explain how your design fits into the larger picture. Are the other open problems
+> in this area you're familiar with? How does this design fit with potential
+> solutions for those issues?
+
+> Connect your design to the motivations you listed above. When describing a part of
+> the design, it can be useful to share an example of what it would look like to
+> utilize the implementation as solution to the problem.
+
+## How we teach this
+
+> What names and terminology work best for these concepts and why? How is this
+idea best presented? As a continuation of existing Svelte patterns, or as a
+wholly new one?
+
+> Would the acceptance of this proposal mean the Svelte guides must be
+re-organized or altered? Does it change how Svelte is taught to new users
+at any level?
+
+> How should this feature be introduced and taught to existing Svelte
+users?
+
+## Drawbacks
+
+> Why should we *not* do this? Please consider the impact on teaching Svelte,
+on the integration of this feature with other existing and planned features,
+on the impact of the API churn on existing apps, etc.
+
+> There are tradeoffs to choosing any path, please attempt to identify them here.
+
+## Alternatives
+
+> What other designs have been considered? What is the impact of not doing this?
+
+> This section could also include prior art, that is, how other frameworks in the
+> same domain have solved this problem differently.
+
+## Unresolved questions
+
+> Optional, but suggested for first drafts. What parts of the design are still TBD?
diff --git a/0000-declarative-actions.md b/text/0000-declarative-actions.md
similarity index 95%
rename from 0000-declarative-actions.md
rename to text/0000-declarative-actions.md
index cb30f7a..ead9fec 100644
--- a/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -451,7 +451,7 @@ export type Args = {
     fontSizePixels: number;
     color?: string;
 }
-export function parametersExample(node: Node, args: args) {
+export function parametersExample(node: Node, args: Args) {
     const element = node as HTMLElement;
     if (args.color) element.style.setProperty("color", args.color);
     element.style.setProperty("fontSize", args.fontSizePixels + "px");
@@ -481,7 +481,7 @@ Declarative action:
   export let fontSizePixels: number;
 </script>
 
-<target stye="color: {color}; font-size: {fontSizePixels + 'px'};" />
+<target style="color: {color}; font-size: {fontSizePixels + 'px'};" />
 ```
 
 ```html
@@ -570,14 +570,20 @@ I have brought up some already:
 
 More:
 
-1. How should we distinguish Components from Actions?
+1. If we chose the "Data Attributes" approach to parameters could we integrate this with Style Properties? PR [#13](https://github.com/sveltejs/rfcs/pull/13)
+
+   Something like `data:--some-style` could be interpreted as a Style Property. If we don't, it might be hard to receive styles as arguments and use them without overwriting the `styles` attribute without some sort of CSS-in-JS solution.
+
+2. How would constant props work?
+
+3. How should we distinguish Components from Actions?
 
    My idea would be to add `context="action"` to scripts in actions. `context="module"` would still be supported. A single `.svelte` file shouldn't have a script without context and a script with `context="action"`. `<Target />` shouldn't be used in `.svelte` files without a `context="action"` script. Another way could be to force action's files' names to start with a lower case letter.
 
    I'm open to suggestions.
 
-2. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
+4. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
 
-3. Should custom CSS properties, set inside the Action, be available to the children of the component the Action is applied to?
+5. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
 
 ##### I will add more as/if they rise in the pull request.
diff --git a/text/0000-style-properties.md b/text/0002-style-properties.md
similarity index 100%
rename from text/0000-style-properties.md
rename to text/0002-style-properties.md
diff --git a/text/0002-reactive-stores.md b/text/0003-reactive-stores.md
similarity index 100%
rename from text/0002-reactive-stores.md
rename to text/0003-reactive-stores.md
diff --git a/text/0003-reactive-declarations.md b/text/0004-reactive-declarations.md
similarity index 100%
rename from text/0003-reactive-declarations.md
rename to text/0004-reactive-declarations.md
diff --git a/text/0004-better-composition.md b/text/0005-better-composition.md
similarity index 100%
rename from text/0004-better-composition.md
rename to text/0005-better-composition.md

From f6f65384f95a9a10f0558d6a2055d89d8eb192b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 18:36:18 +0000
Subject: [PATCH 15/22] done v3. 1 more revision

---
 text/0000-declarative-actions.md | 39 ++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/text/0000-declarative-actions.md b/text/0000-declarative-actions.md
index ead9fec..68f093a 100644
--- a/text/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -69,7 +69,7 @@ Consumer component:
 
 ##### [\*more on the `<target />` Element](<#The\ \`\<target /\>\`\ Element>)
 
-##### [\*\*parameters will slightly vary from current action consumption](#Parameters)
+##### [\*\*parameters will slightly/greatly differ from current action consumption](#Parameters)
 
 ## Motivation
 
@@ -198,7 +198,7 @@ Since most of what you're doing with an action is modifying an Element I don't s
 
 Apart from the ergonomic differences there are also functional differences. As I mentioned [above](#Motivation), being able to use Svelte's extensions to the Markup and being able to style the target Element without bypassing Svelte's style system are benefits of this implementation of actions that are in no way possible with the current one.
 
-### More on CSS
+### More on styling
 
 Personally, styling is my greatest concern. Currently there is no way to abstract styles applied directly to an element cleanly. As of today there are 3 routes you can take:
 
@@ -295,7 +295,7 @@ This option works fine but has the disadvantage of not being able to use Svelte'
 
 ```css
 /* external.css */
-.red-background {
+.abstracted-styles {
   background-color: red;
 }
 ```
@@ -305,7 +305,7 @@ This option works fine but has the disadvantage of not being able to use Svelte'
 <script>
   let target;
   $: {
-    if (target) target.parentElement.style.classList.add("red-background");
+    if (target) target.parentElement.style.classList.add("abstracted-styles");
   }
 </script>
 
@@ -362,6 +362,7 @@ With Declarative Actions it would look like this:
 
 <target class:abstracted-styles="{true}" />
 
+<!------------------------------------------------------------------------------------------- -->
 <!-- I avoided: -->
 <target class="abstracted-styles" />
 <!-- or -->
@@ -397,7 +398,7 @@ Consumer component:
 
 The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to and vice versa.
 
-In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Consumer already applied to the action's target. Or could replace them (!?! idk). In my opinion adding elements around the `<Target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
+In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<Target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
 
 Something like:
 
@@ -447,14 +448,15 @@ Current implementation of actions:
 
 ```javascript
 // parametersExample.ts
-export type Args = {
+export type ArgsType = {
     fontSizePixels: number;
     color?: string;
 }
-export function parametersExample(node: Node, args: Args) {
+
+export function parametersExample(node: Node, args: ArgsType) {
     const element = node as HTMLElement;
     if (args.color) element.style.setProperty("color", args.color);
-    element.style.setProperty("fontSize", args.fontSizePixels + "px");
+    element.style.setProperty("font-size", args.fontSizePixels + "px");
 }
 ```
 
@@ -501,7 +503,7 @@ Declarative action:
 <div use:parametersExample="{fontSizePixels}">1 argument</div>
 ```
 
-Another option would be to rework the parameters completely. An idea I had, which could even potentially be used with the current actions, would be to use [Custom Data Attributes](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*). The action could capture the respectively named Data Attribute. A parameter called `foo` would have the value of an attribute called `data-foo`.
+Another option would be to rework the parameters completely. An idea I had, which could even potentially be used with the current actions, would be to use [Custom Data Attributes](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*). The action could capture the respectively named Data Attribute. A parameter called `foo` would have the value of an attribute called `data-foo` (or even `data-[actionname]-foo` to prevent name collisions, if the consumer wants to use Data Attributes for other purposes, maybe even other actions).
 
 Example Consumer (the Action would be the same as the Declarative Action above):
 
@@ -537,7 +539,7 @@ Example Consumer (the Action would be the same as the Declarative Action above):
 
 ## How we teach this
 
-We should teach this roughly the same as we teach Components with Slots. Though `<Target />` "only accepts one child", since the action is applied with a directive, therefore it can alias to said child.
+We should teach this roughly the same as we teach Components with Slots. Though `<target />` "only accepts one child", since the action is applied with a directive, therefore it can alias to said child.
 
 Current svelte guides shouldn't have to be reorganized since there should be a section for Actions already.
 
@@ -549,13 +551,13 @@ Current svelte guides shouldn't have to be reorganized since there should be a s
 
 - As for teaching, although this is a little more complicated than just a simple function, it shouldn't be that hard to teach/learn (I think ?).
 
-- Performance? I have no clue (could even be a benefit (?!) rather than a drawback since Declarative Actions would be statically analyzable).
+- Performance? I have no clue (it could even be a benefit (?!) rather than a drawback since Declarative Actions would be statically analyzable).
 
 ##### I will add more as/if they rise in the pull request.
 
 ## Alternatives
 
-The only alternative I could come up with was to introduce the `<Target />` Element, as described, and allow its use in Components, which would leave the current Action developer experience (arguably lesser than Declarative Actions) as it is.
+The only alternative I could come up with was to introduce the `<target />` Element, as described, and allow its use in Components, which would leave the current Action developer experience (arguably lesser than Declarative Actions) as it is.
 
 By not making this change, as I mentioned above, it would still be impossible to apply styles directly to an Element defined, styled, etc.. by the consumer.
 
@@ -574,16 +576,19 @@ More:
 
    Something like `data:--some-style` could be interpreted as a Style Property. If we don't, it might be hard to receive styles as arguments and use them without overwriting the `styles` attribute without some sort of CSS-in-JS solution.
 
-2. How would constant props work?
+2. If we chose the "Data Attributes" approach, could we just provide both a directive to set Data Attributes and a directive to set Action parameters and use Data Attributes in the background?
+    Ex.: `data:actionname:parametername={value}`. This way we could obfuscate the parameter names to avoid collisions.
+
+3. How would constant props work?
 
-3. How should we distinguish Components from Actions?
+4. How should we distinguish Components from Actions?
 
-   My idea would be to add `context="action"` to scripts in actions. `context="module"` would still be supported. A single `.svelte` file shouldn't have a script without context and a script with `context="action"`. `<Target />` shouldn't be used in `.svelte` files without a `context="action"` script. Another way could be to force action's files' names to start with a lower case letter.
+   My idea would be to add `context="action"` to scripts in actions. `context="module"` would still be supported. A single `.svelte` file shouldn't have a script without context and a script with `context="action"`. `<target />` shouldn't be used in `.svelte` files without a `context="action"` script. Another way could be to force actions' files' names to start with a lower case letter.
 
    I'm open to suggestions.
 
-4. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
+5. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
 
-5. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
+6. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
 
 ##### I will add more as/if they rise in the pull request.

From f73188a5f276c6f9a6153681a32f3e14eb2faaa2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 18:53:19 +0000
Subject: [PATCH 16/22] done

---
 text/0000-declarative-actions.md | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/text/0000-declarative-actions.md b/text/0000-declarative-actions.md
index 68f093a..d9c777b 100644
--- a/text/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -398,7 +398,7 @@ Consumer component:
 
 The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to and vice versa.
 
-In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<Target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
+In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute. Siblings should not be supported in my opinion.
 
 Something like:
 
@@ -545,13 +545,13 @@ Current svelte guides shouldn't have to be reorganized since there should be a s
 
 ## Drawbacks
 
-- This would be a breaking change. Although it may be possible to keep the old actions around (I assume, I'm not well versed in the Svelte internals), it might not be worth the complexity. Having multiple ways to write an action might be more confusing than it needs to be, specially for new users.
+1. This would be a breaking change. Although it may be possible to keep the old actions around (I assume, I'm not well versed in the Svelte internals), it might not be worth the complexity. Having multiple ways to write an action might be more confusing than it needs to be, specially for new users.
 
-- Verbosity. For simple actions that need to be written imperatively anyway, this will be more cumbersome.
+2. Verbosity. For simple actions that need to be written imperatively anyway, this will be more cumbersome.
 
-- As for teaching, although this is a little more complicated than just a simple function, it shouldn't be that hard to teach/learn (I think ?).
+3. As for teaching, although this is a little more complicated than just a simple function, it shouldn't be that hard to teach/learn (I think ?).
 
-- Performance? I have no clue (it could even be a benefit (?!) rather than a drawback since Declarative Actions would be statically analyzable).
+4. Performance? I have no clue (it could even be a benefit (?!) rather than a drawback since Declarative Actions would be statically analyzable).
 
 ##### I will add more as/if they rise in the pull request.
 
@@ -572,23 +572,23 @@ I have brought up some already:
 
 More:
 
-1. If we chose the "Data Attributes" approach to parameters could we integrate this with Style Properties? PR [#13](https://github.com/sveltejs/rfcs/pull/13)
+3. If we chose the "Data Attributes" approach to parameters could we integrate this with Style Properties? PR [#13](https://github.com/sveltejs/rfcs/pull/13)
 
-   Something like `data:--some-style` could be interpreted as a Style Property. If we don't, it might be hard to receive styles as arguments and use them without overwriting the `styles` attribute without some sort of CSS-in-JS solution.
+   Something like `data:--some-style` could be interpreted as a Style Property. If we don't, it might be hard to receive styles as arguments and use them without overwriting the `styles` attribute without using some sort of CSS-in-JS solution.
 
-2. If we chose the "Data Attributes" approach, could we just provide both a directive to set Data Attributes and a directive to set Action parameters and use Data Attributes in the background?
-    Ex.: `data:actionname:parametername={value}`. This way we could obfuscate the parameter names to avoid collisions.
+4. If we chose the "Data Attributes" approach, could we just provide both a directive to set Data Attributes and a directive to set Action parameters and use Data Attributes in the background?
+   Ex.: `data:actionname:parametername={value}`. This way we could obfuscate the parameter names to avoid collisions.
 
-3. How would constant props work?
+5. How would constant props work?
 
-4. How should we distinguish Components from Actions?
+6. How should we distinguish Components from Actions?
 
    My idea would be to add `context="action"` to scripts in actions. `context="module"` would still be supported. A single `.svelte` file shouldn't have a script without context and a script with `context="action"`. `<target />` shouldn't be used in `.svelte` files without a `context="action"` script. Another way could be to force actions' files' names to start with a lower case letter.
 
    I'm open to suggestions.
 
-5. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
+7. This is a personal annoyance. What is the current convention for action names? All lower case? Camel case? What should it be for Declarative Actions?
 
-6. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
+8. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
 
 ##### I will add more as/if they rise in the pull request.

From 86532a4bcea3819ee66ca936de018e5b8987d3bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 18:55:41 +0000
Subject: [PATCH 17/22] removed .vscode

---
 .vscode/settings.json | 13 -------
 0000-template.md      | 91 -------------------------------------------
 2 files changed, 104 deletions(-)
 delete mode 100644 .vscode/settings.json

diff --git a/.vscode/settings.json b/.vscode/settings.json
deleted file mode 100644
index effd5f8..0000000
--- a/.vscode/settings.json
+++ /dev/null
@@ -1,13 +0,0 @@
-{
-    "cSpell.words": [
-        "mousedown",
-        "mousemove",
-        "mouseup",
-        "panend",
-        "panmove",
-        "pannable",
-        "panstart",
-        "pointerdown",
-        "pointerup"
-    ]
-}
\ No newline at end of file
diff --git a/0000-template.md b/0000-template.md
index 65559d9..0c61215 100644
--- a/0000-template.md
+++ b/0000-template.md
@@ -25,36 +25,6 @@
 > Are there open issues on Github where people would be helped by this?
 > Will the change have performance impacts? Can you quantify them?
 
-> Please focus on explaining the motivation so that if this RFC is not accepted,
-> the motivation could be used to develop alternative solutions. In other words,
-> enumerate the constraints you are trying to solve without coupling them too
-> closely to the solution you have in mind.- Start Date: (fill me in with today's date, YYYY-MM-DD)
-- RFC PR: (leave this empty)
-- Svelte Issue: (leave this empty)
-
-# (RFC title goes here)
-
-## Summary
-
-> One paragraph explanation of the feature.
-
-## Motivation
-
-> Why are we doing this? What use cases does it support?
-
-> Please provide specific examples. If you say "this would be more flexible" then
-> give an example of something that becomes easier. If you say "this would be make
-> it easier to do X" then give an example of what that looks like today and what's
-> hard about it.
-
-> Don't assume that others recognize the problem is one that needs to be solved
-> Is there some concrete issue you cannot accomplish without this?
-> What does it look like to accomplish some set of goals today and how could
-> that be improved?
-> Are there any workarounds that are necessary today?
-> Are there open issues on Github where people would be helped by this?
-> Will the change have performance impacts? Can you quantify them?
-
 > Please focus on explaining the motivation so that if this RFC is not accepted,
 > the motivation could be used to develop alternative solutions. In other words,
 > enumerate the constraints you are trying to solve without coupling them too
@@ -122,64 +92,3 @@ on the impact of the API churn on existing apps, etc.
 ## Unresolved questions
 
 > Optional, but suggested for first drafts. What parts of the design are still TBD?
-
-### Technical Background
-
-> There are a lot of ways Svelte is used. It's hosted on different platforms;
-> integrated with different libraries; built with different bundlers, etc. No one
-> person knows everything about all the ways Svelte is used. What does someone who
-> knows about Svelte but hasn't necessarily used anything outside of it need to
-> know? Are there docs you can share?
-
-> How do different libraries or frameworks implement this feature? We can take
-> design inspiration from others who have done this well and improve upon the
-> designs or make them better fit Svelte.
-
-### Implementation
-
-> Explain the design in enough detail for somebody familiar with the framework to
-understand, and for somebody familiar with the implementation to implement. Any
-> new terminology should be defined here.
-
-> Explain not just the final design, but also how you arrived at it. What
-> constraints did you face? Are there corner cases you've come up with solutions for?
-
-> Explain how your design fits into the larger picture. Are the other open problems
-> in this area you're familiar with? How does this design fit with potential
-> solutions for those issues?
-
-> Connect your design to the motivations you listed above. When describing a part of
-> the design, it can be useful to share an example of what it would look like to
-> utilize the implementation as solution to the problem.
-
-## How we teach this
-
-> What names and terminology work best for these concepts and why? How is this
-idea best presented? As a continuation of existing Svelte patterns, or as a
-wholly new one?
-
-> Would the acceptance of this proposal mean the Svelte guides must be
-re-organized or altered? Does it change how Svelte is taught to new users
-at any level?
-
-> How should this feature be introduced and taught to existing Svelte
-users?
-
-## Drawbacks
-
-> Why should we *not* do this? Please consider the impact on teaching Svelte,
-on the integration of this feature with other existing and planned features,
-on the impact of the API churn on existing apps, etc.
-
-> There are tradeoffs to choosing any path, please attempt to identify them here.
-
-## Alternatives
-
-> What other designs have been considered? What is the impact of not doing this?
-
-> This section could also include prior art, that is, how other frameworks in the
-> same domain have solved this problem differently.
-
-## Unresolved questions
-
-> Optional, but suggested for first drafts. What parts of the design are still TBD?

From 39f0467f4143e4598bc54b21f9b2ffe91f8e4a02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 18:57:43 +0000
Subject: [PATCH 18/22] file names

---
 text/{0002-style-properties.md => 0001-style-properties.md}       | 0
 ...{0001-reactive-assignments.md => 0002-reactive-assignments.md} | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename text/{0002-style-properties.md => 0001-style-properties.md} (100%)
 rename text/{0001-reactive-assignments.md => 0002-reactive-assignments.md} (100%)

diff --git a/text/0002-style-properties.md b/text/0001-style-properties.md
similarity index 100%
rename from text/0002-style-properties.md
rename to text/0001-style-properties.md
diff --git a/text/0001-reactive-assignments.md b/text/0002-reactive-assignments.md
similarity index 100%
rename from text/0001-reactive-assignments.md
rename to text/0002-reactive-assignments.md

From 932bd708caa73d21c431bbfe7acb2fdf80edc868 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 19:19:40 +0000
Subject: [PATCH 19/22] removed wrong siblings statement

---
 text/0000-declarative-actions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-declarative-actions.md b/text/0000-declarative-actions.md
index d9c777b..115a910 100644
--- a/text/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -398,7 +398,7 @@ Consumer component:
 
 The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to and vice versa.
 
-In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute. Siblings should not be supported in my opinion.
+In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
 
 Something like:
 

From 9579c7a2359b7cdf0dcb165f918c087e22944341 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <berna.agua@gmail.com>
Date: Wed, 25 Nov 2020 19:21:22 +0000
Subject: [PATCH 20/22] Update 0000-declarative-actions.md

---
 text/0000-declarative-actions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-declarative-actions.md b/text/0000-declarative-actions.md
index 115a910..7195e10 100644
--- a/text/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -398,7 +398,7 @@ Consumer component:
 
 The `<target />` Element should alias to the the Element the action is applied to. Any attributes set in the `<target />` Element should be set in the Element the action is applied to and vice versa.
 
-In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<target />` (parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
+In the summary I alluded to the fact that `<target />` should be the only Element present in an action, apart from `svelte:window`, `svelte:head` and `svelte:body`. Should this be the case? I could see someone wanting to modify the DOM tree with an Action. Should we encourage this? If someone really needs to do this, they can do so imperatively anyway, but would lose all the goodness of Declarative Actions. We could even allow `<target />` to have children (?!?! iffy). The children could be added at the end/start of the children the Element the Action is applied to already has. Or could replace them (!?! idk). In my opinion adding elements around the `<target />` (siblings, parents, grandparents, etc.) could be an idea worth discussing but adding children seems too convolute.
 
 Something like:
 

From d103ad63b515a6f59680bb7934f4d85eaee09812 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Tue, 28 Sep 2021 14:44:56 +0100
Subject: [PATCH 21/22] Update 0000-declarative-actions.md

---
 text/0000-declarative-actions.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/text/0000-declarative-actions.md b/text/0000-declarative-actions.md
index 7195e10..a68b536 100644
--- a/text/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -591,4 +591,6 @@ More:
 
 8. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
 
+9. [Prinzhorn's comment](https://github.com/sveltejs/rfcs/pull/41#issuecomment-924762831) - Is `<target />` a good tag? Should we use `<svelte:target />` since `<target />` isn't standard? Any other name?
+
 ##### I will add more as/if they rise in the pull request.

From 0556500e7a82cabb148771a70d415aaca9341d29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernardo=20Ant=C3=B3nio=20Borda=20d=27=C3=81gua?=
 <34165908+Zizico2@users.noreply.github.com>
Date: Thu, 30 Sep 2021 15:54:05 +0100
Subject: [PATCH 22/22] Update 0000-declarative-actions.md

---
 text/0000-declarative-actions.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/text/0000-declarative-actions.md b/text/0000-declarative-actions.md
index a68b536..a298659 100644
--- a/text/0000-declarative-actions.md
+++ b/text/0000-declarative-actions.md
@@ -537,6 +537,14 @@ Example Consumer (the Action would be the same as the Declarative Action above):
 <div use:parametersExample data:fontSizePixels>1 argument</div>
 ```
 
+EDIT | 30-09-2021
+
+## Implementation
+
+As for (Pinzhorn's suggestion)[https://github.com/sveltejs/rfcs/pull/41#issuecomment-924762831], Svelte should be able to compile Declarative Actions to imperative actions. From there, Declarative Actions would be usable as any other action. Both as a function or with `use:`. This would also mean 100% backwards compatibility and we would have the ability to mix n' match both types of actions. Declarative actions wouldn't need to replace the current ones.
+
+EDIT | END
+
 ## How we teach this
 
 We should teach this roughly the same as we teach Components with Slots. Though `<target />` "only accepts one child", since the action is applied with a directive, therefore it can alias to said child.
@@ -546,6 +554,7 @@ Current svelte guides shouldn't have to be reorganized since there should be a s
 ## Drawbacks
 
 1. This would be a breaking change. Although it may be possible to keep the old actions around (I assume, I'm not well versed in the Svelte internals), it might not be worth the complexity. Having multiple ways to write an action might be more confusing than it needs to be, specially for new users.
+EDIT | 30-09-2021 - (this may not be true anymore)
 
 2. Verbosity. For simple actions that need to be written imperatively anyway, this will be more cumbersome.
 
@@ -591,6 +600,12 @@ More:
 
 8. Should custom CSS properties set inside the Action be available to the children of the component the Action is applied to?
 
+EDIT | 28-09-2021
+
 9. [Prinzhorn's comment](https://github.com/sveltejs/rfcs/pull/41#issuecomment-924762831) - Is `<target />` a good tag? Should we use `<svelte:target />` since `<target />` isn't standard? Any other name?
 
+EDIT | END
+
+
+
 ##### I will add more as/if they rise in the pull request.