Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Advanced Search

brandon

Circle Member
  • Content Count

    2,162
  • Joined

  • Last visited

  • Days Won

    29

Posts posted by brandon


  1. Hi @AtelierDeux. The reason you're seeing raw code displayed on your site is due to inserting the code in the wrong location.

    I've updated the original post to include links that explain how to add the code. Note that you have to use both the CSS and the JavaScript together, and insert them both according to the directions. In your case, you're using per-page header code injection which may also work, but best to do as the directions say (and now link-to).


  2. Related Questions with Possible/Related Answers:

    • https://forum.squarespace.com/topic/151557-brine-productsgallery-moving-alternative-imagesthumbnails-to-the-right-of-the-main-image/#comment-332321
    • https://forum.squarespace.com/topic/8841-feature-req-product-gallery-thumbnail-layout-location/?tab=comments#comment-50080

    Other Related Questions:

    • https://forum.squarespace.com/topic/1551-moving-product-thumbnails-brine-template/?tab=comments#comment-9130
    • https://forum.squarespace.com/topic/151905-slideshow-gallery-moving-thumbnails-to-the-right-of-the-main-image/#comment-333451

    Another Possible Answer:

    • https://www.sqspthemes.com/blog/vertical-product-thumbnail-gallery

  3. I wouldn't say it's an issue with the logo. There's what's called a "race condition" (as in two JavaScript functions racing against each other) being caused between how Firefox is loading the header content and the "SyncHeader" function in the Bureau template family. Firefox is just a little slower (possibly due to flexbox-related calculations, but I'm not sure) and so the height is being calculated too soon.

    This is probably fixable by recreating the gist of the function from Squarespace's own code, then running it a little later.

    Insert the following via sitewide Header code injection:

    <script>
      // Fix header height on init. load in Firefox.
      window.Squarespace.onInitialize(Y, function() {
        document.querySelector(".nav-close-toggle-wrapper").style.height = document.querySelector(".site-page").style.marginTop = document.querySelector(".site-header").offsetHeight + "px";
      });
    </script>

    If that doesn't fix it, try this one instead of the one above:

    <script>
      // Fix header height on init. load in Firefox.
      window.addEventListener('load', function () {
        document.querySelector(".nav-close-toggle-wrapper").style.height = document.querySelector(".site-page").style.marginTop = document.querySelector(".site-header").offsetHeight + "px";
      });
    </script>

    Let me know how that works for you.

    -Brandon


  4. You may try the solution suggested here, but also consider that's not most performant way to go about it. See my response at the end of that thread, if you're interested.

    Another option is to use Fixit - Fixed Headers for Squarespace - Brine which I created.

    Besides helping with making fixed/sticky headers (and accounting for a lot of variables that most CSS-only solution do not account for), it also adds the ability to add/remove a CSS class at the scroll-distance of your choice, making it fairly easy to adjust navigation color, background color, text size, opacity, logo size (or alternate logo), etc. when scrolled.

    When simple CSS approaches work, use 'em. If they don't, you can checkout Fixit.

    -Brandon


  5. For what it's worth, for templates based on Brine , the number of concerns when creating a fixed header are much greater than is typically appreciated, and include:

    • differences between index and non-index pages
    • differences between first-child index sections with image vs without.
    • whether you have the headers set to overlap on index pages
    • what headers (top/bottom) are enabled
    • whether the screen is resized
    • whether the announcement bar is used
    • whether the announcement bar is used but then closed by user
    • whether text in the announcement bar is wrapped when screen width changes
    • whether the header covers up content when anchor links (same-page "jump" links) are used
    • whether then navigation wraps or font size changes on width change (and therefore header height changes, and therefore necessary padding)
    • whether you want the header fixed on mobile (and again, whether you also want the announcement bar fixed on mobile along with it)
    • whether you have the mobile information bar (MIB) enabled for mobile devices.
    • and more.

    A lot of these issues have been around...for years.

    If you have a very simple use case and manage to avoid all of the above (and more) concerns, basic CSS like position:fixed or position:sticky can indeed be used. For other cases, a CSS-only approach will cause some problems that you may not detect (but your users probably will). For those cases, I created Fixit - Fixed Headers for Squarespace - Brine.

    It also adds the ability to add/remove a CSS class at the scroll-distance of your choice, making it fairly easy to adjust navigation color, background color, text size, opacity, etc. when scrolled.

    Finally, note that using onScroll as proposed in the code samples above is not the most performant way to go about solving the issue. It better to also leverage requestAnimationFrame and/or setInterval when doing such things with onScroll.

    -Brandon


  6. Okay, that clarifies things. It is a common expectation to be able to see the pages you've created using Squarespace's editing UI. However, that's not how the Squarespace Dev. platform works, despite being a common misunderstanding.

    Besides the static pages you've created within /pages, you will not see a per-page representation of your site. The files you see are a templating system. The pages you have created via the Squarespace editing UI are rendered based on the .region files. The page layout you select from the page's settings panel within the Squarespace editing UI determines which .region file(s) will be used to render the page when a user arrives to it.

    Said another way, each page does not exist as an independent HTML document. Rather, it is rendered on-demand by the server, for the user, based on your template files. Changing a .region file will affect all pages that utilize it, when a page is rendered in real-time as users arrive to your site.

    When you create a new page using the Squarespace editing UI, the existence of that page is recorded as part of the database/infrastructure for your site, apart from your template files. Squarespace's servers then know to render the page based on your template files and the layout you selected for the page. Therefore, you won't see a representation of the page in the template files, but you can change the appearance and behavior of the page by altering the template files.

    To affect pages individually, you must either create individual layouts (that is, combination of .region files and layout definition within the template.conf file) or use {.equal?} predicates within the .region files in order to "target" specific pages/contexts. And even then, you will not have access to the HTML within a given Squarespace {main-content} area or block-field, and so you are still somewhat limited.


  7. Hi @LianLim.

    It's possible that something isn't working right for you, but it's also common to misunderstand how the Squarespace Dev. platform works. When you obtain the template files for a site via Git or SFTP, you will not see a representation of the pages themselves. What you get is a group of files that represent the "templating system" that determines how the pages look and behave.

    So you should not expect to see a page-by-page representation, unless you are referring specifically to the static pages feature, which can also be hard to understand in itself.

    If you can provide further clarification of what you're expecting to see, what you're trying to accomplish and what you're currently seeing, that might help provide additional insight to you. Perhaps even a screenshot of what you're seeing, file-wise.

    -Brandon


  8. Yes, @hmfedders. You could do something like this, which would hide the description in a specific gallery on every-other item:

    [data-section-id="5db2f35f9ff0e37436549a65"] .gallery-grid-item:nth-child(even) .gallery-item-description {
      display: none;
    }

    Or you could target a list of gallery items individually by using their data-slide-url attribute:

    .gallery-grid-item[data-slide-url="1m274ar58gglbeuorp6quol3tmkhel-lx99y"] .gallery-item-description {
      display: none;
    }

    Do keep in mind that in the above examples, the data-section-id and data-slide-url would need to be changed to match your website. You can obtain these attributes using your browser's developer tools/inspector.


  9.   Hi @NuprinBoy.

    You understood correctly. You can control which galleries get descriptions by sending a CSS selector to the function. In your case, try this: In the first line of code in the function replace

    addGalleryItemDescriptions();

    with:

    addGalleryItemDescriptions(".gallery-lightbox");

    If that doesn't work, provide a link to the site/page in question and I'll take a look.

    -Brandon


  10. I agree with Paul. Having said that, I once had a client that insisted against my repeated advice. I managed to convince them to only have it blink a few times and only on the home page. Something like this:

    .homepage .sqs-announcement-bar-dropzone {
      animation: flash 0.9s linear;
      animation-iteration-count: 4;
    }
    
    @keyframes flash {
      50% {opacity: 0.5;}
    }

    There may be better approaches, of course.


  11. Hi @VLabrie.

    I have implemented Flickity on multiple Squarespace websites, and it's a great library. However, it's really more of a developer's gallery tool/module than something you implement on top of a Squarespace gallery. In other words, it's its own gallery module in itself. It could be used without developer mode, but would likely be more cumbersome than would be reasonable to implement.

    For slideshow gallery blocks (and other blocks and contexts too), I created Swipeable Galleries for Squarespace. Now, to clarify, it does not alter the transition of images (as in, if your gallery fades, it will still fade...but gestures will trigger the transition) nor does it add touch/track-pad swiping (such as two-finger swipe for horizontal scroll). It focuses on touch devices (tablets, phones, most Windows-based laptops these days, etc.), and adds swipeability to those. So, it doesn't check all your boxes, but it may suffice.

    I hope that helps.

    -Brandon

×
×
  • Create New...