WICG / cq-usecases

Use cases and requirements for standardizing element queries.
Other
184 stars 24 forks source link

Require “performance” #65

Open eeeps opened 6 years ago

eeeps commented 6 years ago

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 commented 6 years ago

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.