Rogue capital A with a circumflex accent appears

That makes sense. Sometimes it often seemed a bit petty – like I’ve noticed a number of sites I’d have expected to be booted clean off for ‘duplicate content’ aren’t being slapped down as much anymore either.

… which can often offset most anything wrong with a site… so yeah. Content of value people want can often make them put up with most anything.

In any case, just to kill some time I did a quick redesign/recode of his page to show EXACTLY what I mean on how it could be cleaned up and made more accessible for a minimum of effort. Took about 20 minutes. You guys know me and my famous rewrites.

Took a lot of liberties on the design BECAUSE it was so broken and illegible… It was also annoying the beautiful B&W picture of the bride being covered up by so much content – you couldn’t even see her face, much less most of the photo…

http://www.cutcodedown.com/for_others/zygoma/template.html

as with all my examples the directory:

http://www.cutcodedown.com/for_others/zygoma

… is wide open for easy access to the bits and pieces. Tested working perfect in the latest flavors each of Opera, Saffy, Chrome and FF, Works to a degree (loses the text-shadows) in IE9, degrades losing a lot of shading and rounded corners in IE8 and lower (OH noes, not that!), and remains usable all the way back to IE 5.5 – though I shove the minimum width at IE6/lower these days instead of wasting time on a evaluation. Would be valid XHTML strict if not for the ‘pretend’ tags google and facebook basically ‘pull out of their backsides’ for no good reason.

Semi-fluid layout for accessibility, color contrasts WELL within accessibility norms and tightened up the color spectrum to be less harsh… re-optimized all the images bringing the page size (not counting the scripts I disabled for testing) down to 145k from the original megabyte (1.3m - 300k scripts).

I also tweaked the content so that it’s not CONSTANTLY changing between first and third person, removed a good number of redundancies that served no purpose (apart from risking getting slapped down for duplicate content), tweaked up the meta tags to be a bit more useful/meaningful… and yanked the nonsensical/redundant items from the menu… and of course padded the text away from the edges of it’s boxes to also help on the legibility front.

A more complete version would have a media query for a narrow-screen stylesheet (probably only needs one), and of course a print.css as well.

Wow, amazing work, Jason.

I’m curious to know if Zygoma likes the rewrite (as far as, how it looks)?

What has been working, apparently, are these Panda tweaks they do. Plenty of complaints from site owners hit by that. Then again, I often wonder if only people who use content spinners and other garbage are the ones who pay attention to stuff like Panda updates… everyone else getting hit, has no clue what happened.

Thank you Death shadow, have a nice weekend :wink:

Ok Death shadow muy site does look totally ***** in your screen grab, th eproblem is I’d tested it in IE9 IE8 and firefox maybe i have missed something. War of words aside maybe i should download IE tester, but may i “Politely ask” waht browser & operating system are you seeing my site in, please dont flame thrower me, I’m genuinely asking a polite question and I respect your advice.

Thanks in advance,
David

I mentioned it via PM, but to further elaborate here it’s both Opera and IE7 (and 8/9 if you turn off the new behaviors) on a 120dpi system. This is most likely caused by your designing on the notion that certain elements would remain fixed in size and/or height, when your fonts are still dynamic. The entire POINT of things like the WCAG saying to use %/EM fonts is so that they auto-enlarge WITHOUT the user having to dive for the zoom on every page… so your layout needs to be flexible enough to handle that.

I think it’s why many developers stick with “just do everything in PX” along with the “crap out a fixed width” approach, is the mere notion of things automatically adjusting their size is “too hard” for them – sad since in many ways it’s EASIER because, well… Everything automatically adjusts to it’s content instead of constantly having to declare sizes on everything. It also REALLY ties your hands behind your back when it comes time to do what’s now being called “responsive design” – a new name for what was the ENTIRE POINT of HTML from the beginning - marking up content in a manner where the user agent can best adjust the content to the capabilities of the target device… In that way HTML 2 based sites were more about “responsive design” than most of what people have churned out since the PSD jockeys took over “design”.

Another of the issues – the overlapping lines – is caused by changing your font-size without redeclaring the line-height, which can result in VERY unpredictable behaviors cross-browser. Some people say you can omit the metric on the line height (line-height:1.5 for example, instead of 1.5em) and it will inherit properly, I’ve found that not to work worth spit on a boot. My rule of thumb is if you change the font size, change the line-height.

Even in Firefox (which I’m assuming is rendering right) it’s not great – on the accessibility front there are things like color contrast between text… the ochre text in the header for example is well below contrast minimums compared to the image behind it – the pattern of the image further exacerbating the issue. Same goes for the ‘redundant’ red text at the top of the content column… let’s use that one as an example.

The easiest formula for color contrasts is to convert to emissive luminance:

L= 0.3 Red + 0.59 Green + 0.11 Blue

If the luminance of two colors is less than 50% apart, there will be legibility issues for a LOT of visitors… 50% is ‘minimum’, 75% is ideal… so let’s plug in that red and the uniform grey from the bridal pic behind it.

The grey is roughly #888888 or 136,136,136 – which after the above math equals… 136. The red is #CC3333 or 204,51,51 – which is 61.2+30.09+5.61 = 96.9… divide by 2.55 to get percentage and the grey is 53.33%, the red is 38% – so that’s only 15.33% when you want at least 50% separation. For some people that text might as well be invisible. The footer uses that same red, with black text. Black is 0, so that’s only 38% which is why it too is hard to read. Even the black text on that gray is 53.33%, barely over what’s considered minimum.

In the ‘rewrite’ I did I took that same red (because it IS a nice color choice) and went with white on it (100%) for a 62% contrast… a little below the ideal, but entirely adequate. Colors when it comes to text cannot just be about what’s pretty – you HAVE to make it legible too. (something I don’t think is even covered anymore in graphic arts programs given what I’ve seen the past five or six years).

Off Topic:

… and don’t sweat things getting a little heated – It’s why I went the extra mile on that rewrite to illustrate what I’m talking about as I’d really like you to understand why I reacted as I did to it, and how to fix/improve all those things I pointed out as flaws.

Thank you, i added a £ html entity which fixed it :slight_smile:

David, you should test your site in the following, in no specific order:

  • Google Chrome[]Mozilla Firefox[]Opera[*]Safari

Then, after it works right in all of those standards-compliant browsers, take a deep breath, have a slug of tequila, and open it in IE.

You mean versions below IE 8+? Because 8 and 9 are just as standards-compliant as the others.