New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What do we want to be able to query? #43

Open
eeeps opened this Issue Jun 20, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@eeeps
Collaborator

eeeps commented Jun 20, 2017

Element width, is an obvious one.

Height, sure.

Aspect ratio? Why not! But what about arbitrary CSS properties, or, say, lines of text or number of children?

There are use cases for all of these things. What's practical to require from the start, and how should the door be kept open for queries of the future?

@Wilto

This comment has been minimized.

Show comment
Hide comment
@Wilto

Wilto Jun 20, 2017

Contributor

I think I’d want to keep this first pass focused on width/height—that way we can work out the mechanism for container queries without needing to figure out/spec a whole mess of specific features up front.

That said, we should probably get the idea of future query-able features into the use cases doc, so we don’t run the risk of locking the mechanism itself into width/height only.

Contributor

Wilto commented Jun 20, 2017

I think I’d want to keep this first pass focused on width/height—that way we can work out the mechanism for container queries without needing to figure out/spec a whole mess of specific features up front.

That said, we should probably get the idea of future query-able features into the use cases doc, so we don’t run the risk of locking the mechanism itself into width/height only.

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Jul 20, 2017

Collaborator

I've experimented with many different breakpoints, but I keep coming back to this core set of features:

  • width
  • height
  • number of characters of text
  • number of children
  • scroll position
  • aspect-ratio
  • orientation

I've implemented these features in a few different plugins so you can see how it can work and what CSS + JS are required to make it work right now in the meantime. Hopefully standardization can solidify some of these approaches into something that works!

I would also like to note - 'number of lines of text' turns out to be less useful as a responsive breakpoint in practice than it might appear at first. Even when you're dealing with numbers of lines of text in a layout, the solution often lies in knowledge of characters and/or the width of the element.

Collaborator

tomhodgins commented Jul 20, 2017

I've experimented with many different breakpoints, but I keep coming back to this core set of features:

  • width
  • height
  • number of characters of text
  • number of children
  • scroll position
  • aspect-ratio
  • orientation

I've implemented these features in a few different plugins so you can see how it can work and what CSS + JS are required to make it work right now in the meantime. Hopefully standardization can solidify some of these approaches into something that works!

I would also like to note - 'number of lines of text' turns out to be less useful as a responsive breakpoint in practice than it might appear at first. Even when you're dealing with numbers of lines of text in a layout, the solution often lies in knowledge of characters and/or the width of the element.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment