CutCodeDown
Web Development => HTML / CSS => Topic started by: JesseWillWreckYa on 2 Aug 2020, 08:06:05 pm
-
My sister wants a image gallery on her site, thought I knew what I was doing but now I'm lost.
The gallery should have 4 images across at desktop, but they're not fitting right. The hover should also enlarge them but I can only figure out how to do it for the x axis since they're all different aspects. How do I get the bottom two to not ride up all funny and the containers to match?
I have this code:
<div id="gallery">
<div class="galleryCard">
<a href="images/gallery/test_full.png">
<img src="images/gallery/test_thumb.png" class="gelleryImage">
</a>
<p class="galleryText">
<a href="#>Some text describing the image</a>
</p>
</div>
<div class="galleryCard">
<a href="images/gallery/test_full.png">
<img src="images/gallery/test_thumb.png" class="gelleryImage">
</a>
<p class="galleryText">
<a href="#>Some text describing the image</a>
</p>
</div>
<div class="galleryCard">
<a href="images/gallery/test_full.png">
<img src="images/gallery/test_thumb.png" class="gelleryImage">
</a>
<p class="galleryText">
<a href="#>Some text describing the image</a>
</p>
</div>
</div>
and this:
.galleryCard {
float:left;
width:25%;
}
.galleryImage,
.galleryText {
margin:1em;
}
.galleryImage {
position:relative;
width:160px;
height:auto;
margin:1em;
transition:all 0.5s;
}
.galleryImage:hover {
width:200px;
left:-20px;
}
-
Forgot too. How I make the hover change the image when the text or area around the image is hovered?
-
Well, you've got three problems. One I've already explained to you in that you've got "classes for nothing" AND non-semantic markup. The other is that you're trying to work in pixels, AND trying to use positioning for what I think should be transform:scale's job. It's a newer property that I'm not too surprised you don't know yet.
First let's fix the markup. A gallery like this is a list of choices. As such it goes into a UL with LI just like how you'd write a menu. If we wrap ALL the content in an anchor we can hook that for the style and still have legacy browser support if you care,
YES, anchors around block level tags USED[/b] to be invalid. HTML 5 changed that rule. I'm not 100% kosher with that, but here it doesn't matter, you don't need block level tags inside it.
Because honestly, I doubt you have enough text for each of these to be a paragraph, and P is kind of redundant inside proper line-items in situations like this.
To that end, gut the markup down to:
<ul id="gallery">
<li>
<a href="images/gallery/test_full.jpg">
<img
src="images/gallery/test_thumb.jpg"
alt="describe this image, ALT IS NOT OPTIONAL"
>
Some text describing the image
</a>
</li><li>
<a href="images/gallery/test2_full.jpg">
<img
src="images/gallery/test2_thumb.jpg"
alt="describe this image, ALT IS NOT OPTIONAL"
>
Some text describing the image
</a>
</li><li>
<a href="images/gallery/test_full.jpg">
<img
src="images/gallery/test_thumb.jpg"
alt="describe this image, ALT IS NOT OPTIONAL"
>
Some text describing the image
</a>
</li><li>
<a href="images/gallery/test_full.jpg">
<img
src="images/gallery/test_thumb.jpg"
alt="describe this image, ALT IS NOT OPTIONAL"
>
Some text describing the image
</a>
</li><li>
<a href="images/gallery/test_full.jpg">
<img
src="images/gallery/test_thumb.jpg"
alt="describe this image, ALT IS NOT OPTIONAL"
>
Some text describing the image
</a>
</li><li>
<a href="images/gallery/test_full.jpg">
<img
src="images/gallery/test_thumb.jpg"
alt="describe this image, ALT IS NOT OPTIONAL"
>
Some text describing the image
</a>
</li>
</ul>
Note the inclusion of ALT and the removal of all the P and "classes for nothing".
To get them to have equal height so that the floats don't ride up funky, the new "flex" layout is probably a safe bet, though you could also use inline-block instead of the floats. Depends on what else you're planning for styling here. Just beware that if you go with flex, IE9 and earlier won't have columns.
Assuming a reset is in use and everything is set to box-sizing:border-box, the CSS would go something like this:
#gallery {
list-style:none;
display:flex;
flex-wrap:wrap;
justify-content:center;
max-width:48em;
margin:0 auto;
}
#gallery a {
display:block;
max-width:12em;
vertical-align:top;
padding:1em;
}
#gallery img {
display:block;
width:100%;
height:auto;
margin:0 auto 1em;
transition:transform 0.5s;
}
#gallery a:focus img,
#gallery a:hover img {
transform:scale(1.25);
}
Remember -- as I told you last week -- to set :focus in addition to :hover so that keyboard navigation isn't left out in the cold. Don't worry, you'll start remembering these little details given time.
Also notice how I converted to using EM. With box-sizing set a 12em max-width minus the 1EM internal padding gives you 10em, which at normal font-size is 160px. This makes the thumbnails dynamic so that users like myself on 4k displays can get them larger without diving for the zoom. Remember what I said? Use EM whenever you can? Well, use 'em!
To that end between dynamic scaling and high res displays, I'd probably "bite the bullet" and use 2x resolution thumbs, so 320px wide. A bit bandwidth heavy, but that could probably be helped by using JPEG or even WEBP instead of PNG. Really the best image format for each thumb in "production" should be tested with the best format chosen.
Here's a live demo I tossed together for you:
https://cutcodedown.com/for_others/JesseWillWreckYa/gallery/
The nice part of using flex here is that flex-wrap:wrap and the use of max-widths means it's already "responsive" without even resorting to media queries. Flex says that all containers inside it scale to share box-edges. With flex-wrap and a max-width on the children and a max width on the container, it will all auto-flow to fit.
And transform:scale means you don't have to play games width setting the width or positioning. The 1.25 scale for hover I came up with by just dividing the 160px you had by the 200px hover.
NOT too complicated once you gut out all the unnecessary doo-dads.
That about what you're looking for?
-
I added background-color to the <li> and it works exactly how I was thinking. Thanks.
How do you make this look so easy I even understood the code which I'm not used to without staring at it more.
-
I added background-color to the <li> and it works exactly how I was thinking. Thanks.
How do you make this look so easy I even understood the code which I'm not used to without staring at it more.
Because there is no clutter and it’s simplified — I know what you mean as even I can understand the code from this forum too...
-
How do you make this look so easy I even understood the code which I'm not used to without staring at it more.
Again something I told you and your co-workers in our zoom conference. Formatting and minimalism.
The less code you use, the less there is to break. The less code you use, the less code there is for others to digest. The less code you use, the easier it is to maintain.
Aka the opposite of modern practices and everything "hot and trendy" right now like these dumbass frameworks... where they start you out with more code than you should have before you even write a single line, to vomit up as much if not more code than you'd write without them... that on top of the underlying language you're supposed to learn ends up saddling you with even more crap on top.
Likewise I try to follow the grammatical/structural reasoning that created HTML in the first place. If you follow the intent of the language, the purpose of the tags, and leverage the meanings, you get cleaner easier to follow code.
It's why I wince when I see mind-numbingly stupid trash like:
<div class="h1 text-red box-shadow-inset col-4-s">
doing the job of:
<h1>
Or bloated trash like:
<div class="tac p42">
<fieldset class="tal dib bge">
Where christmas only knows what the blazes any of those classes are even supposed to be/do.
HTML has structural rules we're supposed to follow, but people make up lame excuses to not do so and/or are never taught them in the first place. HTML and CSS are separate for a reason which is why 100% of the time <style> is utter garbage and 99% of the time if you need style="" you're doing something wrong. Presentational tags were deprecated to simplify the markup and make us write more accessibile code, and that's why idiocy like:
<div class="text-center align-center font-size-large color-red">
Completely misses the point of HTML, CSS, and is such utter garbage the people who get wood for that type of lunacy need to admit defeat and go back to writing the HTML 3.2 they so clearly seem to miss... because that is NO different than writing:
<center><font size="3" color="red">
In terms of functionality... the VERY FLIPPING THING we were told to stop doing way the fudge back on HTML 4 Strict.
That's why making stylesheets like this:
.w3-pale-blue,.w3-hover-pale-blue:hover{color:#000!important;background-color:#ddffff!important}
.w3-text-amber,.w3-hover-text-amber:hover{color:#ffc107!important}
.w3-text-aqua,.w3-hover-text-aqua:hover{color:#00ffff!important}
.w3-text-blue,.w3-hover-text-blue:hover{color:#2196F3!important}
.w3-text-light-blue,.w3-hover-text-light-blue:hover{color:#87CEEB!important}
.w3-text-brown,.w3-hover-text-brown:hover{color:#795548!important}
.w3-text-cyan,.w3-hover-text-cyan:hover{color:#00bcd4!important}
.w3-text-blue-grey,.w3-hover-text-blue-grey:hover,.w3-text-blue-gray,.w3-hover-text-blue-gray:hover{color:#607d8b!important}
.w3-text-green,.w3-hover-text-green:hover{color:#4CAF50!important}
.w3-text-light-green,.w3-hover-text-light-green:hover{color:#8bc34a!important}
.w3-text-indigo,.w3-hover-text-indigo:hover{color:#3f51b5!important}
.w3-text-khaki,.w3-hover-text-khaki:hover{color:#b4aa50!important}
.w3-text-lime,.w3-hover-text-lime:hover{color:#cddc39!important}
.w3-text-orange,.w3-hover-text-orange:hover{color:#ff9800!important}
.w3-text-deep-orange,.w3-hover-text-deep-orange:hover{color:#ff5722!important}
.w3-text-pink,.w3-hover-text-pink:hover{color:#e91e63!important}
.w3-text-purple,.w3-hover-text-purple:hover{color:#9c27b0!important}
.w3-text-deep-purple,.w3-hover-text-deep-purple:hover{color:#673ab7!important}
.w3-text-red,.w3-hover-text-red:hover{color:#f44336!important}
.w3-text-sand,.w3-hover-text-sand:hover{color:#fdf5e6!important}
.w3-text-teal,.w3-hover-text-teal:hover{color:#009688!important}
.w3-text-yellow,.w3-hover-text-yellow:hover{color:#d2be0e!important}
.w3-text-white,.w3-hover-text-white:hover{color:#fff!important}
.w3-text-black,.w3-hover-text-black:hover{color:#000!important}
So you can crap the style into the markup is a complete failure to grasp the most basic of HTML/CSS principles, and reeks of the same broken halfwitted mindset that led to the worst code of the mid to late '90's browser wars.
The same goes for slopping the same classes onto everything. If you've got a class/id on the parent container, and every like-child of the same tag is getting the same class, NONE of them should have classes. That was a big problem with your original code is that you were putting in a bunch of classes you just don't need. There's sufficient code uniformity that adding those "classes for nothing" only makes it more confusing and harder to follow.
Hence the more minimalist approach focused on semantics and leveraging that semantics with selectors. There is a BALD FACED LIE making the rounds that such selector use is "slow" or that you should use this mind-numbingly derpy "BEM" class naming convention to make the "render" faster... where much like with the "Tables are teh evilz" whackjobs it's a BS claim... since if a 486/66 with 8 megs of RAM running IE 5 under windows 3.1 could handle it, they can have a quadruple helping of sierra tango foxtrot uniform when my flipping $80 cheap Chinese phone has four cores clocking in at 1.5ghz.
As I've said many the time the past decade, maybe if people stopped using 128k of markup to do 16k or less' job, 500k or more of CSS to do 48k or less' job, and 2 megabytes or more of JavaScript on pages that if they even warrant the PRESENCE of scripting likely don't need more than 64k of it, MAYBE these derpy concerns about "render time" wouldn't be an issue. Maybe the idiotic "pageloads are evil" that suckers people into using broken SPA's (Single Page Applications) wouldn't be a thing. MAYBE, just MAYBE if people would learn the underlying languages they'd realize that "throwing more code at it" in the form of extra tags, extra classes, and these dipshit frameworks
But note, whilst I promote minimalism, THAT DOES NOT MEAN BYTE OBSESSION!!! I cannot emphasize that enough, that they are not the same flipping thing!
Minimalism means using as few tags, classes, and id's as you can get away with, WITHOUT sacrificing code clarity or creating excess bloat elsewhere.. It does not mean bean-counting every byte, using cryptic class/id names nobody can figure out, or sacrificing whitespace... well, at least on your development copy. (and really if whitespace minification pays dividends in your HTML, something's wrong with the HTML)
Saving a few bytes is NEVER worth compromising the ability to read and maintain the code. That's the difference between minimalism and byte-obsession. (I should write a Medium article on that...)
An example of byte obsession comes from about a decade and a half ago, in the form of "holy grail layout". It was based on the idea that putting content before sidebar stuff. That's a good idea in terms of both accessibility and search. It is, not arguing that. But the "holy grail" idea was that each of the columns should only need one DIV to keep the markup small. (something we can do easily today with FLEX)
Problem was at the time people would use 1k of fragile, hack-filled CSS to avoid adding one extra <div></div> in their markup. That is DUMB. Oh noes, notz won extru DIV!!!
It's why "Holy Grail" was a really good name for it, as people became so obsessed with a single goal they never questioned the sanity of it. Just like the various fictions about the Arthurian knights, and how the quest for the Grail was actually their undoing.
If you need that extra container, or you really need that extra class, go ahead and add it. Just don't dive for it as the be-all end-all answer to every question!
That's really a problem development wide, is people choose certain programming techniques, and then like the proverbial man with a hammer assume that everything is a nail.
The only place that mentality pays off is in code formatting. The one area the code you posted is absolutely PERFECT. You put the tags on their own lines and indented them consistently. IT's the ONE place where everything actually is a nail.
Clean, clear, consistent code formatting can do more for code clarity, digestibility, and maintainability than any other factor. Consistency, more than anything else, is what's important.
There are many, MANY different code formatting styles, they're all valid so long as everyone working on a project agrees to use the same one. CONSISTENCY!!! It's only when styles get mixed-and-matched, when "style guides" are not established or followed, or when people just "make it up as they go" that problems arise.
Like I was just dealing with some PHP code that went something like this: (slightly changed to protect the guilty)
if($_SERVER['SERVER_ADDR']=='127.0.0.1'){require_once 'local.config.php';}else{require_once 'net.config.php'; }
Nothing "really" wrong with it, though a ternary operator would simplify things... but it's painful to read because they whitespace stripped it for NO good reason. All over the codebase of said system there is zero consistency of formatting or style. Much of it seems minified, some of it has endless blank lines for who knows what, it's a mess.
Just simply formatting it and adding a hair of whitespace:
if ($_SERVER['SERVER_ADDR'] == '127.0.0.1') {
require_once 'local.config.php';
} else {
require_once 'net.config.php';
}
Improves the code clarity many-fold... and if one takes the time to realize that require_once can be functionally applied...
require_once(
$_SERVER['SERVER_ADDR'] == '127.0.0.1' ?
'local.config.php' :
'net.config.php'
);
Is even clearer/simpler.
Even the best code can LOOK confusing if it's poorly formatted. That's why this:
#gallery{list-style : none; display : flex; flex-wrap : wrap; justify-content : center; max-width : 48em; margin:0 auto;}
Is hard to follow hard to understand garbage compared to:
#gallery {
list-style:none;
display:flex;
flex-wrap:wrap;
justify-content:center;
max-width:48em;
margin:0 auto;
}
A concept that seems lost on far, FAR too many developers out there.
-
Where's the thumbs up button? I too cringe when I see people trying to deal with some of the "hot and trendy" things that, as you say, come out of the box with so much gorp it's hard to see the trees. I'm a huge fan of the KISS principle and get looked at strangely all the time because of it. That's OK though, I like being strange and writing things that other people can actually understand.
-
Where's the thumbs up button?
Just below your avatar...
[applaud] [smite]
...I presume that [applaud] equates to thumbs up
and [smite] equates to thumbs down. 8)
coothead
-
Well I'll be, thanks.
-
...
...
...
Or bloated trash like:"tal dib bg
<div class="tac p42 bge">
Where Christmas only knows what the blazes any of those classes are even supposed to be/do.
That's me folks :)
The idea is I design pages in PHP and have the following Three Letter Acronyms in the CSS style sheet:
.bge {background-color: #eee;}
.dib {display: inline-block;}
.mga {margin: 0 auto;}
.tal {text-align: left;} .tar {text-align: right;}
.w88 {width: 88%; max-width: 888px;}
Using the above makes it easier to change the way tags look and feel without having to flip back and forth to the style sheet. I believe it is not very efficient and once the page looks OK then can replace the TLAs with a meaningful class name and update the style sheet. The majority of web pages I create are strictly for my benefit and not for a team. I'm a little long in the tooth to create web pages and style sheets to try and gain approval of others and not likely to change :)
With PHP driven web pages I always set a LOCALHOST constant which can be used to have a single web page that works on both locahost and the online version. This saves having two files and overwriting the wrong file!
defined('LOCALHOST')
?:
define('LOCALHOST', 'localhost'===$_SERVER['SERVER_NAME');
$tmp = LOCALHOST
? 'local.config.php'
: 'net.config.php';
require_once $tmp;
-
That's me folks :)
I didn't want to -- or mean to -- single you out. I've seen others using similar techniques and it's equally as flawed no matter how you go about it.
The idea is I design pages in PHP and have the following Three Letter Acronyms in the CSS style sheet:
PHP is not a design tool. You should be having your PHP spit out semantic markup and/or have written semantic markup SEPARATE from the PHP long before you even think about applying style to it.
You're just making yourself work harder by failing to separate your concerns, resulting in harder to follow, harder to write, harder to maintain cryptic code.
Using the above makes it easier to change the way tags look and feel without having to flip back and forth to the style sheet.
Which I think shows the flaw in your workflow. You're actually thinking of flipping back and forth, and you're ONLY thinking what it looks like.
Screens are wide now. Hence the term "widescreen". Code still tends to work best narrow. Solution to "flipping back and forth"? Put both on the screen side by side. Hence why "tabbed editors" are useless crap, as are these editors that add all sorts of "management" sidebars and other such tomfoolery.
And again "look and feel" shouldn't even be any of PHP's flipping business any more than it is the markup. Failing to separate your concerns from the start just makes your server-side code work harder.
The majority of web pages I create are strictly for my benefit and not for a team.
And that shows, but it's also a flawed attitude when you start doing rewrites and posting code online for OTHER people. Much less it means the sites you make are less than useful for visitors to your sites, THE ONLY AUDIENCE THAT MATTERS when it comes to websites.
Much like "wearing a mask", it's not about you.
With PHP driven web pages I always set a LOCALHOST constant which can be used to have a single web page that works on both locahost and the online version. This saves having two files and overwriting the wrong file!
This is why I prefer to move as much as I can out of my index.php, that way I'm not uploading it when making changes or on deployment.
For example my current approach:
<?php
/*
Paladin CMS index.php
Jason M. Knight, December 2019
ALL user requests should be routed through this file
via .htaccess or ngnix configuration
*/
include('libs/startup.lib.php');
new Director(
'mysql:dbname=paladin;host=localhost', // dsn
'xxxxx', // username
'yyyyy' // password
);
With ALL non-whitelisted requests routed through that. Gives me immediate isolation of scope, and is so simple there is no reason that I'd need to re-upload it.
My installer accepting FTP login data so it can write to the files whilst keeping them 644 locally; said installer letting you type in said data. Because the installer creates the index.php, it's not part of the distribution tree.
I'm working on a commercial version where I use Electron to build a remote installer. Sucks adding the overhead of 32+mb of runtime to the distro, but when I'm likely going to be a megabyte smaller than most CMS .rar files that's probably acceptable. Said installer will also have an "update" mode that simply refreshes the files to the latest versions that it will switch to once the databases are created.
As it is, for smaller projects I always just have deploy scripts that upload to live only what's been changed. That way rather than dicking around with a FTP client, I can just go to the command line in the project folder and type "./deploy" to upload the changes. This way I can also avoid uploading files that should not be overwritten.
Part of why I laugh at "code management" tools, they often lack basic functionality like that, and seriously we're programmers. If you can't handle tossing together a shell script once you hit proper levels of proficiency, there's something WRONG.
-
Much like "wearing a mask", it's not about you.
That is where most seem to mess up. You introduced me and mine to a different way of thinking about how we build sites as we were focusing on everything except the end user. Not our agency our staff but the people who will actually use the site daily
Thinking on how we were doing things its really strange that in making a set of websites and applications for our field offices and the public to use we didnt once take into account the people who would actually use any of it.
What did you say about happy happy fun time?
-
Thinking on how we were doing things its really strange that in making a set of websites and applications for our field offices and the public to use we didnt once take into account the people who would actually use any of it.
That's because your former boss was a bit like the fireman who went around as an expert giving lectures, considered the foremost authority on the subject, but then turned out to be a serial arsonist? He went around setting fires so he could play the hero.
But in his case, through sloppy practices, neglect of what actually needed to be done, and management not seeing the warning signs because he was so good at sucking up, things built up pressure until something had to give.
The warning signs something was awry was there, but nobody dared to point it out because of how things were being run. It's this way in most cases where dissension is stamped out, and it's not about being right, it's about winning. You see this society-wide right now where people will defend the dumbest most nonsensical things because they want to be on the winning side, not the right side. In the face of that obsession of "winning at all costs" even when wrong? Eventually everyone ends up losing.
What did you say about happy happy fun time?
I say that a lot.
"It's called work, not happy happy fun time"
Too many people treat this as a recreational sport and don't realize that if you're doing it for work, it's WORK! Treat it as such. It means you might actually have to DO some work instead of sleazing by blindly copying what everyone else has already done. It also means you might actually have to learn the basics before you're qualified to figure out if what other people have already done is worth copying. A step these "frameworks" often dupe people into skipping.
It's one of the biggest failures I see all the time is people who don't know the most basic parts of how HTML and CSS are even supposed to be used. They either make things up as they go or blindly choosing things like frameworks before they know enough to figure out which one (if any) fits the task at hand.
Sometimes you need to take a step back and slow down. People are in such a rush they'll screw themselves over today to just make more work tomorrow, then praise how "easy" that was. It establishes confirmation bias. Because they got A result, they assume it's the right result before they even know what right and wrong are. (I know i was guilty of that with HTML prior to 2004-ish). Once confirmation bias is in place it becomes very hard to accept that what "worked for you" was in fact wrong, broken, and utter trash.
... and that's when the lame excuses come rolling out, because they think "It gets the job done" when it really doesn't, and often have thought that way for so long that when things do go pear shaped they are incapable of accepting the reality of it. The literal definition of cognitive dissonance. They'll either flat out deny the facts because it contradicts what "got it done" for them for years, or twist and bend the facts to fit their narrative.
People who think that way often getting their panties in a knot when it does finally break and they're told why. See how -- again not to single out your former boss -- he utterly lost his mind over being told that the field agent reporting form couldn't be written to rely 100% on JavaScript. It was a simple rewrite, not even a
half-hour's worth of work for YOU (since you were the one who implemented the changes I laid out), but he went full on temper tantrum over the fact that we had to pitch the client-side building of "components" by React in the bin just to meet internal requirements for workplace accessibility.
But I was the one being "unreasonable."
That the page-load non-scripted version is now so fast even compared to a SPA I think speaks volumes of just how ridiculous that mess was in terms of using 80k of HTML that relied on 2.1 megabytes of Javascript (half that framework overhead) just for a 12 INPUT form. Particularly when that was in-house and the company mandates the use of Chrome, meaning the full HTML 5 validation could be used with impunity. There was nothing there to warrant the PRESENCE of JavaScript, much less a floppy and a half worth of it.
... and we were rushed. We had three weeks to get it done to avoid it going to court. Every single step at which he fought us making the needed changes -- and I mean US as he fought you and your co-workers as much as he did me -- was another day wasted with the deadline looming.
And I deal with people like that four to six times a year on contracts. There's a reason these people with bad practices, bad habits, blindly throwing frameworks together, and refusing to embrace semantics, separation of presentation from content, and so forth end up in trouble. The sad part is that no matter how much trouble they seem to be in, they cannot accept the reasons that led them there.
It's why accessibility consulting needs be inherently tied to efficiency consulting. You need to investigate and fix not only the immediate problem, but what (or who) created the problem in the first place. And if they're going to actively fight fixing said problems, cut them out like a cancer because that's all such developers really are.
-
Oh, also I think a lot of people get into programming because they view it as a "easy" job where they won't have to do "real work"
EVERY job is "real work" and if you're not doing "real work" you're not doing your flipping job!
-
Trying to make this lightbox from scratch so I know how it is done. As you said you shouldn't choose off the shelf scripts for things you don't know how to do since how do you know if they are any good?
I added classes to every anchor so I could add events, but you keep saying that none of them need classes? How do you grab onto them to apply those event handlers like you taught me if they do not have a class?
-
There are a lot of ways you can handle this if you think about the structure. For example, all the anchors you want to add your lightbox script to are inside #gallery, hence:
var
gallery = document.getElementById('gallery'),
anchors = gallery.getElementsByTagName('a');
In newer scripting -- aka if you don't care about IE 8/earlier -- you can use querySelectorAll to hook them using selectors just as you would in CSS.
var
anchors = document.querySelectorAll('#gallery a');
VERY powerful, but beware that on larger DOM targets it can be quite slow compared to getting the ID and then the anchors of that parent element.
Another approach which can be a bit of code but often runs faster is to "Walk the DOM". DOM walking is the process of grabbing a parent element and then using firstElementChild and nextElementSibling to literally "walk across" the document nodes.
If we were to walk all the LI, we know that the anchor is the LI's first-child, thus your attach could be written something like this:
var
gallery = document.getElementById('gallery'),
li = gallery.firstElementChild;
if (li) do {
li.firstElementChild.addEventListener('click', lightBoxClickEvent, false);
} while (li = li.nextElementSibling);
Where lightBoxClickEvent is your event handler callback function. Because we walk the DOM instead of gathering up all the elements first, this would actually run faster, and it uses less memory because we aren't creating Arrays or NodeLists.
"walking the DOM" is a tricky thing to understand until you understand how your HTML elements directly correspond to Node objects, and how those various Node point at each-other with firstChild, lastChild, nextSibling, previousSibling, parentNode, and the various "element" equivalents like firstElementChild and nextElementSibling. There's no such thing as parentElementNode since only elements can have child nodes. If you're in a child, its parent must be an ElementNode.
I think I was lucky as by the time I learned HTML and JavaScript, I was already familiar with pointered lists, and more specifically "tree" structures that rely on pointers. That's all those various reference properties of a Node are, pointers. They point at the element (if any) that has said relationship. Years of programming btree (binary tree) sorts made me very familiar with how that works long before JavaScript even existed.
I can't imagine how hard it is to grasp said structure without that background.
In a LOT of cases where people do complex querySelectorAll style code -- such as that encouraged by mental huffing midgetry like jQuery -- would be better served using less memory and executing faster if people would just take the DOM for a walk.
But it often seems like a lot of people talk about "DOM Manipulation" when what they are doing is nothing of the sort, and refuse to leverage the DOM in an effective manner. In fact it oft feels like there's an irrational fear of the DOM, as if she's gonna get up off the floor, rip off the leash, and start chasing you with a whip.
That was a joke.
-
Wait if querySelectorAll exists why does jQuery waste time with its dollar sign method?
Also can you explain this:
if (li) do {
li.firstElementChild.addEventListener('click', lightBoxClickEvent, false);
} while (li = li.nextElementSibling);
do, then while? I havent seen that before I thought while had to go first. Also why the if if you just got the elements.
The first code also does getElementsByClassName on the element you got by id. I thought that only worked on document. I just checked MDN as you often suggest and sure enough its a method of Node and not document. Document inherits from Node. So when you do that it is only returning the ones inside div.gallery and not all of them? Thats handy! Why do I see so much code where people do all of them off document and then loop through them looking for classes, data or checking the parent?
-
Wait if querySelectorAll exists why does jQuery waste time with its dollar sign method?
I know normally you'd expect a big long rant about how stupid jQuery is, but in this case it's not -- well, not entirely -- their fault. Simple fact is that querySelectorAll didn't exist in JavaScript when jQuery was originally created. In terms of browser support it does not exist in IE 7 or earlier, and when jQ was new, support back to at least IE6 was still considered "essential".
Sadly their use of it for EVERYTHING is part of what makes jQ such an inefficient and outdated mess. Even when new it was pretty pointless, but like a lot of things it has aged like milk. See all the things that 15 years ago REQUIRED JavaScript to be done that as of about ten years ago we could use CSS for.
Also can you explain this:
do/while is a less used but important construct to know. Well, it's less used in C syntax languages because C programmers think about almost every problem backwards.
In many languages starting the loop and then testing the condition is the norm. This is even true in assembler where it's more natural to put the test at the end of the loop, instead of pointlessly looping back to the test at the start that then on failure has to jump-out. In Wirth family languages -- Pascal, Modula, Ada -- they have the "repeat until" construct which is identical in functionality to do/while. In point of fact in older versions of said languages they had no equivalent of while {}.
Hence something like:
program testInput;
uses
crt;
var
ch : char;
begin
writeln('Press <ESC> to Exit');
repeat
ch := readkey();
until ch = #27;
end.
Being the norm for loop logic in such languages.
It can be extremely useful in cases like this where our operation to get the first element -- parent.firstElementChild -- does not match our loop to get the next element. You could write the same section as:
while (li) {
li.firstElementChild.addEventListener('click', lightBoxClickEvent, false);
li = li.nextElementSibling;
}
But it's not necessarily clearer and it can execute slower since it forces an extra return to the start of the while at the end. Whether or not it's actually slower would hinge more on how the JavaScript engine is implemented. I know some people prefer this approach, more power to them. Both are valid ways of coding it, use whichever you're more comfortable with.
Why do I see so much code where people do all of them off document and then loop through them looking for classes, data or checking the parent?
Ignorance.
As I often say, I don't meant that as an insult. Ignorant just means you don't know any better. You can fix ignorance.
In this case as JavaScript just has a LOT of functions, objects, and methods and it's hard to be sure you've learned all of them, or that you've learned to use any of them to their full potential. I still go to MDN regularly to look something up that I've forgotten the nitty gritty details of, and ended up going "huh, how about that!". This is more the case now that the ECMA is adding new stuff with such frequency, and browser makers -- or at least Quantum and Blink -- are keeping up with implementation.
This is often worse in languages that have truly massive function/object libraries like PHP. So often you'll see people brute force code things that PHP already has functions/methods to handle. It's not because these programmers are stupid, it's because they don't know everything PHP basically hands you on a silver plate.
A situation only exacerbated by the fact that so many developers learn by blind copypasta without comprehension. This is because so many people will hand you a snippet, then NOT explain it.
Part of why I put so much effort into my code breakdowns and explanations. Might make a few half-tweet TLDR mouth-breathers scream "AAAH WALL OF TEXT", but in my view you get no points for half-answers.
-
(https://pbs.twimg.com/media/EDeA12uUwAICB3o.png)
https://images.app.goo.gl/RsBSmK1KE4MhQLpF8 (https://images.app.goo.gl/RsBSmK1KE4MhQLpF8)
-
https://images.app.goo.gl/RsBSmK1KE4MhQLpF8 (https://images.app.goo.gl/RsBSmK1KE4MhQLpF8)
Which is actually a really good point! It's about knowing when it's the right tool for the job and when it's not.
If the condition could be fatal, it's the wrong tool... If you KNOW the first case is always true (because you just set it up) do/while is the correct one to use, or if the first condition differs from later ones. But if an initial test is the same as the loop test, and it's possible the loop will not -- or more importantly should not -- be run, then hell yes, use conventional while () {}.
For example:
var
anchors = document.getElementsByTagName('a'),
i = 0;
while (a = anchors[i++]) {
a.addEventListener('click', clickOverride, false);
}
Would be a good approach if "for" didn't exist. (again, this is just an example, not something you'd do real world".
But let's say you have a database result in PHP where if there are results you want to loop them out into a table. A lot of people would write that as:
$stmt = $db->query('
SELECT *
FROM users
');
if ($stmt->rowCount()) {
echo '
<tr>';
while ($row = $stmt->fetch() {
foreach ($row as $data) echo '
<td>', $data, '</td>';
}
echo '
</tr>';
}
But what if you could eliminate the rowcount function? Well, you can!
$stmt = $db->query('
SELECT *
FROM users
');
if ($row = $stmt->fetch()) {
echo '
<tr>';
do {
foreach ($row as $data) echo '
<td>', $data, '</td>';
} while ($row = $stmt->fetch());
echo '
</tr>';
}
Which is how a "Wirth" programmer used to "repeat/until" would think of solving that problem. It's often handy in cases where things like rowcount doesn't even work -- Oracle for example -- to be able to sample if there are results or not. One of the easiest of which being to simply pull the first result to see if it fails.
It's also handy if the first row is in the type of data where you know the first one needs to be output differently. Sometimes you need that first row before what's done inside the loop.
The key in all such cases being that you still have a safety "if' at the start, neatly avoiding "Coyote Logic".
But another example, take working with CSV where the first row is the column names.
if (($handle = fopen('test.csv', 'r')) !== FALSE) {
$dataRowCount = 0;
if ($row = fgetcsv($handle)) {
$columns = count($row);
echo '
<table id="test">
<caption>Test Data</caption>
<thead>
<tr>';
foreach ($row as $data) echo '
<th scope="col">', $data, '</th>';
echo '
</tr>
</thead><tbody>'
while ($row = fgetcsv($handle)) {
echo '
<tr>';
$i = 0;
$count = count($row);
if ($count > 0) {
echo '
<th scope="row"', (
$count == 1 ? ' colspan="' . $count . '"'
), '>', $row[$i++], '</th>';
while ($i < $count) echo '
<td>', $row[$i++], '</td>'
$dataRowCount++;
} else echo '
<td colspan="', $columns, '" class="error">No Data</td>';
echo '
<tr>';
} // while fgetcsv
echo '
</tbody><tfoot>
<tr>
<td colspan="', $columns, '">', $dataRowCount, '</td>
</tr>
</tfoot>
</table>';
} else echo '
<p class="error">No Records Found in test.csv</p>';
} else echo '
<p class="error">Unable to open test.csv</p>';
Whilst it doesn't use do/while, it does do the "fetch to test THEN loop" approach.
Not that in production I'd mix template with logic like that. Also warning, drive-by, may have typos
The big advantage of "test by fetch" being that you don't have to incorporate extra crap INSIDE the loop. A lot of people would use the row count and test for zero to determine if a TH or TD should be used. That makes your loops slower.