Can someone take a look at this page and let me know why it doesn’t work properly in IE7? It works fine in all other browser. The layout is fine however the images should be clickablle and and they are not. They are clickable in every other browser
http://waldrondigitaldesigns.com/gallery.html
Thanks
Bryan
Seeing no difference in IE7 here, though I’m not sure I’m seeing it properly as the layouts all screwy across all browsers and there are lots of accessibility issues – like the illegible color contrasts on the text.
Though if I were to take a guess, I’d suspect the jquery for nothing as the most likely cause of the problems. That over two thirds of the DIV in your markup probably belong in the trash, you’ve got clearing div when you don’t even seem to have enough floats to need clearing, separate anchors on elements that should probably be single anchors, and a needlessly complex CSS on a relatively simple layout are likely amongst your issues.
Gimme a few minutes and I’ll toss together a rewrite to show you what I mean.
Markup of a rewrite complete – should be within 5% of what it needs to do the layout/CSS. I’m out the door in a minute or two, but when I get back I’ll belt out the CSS I’d use with that and toss it up live on my server so you can see how I’d handle that…
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
lang="en"
xml:lang="en"
><head>
<meta
http-equiv="Content-Type"
content="text/html; charset=utf-8"
/>
<meta
http-equiv="Content-Language"
content="en"
/>
<link
type="text/css"
rel="stylesheet"
href="screen.css"
media="screen,projection,tv"
/>
<link
rel="shortcut icon"
href="images/camera.ico"
/>
<title>
Maki Photography
</title>
</head><body>
<div id="pageWrapper">
<h1>
<a href="index.html">
Maki Photography
</a>
</h1>
<ul id="mainMenu">
<li><a href="about.html">about us</a></li>
<li class="logoGap"><a href="gallery.html">gallery</a></li>
<li><a href="pricing.html">pricing</a></li>
<li><a href="contact.html">contact us</a></li>
</ul>
<hr />
<h2>Gallery</h2>
<ul id="gallery">
<li class="engagement">
<a
href="engagements.html"
style="background-image:url(images/engagement2-small.jpg);"
>
<img
src="Images/engagement-small.jpg"
alt="Couple getting engaged"
/>
Engagement Photos
</a>
</li>
<li class="weddings">
<a
href="weddings.html"
style="background-image:url(images/wedding2-small.jpg"
>
<img
src="Images/wedding-small.jpg"
alt="Couple at wedding"
/>
wedding photos
</a>
</li>
<li class="family">
<a
href="family.html"
style="background-image:url(images/family2-small.jpg)"
>
<img
src="Images/family-small.jpg"
alt="Young girl Posing for Family Photo"
/>
family photos
</a>
</li>
<li class="seniors">
<a
href="senior.html"
style="background:url(images/senior2-small.jpg);"
>
<img
src="Images/senior-small.jpg"
alt="Young Woman Posing for Yearbook Photo"
/>
senior portraits
</a>
</li>
<li class="corporate">
<a
href="corporate.html"
style="background: url(Images/corporate2-small.jpg);"
>
<img
src="Images/corporate-small.jpg"
alt="Employees in Company Dresswear"
/>
corporate photos
</a>
</li>
</ul>
<hr />
<div id="footer">
<a href="" class="facebook">
<img
src="Images/facebook.png"
alt="facebook"
/>
Find us on Facebook!
</a>
Maki Photography, LLC
Hershey • Pennsylvania<br />
Call to Schedule! 717.534.1352<br />
Email:
<a href="mailto:info@makiphotography.net">
info@makiphotography.net
</a>
<ul>
<li><a href="index.html">home</a></li>
<li><a href="about.html">about us</a></li>
<li><a href="gallery.html">gallery</a></li>
<li><a href="pricing.html">pricing</a></li>
<li><a href="contact.html">contact us</a></li>
</ul>
<div>
© 2012; Maki Photography, LLC •
Site created by
<a href="http://www.facebook.com/waldron.digital.designs">
Waldron Digital Designs
</a>
</div>
<!-- #footer --></div>
<!-- #pageWrapper --></div>
</body></html>
Which is basically half the code, and will likely not be wasting time with any jquery. I’ll retain the fades, but they won’t work in IE… No matter how pretty those transitions are, they cause endless headaches when done via javascript – as evidenced by the jquery bloat adding 100k to your page and the problems in legacy IE.
jQuery – 4k of solving cross browser issues, 88k of stupid animated crap that has no business being done from javascript in the first place.
WOW! Thanks a lot. That is a big help to someone who is still learning. Much appreciated.
I need to get out of putting divs around everything. Most of them are probably not needed.
Took me longer than planned because apparently another server in the data center I’m hosted on went rogue and was hogging the pipe…
In any case, here’s what I came up with:
http://www.cutcodedown.com/for_others/waldo567/template.html
as with all my examples the directory:
http://www.cutcodedown.com/for_others/waldo567/
is wide open for easy access to it’s bits and pieces. I’ll start in on a breakdown of the how/where/why of the HTML, then I’ll do the same for the CSS. Valid XHTML 1.0 Strict, has the transitions on hover in modern browsers (don’t work in IE, not a big deal IMHO and better than blowing 100k on it), tested working in pretty much everything that matters. Also re-encoded a couple of the image files while trying to get things a bit more semantic/meaningful, dropping the sizes a wee bit along the way… bringing it in at 191k in 19 files instead of the 306k in 21 files you were trying to use.
I darkened a lot of the font colors to bring it into compliance with accessibility guidelines like the WCAG – they were too bright to be on a white background and as such were hard to read; for some people the orange you had on white would be effectively invisible. There’s a formula:
Luminance = 0.3 red + 0.59 green + 0.11 blue
If your background color and text color when run through that are more than 50% apart, (since we’re talking 0…255 that’s 128=50%) it’s illegible. Ideally you want around 75%, but anything over 50% is ‘acceptable’. Even when being creative, it often comes down to the math.
Ok, let’s talk about the markup changes I did.
First up you’ll notice I wrote it as XHTML 1.0 Strict; you were using XHTML which is good – means XML data scrapers have an easier time of going through the page and gives you better structural rules to make writing and maintaining the page simpler… but Transitional means “in transition from 1997 to 1998” – meaning it allows you to use decade out of date coding practices and elements that were dropped for being bad from an accessibility standpoint… STRICT is the most modern current recommendation; HTML 5 is nowhere near ready for real world use and offers no real improvements, and it’s still in Draft, so stick with what works.
You’ll notice I have a lot of extra tabs and linefeeds in there - just makes it clearer what’s going on instead of dumping all the important stuff onto single lines where you cant figure out where anything begins or ends – at the same time you’ll notice I stuff <html><head>, </head><body> and </body></html> onto the same lines – these should be present in every document so there’s not really a point to giving them more formatting, and putting them together helps as a gentle reminder that NOTHING should EVER go between them… You’ll see people putting stuff between them all the time, so anything to remind us “don’t do that” has to be a good thing.
You’ll notice I keep the stylesheet as a single file – in most cases multiple files take longer to load; it’s called handshaking, so any time you have files separated for things like stylesheets or hover state images, it’s better to get them combined down as single files. You’ll also notice the use of a MEDIA attribute – a screen layout probably won’t make a whole lot of sense when printed or for handhelds, so let’s say “this is for screen” in as clear a manner as we can. “projection” and “tv” are for things like internet kiosks, Opera in fullscreen operation (goes to projection instead of screen, nobody knows why), or devices like the Wii browser or old webTV boxes (that there ARE still people using!)
On the “shortcut icon” link notice I pulled the type – for some reason Opera and IE can both fail to see the icon with that present; your camera.ico was 404, so I just pulled one out of my stock icon directory to verify it was working.
Getting down to BODY, first up we have DIV#pageWrapper. You had “container” which is a pretty generic name and really doesn’t say what it’s containing or which container it is… I’m not a big fan of generic/vague names on things, and pageWrapper says what it does, wraps most if not all the page content.
You weren’t really doing anything that needed most of those extra DIV, hence the h1. It got a bit of a rewrite since my above post:
<h1>
<a href="index.html">
Maki
<span>Photography</span>
<b></b>
</a>
</h1>
The nested span is to split “photography” onto it’s own line and to allow us to target it for styling when images are disabled, without changing how it works on non-screen.css clients. Designing websites is NOT just about making pages for desktop screens – screen readers, search engines, and users on low bandwidth who disable things like CSS, images and javascript also need to be addressed… if you use a browser like opera and disable the CSS (view -> style -> user mode; “author mode” will return you to normal operation) you’ll see that the semantic markup makes a useable, if a bit plain a page; in a lot of ways that’s what search engines and screen readers will ‘see’.
The empty bold tag is a “image sandbag”. The image replacement method you were using of the massive negative text-indent is useless for images off users; who are exactly for whom such methods are for. I absolute position this over the h1 to hide the text with the logo image; images off user gets styled text. Images on they get the logo.
ul#mainMenu is of course the menu. I retained the ‘gap’ class as that made a good deal of sense, but again it really doesn’t need any extra wrappers as you weren’t doing anything that needed them or that couldn’t have been applied directly to the UL.
You’ll see a couple horizontal rules – I use those for non-screen.css users to indicate the end of sections and further divide the content semantically. For screen.css we’ll just hide those.
The content div really wasn’t doing anything, so I got rid of it. Some of your subpages may actually need a wrapper, so that’s up to you as to if to add it back in or not. For now, keep it simple, don’t need it…
ul#gallery – I took your image/link sections and combined them into a single list instead of the two lists and multiple unrelated DIV. A big problem with having them broken apart like you had it is there’s no ‘relationship’ between the images and their text… and each of them was two anchors doing the job of one.
You’ll notice I moved the background images to the anchors – this makes it easier to do the ‘fade’ effect using CSS3. Normally I frown on inlining CSS with the STYLE attribute, but in this case I think they’re as much content as anything else – it’s one of the few cases where I’d say “yeah, that’s fine” on that; alongside special situations like using width on a nested pair of span to make a bar-chart… in that case WIDTH is content. Good rule of thumb though is that if you have to use STYLE, you’re probably doing it wrong… but like any rule of thumb exceptions abound.
I put classes on the LI though we likely don’t really need them. No harm no foul as they’re all at least unique.
#footer I also cut way down. The facebook anchor I ended up changing also from my original post:
<a href="#" class="facebook">
Find us on <span>Facebook!</span>
</a>
Span as before is to force a newline. Putting the text in the link instead of an IMG tag gives non-image users a bit more meaningful a page.
Most of the text in there is not a coherent run of one or more sentences, so I really don’t consider them to GRAMATICALLY be paragraphs. Typographically you might use a paragraph sign to indicate the break, but typography is presentation; HTML is not – HTML is about saying what it is, not what it looks like.
Because it’s the only list inside #footer, I saw no real reason to give the bottom menu a class or ID. Don’t need it. Likewise the bottom centered part is the only centered flow text, so it’s DIV being all alone doesn’t need a class or ID either – we can use the parent #footer to nab both of those.
Close out the footer and pagewrapper, and we’re done.
Notice my comment placement – I put them before/inside the closing tag because older versions of IE and FF can both have oddball rendering errors if comments end up between sibling-level floats, margined elements, inline-block elements, and a host of other complex positionings. These bugs can make content just dissappear, it can make content render twice slightly offset over itself – and when it happens you would never think an element that’s supposed to be ignored would be at fault… Moving it before the close prevents it from ever being between ‘sibling elements’ so you never have to worry about those bugs cropping up.
… and it’s just nice to see what it is that’s being closed when you’re scrolled down to the bottom.
Ok, that’s it for the HTML. I’m out the door for a while again, but when I get a chance I’ll try and put together a similar breakdown of the CSS.
Again. Great job. A well learned lesson that I will certainly put to good use. Thank you for taking the time out to help me in such an impressive manner.
What should I do about the transition in IE? Do they need to be done using javascript seeing as how IE doesn’t support transition right now?
Alright, let’s talk CSS.
I start all my stylesheets with a reset – you had the reset as a separate file, generally a good reset should be small enough there’s no reason to do that, and one less handshake can be anywhere from 200ms to a full two seconds speed up in page load time.
The reset I use is an ACTUAL reset, as in it sets the values I need consistent across all browsers that actually don’t start out the same way. There are larger resets like Meyer’s “reset reloaded” – the one you were using… but it wastes time setting values we’re probably just going to change anyways… it’s a massive bloated mess that is more framework than reset; and CSS frameworks are ALWAYS bad news… Meyers reset only got worse with the introduction of HTML 5. when you’re up to 1.11k of CSS before you even start your own styles, that’s going a bit far.
There are smaller resets than the one I use, most notably the ‘universal reset’ of * { padding:0; margin:0; } but that can cause headaches cross browser because it nabs EVERY tag, and for some tags like INPUT, SELECT and TEXTAREA that can actually make things worse.
The one I use is in the middle – a conservative quarter of a kilobyte, resetting just what I need reset.
… and we’re moving.
hr – as mentioned I just hide these for screen.css users. They are in there for non CSS users and to semantically break up the page. The second one in the markup before FOOTER in particular – if that wasn’t there the ‘footer’ would still be part of the h2 preceding it ‘structurally’.
body – I threw in the IE 5.5 centering fix just because most of your content was centered anyways and it’s only one tiny line. While IE5 shouldn’t matter anymore, you have to remember that on windows mobile devices IE6 is a new thing as of just four years ago… and IE6 remains what’s on the majority of Windows Mobile devices because there is no IE7 or later for them. What, you missed the “Six on Six” party M$ threw? That’s ok, so did everyone else… and they wonder why they can’t make headway in the mobile space.
I set the fonts sizes in % so they auto-enlarge for large font users like myself – all ‘content’ area fonts should whenever possible be based off the browser default size and not be declared in PX. In some places PX is what you have to do; your menu for example if allowed to auto-enlarge or auto-shrink would result in a broken layout… Setting a % on body and using that size and face on the majority of your content is usually your best bet, and then change that only in the handful of spots you ‘need’ px or different sizes.
… and of course no surprises from the body background… though notice on both font and background I’m using the ‘condensed’ properties. Cleaner, clearer, and less code.
#pageWrapper – width, centering, and a bit of top padding. Nothing fancy. Normally I would advise against building a page with a fixed width like that as it’s bad for accessibility, but your menu design and placement of the gallery stuff isn’t ‘viable’ for a fluid or semi-fluid layout. Media queries and changing the layout for different sizes remains an option though.
h1 – the position:relative is so I can absolute position the empty bold tag inside this for the image replacement. Fixed width, height and centering, with an overflow to ‘chop off’ the bold tag for when we move it on hover.
The negative bottom margin makes the menu ‘ride up’ over the h1.
The font size is for the first word… bringing us to:
h1 a – the display:block is to let us add padding if desired, not entirely necessary but nice to have. Turn off the underlines, set the color.
h1 a span – on this one the display:block makes the second word go to it’s own line. Change the font size,
You’ll notice we’re using PX fonts here – we have to due to the image being placed over them. %/em would auto-enlarge and therein possibly try to bust out of our container… px is usually bad from an accessibility standpoint, but thankfully in this case our smallest text is 22px, and it’s unlikely anyone is going to complain about that being ‘too small’.
Put it all together, and images off you still get a formatted text similar to your image!
h1 a:active span,
h1 a:focus span,
h1 a:hover span - and we can even replicate the hover state.
h1 a b – our image replacement sandbag. We absolute position it over the text hiding it. I set the height double high, so that we can use one image instead of two for that hover. This means a smaller single file (since they can share a palette and like mass-compression values)… so when we get to:
h1 a:active b,
h1 a:focus b,
h1 a:hover b – all we have to do is slide these up. The overflow chops off the difference. We could also slide the background, but for some reason that takes a bit longer to render, and since we’re already absolute positioned, it’s really splitting hairs as to how you move that image.
#mainMenu – turn off bullets, fix the height really tall to make sure our content is pushed down past the menu and the h1.
#mainMenu li – display:inline prevents IE7 from weirding out and ‘staircasing’ our anchors… and means we can use text-align:center on them instead of playing with floats and measured widths on everything. Wee bit of extra padding on them just spaced them apart a bit more.
#mainMenu a – inline-block allows us to set top/bottom paddings if needed, and makes it a predictable ‘block’ for showing the camera image. Again these are PX because of the fixed width, where auto-enlargement would break the layout. I put a more complete font-family stack in place as that’s just good practice, and you’ll notice that in addition to the darker (and more legible) color I attach the image BEFORE it’s hovered. This loads it ahead of time so there’s no delay the first time someone mouse-over’s it. Sliding it 99em out of the way hides it neatly until needed.
#mainMenu .logoGap a – you know what this does; margin to make room for the h1.
#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover – change the color and slide the background into place. Pretty simple.
h2 – padding, font, color. This gets a percentage font size so it’s twice the size of what we declared on body, which of course is the browser default size. That way on machines like mine all the content h2’s blow up 25% larger so I can read them.
#gallery – kill the bullets, set the special font. I use the full condensed property just because when you change face or size it’s more predictable if you change line-height – and by the time I say line-height and font-family, I could just say font with normal and the sizes.
#gallery li – display:inline means they’ll auto-center and again removes a slew of IE7 headaches.
#gallery a – inline-block lets us set a width, I made it 2px wider than the image to make room for that border on them. This means the background-image needs to be slid over. We can’t use the shorthand ‘background’ in the HTML or the CSS here because they’ll override each-other, and not in a consistent manner cross-browser.
#gallery a,
#footer a – these share color and:
#gallery a:active,
#gallery a:focus,
#gallery a:hover,
#footer a:active,
#footer a:focus,
#footer a:hover – hover effects, so I target them all at once.
#gallery img – the border and our CSS3 transitions. Even with the mess of browser specific prefixes this is still WAY nicer than trying to use jquery to do it. Transitions don’t work in IE9/lower, but I don’t consider that a real deal-breaker as the hover effect will still work, it just won’t have the fade. Oh noes, not that 
#gallery a:active img,
#gallery a:focus img,
#gallery a:hover img – and of course the change to the image on hover… we just set it’s opacity to invisible. The ease-in-out CSS3 transition handles the rest.
#footer - we didn’t use any floats, so no clearing needed. The text-align lets us have our first bit of text on the left, some simple padding to make it pretty, font setting again in %, I went with 85% because it’s a sans-font and you can go a wee bit smaller with that than you can serif fonts. Color, border… simple.
#footer .facebook – float it right, pad it pretty and a bit of top/bottom padding to make room for the image. I put just the logo in as a background, and then retain the text setting it in PX (again due to the image interaction). Means smaller image and better images-off or CSS off functionality. We have two lines at 16px line height for 32px total, then the 2px top and bottom paddings add up to 36px, the size of that image.
#footer .facebook span – display:block moves the word ‘facebook!’ to a new line.
#footer .facebook:active,
#footer .facebook:focus,
#footer .facebook:hover – I use opacity here to give it a hover effect. The text ended up a bit too light so I just darken the color a hair which then gets lightened by the opacity setting along with the background image.
#footer ul – with that .facebook floated before it, NOW we should have a clear. Better safe than sorry. Kill the bullets, pad it, and center it.
#footer li put them all on one line.
#footer ul a as before inline-block so we can set dimensions if desired… the rest of our values get inherited off #footer a.
#footer div – the final bit of text just gets centered.
… and that’s it.
I know that’s a lot to take in all at once, but I hope this helps. Any questions fire away.
I wouldn’t bother – it’s a lot of code for little if any return. Honestly, I’d probably not even have the transition to another image in any browser, and instead just do something like make them appear to highlight by giving them opacity. It’s a simpler/faster effect, still gives user interaction, and is even less code, and would mean five less images on the page.
A lot of ‘cute’ stuff like those types of fade effects are as likely to drive users away as to make people go “wow, neat”. Wow lasts five seconds, bounce because the user wasn’t willing to wait for the page to load lasts a lifetime. A lot of cutesy animations fall squarely into the latter category.
Though it most certainly could be done with a script… I’d suggest writing one or having one written that does NOT rely on some massive nonsensical library to function if you REALLY want that. jquery – just say no.
[ot]
This is your site:
This is your site on jQuery:
Any questions?[/ot]
Good point seeing as how the whole idea is to get users to stay on the site and convert into a potential customer. Once I have had a chance to digest the information I am going to get work on reducing all the garbage on the rest of the site.