diff --git a/Proposal.md b/Proposal.md
index 3224fbd..ae0dde2 100644
--- a/Proposal.md
+++ b/Proposal.md
@@ -22,9 +22,9 @@ In discussions with the React framework team regarding ways React could be able
 
 Perhaps most importantly, **declaratively exposing to the platform the strategy for how the custom element (or custom enhancement) goes about parsing its observed attributes would give the platform (and userland implementations) the opportunity to optimize this processing during template instantiation** -- scenarios where the attributes are repeatedly cloned and (if necessary) re-parsed.  If the platform ever makes it to the point where it provides official support for template instantiation, it could look for optimizing opportunities -- cache the parsed strings.  In the meantime, userland implementations of template instantiation could take advantage of the same sorts of optimizations **without requiring adopting a proprietary solution**, but rather, based on this standard.
 
-As has been pointed out [here](https://web.dev/articles/custom-elements-best-practices#avoid_reentrancy_issues) and [there](https://jakearchibald.com/2024/attributes-vs-properties/), for attributes/properties where the property is of type string, or boolean, the issue of "excessive string parsing" argument doesn't hold much weight, intuitively at least, as far as using the attribute value (or lack of the presence of the attribute) as the "source of truth" for the property values.  But this argument doesn't apply to other types (numeric, dates and especially JSON/Object types).
+As has been pointed out [here](https://web.dev/articles/custom-elements-best-practices#avoid_reentrancy_issues) and [there](https://jakearchibald.com/2024/attributes-vs-properties/), for attributes/properties where the property is of type string, or boolean, the issue of "excessive string parsing" doesn't hold much weight, at least intuitively.  Using the attribute value (or lack of the presence of the attribute) as the "source of truth" for the property value doesn't involve a parsing step, only a method call.  But this argument doesn't apply to other types (numeric, dates and especially JSON/Object types).
 
-In the spirit of "the source of truth will set you free" I did a quick test of the timing difference between using attributes as the "source of truth" vs a property, focusing on the most "borderline" case -- where the property is of type number.  The results are [in line](https://github.com/bahrus/xtal-element/blob/baseline/demo/misc/numberAttribTest.html) with what I expected:
+In the spirit of "the source of truth will set you free" I did a quick test of the timing difference between using attributes as the "source of truth" vs a property, focusing first on the most "borderline" case -- where the property is of type number.  The results are [in line](https://github.com/bahrus/xtal-element/blob/baseline/demo/misc/numberAttribTest.html) with what I expected:
 
 > 149.5 milliseconds passing number prop
 > 238 milliseconds passing via attribute
@@ -57,7 +57,7 @@ The same gap is observed in all three browsers.
 
 Oops?
 
-The other factor that the latter article points out is that some attributes may be used only for configuration.  Other attributes may be used, at least after the initial hydrating handshake, primarily to "reflect state" for styling purposes (but the [newly adopted](https://caniuse.com/mdn-api_customstateset) custom state api [may perhaps](https://knowler.dev/blog/please-keep-your-hands-arms-and-legs-inside-the-custom-element) serve that purpose more effectively.)  Or [maybe not](https://www.abeautifulsite.net/posts/styling-custom-elements-without-reflecting-attributes/).  A solid use for when custom state may be preferable is provided [here](https://www.dannymoerkerke.com/blog/the-hidden-power-of-custom-states-for-web-components/) -- basically scenarios where we want to display readonly state information while keep encapsulation pristine.  Basically, for read only properties.
+The other factor that the latter article points out is that some attributes may be used only for configuration.  Other attributes may be used, at least after the initial hydrating handshake, primarily to "reflect state" for styling purposes (but the [newly adopted](https://caniuse.com/mdn-api_customstateset) custom state api [may perhaps](https://knowler.dev/blog/please-keep-your-hands-arms-and-legs-inside-the-custom-element) serve that purpose more effectively.)  Or [maybe not](https://www.abeautifulsite.net/posts/styling-custom-elements-without-reflecting-attributes/).  A solid use for when custom state may be preferable is provided [here](https://www.dannymoerkerke.com/blog/the-hidden-power-of-custom-states-for-web-components/) -- basically scenarios where we want to display readonly state information while keep encapsulation pristine.
 
 Anyway, how are the different ways attributes can be used relevant to the proposed API? How can the platform provide the most effective help for managing attributes, given the different kinds of use cases we want to support?  I think the most relevant questions for the developer are: