aboutsummaryrefslogtreecommitdiffstats
path: root/root/articles/mmmfs/evaluation
diff options
context:
space:
mode:
authors-ol <s-ol@users.noreply.github.com>2019-12-31 17:40:54 +0000
committers-ol <s-ol@users.noreply.github.com>2019-12-31 17:42:54 +0000
commit719fe5d1a2f8b2d1e2c58b7aed18e6062656ca90 (patch)
tree04efc4064b5f696477e6a95a4b6ea154c41c2a41 /root/articles/mmmfs/evaluation
parenttable-of-contents, reference order (diff)
downloadmmm-719fe5d1a2f8b2d1e2c58b7aed18e6062656ca90.tar.gz
mmm-719fe5d1a2f8b2d1e2c58b7aed18e6062656ca90.zip
spellcheck
Diffstat (limited to 'root/articles/mmmfs/evaluation')
-rw-r--r--root/articles/mmmfs/evaluation/text$markdown+sidenotes.md10
1 files changed, 5 insertions, 5 deletions
diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
index 70b8df5..27181a8 100644
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
@@ -25,7 +25,7 @@ separately from its parent and context in most cases. This has made the implemen
than initially anticipated.
### 6.1.2 pinwall
-The pinwall example shows some strenghts of the mmmfs system pretty convincingly.
+The pinwall example shows some strengths of the mmmfs system pretty convincingly.
The type coercion layer completely abstracts away the complexities of transcluding different types of content,
and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
@@ -80,7 +80,7 @@ while others may be intrinsic limitations in the approach taken.
In the current system, there is only a single, global set of *converts* that can be potentially applied to facets
anywhere in the system.
Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
-For example if a fileder conatining multiple images wants to provide custom UI for each image when viewed independently,
+For example if a fileder containing multiple images wants to provide custom UI for each image when viewed independently,
this code has to either be attached to every image individually (and redundantly), or added as a global convert.
To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce
a new type and change the images to use it, which may present even more problems, and works against the principle of
@@ -94,7 +94,7 @@ Additionally it could be made possible to use this mechanism to locally override
further up in the tree, for example to specialize types based on their context in the system.
<mmm-embed wrap="marginnote" path="../references/alternatives-to-trees">See also </mmm-embed>
-The biggest downside to this approach would be that it presents another pressure factor for, while also reincforcing,
+The biggest downside to this approach would be that it presents another pressure factor for, while also reinforcing,
the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
### 6.2.2 code outside of the system
@@ -109,7 +109,7 @@ This weakness represents a failure to (fully) implement the quality of a "Living
*Ink and Switch*<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>.
In general however, some portion of code may always have to be left outside of the system.
-This also wouldn't necessarily represent a problem, but in this case it is particularily relevant
+This also wouldn't necessarily represent a problem, but in this case it is particularly relevant
for the global set of *converts* (see above), as well as the layout used to render the web view.
Both of these are expected to undergo changes as users adapt the system to their own content types and
domains of interest, as well as their visual identity, respectively.
@@ -148,7 +148,7 @@ viewable HTML markup, but it is hardly possible to propagate changes to the view
This particular instance of the problem might be solvable using a Rich-Text editor, but the general problem worsens when
the conversion path becomes more complex: If the markdown source was fetched via HTTP from a remote URL (e.g. if the
facet's type was `URL -> text/markdown`), it is not possible to edit the content at all, since the only data owned by
-the system is the URL string itself, which is not part of the viewable representation. Similarily, when viewing output
+the system is the URL string itself, which is not part of the viewable representation. Similarly, when viewing output
that is generated by code (e.g. `text/moonscript -> mmm/dom`), the code itself is not visible to the user, and if the
user wishes to change parts of the representation, the system is unable to relate these changes to elements of the code
or assist the user in doing so.