Added limitations section first draft #64
Conversation
index.bs
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 and require additional parsing. |
There was a problem hiding this comment.
I think we should add information about the additional reflows here too.
Somethink like: 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.
@andykirk do you want us to discuss this right here?
Or should we merge your pull request first and I create a sepearte pull request for this afterwards?
There was a problem hiding this comment.
Hi. Not sure / don't mind. Happy to discuss here as @beep suggested, but also happy with your suggested change. Maybe we can amend this PR?
There was a problem hiding this comment.
Amending seems right to me.
Can you commit my change and push it to your branch?
(As I have no push rights to your repo)
There was a problem hiding this comment.
@ausi PR amened. This part of the conversation now 'outdated'.
Since we have the Should we add that iframes are also problematic because they stop the styles from being inherited, and thus every component has to set font family/size/color again? |
|
@ausi Good point. I hadn't considered that. Maybe re-phrase / clarify it for "some browsers"? Without the use of JavaScript, ? |
|
👍 |
|
Amended again. Re. style inheritance, what about:
|
index.bs
Outdated
| @@ -88,7 +88,7 @@ The use of <strong>CSS layout methods</strong> such as <strong>Flexbox</strong> | |||
| 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: | |||
| <ol> | |||
| <li> | |||
| Without the use of JavaScript, iframes 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. | |||
| 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> | |||
| <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:
The contents of an iframe do not natively affect the dimensions of the iframe itself.
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'.
There was a problem hiding this comment.
I'm okay with the wording here since we can always edit this after pulling it in too!
My 2¢ is that “The only known exception to this at the time of writing is iOS Safari” being at the end of its paragraph makes it sound to me like iOS safari is the exception to this part: “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 opposite dimension of the query. …” except in iOS Safari?
Plus, relating to that limitation part: have we discussed and agreed on the limitation that it shouldn't be able to affect the original queried element in the same sense of the query? I saw one suggestion somewhere related to that, but I'm not sure that idea has been scrutinized by the group yet.
|
@tomhodgins you're right - I was being hasty. I can move that to where it makes more sense. I'm not sure about your 2nd point. I thought that if the contents of the 'module' do not / cannot affect the size of the container itself, we're making the whole thing a bit useless? E.g. if layout changes in response to container width - the height of the container must be able to adapt to the new content height or you'd have gaps / overflow issues? That was my understanding. |
I might suggest pulling this point out into an issue, if it merits discussion and it doesn’t directly affect/block this PR. |
|
Re-phrased content sizing exception. |
|
Comments for reference: Happy for this to be a separate issue. I don't think it blocks this PR? AS @tomhodgins say's, we can edit this post-PR. |
index.bs
Outdated
|
|
||
| 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. | ||
|
|
||
| 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.
Fixed.
|
@tomhodgins @hereinthehive, just checking: is this ready to merge? If not, are there specific items that need to be addressed by @ausi and/or @andykirk? Thanks! |
|
I'm good with this PR, as long as we create that issue to figure out what kind of containment we might want to put in here. Thanks for your writing and edits @andykirk 🙌 |
Marvelous, thanks. Then merge away, sir!
Sounds grand. Would you mind writing up that issue, @tomhodgins? |
index.bs
Outdated
|
|
||
| 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.
index.bs
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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.
- complex media queries
- Flex, Grid, and ???:
- iframes
There was a problem hiding this comment.
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.
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.
index.bs
Outdated
|
|
||
| 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. | ||
|
|
||
| The use of <strong>iframes</strong> produces the closest effect to what Container Queries is intended to achieve, but their use has three significant drawbacks: |
There was a problem hiding this comment.
nit: code instead of strong?
There was a problem hiding this comment.
I used stong as it’s like and inline heading, like the points above. I’ll swap it out as part of the change to a dl.
index.bs
Outdated
| <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,
This necessitates a new document composition paradigm that's very different from the methods currently employed by developers, and incurs the additional overhead of generating an additional nested browsing context, which degrades performance.
There was a problem hiding this comment.
Oops! I see you already basically did this in a009cf9 – apologies.
index.bs
Outdated
| 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> | ||
| <li> | ||
| In the majority of browsers, the contents of an iframe do not natively affect the dimensions of the iframe itself. The only known exception to this at the time of writing is iOS Safari. 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.
"natively affect" is unclear. Its also not clear what we mean by Safari behaving differently.
There was a problem hiding this comment.
Ok, I can expand on that. @tomhodgins do you have any resources or evidence for the Safari iOS thing?
There was a problem hiding this comment.
There isn't yet a standards-based way to declaratively tell an iframe to auto-size to fit its contents (see w3c/csswg-drafts#1771). Can we leave it at that, rather than getting into implementation-specific hacks?
There was a problem hiding this comment.
That would be my preference. @tomhodgins ? @eeeps was the intention to include the link to the draft spec you cited?
There was a problem hiding this comment.
It's been happening on iOs as long as I can remember, I looked it up the first time I saw it and found articles, but lately I can't find anything on Google - so I wrote my own test:
<meta name=viewport content="width=device-width, initial-scale=1">
<iframe></iframe>
<iframe src="http://staticresource.com/"></iframe>
<iframe src="http://eqcss.com/"></iframe>Screenshots: https://imgur.com/a/SKjp4
There was a problem hiding this comment.
I’d opt for more generic language here, personally. If only because it’s possible that if a specific (non-standard) implementation might change its behavior in the future.
There was a problem hiding this comment.
@eeeps @tomhodgins @beep - sorry, dropped out for a while.
To sum, I’m going to change this:
In the majority of browsers ... iOS Safari.
To this:
There currently is no standard, declarative way for an iframe to auto-size to fit its contents.
And leave it at that?
There was a problem hiding this comment.
@andykirk That sounds great to me.
There was a problem hiding this comment.
Ok, I updated this.
I also re-worked the example/requirements but. I know we still need to discuss that, but I think it reads better now. Happy to change back or re-work if needed.
index.bs
Outdated
| In the majority of browsers, the contents of an iframe do not natively affect the dimensions of the iframe itself. The only known exception to this at the time of writing is iOS Safari. 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. | ||
| </li> | ||
| <li> | ||
| The contents of an iframe do not inherit any styles from their parent document, forcing the styles used by the 'module' to be redeclared. |
There was a problem hiding this comment.
I guess it also builds up a whole new CSSOM in each iframe, which would be expensive too.
Has anyone been crazy enough to use this technique in practice? If so, we should list sites if we know any.
There was a problem hiding this comment.
I don’t know. Anyone?
There was a problem hiding this comment.
There was a problem hiding this comment.
Might want to ask Hugo Giraudel -> https://github.com/edenspiekermann/iframify
I believe they this solution on style guides
index.bs
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
|
Generally speaking, this is a good start, but I'd like to see it made a bit stronger before you merge it. I suggest strengthening this a little bit more and pinging @tantek to review it. If @tantek is like, "yeah, that seems seriously bad"... then we know we are onto something. @tantek might also have suggestion for how to make sure the arguments are well targeted at CSS/Browser folks. |
|
Thanks @marcoscaceres, I’ve responded to each of your points and I’m happy to rework it. Cheers |
Sure, up to you all how you want to work. Two options: keep iterating and using the Previews at the top of this pull request to share and review the changes, or merge early/often and iterate. I'm personally a fan of the former (keep hacking on a single PR), but the other way works fine too. |
|
(approving changes, but please fix the small things if possible :) ) |
|
Thanks @marcoscaceres - will fix as much as I can. Some of the other things will require more work/discussion. |
index.bs
Outdated
| @@ -106,7 +106,7 @@ There is currently no native CSS mechanism available to developers that achieves | |||
| 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> | |||
| In the majority of browsers, the contents of an <code>iframe</code> do not natively affect the dimensions of the <code>iframe</code> itself. The only known exception to this at the time of writing is iOS Safari. 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. | |||
| In the majority of browsers, the contents of an <code>iframe</code> do not natively affect the dimensions of the <code>iframe</code> itself. The only known exception to this at the time of writing is iOS Safari which sets the height of the <code>iframe</code> to the height of it's content. 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.
See my comment on the old commit here https://github.com/WICG/cq-usecases/pull/64/files/28f7e75daa6f74948281a2b4a7ad26cb578cfe35#r168499068 – I don't know if it's worth mentioning Safari's non-standard behavior.
|
Hi, sorry for the radio silence - I was struck down with the flu. Is there anything here waiting on me? To be honest, it's very difficult describing the limitations there are with existing techniques when there isn't a solid set of requirements to compare them against. Sort of chicken / egg thing. |
|
@andykirk, thanks for the nudge. A few tiny copyedits from me:
That’s all I’ve got. None of these feel like blockers to me…so unless anyone objects, I think this is ready to merge? @andykirk, thanks so much to you (and everyone else participating here) for all your hard work getting this first draft in place. It’s looking really stellar to me! |
|
Thanks @beep. Apostrophes - ugh! Good spots. I can fix these bits when I get into the office tomorrow. 8am GMT. Too fried to do it now. |
|
@andykirk Hey, that sounds perfect. Thank you again! |
|
Done. |
|
@andykirk Looks grand to me. Thank you! I’ll leave this open for a couple hours in case anyone has any final comments, but I think this is looking good to merge. Thanks again for all your hard work, Andy. This feels like an excellent first draft of the section. |
|
Yes, thank you @andykirk for being patient with all these changes :D <3 |
|
🎉 |
|
Thanks everyone 👍 |
|
Thank you, @andykirk! And to everyone else who chimed in on this PR; I’m really excited about this. |
|
Just had a read also. Looks great and reads nicely! Thanks everyone. |
As discussed in #53
+@ausi
Preview | Diff