to note, I'm using screen size heuristics to make estimations on viewport height based on width to simplify the deisgn. This is possible a faulty heuristic and maybe would be better off using a height query rather than a width query for complete accuracy. The issue will exist in either method

another note is that the banners and navs as described are required to be static elements. Once they're displayed, you cannot scroll them away.

I have a web app design that is very vertical-space sensitive (supporting users at 1024x768 resolutions minus browser chrome), requiring two navigation elements because of certain technical reasons.

A third banner component needs to be added to the screen in certain contexts. Given this sensitivity, I'm looking to wrap the component into the top navigation as soon as horizontal space allows, as such

(I've removed identifiable elements)

Navigation at 320

At the smallest breakpoint there isn't enough horizontal space to place the banner into the top nav and we have to make do. It's ok, at these widths you're not as vertically challenged because you're likely in a portrait orientation.

At the next breakpoint it becomes possible to place the component into the top nav:

Navigation at 578

It leessens the pressure on vertical real estate because at this size you're likely into a landscape/4:3 environment and now we're pressed for vertical space.

At first glance everything seems fine. The component fits, and it's a little larger than at the 320 breakpoint.

However, the whole app is fluid and so that 320 breakpoint is also the design at 500, or at 577. In these situations the space available for the banner is far larger than it is at just a 1px increase in viewport.

for example, at 550 the banner could be 518 wide but when we increase the viewport to 600 the banner is suddenly only 328 wide.

And this becomes a challenge because the banner actually has a dynamic display and is far more usable at 550 than at 328. I'm trading off usability in one direction for usability in another.

((e: it is plenty usable at any size. but the experience as we get more space is admittedly nicer. The banner has a minimum standard for information and the result cna become compressed))

I can't be the only person to have encountered this issue (responsive nav do this sort of thing all the time but in their cases the extra width is not being utilised to the extent that the banner component here would be).

Any advice or guidance from experience or otherwise to help me out with this issue?

Do i just keep the banner underneath? Do I prevent the full banner experience at the lower breakpoint to improve the progressive expansion at a larger breakpoint? (no) Do I just accept that when trying to account for these competing sensitivities that something has to give and as long as the banner is usable then these edge cases are just a thing that happens?

Cheers for the input.

  • Generally I try not to mix width media queries with the height of the elements. Height queries for height changes and width queries for width changes.
    – Alvaro
    Commented Jan 27, 2017 at 17:41
  • So do you suggest that the best scenario here would be to determine the within-below placement on a height query and then just let the banner use whatever width it has as a result? Would that not leave me with the same issue but plenty more weird edges? Commented Jan 27, 2017 at 17:52
  • It was just a comment in case it could help. I have difficulty understanding the question, as I am not sure if you refer to width or height, if you could clarify to which of the two the numbers refer, in case others have the same problem.
    – Alvaro
    Commented Jan 27, 2017 at 17:55
  • I've edited the question to note that i'm using width as a (faulty) heuristic to estimate height, cheers. I could use height queries to see if the design would benefit from wrapping the banner into the nav but I believe the issue that concerns me would still exist. Ill definitely explore doing it that way anyway though, cheers. Commented Jan 27, 2017 at 18:04
  • A few more questions :p Which are the breakpoints and what is the size of the banner? The actual display is: 0-320 banner below; 320-? banner inside; more? "at 550 the banner could be 518 wide but when we increase the viewport to 600 the banner is suddenly only 328 wide." why is this happening? Does the banner need to have the same size always or could it have fixed proportions but scale (eg. 200*100; 500*250)?
    – Alvaro
    Commented Jan 28, 2017 at 8:59

3 Answers 3


I would recommend keeping the banner in the top bar for as long as it is usable and the user can get the full experience from it. When there are issues with the available space, move the banner below the navbar as the user will prefer to scroll down a bit than to have a considerably worsened experience just because of an unlucky display size.

You could also try to remove some less important options when there is less room, if you really don't want to move the banner below the navbar. I would suggest using the solution in the first paragraph but the decision belongs to you.


Seems like you are actually looking for "element queries", that currently don't exist, instead of media queries.

So you want to change behavior according to the actual banner width.

Recently there was a script called eqio (https://github.com/stowball/eqio) wich sets classes based on width rules you define for that element. There are other scripts emulating element queries.

As css is not capable of doing these queries, a script is a fallback solution. I am not that happy with this solution, but it's the only way to support good ux in either case.


It sounds like you may just be moving this element into the top bar at too small of a breakpoint, if the 328 space is compressing the content too much.

You may want to add a custom breakpoint that applies to this area -- a lot of people use the standard 768/1024 breakpoints, but really you can base breakpoints on any number if it does a better job of laying out the content at particular sizes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.