Hello and welcome to our community! Is this your first visit?
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 3 of 3
  1. #1
    Senior Coder
    Join Date
    Aug 2006
    Thanked 402 Times in 399 Posts

    Images: Lazyload, Popup, and <noscript>

    I'm looking for some feedback on design regarding non-JS-capable browsers. I have a site at French and French-Printed Banknotes, their Artists and Issuing Banks which displays lists of image thumbnails. When clicked, larger versions come up. What I'd like to be doing is:

    1. Lazy load the thumbnails since there can be a lot of them (ie, JS actually causes the load, but only if the image is "on screen")
    2. Use a lightbox for display of the larger images if the browser is big enough, but display them via a href= direct link if the browser is smaller. These are html pages of detail, not just a single larger image.
    3. Support a non-JS-enabled browser by not lazyloading (ie, just displaying all the thumbs), and no lightbox
    4. Do all this with as light a footprint as possible in terms of download and page view time

    I do this site for my own enjoyment, and while some of these goals might be extraneous, it's what I enjoy doing in my free time. Feel free to add more goals

    In any event, the current site implements 1,2 and 4, and frankly when I dropped in the lazyload code, I forgot about supporting the non-JS browser. My thought (briefly tested to make sure it can work) is this:

    - On page load, output each thumbnail as a pure html code, wrapped in a <noscript> tag
    - on document.ready, run a JS routine to remove the <noscript> wrappers, and modify the thumbnail code to insert the lazyloading tags
    - on document.resize, run a JS routine to swap between the lightbox popup and the direct link version of the larger images

    So the questions: does this design, as a solution to allow a full list or lazyloading where JS is available, sound reasonable, and is there any "breaking of rules" by using <noscript> in this way? Or do you have a different suggested solution?

    The only alternate designs I've come up with involve generating multiple versions of the html code around thumbnails (e.g. a html-only version, a lazyload version, a lightbox version, and a non-lightbox version) and then switching between them with various JS and media query flags. This just sounds very heavy to me.

  2. #2
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Keene, NH
    Thanked 529 Times in 515 Posts
    I would suggest that you first write the page with conventional paginated navigation. GOOD scripting should always -- if at all possible -- try to make a fully functional page WITHOUT JavaScript first.

    I've always found that if you do that, adding the scripting gets easier, not harder! It's less work overall as most of the grunt-work both client-side and server-side is already in place, and you just need to "tweak" it for AJAX enhancement.

    For example you could put an ID on the pagination at the bottom of the page so as to hook it with JS. You would then slide it off the left side of the screen to hide it, whilst using its position on the page as when to load the next "batch" / page worth of thumbs when scrolling. Your server side query to pull the batches would be identical either way, so the only difference is output. Rather than output markup, just output the URI's as JSON and build the new elements directly on the DOM instead of derping them in with innerHTML.

    As such you wouldn't even need them as NOSCRIPT, as you'd be progressively enhancing the page instead. I wouldn't say using NOSCRIPT would violate any rules, it just seems unnecessary. If anything it could be used to provide you with the data needed to load the additional subsections, something you can't use the pagination menu for if it doesn't even exist on the DOM (which is an issue with NOSCRIPT, it literally won't even exist for JS to see!)

    Just like how you'd handle a lightbox "properly". You mark them with a wrapping class, and hook all the anchors to load the image in your modal whilst cancelling the anchor's event.

    Progressive enhancement, it always seems to be the easiest way to implement things if you care about graceful degradation should scripting, style, or even images be missing/blocked/inapplicable to the UA in question.

    It's why my process is always:

    1) Content as plaintext or a reasonable facsimile of future content.

    2) Mark it up semantically with ZERO concern for layout or appearance.

    3) Bend that markup to my will to create the legacy desktop layout.

    4) Use media queries to handle re-arranging the layout for smaller displays.

    5) Apply colour, presentational images, and other such decorations.

    6) Enhance the page with JavaScript where and only as needed/desired, using as light a touch as possible.

    It just keeps you out of trouble, gives you a clear development roadmap to follow, and results in pages with a high degree of accessibility, usability, sustainability, maintainability, speaking well of one's abilities as a developer.

    ... and why I consider those who start out site building dicking around in photoshop or worrying about fancy scripted garbage to be totally "3i" -- ignorant, incompetent, and inept!
    Last edited by deathshadow; Sep 12th, 2019 at 10:40 PM.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture

  3. Users who have thanked deathshadow for this post:

    tracknut (Sep 12th, 2019)

  4. #3
    Senior Coder
    Join Date
    Aug 2006
    Thanked 402 Times in 399 Posts
    Thanks for the suggestions and the feedback on noscript. I will look into the idea of pagination (rather than just a long scrolling screen) for the JS-less folks, and see if I can come up with a good way to use that model. It's an interesting proposal.


Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts