Added limitations section first draft #64
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -77,6 +77,27 @@ 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: | ||
|
|
||
| The use of <strong>Media Queries</strong> 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. | ||
|
|
||
| The use of <strong>CSS layout methods</strong> 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>) cannot employ the full capabilities of CSS on an element tree. | ||
|
There was a problem hiding this comment. You should probably briefly say what the fab four technique is. like: "such as the fab four technique, which bla bla briefly bla bla" It's unlikely the reader has heard of this (I'd never heard of it)... but the reader should be able to get the basic gist of what it is, and then continue reading... with the option of clicking the link if they want more info. There was a problem hiding this comment. Ok, I’ll give it a go. I want to avoid bloat, but you’re right, it needs context. I guess I assumed the link to the technique was enough. |
||
|
|
||
| The use of <strong>iframes</strong> produces the closest effect to what Container Queries is intended to achieve, but their use has two significant drawbacks: | ||
|
There was a problem hiding this comment. The “two significant drawbacks” are now three 🤓 There was a problem hiding this comment. Doh! Of course, good spot. |
||
| <ol> | ||
| <li> | ||
| Without the use of JavaScript, some browsers require that the contents of the iframe 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> | ||
|
There was a problem hiding this comment. It also incurs the additional overhead of unnecessarily spinning up an additional nested browsing context, which can degrade performance (lots of iframes would be bad!). There was a problem hiding this comment. Ok. Someone want to come up with some wording for that for me to include? There was a problem hiding this comment. I think @marcoscaceres already nailed it. How about just,
There was a problem hiding this comment. Oops! I see you already basically did this in a009cf9 – apologies. |
||
| <li> | ||
| The contents of an iframe do not natively affect the dimensions of the iframe itself. The contents of a container that is the subject of a Container Query are still expected to be able to affect the layout of its parents in the <em>opposite</em> dimension of the query. For example, in the case of a Container Query that is based on a containers <em>width</em>, it is still expected that the container’s contents affect the <em>height</em> of a container, subject to any overflow rules. | ||
|
There was a problem hiding this comment. Despite having some security implications, iframes on mobile safari on iOS are affected by the document contained inside them. By default, the height of the iframe expands to match the height of the embedded document. There was a problem hiding this comment. ^ this was referring to this wording:
There was a problem hiding this comment. Ok, thanks. Will consider how to re-phrase that. There was a problem hiding this comment. @tomhodgins - I've re-phrased. This part of the conversation is now 'outdated'. |
||
| </li> | ||
| </ol> | ||
|
|
||
| <strong>JavaScript-based solutions</strong> (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, and the usual caveats of JavaScript availability and failure still 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. | ||
|
There was a problem hiding this comment. Please break this up into two sentences. There was a problem hiding this comment. Oh, with the javascript stuff... we should say that there are like 20 JS solutions out there - and link to the list. If you know that a solution is being used on a really popular site (i.e., one with a few million users), please say which one. There was a problem hiding this comment. First point - fair enough. Second point - can we include a list on the Wiki so I can link to it? Anyone care to make that list? @tomhodgins? There was a problem hiding this comment. Here's the list of JS solutions on the wiki https://github.com/WICG/cq-usecases/wiki/Speculative-Prolyfills As for usage, the publicwww links that @tomhodgins showed me a while back are the best window into usage that I've yet found #41. The most popular site on the three lists there (for EQCSS, cq-prolyfill, and css-element-queries) is harvard.edu, with (Alexa?) rank #702. There was a problem hiding this comment. There's also a dozen or so listed on http://whoisworkingoncontainerqueries.com |
||
|
|
||
|
|
||
| <h2 id="requirements">Requirements</h2> | ||
|
|
||
| The use cases give rise to the following <dfn id="dfn-requirements">requirements</dfn>: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this is screaming to be a bunch of list items, a definition list (with a brief name for each workaround), or even small sub sections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to highlight how ridiculously complex a media query could be, so showing one here would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First point - that’s fine, it’s just how I write. I can change that.
Second point - I thought the original work in the Use Cases section inferred that complexity.
The article by Mat Marquis does illustrate it further. Perhaps a link to that? If not, perhaps some else can find one in the wild or write one? I don’t really have the capability to to come up with a good example at the moment and I don’t want to hold things up.
Again, I’d like to avoid bloating this if possible.