Skip to content
This repository has been archived by the owner on Feb 16, 2023. It is now read-only.

Require “performance” #65

Open
eeeps opened this issue Feb 14, 2018 · 1 comment
Open

Require “performance” #65

eeeps opened this issue Feb 14, 2018 · 1 comment

Comments

@eeeps
Copy link
Collaborator

eeeps commented Feb 14, 2018

Everything that I read from people who understand the mechanics of layout leads me to believe that container queries are going to be necessarily more expensive than media queries, and potentially much more expensive.

Here’s a choice example from @dbaron (emphasis mine):

If you have an algorithm that's fundamentally two-pass, then you either (1) need to re-layout everything back to the first pass state and then re-layout everything again back to the second pass state, or (2) maintain separate data structures of the first pass and second pass states. For nesting of elements that use container queries, (1) would yield an exponential cost in time and (2) would yield an exponential cost in memory usage; I don't think either is likely to be acceptable as a performance/memory characteristic of the Web platform.

We should at least mention performance in the document. However, as I said in #7, I am wary of putting any particulars on this. My feeling is, any performance requirement we include should be from users’ or authors’ perspectives, not implementers’. We should write about the consequences of performance, – rather than writing from a hardcore Computer Science perspective, with an understanding of the problem from the inside, out (as @dbaron does above).

Ideas? Volunteers?

@beep
Copy link
Collaborator

beep commented Feb 14, 2018

Thanks for writing this up, @eeeps. I don’t know quite enough about the problem space to volunteer. (But can, if someone could partner with me!)

I did want to call this out, though:

My feeling is, any performance requirement we include should be from users’ or authors’ perspectives, not implementers’. We should write about the consequences of performance

This seems like a really, really key distinction to me, and +1 to hewing to it as we work on this requirement.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants