Added limitations section first draft

[andykirk]

As discussed in #53

+@ausi

---

Preview | Diff

[ausi]

Without the use of JavaScript, iframes require that the contents of the iframe are stored in a separate HTML document rather than being part of the current document.

Since we have the srcdoc attribute for iframes nowadays (except in IE/Edge), this point seems to no longer be 100% correct.

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?

[andykirk]

@ausi Good point. I hadn't considered that. Maybe re-phrase / clarify it for "some browsers"?

Without the use of JavaScript, iframessome browsers require that the contents of the iframe are stored in a separate HTML document rather than being part of the current document.

?

[ausi]

:+1:

[andykirk]

Amended again.

Re. style inheritance, what about:

3. The contents of an iframe do not inherit any styles from their parent document, forcing the styles used by the 'module' to be redeclared.

[andykirk]

@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.

[beep]

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.

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?

I might suggest pulling this point out into an issue, if it merits discussion and it doesn’t directly affect/block this PR.

[andykirk]

Re-phrased content sizing exception.

[andykirk]

Comments for reference:

https://github.com/WICG/cq-usecases/issues/49#issuecomment-360551606 https://github.com/WICG/cq-usecases/issues/49#issuecomment-360557485

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.

[beep]

@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!

[tomhodgins]

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 🙌

[beep]

I'm good with this PR

Marvelous, thanks. Then merge away, sir!

as long as we create that issue to figure out what kind of containment we might want to put in here.

Sounds grand. Would you mind writing up that issue, @tomhodgins?

[marcoscaceres]

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.

[andykirk]

Thanks @marcoscaceres, I’ve responded to each of your points and I’m happy to rework it. It will cause a delay though. If it were merged others could then try to tackle some of the points as separate PRs.

Cheers

[marcoscaceres]

If it were merged others could then try to tackle some of the points as separate PRs.

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.

[marcoscaceres]

(approving changes, but please fix the small things if possible :) )

[andykirk]

Thanks @marcoscaceres - will fix as much as I can. Some of the other things will require more work/discussion.

[andykirk]

Hi, sorry for the radio silence - I was struck down with the flu.

Is there anything here waiting on me? The only thing I can think of was where @beep suggests talking about the width - height thing in a seperate issue.

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.

[beep]

@andykirk, thanks for the nudge. A few tiny copyedits from me:

• “min-width adn max-width to affect” s/b “min-width and max-width to affect”
• “based on the width of it’s parent” s/b “based on the width of its parent”
• “a child elements' display property” s/b “a child element’s display property”
• “based on a containers width” s/b “based on a container’s width”
• “incur additional overheads” s/b “incur additional overhead”

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!

[andykirk]

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.

[beep]

@andykirk Hey, that sounds perfect. Thank you again!

[andykirk]

Done.

[beep]

@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.

[tomhodgins]

Yes, thank you @andykirk for being patient with all these changes :D <3

[beep]

🎉

[andykirk]

Thanks everyone 👍

[beep]

Thank you, @andykirk! And to everyone else who chimed in on this PR; I’m really excited about this.

[marcoscaceres]

Just had a read also. Looks great and reads nicely! Thanks everyone.