Why not height?
ivansglazunov opened this issue · 20 comments
Hi @ivansglazunov, we have not found a need for height quite yet as most content on the web that extends the viewport height can just be scrolled down, but if this is an urgent requirement I can definitely get along with the idea. Would you like to submit a pull request containing your proposed feature additions? I'm sure @Jenius would accept this addition, but it's worth hearing his thoughts first.
The popular trend of the season - one idea on one screen.
Placed inside the content without scrolling. Page 1 might consist of 1-15 screens.
At the moment, I use media manually.
Perhaps it would be enough to rename between =>between-width, and create a from-height``to-height between-height to start. If it would be easier to get it in the form of a pull request, I can do it.
@ivansglazunov renaming between to between-width will break existing API, imo, not a good deal for supporting rare used feature.
I used vertical queries only once, with full-screen slides, same as your case.
this is a duplicate of #38 btw
I'm against breaking changes when they are not necessary, however, we recently changed to and from to to-width and from-width because of an issue with those words being used in gradient syntax, so I can accept this breaking change in API as being more aligned with those changes. It would be wise to listen to @Jenius' thoughts on the matter though, as this is quite an opinionated change.
Although width-based queries may be the norm, height-based ones are no less from the spec's point of view so it would be nice if this were reflected in the naming of the functions in my opinion.
I also use mainly width-based queries, but height-based ones are used for more than just slides, of course. For example, I'll be making navigation sticky when the viewport is over a certain height.
Yeah I'm conflicted here. I don't see height-based queries as being a very common request as has been mentioned, and also do not want to push a massively breaking change either. But at the same time between-widths is definitely a more accurate and descriptive way to describe what the mixin actually does than between, and as Declan mentioned is less likely to end up conflicting with some addition to css or other mixin library. And to be fair although I personally see no use for height queries, they must exist for a reason and obviously some people are interested in having them.
I think I'm swaying towards the side at the moment of saying I'm ok with switching between to between-widths. For now, we could alias between to between-widths so that we don't push a breaking change, but add a deprecation notice to it (using stylus' warn), then we can remove it in a future version down the line if needed. I think that solves everyone's issues 😀
On that last note, I've thought of a way of addressing that in #53 that won't constitute any deprecation or breaking change and would be better in the long run. The steps necessary for that would be to change all of the mixins from name to rupture-name and then alias them to their old values. Then, modify them so that they accept a type argument, and create from-height / from-width that is essentially the same as calling from(type: 'height'). If anyone encounters any issue with broken keywords or variables, they can just set rupture.no-conflict to true and then use rupture-from-height
Ok, so from would default to width, but just get an extra parameter type which could be set to height and switch it? I can get down with that.
👍
I have a use case for height as well, due to some still believing in "the fold" that I would like to squish up some designs, i.e. signup form spending on the vertical viewport.
If it helps at all, there's quite a bit of research out there that proves that "the fold" is not a thing and doesn't exist. I know how client work is and it's tough, but this one there is no question about it, and solid research and studies to back that it's not a legitimate concern.
Yup well aware of research hence my air quoting "the fold" but hierarchy simply do not get it no matter what they are presented with. :(
@ivansglazunov , are you referring to a method like this? http://jsfiddle.net/oneeezy/rrfwogxm/
That's what I got out of it when you said "one idea on one screen".
This is done with CSS "viewport" units. You can simply say...
section { height: 100vh; }
And it will fill the height of any screen size allowing you to have "15 screens" in "1 page". (assuming that's what you were referring about).
Just had a use case where I could do with height queries, so +1 to this.
There's many use cases for height queries, I've used them myself for a few different projects. One was a web application where the GUI was built up of "tiles" in a grid-system that aligned the tiles differently depending on height and width.
The latest commit was 2 years ago though, so not sure how likely this is to be solved?
Personally, I have no use whatsoever for height queries, and I don't have time to add it. However, for anyone who feels strongly about it, you are more than welcome to submit a pull request to add it! While the project hasn't needed updates in a while (media queries are media queries), I am still monitoring it and will review and ship if someone submits a good PR.
Does this mean the PostCSS port is also on ice? I was really looking forward to it as I attempt to make the pipeline a little more post processor agnostic which PostCSS seems to help with.
@custa1200 So for postcss, you can use custom media queries to pretty much cover the situation. Generally my team's philosophy is shifting more towards standards-compliant approaches over excessive syntactic sugar, for compatibility and developer accessibility reasons. We are now only using postcss, no stylus. If others are still more on the stylus/syntax sugar train, have lots of ideas for adding to rupture, and prove they can do a good job with it, I'd be glad to designate them as the new lead maintainer.
Height queries are useful for reducing overall top/bottom padding on panels, +1
As a proposal, I think we could use named parameters width and height and keep the default current behaviour untouched.
+above(1200px) // @media screen and (min-width: 1200px)
+above(height: 900px) // @media screen and (min-height: 900px)