Added limitations section first draft (#64)

* Added limitations section first draft

* Added reflow statement from @ausi

* Clarified 'seperate document' statement because of srcdoc.

* Added style inheritance statement proposed by @ausi

* Added iOS content sizing exception raised by @tomhodgins

* Re-phrasing content sizing exception

* Updated number of iframe drawbacks

* Changed to using a dl

* Clarified Fab Four technique and restructured the sentence

* Removed explicit number to avoid having to keep changing this

* Wrapped iframe wording in code tags

* Added iframe point about nested browsing contexts

* Added some clarity to the iOS safari iframe exception

* Restructured the JavaScript wording a little

* Generisized iframe autofit statement, and re-worked the requirement/example

* Fix typos and grammar from @beep

See #64 (comment)

index.bs

@@ -77,6 +77,55 @@ The module in this new sidebar context will never need to reflow to the wider la
 	<figcaption>A stylesheet heatmap showing added redundancy and rewriting of existing styles required to accommodate the layout variation in <a href="#fig-4">fig. 4</a> </figcaption>
 </figure>
 
+<h2 id="limitations-of-current-techniques">Limitations of current techniques</h2>
+
+There is currently no native CSS mechanism available to developers that achieves the primary function of container queries, which is to <em>employ the full capabilities of CSS to a specific element tree based on the state and properties of their container</em>. Therefore developers must look to workarounds to achieve their goals. These workarounds and their limitations are outlined here:
+
+<dl>
+    <dt>
+        Media Queries
+    </dt>
+    <dd>
+        The use of Media Queries can only affect CSS changes based on the state and properties of the viewport. The viewport is not a good indicator of the state and properties of a particular container within the viewport.
+    </dd>
+    <dt>
+        CSS layout methods
+    </dt>
+    <dd>
+        CSS layout methods such as <strong>Flexbox</strong> and <strong>Grid</strong>, alongside <strong>CSS-based workarounds</strong> (such as the <a href="https://medium.freecodecamp.org/the-fab-four-technique-to-create-responsive-emails-without-media-queries-baf11fdfa848">Fab Four technique</a> which uses a combination of <code>width</code>, <code>calc</code>, <code>min-width</code> and <code>max-width</code> to affect binary changes to an elements width based on the width of its parent when compared to a static value, or 'breakpoint') can only deliver a small fraction of the functionality Container Queries are intended to offer.
+        These methods cannot employ the full capabilities of CSS on an element tree. For example, they cannot affect a child element's <code>display</code> property in order to affect an new layout based on the width of a container.
+    </dd>
+    <dt>
+        <code>iframe</code>s
+    </dt>
+    <dd>
+        The use of <code>iframe</code>s produces the closest effect to what Container Queries is intended to achieve, but their use has some significant drawbacks:
+
+        <ol>
+            <li>
+                Without the use of JavaScript, some browsers require that the contents of the <code>iframe</code> are stored in a <em>separate HTML document</em> rather than being part of the current document. This necessitates a new document composition paradigm that’s very different from the methods currently employed by developers.
+            </li>
+            <li>
+                There is currently no standard, declarative way for an <code>iframe</code> to auto-size to fit its contents. A container that is the subject of a Container Query is still expected to be able to adapt to its contents in the <em>opposite</em> dimension of the query. For example, in the case of a Container Query that is based on a container's <em>width</em>, it is still expected that the container can adapt to the <em>height</em> of it's contents, subject to any overflow rules.
+            </li>
+            <li>
+                The contents of an <code>iframe</code> do not inherit any styles from their parent document, forcing the styles used by the 'module' to be redeclared.
+            </li>
+            <li>
+                <code>iframe</code>s incur additional overhead by creating additional nested browsing contexts, which can degrade performance.
+            </li>
+        </ol>
+    </dd>
+    <dt>
+        JavaScript-based solutions
+    </dt>
+    <dd>
+        JavaScript-based solutions (for example <a href="https://elementqueries.com/">EQCSS</a>) should not be considered an adequate replacement for a native CSS solution for all the same reasons any other layout- or appearance-based declarations are the domain of CSS, not JavaScript. The usual caveats of JavaScript availability and failure also apply.
+
+        JavaScript solutions also create additional network traffic, require additional parsing and perform an additional reflow after every layout that affects the matching state of a container query.
+    </dd>
+</dl>
+
 <h2 id="requirements">Requirements</h2>
 
 The use cases give rise to the following <dfn id="dfn-requirements">requirements</dfn>: