Making a gallery what is wrong?

[JesseWillWreckYa]

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;
}

[JesseWillWreckYa]

Forgot too. How I make the hover change the image when the text or area around the image is hovered?

[Jason Knight]

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:

Code: [Select]

<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:

Code: [Select]

#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?

[JesseWillWreckYa]

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.

[GrumpyYoungMan]

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...

[Jason Knight]

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:

Code: [Select]

<div class="h1 text-red box-shadow-inset col-4-s">
doing the job of:

Code: [Select]

<h1>
Or bloated trash like:

Code: [Select]

<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:

Code: [Select]

.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)

Code: [Select]

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:

Code: [Select]

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...

Code: [Select]

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:

Code: [Select]

#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:

Code: [Select]

#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.

[Dave]

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.

[coothead]

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. 

coothead

[Dave]

Well I'll be, thanks.

[John_Betong]

...
...
...

Or bloated trash like:"tal dib bg

Code: [Select]

   <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:

Code: [Select]

.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!

Code: [Select]

defined('LOCALHOST')
?:
define('LOCALHOST', 'localhost'===$_SERVER['SERVER_NAME');

$tmp = LOCALHOST
         ? 'local.config.php'
         : 'net.config.php';

require_once $tmp;



[Jason Knight]

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:

Code: [Select]

<?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.

[JesseWillWreckYa]

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?

[Jason Knight]

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.

[Jason Knight]

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!

[JesseWillWreckYa]

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?