Forum Replies Created
-
This reply has been marked as private.This reply has been marked as private.This reply has been marked as private.
Hello.
We are very close, I believe. Between 1150 and 979 px, the search icon is not there and the logo is not perfectly centered. At 979 px both of these work as expected. You can see this on the site.
Thanks again.
Hello.
Thanks again. This is very close to what we want. Unfortunately, the logo and search icon disappear between 1150px and 979px.
Thanks.
Hello,
Also, in between 1150px and 979px, Firefox displays the header far to the right, partially out of the viewable area.
Thanks again.
Hello,
This helps very much, thank you. However, between 1150 and 979 px width, while we see the mobile menu, the header does not yet appear above the slider/header background image. At 979 px and below the white header appears above the slider or header background image as expected. Is this something that can be fixed with custom CSS?
Thanks.
Hello.
This is something we would like to do. The link to the site is https://www.axiom4.com/. It looks like in order to prevent the main menu from wrapping, we’ll need the mobile menu to show up at a width of 1150 pixels.
Thanks.
in reply to: Tabs to the left of contentI went ahead and created a new support topic for this.
in reply to: Tabs to the left of contentHello. Thanks again for all your help.
Now what I’m trying to do is have the tab element display a certain tab on page load depending on the URL. So for instance, if the last tab has an anchor address of /page/#tab-1521742064890-8-2, and I put this link on another page and a user clicks that link, then when /page/ loads it will automatically show the tab #tab-1521742064890-8-2. Is there a way to do this?
Thanks again.
in reply to: Header images using absolute pathActually, the problem seems to be even worse. Setting the relative URL prefixed with “../” isn’t sufficient to stop the edit page from trying to reference 150×150 thumbnails which have absolute URLs pointing to the old staging site. In fact, when we remove the header background image URL completely, for some reason the edit page still references these thumbnails from the old staging site. It appears as though setting a new absolute path for the header background image, saving, and then setting a relative path works, but I suspect we’ll run into problems again when we go live.